Flüssiges für Profis

Profis sind am produktivsten, wenn sie von Prozessen "in Ruhe gelassen" werden, ohne aber die Übersicht zu verlieren. Welche Art von Prozessen und Tools dies ermöglichen und welche eher hinderlich sind, erfahrt ihr hier. Seid ihr eher Prozess-orientiert oder eher Macher? Oder ist das gar kein Gegensatz? Falls doch, gibt es einen Weg der Zusammenarbeit?

Nein , es geht hier nicht um’s Feierabendbier (das gibt’s im Swisscom Business Park gelegentlich auch). Es geht um Prozesse und Tools für Professionals, und warum diese „flüssig“ sein sollen.

Ein fast dreissigjähriger Kleinkrieg entzweit die Geschäfts-IT: Macher gegen Prozess-Orientierte (ich nenne sie mal „Prozessler“) . Über die Jahre hat so mancher die Seite gewechselt, und die meisten bewegen sich heute zwischen den Polen. Die Prozessler werfen den Machern vor, chaotisch und planlos loszuziehen. Die Macher glauben nicht, dass die Prozessler je über das Planungsstadium hinaus kommen („Analysis Paralysis“). Zurzeit haben die Macher die Oberhand, nachdem sie mit eXtreme Programming und Agilen Methoden die Prozessler mit deren eigenen Waffen geschlagen haben.

Es ist Zeit, aufeinander zuzugehen, und die Stärken zu kombinieren.

Prozesse sollten die besten Macher effektiver machen, statt zu versuchen, die schwächsten mitzuziehen und die besten zu lähmen (zu Beispiel durch Zerteilen der Aufgaben in zu kleine Stücke, Aufbrechen von Verantwortung an den falschen Stellen, so dass es keine Gesamtverantwortung mehr geben kann).

Prozesse sollten in den Hintergrund treten, wenn die Macher in einem Flow (einer Art Arbeitsrausch, oder einfach konzentriertes flüssiges Arbeiten) sind.

Begriffen haben dies die Hersteller unserer Entwicklungs-Prozess-Tools (JIRA , Confluence und andere Tools von Atlassian):

  • Sie laufen im Browser, sind also (fast) immer und überall verfügbar. Das ist wichtig, falls ich plötzlich eine Idee zu einem Problem oder Aufgabe habe, und rasch was nachschauen muss. Ich muss keine Applikation starten und kein Plugin laden, und alle relevanten Information können auch mit Kunden geteilt werden.
  • Kollegen und Kunden können nahtlos in die Prozesse einbezogen werden, ohne dies vorher definieren zu müssen. Hier ist auch ein breit zugängliches Wiki zu Dokumentation und zum Teilen von Wissen nützlich.
  • Veränderungen werden aufgezeichnet, und die betroffenen Kollegen je nach deren Wunsch informiert.
  • Informationen über Änderungen, sowie alles Wissenwerte wird in Dashboards übersichtlich festgehalten (besonders nützlich für Manager)
  • Die Tools sind professionell – das ist sehr wichtig, denn von Amazon, Google, etc. sind wir enorm verwöhnt (was einfach aussieht und zu bedienen ist, ist sehr aufwändig nachzubauen; also nichts für „Heimwerker“).
  • Die Tools sind nahtlos in den Ablauf integriert, ohne einem bestimmten Prozess oder ein bestimmtes IDE (Integrated Development Environment wie Visual Studio oder Eclipse) zu erzwingen. Damit ihr seht, was ich meine, hier ein kurzes Promotions-Video von Atlassian:

Auch bei Swisscom kochen wir nur mit Wasser: Wir haben in verschiedenen Bereichen auch Tools, die aus der vor-Web-Ära stammen. Sie bieten nicht denselben Komfort, den wir von Amazon & Co. gewohnt sind, das Benutzerinterface ist proprietär, bestenfalls gewöhnungsbedürftig. Falls diese Tools dann noch ein separates Passwort brauchen (das dann noch abgelaufen ist und erneuert werden muss), bin ich definitiv aus dem Flow geworfen und ärgere mich über die Prozesse. Dann mache ich keine kleine, inkrementelle Verbesserungen, wenn ich dazu z.B. ein Dokument zuerst auschecken, dann auf einem PC editieren und dann wieder einchecken muss (statt es einfach kurz im Wiki anzupassen).

Ich denke, solche isolierte Tools werden in Zukunft nur noch dort verwendet, wo die Benutzer einen Grossteil ihrer Tätigkeit im Tool selbst verbringt, statt das Tool nur unterstützend zu benötigen.

In anderen Bereichen werden die Prozesse verschlankt und kontinuierlich statt periodisch getrieben, die Verantwortungen anders verteilt. Der Betrieb von Applikationen wird mit der Entwicklung gekoppelt (DevOps), während die Infrastruktur in der Cloud standardisiert bereit steht. Ein Service-Desk läuft dann vielleicht weiterhin auf einem speziellen vor-Web  ITIL-Tool, während das Applikation Management und die Entwicklung zusammen ein DevOps-freundliches Tool wie JIRA braucht.

So, die Arbeit ist dank einem Flow für heute fertig, jetzt gehe ich mit den Kollegen was trinken.