Der Unterschied zwischen Projekten und Produkten

Projekte-und-Produkte_Hero

Im Geschäftsalltag begegnet mir allzu häufig ein eher schwammiger Gebrauch des Wortes Projekt. Alles an dem wir arbeiten, wird als Projekt deklariert, obwohl das so eigentlich nicht ganz richtig ist. Wir arbeiten nicht an Projekten, sondern an Produkten. Der Arbeitsvorgang selbst kann Teil eines Projekts sein, aber das Ergebnis, das Artefakt, das Resultat ist immer ein Produkt. Im Gegensatz zu einem Produkt, hat ein Projekt immer ein konkretes Ziel, einen begrenzten Zeitrahmen und/oder ein begrenztes Budget. Bei Produkten ist dies nicht der Fall. Produkte werden entwickelt und von Zeit zu Zeit geändert, um verbessert oder aktualisiert zu werden. 

 

Wir arbeiten an Produkten, während wir in Projekten arbeiten.

 

Schlussendlich spielt es keine Rolle, ob ein Unternehmen Produkte für externe Kunden, Endkunden oder den internen Gebrauch entwickelt. Es ist absolut dasselbe. Jedes Stück Software, das ich jemals geschrieben habe, habe ich für ein Produkt geschrieben. Es gab immer ein neues Artefakt oder eine neue Version des Produktes. 

 

Größere Änderungen hingegen werden in Projekten umgesetzt und haben schlussendlich zum Ziel, Funktionalitäten mit einer hohen technischen oder fachlichen Kohäsion zu liefern und somit einen Mehrwert zu generieren. Das Ergebnis aber, ist immer eine neue Version bzw. eine neue Veröffentlichung des Produkts. In den seltensten Fällen bleibt eine Software nach Abschluss eines Projekts unverändert. Sie wird abgeändert, erweitert und an die individuellen Anwendungsfälle der Stakeholder angepasst. Und das ist auch absolut in Ordnung so.

 

Konsequenzen eines produktbezogenen Arbeitens

Die Erkenntnis, dass man an Produkten, anstatt an Projekten arbeitet, bringt allerdings ein gewisses Maß an Umdenken und zusätzlichen Erwägungen mit sich. So muss eine intensive Auseinandersetzung mit den Qualitätsanforderungen stattfinden und die Illusion genommen werden, eine perfekte und einmalige Implementierung würde zu einem Code führen, der niemals wieder verändert werden müsste und für alle Zeit perfekt ist. Diesem Irrtum begegne ich nicht selten.

 

 Die Denkweise trägt nicht der Tatsache Rechnung, das sich Anforderungen ändern, Sicherheitslücken aufgedeckt werden, rechtliche Rahmenbedingungen ändern, neue Endgeräte auf den Markt kommen während andere verschwinden und sich der gesamte technologische Wandel immer weiter beschleunigt. Die Halbwertzeiten von Technologien werden immer kürzer und Technologien müssen austauschbar eingesetzt werden. Alle diese Gründe können Änderungen erforderlich machen. Schlussendlich führt der Perspektivwechsel dazu, den  gesamten Lebenszyklus eines Produkts und die Gesamtkosten der Investition zu überdenken.

 

Als weitere Konsequenz führt der Gedanke weg vom klassischen Festpreis-, Pay-once-and-get-it-all-forever-Denken hin zu einem Verständnis von Softwareentwicklung als Dienstleistung, die von Zeit zu Zeit Haltungskosten generiert. Dabei wird ein Produkt entwickelt, und alle Qualitätsaspekte wie Wartung, Benutzerfreundlichkeit, technische Upgrades und viele Weitere müssen berücksichtigt werden.

 

Diese Veränderung ist dabei in bester Gesellschaft der Servicisierung wie sie im Allgemeinen auch in anderen Bereichen stattfindet, wo Abo Modelle (Spotify, Netflix, Cloud Gaming Services, Office 365) den Kauf von Software-Produkten (z.B. Office 2013) oder digitalen Medien (z.B. Musik, Filme) immer mehr ablösen und dafür die regelmäßige Aktualität des Produkts gewährleisten.