2024 12 02 Bitte Nicht Zu Linientreu 01

Bitte nicht zu linientreu! - Gedanken für eine statusbefreite Produktentwicklung abseits von „Projekt“ und „Linie“ von Sven Schneider

Gute Filme beginnen manchmal mit dem Ende. Warum also nicht auch ein Blogbeitrag?

Genervt klickt sich Peter durch die Anfragen im Ticketsystem. Mal wieder entdeckt der erfahrene Entwickler ein Problem mit dem Login des Onlineshops. Mal wieder muss Peter zwei Komponenten aktualisieren, damit das System halbwegs stabil weiterläuft. „Wenn das so weitergeht, bringt uns der Shop nur noch Ärger und keine neue Kundschaft mehr.“, raunt Peter enttäuscht zu seiner Kollegin Natascha, die ebenfalls über einigen Tickets brütet.
„Vor drei Jahren haben die Chefs mit glänzenden Augen vom Potenzial des neuen Shops geschwärmt. Eine völlig neue UX sollte das werden. Mit drei Klicks zum individuellen Produkt, weißt du noch?“, erwidert Natascha. „Wir haben da aber auch was richtig Gutes an den Start gebracht. Die Energie im Entwicklungsteam war der Wahnsinn. Und jetzt? Jetzt sitzen wir zwei als letzte Mohikaner da und halten das Produkt gerade so am Laufen.“, antwortet Peter. Natascha überlegt. Dann lacht sie: „Tja Peter, wir sind halt kein Projekt mehr. Willkommen im Linienbetrieb. Ich weiß nicht mal, ob es überhaupt noch einen Projektverantwortlichen gibt.“
Schulterzuckend vertiefen sich beide wieder in ihre Arbeit, die nächsten Tickets warten.

Projekt und Linie – zwei widerstrebende Leidenschaften

Vermutlich geht es Natascha und Peter wie vielen Mitarbeitenden im Alltag zwischen ehrgeizigen Entwicklungsprojekten und der Überführung in den Linienbetrieb.
Denn nicht wenige Unternehmen treiben zwei „Leidenschaften“ an:
Die verständliche Neigung, Innovationen konsequent in eigenständige Entwicklungsprojekte auszulagern, und der oft weniger verständliche Drang, genau diese Projekte schnellstmöglich wieder in den gewöhnlichen Betriebsalltag zurückzuführen.
Ich kann die Motivation für dieses Vorgehen durchaus nachvollziehen. Dennoch finde ich die Beweggründe oft zweifelhaft. Sie scheinen getrieben von der Angst, Ressourcen nur so verlässlich planen zu können – und Angst ist bekanntlich kein guter Ratgeber. Mit meinem Blogbeitrag möchte ich daher Mut machen, Entwicklungsprozesse nicht allzu isoliert zu betrachten, sondern sie stärker in das große Ganze einzuordnen.

Eine Linie muss nicht immer schlank sein

 „Linien“ wirken bequem und handelbar. Sie bremsen aber auch Chancen aus und sind noch dazu häufig weitaus weniger wirtschaftlich als oftmals vermutet. Einige Beobachtungen zu schnellen Rücküberführungen in den Linienbetrieb können das verdeutlichen:

  • Schwindende Lebendigkeit: Menschen, die sich für die Entwicklung eines Produktes verantwortlich fühlen, sind oft Feuer und Flamme. Sie möchten ein möglichst gutes Ergebnis präsentieren. Nicht selten haben sie daher weitere Ideen, um ihr Produkt auch nach der Hauptentwicklungsphase weiter zu verbessern. Mit der Überführung in den Regelbetrieb wird diese Lebendigkeit oft abgewürgt. Das einst so motivierte Projektteam fühlt sich nur noch teilweise oder überhaupt nicht mehr zuständig. Das Produkt droht, vom inspirierenden „Newcomer“ zum alternden Dinosaurier zu verkommen.
  • Sinkende Innovationskraft: Mit der Lebendigkeit geht oft auch das innovative Potenzial von Produkten im Linienbetrieb verloren. Denn es fehlen Prozesse und Wege, um kreative Geistesblitze niederschwellig aufzugreifen. Bis ein Optimierungslauf angestoßen wird, geraten manche Verbesserungsideen schon wieder in Vergessenheit.
  • Steigende Gleichgültigkeit: Wie im Beispiel von Peter und Natascha, so fehlt es im Linienbetrieb vieler Produkte an Personen, die sich für die Performance des Produktes verantwortlich fühlen. Ein oder zwei IT-ler sind mit der Beseitigung der gröbsten Bugs beauftragt, ein wirkliches Interesse an der Optimierung des Produktes zeigt aber niemand mehr.
  • Verlangsamte Warnzeiten: Die drohende Gleichgültigkeit bei Produkten im Linienbetrieb führt nicht selten zu einer problematisch langen Vorlaufzeit bei auftretenden Problemen. Da „Stammpersonal“ fehlt, müssen sich weniger beteiligte Personen bei größeren Problemen neu in das Produkt eindenken. Bei sicherheits- und systemrelevanten Bugs kann das mitunter gefährlich werden.
  • Verschleierter Aufwand: Der Abschluss einer Projektphase und eine Überführung in den regulären Alltagsbetrieb mag wirtschaftlich zunächst attraktiver erscheinen als eine langfristig angelegte Produkt(weiter-)entwicklung. Doch die Zahlen trügen. Denn der Aufwand für den Produktsupport im Regelbetrieb wird meist ebenso wenig erfasst, wie die Kosten für Interventionen bei auftretenden Problemen.
  • Überlastete Mitarbeitende: Im Linienbetrieb sind Mitarbeitenden oft mit geringen Stundenvolumina für verschiedene Produkte zuständig. Wie Natascha und Peter stehen ihnen daher nur wenig Ressourcen zur Verfügung, um Probleme bei einzelnen Produkten zu lösen. Echte Verbesserung sind nicht möglich. Zugleich müssen Entwicklerinnen und Entwickler mehrere Projekte im Linienbetrieb gleichzeitig jonglieren. – Ein ermüdender Tanz auf mehreren Baustellen, der bei parallel auftretenden Problemen in mehreren Projekten schnell zur Überlastung führen kann.

Während bei Entwicklungsprojekten immer wieder ausufernde Kosten und unplanbare Risiken befürchtet werden, gilt der Linienbetrieb als schlank und kalkulierbar. Die obigen Punkte zeigen allerdings, dass das ein Trugschluss sein kann. Linien sind nicht immer schmal. Im Gegenteil: Ein übereilter und wenig durchdachter Linienbetrieb kann sich aufblähen und zu einem großen Kostentreiber werden. Daher ist der Blick auf Alternativen lohnenswert.

Bitte nicht zu linientreu

Beispiele für nachhaltige Entwicklungsmodelle – von Citizen Development bis Fusion Team

Viele Unternehmen sind bei Change-Prozessen in der IT noch immer von einem starken Schwarz-Weiß-Denken geprägt: entweder Entwicklungs- oder Anwendungsphase. Bekannte Trends wie DevOps zeigen bereits, wie sich diese altgedienten Denkmuster aufbrechen lassen. Es lohnt sich, weitere Modelle für eine siloübergreifende, kontinuierliche (Weiter-)Entwicklung von IT-Produkten zu betrachten. Viele Ansätze lassen sich dabei auch auf andere Produkte übertragen.

  • „Der IT-ler unter uns“: Während bei klassischen Entwicklungsprojekten einzelne Mitarbeitende aus den Fachbereichen in die IT geholt werden, um dort im Projektteam mitzuwirken, wählen einige Unternehmen einen umgekehrten Weg. IT-ler gehen in die einzelnen Fachbereiche, um dort bei Problemen zu unterstützen und Verbesserungsbedarf zu erkennen. Aus der Zusammenarbeit zwischen IT- und Fachprofis entsteht nicht nur innovatives Potenzial für neue Produkte, auch die Nachbereitung von Neuentwicklungen kann so unkomplizierter und organischer gestaltet werden.
  • Die IT-Gilde: Bei diesem Modell teilt sich die IT ebenfalls auf unterschiedliche Fachabteilungen auf. Allerdings bleiben die IT-Profis miteinander in engem Austausch, um bei Problemen – wie in einer Gilde – zusammenzukommen und gemeinschaftlich zu beraten.
  • Citizen Development: Der Clou dieses Modells besteht darin, dass die Anfordernden zugleich die Entwickelnden sind. Dazu werden die Mitarbeitenden in Fachabteilungen so geschult, dass sie neue Produkte als „Fachbereichsentwickler“ selbstständig voranbringen können. Die zentrale IT unterstützt und coacht das Team, gibt zentrale Leitplanken vor und behält vor allem sicherheitsrelevante Aspekte im Blick.
  • Fusion Teams: Weg von der Funktion, hin zum Prozess. Das ist die Kernidee von Fusion Teams. Einfach erklärt: Alle, die an einem Geschäftsprozess beteiligt sind, überlegen gemeinsam, wie dieser verbessert werden kann, ganz gleich in welcher Funktion und Abteilung die einzelnen Akteure arbeiten. Ziel des Modells ist es, Verbesserungen schneller anzugehen als in groß angelegten Entwicklungsprojekten. Für die Einhaltung unternehmensweiter IT-Sicherheitsstandards sorgen einheitliche Richtlinien, die gemeinschaftlich von vielen Mitarbeitenden aufgestellt werden.

Mein Appell: Plane dein Produkt wie eine neue, smarte Abteilung, die kommt, um zu bleiben!

Die Modelle für eine (langfristige) Zusammenarbeit zwischen IT und Fachbereichen zeigen die vielfältigen Möglichkeiten für nachhaltige Optimierungsprozesse abseits vom klassischen Projekt-Linien-Modell. Daneben finde ich das Einüben einer neuen Sichtweise auf Produktentwicklungsprozesse wichtig: Neue Produkte sollten stets so angedacht werden, als würde im Unternehmen eine neue Abteilung entstehen.
Dabei geht es mir allerdings weniger um den Begriff der Abteilung, den oft – zu Unrecht – die Aura einer langsamen und trägen Institution begleitet, als vielmehr um die Perspektive der Dauer. Es lohnt sich neue Produkte, aber auch die Weiterentwicklung von Produkten langfristig und somit auch nachhaltig anzudenken.
Das heißt jedoch keinesfalls, dass Entwicklungsprozesse dadurch länger dauern müssen oder mehr personelle Ressourcen gebraucht werden. Im Gegenteil: Eine auf Dauer angelegte Produkt- und Ressourcenplanung stellt sicher, dass ein gutes Produkt nach der „Hochphase“ im Entwicklungsprozess durch verlässliche Zuständigkeiten kontinuierlich überwacht und weiterentwickelt wird, so dass das Produkt seine Dynamik und Innovationskraft langfristig behalten kann.

Nicht jede Linie ist rot – Siloübergreifende Verbesserungsprozesse im Alltag fördern

„Projekt“, „Linie“, „Abteilung“ – Die Etikettierung von Prozessen gehört zu den großen Innovationsbremsen in Unternehmen. Der Grund: Labels funktionieren wie Schubladen, die Prozesse in (zu) festgelegte Grenzen pferchen. Problematischer als der Alltagsbetrieb selbst ist für mich daher vor allem das Etikett „Linie“, das den Abschluss einer Innovation signalisiert. Denn gerade im Alltag lassen sich in bereichsübergreifenden Reviews hervorragende gemeinsame Optimierungsansätze gestalten – zum Beispiel durch Methoden wie Wertstromanalysen, Wardley Maps oder de Bonos „6 Denkhüte“.
Das macht deutlich: Innovationen gedeihen – wie das Lebens selbst – ungeachtet von Labels überall dort, wo kreative Freiräume gefördert werden.

Über Sven

Noch mehr Artikel