Manchmal höre ich motivierte EntwicklerInnen sagen, „ich bin Committer im Open-Source Projekt X“, oder wir werden als Unternehmen beauftragt, „am Projekt Y mit zu arbeiten“. In vielen Fällen halte ich das für begrifflich unsauber – es sollte korrekterweise heissen:

Also: System (oder Produkt) statt Projekt.

Aber einen Schritt zurück: Fragen wir doch mal Wikipedia, was „Projekt“ bedeutet:

„Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gesteuerten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Vorgaben bezüglich Zeit, Ressourcen (zum Beispiel Finanzierung bzw. Kosten, Produktions- und Arbeitsbedingungen, Personal und Betriebsmittel) und Qualität ein Ziel zu erreichen.“

Das bedeutet im Klartext, dass ein paar Leute eine Zeitlang zusammen arbeiten, um ein bestimmtes Ziel zu erreichen. Wir könnten Projekte auch zielgerichtete Arbeitsprozesse nennen.

Was diese Definition nicht enthält, ist das entstehende Produkt, in IT-Sprechweise manchmal „das System“, „das Feature“ oder „die Applikation“ genannt.

Dabei bauen wir doch Systeme! Menschen möchten unsere (Software-)Systeme nutzen, um damit unternehmerischen Wert zu schaffen, schwierige fachliche Aufgaben zu lösen oder einfach nur Spaß zu haben. Das Vorgehen, mit dem diese Systeme entstanden sind, ist für diese Menschen völlig belanglos.

Der Fokus liegt auf dem resultierenden Produkt – und nicht auf dem Arbeitsprozess.

Relikt aus IT-Mittelalter

Meiner Ansicht nach resultiert dieser terminologische Lapsus aus dem düsteren IT-Mittelalter, als viele Software-Entwicklungsarbeiten noch mit möglichst vollständiger A-priori-Planung, zu Festpreisen und mit wasserfallartigem Projektmanagement durchgeführt wurden. Keine Iteration, kaum Feedback, Termindruck.

Irgendwann hat unsere Branche zum Glück begonnen, den Wert von iterativem und situativ adaptiertem Vorgehen zu verstehen. Willkommen Lean, Kanban & Friends!

Resultate statt Prozesse

Wir möchten unsere Systeme (aka Produkte) so gut wie möglich bauen, nachhaltigen Wert in hoher Qualität schaffen – und das natürlich mit einer ordentlichen Portion Wirtschaftlichkeit im Hinterkopf.

Wir sollten die Möglichkeiten iterativer Prozesse zu schnellem Feedback und kontinuierlicher Verbesserung nutzen, um diese Ziele zu erreichen. Wir sollten stets das eigene Vorgehen in Frage stellen und nach Möglichkeiten der Optimierung suchen.

All das ist mit Produktfokus möglich, aber bei Projektfokus sehr viel schwieriger: Wir möchten nicht ausschliesslich auf die Einhaltung eines Endtermins (der so genannten Deadline) optimieren, und dabei das Risiko von quick-and-dirty eingehen.

Sinnvolle Termine

Aber, so denken Sie jetzt richtigerweise, manchmal sind doch Termine relevant: Wichtige Messetermine, oder der berühmte Stichtag, an dem ein neues Gesetz in Kraft tritt:

Iterativ arbeitende Entwicklungsteams können mit terminlichen Randbedingungen durchaus umgehen, sofern sie nicht permanent und über lange Zeit nur auf Termine optimieren müssen. Ein iterativ arbeitendes Produktteam wird einen Abfall der inneren Qualität durchaus temporär hinnehmen, um einen aussergewöhnlich wichtigen Termin zu halten – sofern es in nachfolgenden Iterationen dieses Defizit wieder ausgleichen kann.

IEMOD

I eat my own dogfood: Ich muss bekennen, dass ich als aktiver Committer seit Jahren Open-Source entwickle (u.a. arc42 und aim42) und lange Zeit völlig unreflektiert diese Dinge Projekte genannt habe – obwohl es eindeutig Produkte sind, die wir da über Jahre in Teams entwickelt haben.

Aber ich verspreche (begriffliche) Besserung!

Fazit

Wir sollten Dinge beim (richtigen) Namen nennen: Wenn wir über Systeme oder Produkte sprechen, sollten wir auch System oder Produkt dazu sagen.

Produkt-Teams identifizieren sich mit ihrem Baby, sie verinnerlichen Qualitätsbewusstsein und arbeiten oftmals intrinsisch motiviert.

Projekt-Teams fokussieren auf kurzfristige Zielerreichung, auf Deadlines und Einhaltung von Budget. Allen Lippenbekenntnissen des Projektmanagements zum Trotz kommt die Qualität des Systems erst an dritter Stelle.

Quellen und weitere Infos

Wenn Sie mehr Kanban wissen wollen, starten Sie mal mit What-is-Kanban, und wirklich nett ist auch Florian Eisenbergs Roman Kanban - mehr als Zettel, worin er in einen Roman verpackt lesenswerte Ratschläge für die Anwendung von Kanban gibt.

Diskussionen über Projekt vs. Produkt führen insbesondere Protagonisten der agilen Szene. Einige davon habe ich für Sie herausgepickt (wobei die Reihenfolge keine Wertung darstellt und ich mich über Ergänzungsvorschläge sehr freue!):

Danke

Danke an Claudia Rauch für ihre unermüdlichen 2readable Transformationen meiner holprigen Satzkonstrukte.

Danke an ungenannte (schlechte) Projektmanager, dass sie mir deutlich die Schwächen einer Projektorganisation vor Augen geführt habt. Ja – ich habe darunter gelitten. Und letztlich danke an die großartigen Product-Owner, bei denen ich die positive Auswirkungen von Produktorganisation auf Qualität, Kunden- und Teamzufriedenheit und positivem Mindset erleben durfte.

TAGS