Entwickler großer Enterprise-Projekte können viel von den Technologieansätzen und der Entwicklerkultur agiler Webprojekte lernen. Dieses Fazit hatte vor einigen Tagen Tim Bray in einem viel beachteten Blogeintrag gezogen (wir berichteten), in dem er den Gründen nachspürt, warum Millionen von Dollar in den schwerfälligen Mühlen bürokratischer Enterprise-Prozesse verloren gehen.
Dass in der Welt der Web-Startups auch nicht alles Gold ist, was glänzt, haben einige Kommentatoren bereits bemerkt - denn gerade hier gebe es neben den (wenigen) Leuchtturm-haften Erfolgstories (Facebook, Twitter, Google, Basecamp) auch eine unübersehbare Anzahl von in den Sand gesetzten Projekten.
Einen interessanten Beitrag hat nun Frank Sommers zur Diskussion geleistet. Sommers zeichnet eine Typologie von "Projekt-Owner" und bloßem "Caretaker", die jeweils unterschiedliche Kulturen, Motivationen und Interessen mit in ein Projekt brächten.
Owner vs. Caretaker
Der Unterschied zwischen einem "Owner", der selbst persönlich an der Planung, Finanzierung und Umsetzung eines Projekts beteiligt ist, und einem "Caretaker", der als Angestellter ein Projekt lediglich pflegt, verwaltet und weiterentwickelt, sei größer als der zwischen Enterprise-Projekt und Web-Startup. Es sei dieser Unterschied, der zu einem großen Teil für die Diskrepanz zwischen Kosten und Qualität von Software-Projekten verantwortlich sei.Owner hätten eine überaus starke persönliche Bindung zu einem Projekt und ein großes Interesse daran, die Anwender und Kunden zufriedenzustellen. Für Caretaker sei "Sparsamkeit" ein eher fremdes Konzept. Und so ständen Owner agilen Methoden und kurzen Releasezyklen typischerweise aufgeschlossener gegenüber:
Owners are generally very hesitant to throw (their own) money at enterprise software that can't show short-term return on investment. That, in turn, determines to some extent the technologies used in the sense Bray describes. Frank Sommers
Caretaker seien hingegen so etwas wie "professionelle Söldner", die sich nach dem Scheitern eines Projekts immer auch nach einem neuen Brötchengeber umsehen könnten:
Caretakers also have less riding on a project's success professionally: If a project doesn't pan out, they would just look for another project or job. Frank Sommers
Sollten wir also alle Owner werden?
Das ist wohl einfach unmöglich, so Sommers, denn Tim Brays Beobachtungen hätten mit einem uralten Business-Problem zu tun: Sobald ein Unternehmen wachse und damit beginne, Angestellte - "Caretakers" - zu beschäftigen, halte eine völlig neue Kultur Einzug in eine Firma:
As soon as a business starts to have employees, or caretakers, an entirely different set of incentives and motivations enters the firm. While an owner-only company may be very efficient at every turn, you can hardly grow a business without employees. Frank Sommers
Eine interessante Nebenbemerkung: Dieser Prozess könnte auch für Open-Source-Projekte wie Linux oder Eclipse gelten:
I imagine that large open-source projects, such as the Linux kernel or the Eclipse IDE, require more resources than do small projects with a handful of owner-developers. You need to accept somewhat reduced efficiency in return for the ability to grow and serve more customers or users. Frank Sommers
Verliert ein Open-Source-Projekt also an Schlagkraft, wenn es zu einer gewissen Größe herangewachsen ist, oder wenn damit begonnen wird, professionelle Entwickler einzustellen (was z.B. derzeit gerne für den Eclipse-Architekturkern gefordert wird)?
Wie dem auch sei, alle können wir nicht Projekt-Owner sein, so Sommers Fazit. Doch könnten Unternehmen versuchen, die Angestellten zu motivieren, wie Owner zu denken.
Agile practices already promote the notion of "product owner" or even "business owner," and smart firms can make such phrases a fact in business terms, too. Frank Sommers
Stellt sich nur die Frage, warum ein "Caretaker" wie ein "Owner" denken sollte, wenn ihm doch eigentlich gar nichts gehört...
