• Share on Google+

Software wird meistens für die Lösung einer bestimmten Aufgabe geschrieben. Mit jedem Entwicklungsschritt löst sie diese Aufgabe besser. Die Wünsche des Users werden immer besser verstanden. Der User wird von Mal zu Mal zufriedener, weil alles besser von der Hand geht.

Ein schönes Märchen, das leider nie wahr werden wird.

Ich greife einfach mal einen Bereich heraus, mit dem ich viel zu tun habe: Content-Management-Systeme. Diese sind seit Ihren Anfängen immer komplexer geworden und erfüllen immer mehr Anforderungen. Leider kann ich nicht sehen, dass die Anwender im selben Maße zufriedener geworden wären, wie die Software komplexer wurde.
Und selbstverständlich sind sie selbst schuld daran, denn an der Software wird es ja wohl kaum liegen – oder?

Ein konkretes Beispiel soll das Rechtemanagement in TYPO3 liefern: Ganz zu Beginn war TYPO3 ein CMS, um einfach aufgebaute Webseiten ins Netz zu stellen. So konnte ein Redakteur auch ohne technische Vorkenntnisse und mit einer kurzen Einarbeitung Texte im Internet veröffentlichen. Ja, so war das mal, auch wenn es heute kaum noch jemand glauben mag.

Recht haben und Recht bekommen

Die Webseiten wurden komplexer. Auch die CMS wurden komplexer. Es gab nicht mehr nur einen Redakteur, sondern viele Leute, die an ein und derselben Website arbeiteten. Ein Rechtemanagement musste her.

Sowas fängt immer harmlos an. Sicherlich ist es sinnvoll, mehreren Usern den Zugriff auf ein System zu erlauben. Mit unterschiedlichen Accounts, mit unterschiedlichen Rechten. Aber wie unterschiedlich müssen diese Rechte wirklich sein? Dies ist der eigentliche Knackpunkt.

Mit dem Rechtemanagement in vielen CMS (z.B. TYPO3)  können wir wirklich bis auf den letzten i-Punkt alles genau kontrollieren. Die Frage, die ich mir nur oft stelle, ist: Brauchen wir das? Oder wollen wir das, nur weil es geht?

Kontrolle über andere zu haben, scheint manche Menschen zu faszinieren. Und die Vorstellung, alles bis ins kleinste Detail unter Kontrolle zu haben, kommt gerade bei größeren Firmen sehr gut an. Hier wird gern ein wenig übertrieben und dem Affen Zucker gegeben. Am liebsten möchte man die ganze Firmenhierarchie mit dem System darstellen. Zwar wird es dadurch unbedienbar, aber sicher ist sicher. Und schließlich arbeiten diejenigen, die diese Featuritis beschließen, ja nicht mit dem System. So what?

Die bittersüße Wahrheit ist ja: Am Ende arbeiten auch bei großen Seiten nur eine Handvoll Leute mit dem System, die zudem alle sehr ähnliche Rechte besitzen. Von Hierarchie kann da oftmals gar keine Rede sein. Wozu also der Aufwand, die ganze betriebswirtschaftliche Organisationsstruktur mit all ihren Rechten und Restriktionen auf die Software zu übertragen? Aus Notwendigkeit? Nein, weil man’s eben kann!

Auch der ewige Wunsch, den Workflow abzubilden, steht oft einer praktikablen Lösung im Wege. Muss ich denn alle Rechte und Abhängigkeiten, die eine Arbeit mit sich bringt, im System abbilden und damit die Menschen, die mit dem System arbeiten, entmündigen? Wissen die Menschen nicht auch so, was sie zu tun und zu lassen haben?
Wie war dies denn vor der Erfindung des Computers? Vermutlich herrschte in den Betrieben Anarchie.

Aus dem wahren Leben

Ein Autor (Achim) schreibt Artikel. Diese können aber nur von einem Redakteur (Ralf) freigegeben werden. In dem System gibt es eine Vielzahl von Autoren und Redakteuren. Autoren sind immer bestimmten Redakteuren zugeordnet. Die Artikel von Achim gehen also in diesem Fall immer an Ralf. Diese Beziehung der beiden User kann man natürlich im System fest verankern, so dass Achims Artikel nur zu Ralf kommen.

Frage: Muss das System dies wissen? Wenn wir ohne Computer arbeiten würden, dann würde Achim seine Artikel auf den Schreibtisch von Ralf legen, oder? Und es kommt noch besser: Wenn der Ralf mal krank ist, dann weiß der Achim, dass er seine Unterlagen durch die Renate überprüfen lassen muss. Und wenn die krank ist, dann darf er die Artikel selber freigeben. Hört sich kompliziert an, ist aber so. Möchte man diese Szenarien wirklich programmieren?

Warum sollte man dies fest in ein System hineingießen? Vielleicht wenn es sich um einen riesigen Verlag handelt. Gut. Kann sein. Aber die meisten Webredaktionen sind ja nicht sooo groß. Oftmals bestehen sie aus weniger Leuten, als ein Auto Reifen hat.

Ich finde es außerdem nicht wünschenswert, wenn die Computersysteme den Menschen das Denken abnehmen. Ich glaube z.B. nicht, dass Achim einen Artikel freigibt, obwohl er ihn zuerst der Redaktion vorlegen muss. Er bekäme nämlich sonst Ärger. Den hätte er übrigens auch ohne Arbeiten mit dem Computer bekommen. Warum sollten wir dies ändern? Das CMS stellt ja nur ein Arbeitsmittel dar, das dazu dient, Artikel ins Netz zu stellen. Es dient dazu, die erforderlichen Schritte möglichst einfach zu halten. Einfachheit ist das Stichwort.

Bei allem technisch Machbaren sollten wir immer im Auge behalten, ob eine technische Umsetzung des Machbaren auch wirklich den Nutzern einen Mehrwert gibt. Oft ist es doch viel besser, ein System einfacher und damit leichter bedienbar zu halten, als ein kompliziertes Rechtesystem zu verwenden, das nachher niemand mehr benutzen möchte.

Dies gilt natürlich nicht nur für das hier angesprochene Beispiel. Künstlich aufgeblasene Projekte kennt sicher jeder, der in diesem Bereich arbeitet. Deshalb: Einfach mal mehr Einfachheit wagen.

My two cents.

Guido Boyke

 

Dieser Artikel ist in seiner Ursprungsform zum ersten mal 2008 im Pisto-Magazin erschienen. Er wurde überarbeitet und auf den neuesten Stand gebracht.

  • Antworten
    Author
    ben_

    Schön, dass Du ein Beispiel mit einem Redaktionssystem gewählt hast. Ich sage meinen Kunden immer: Wir haben gelernt, dass es nicht funktioniert, zu versuchen, Workflows digital zu modellieren, die nicht gelebt werden. Und wenn die Workflows gelebt werden, dann braucht man sie auch nicht digital zu modellieren. Das lohnt sich immer nur dann, wenn es wirklich vielen, wirklich viel Arbeit erspart.

    Ansonsten, was Einfachheit angeht, kann ich latürnich nicht anders, als hier das Getting Real Manifest hochzuhalten. Ich weiss, ich weiss, das ist vermutlich Eulen nach Athen tragen … aber für den unwahrscheinlichen Fall, dass in Athen gerade alle Eulen ausgeflogen sind, will ich es doch nicht versäumt haben. Und es ist ja eine wirklich, wirklich schöne Eule. Ich bin nach all den Jahren immer noch sehr davon begeistert.

    • Antworten
      Author
      Guido Boyke

      Gerade bei Workflows in der Kombination mit Start-ups kann ich nur davon abraten, alles in Software zu gießen. Oft ändern sich Workflows schneller, als die Programmierer hinterher kommen. Und dann wird Software, die eigentlich die Arbeit unterstützen sollte, ein Klotz am Bein. Software sollte also vielmehr so gebaut werden, dass sie auch Veränderungen in der Arbeitsweise zulässt.
      Dies ist, zugegeben, ein sehr hochgestecktes Ziel, aber man sollte es zumindest nicht aus den Augen verlieren.