Wie lange brauchen wir von der Idee bis zur marktreifen Lösung?

In meinen Folien zeige ich gern die Kurve eines Produktlebenszyklus. Vor allem um unser Bewußtsein zu dokumentieren, dass es eine Phase gibt, in dem ein neues Produkt keinen Gewinn abwirft, weil zunächst einmal die Produktentwicklung und die Produktion finanziert werden muss.

Die Produktentwicklung sollte demnach möglichst effizient betrieben werden. Kleinere Kosten und kürzere Entwicklungszeit bedeutet schneller in der Gewinnzone zu sein.

In der Gewinnzone zahlt sich dann vor allem Qualität aus: Nacharbeit und Reklamation drücken auf das Wachstum, also den Gewinn. Qualität entsteht aber in der Produktentwicklung und in der Produktion. Ich bin der Meinung: Wenn ich mir Qualität in der Produktentwicklung nicht leisten möchte, dann kann ich mir ein Produkt auch ersparen, denn es wird ohnehin einen kläglichen Gewinn abwerfen.

Aber was kostet das nun? Hmm – was kosten rote Pullover? Ich erinnere mich an das Konzept von CMMI. Eigentlich eine Binsenweisheit: Wenn ich eine gute Prognose machen möchte, dann brauche ich fundierte Informationen über das, worauf sich die Prognose bezieht. Für uns Software-Leute heißt das: Wir brauchen belastbare Erfahrungen in der Bewertung unserer eigenen Fähigkeiten.

Und hier möchte ich mal eine Bresche für die kreativen in der Branche reißen: Wir entwickeln Lösungen die es so noch nie gegeben hat. Es ist schon wirklich fundamental etwas anderes, ob man bestehendes Produkt pflegt, zum Beispiel ein Excel flat macht oder ob man eine absolute Produktinnovation aus Messtechnik, Feld-Komponenten, RZ- und Leitwarten-Integration, Milliarden Datensätzen, wissenschaftlich fundierten Algorithmen und visualisierten Korrelationen implementiert. Ich liebe meinen Job 😉

Dennoch: Wie bewerte ich etwas, was ich so noch nie gemacht habe?
Meine Antwort: Indem ich immer wieder etwas mache, was ich vorher noch nie gemacht habe und indem ich meinen Erkenntnisgewinn jeweils bewerte und so weit wie möglich in Zahlen fasse.

Und weil das nicht nur mich, sondern die ganze Firma betrifft, haben wir bei der OKIT ein leichtes Experiment gemacht. Das selbst gewählte Thema ist das Mindestlohngesetz (MiLoG), welches im Rekordtempo von unserer Regierung eingesetzt wurde und die Dokumentations-Pflicht der geleisteten Stunden der Arbeitnehmer einführt, als Nachweis-Bestandteil zum Mindestlohn: Gezahlter Lohn / geleistete Stunden = Stundenlohn. Auch bei uns ging ein Papier-Formular ein mit dem Hinweis, dass beispielsweise unsere Reinigungskraft ihre Stunden darauf dokumentieren solle.

Schmunzelnd musste ich an das alte Vorurteil denken, dass es deshalb so viele Zeiterfassungs-Systeme am Markt gibt, weil jede IT-Bude die eigene ZEF als eines der ersten Projekte angeht.

Aber warum auch nicht. Das scheint ja eine Tradition zu sein. Und das ist doch eine echte Herausforderung: Zeigen wir mal, dass wir schnell auf äußere Trigger reagieren können. Also: Ich wollte es machen. Aber nur, wenn das keine Selbstbeschäftigung wird.

Der Markt ist voller Schulungs- und Weiterbildungsangebote die ich sehr schätze. Ich fand aber gefallen an dem Gedanken ein ganzes Team in einen Workshop zu stecken. Nicht um ein abstraktes Rollenspiel nach vorgegebener Choreografie zu tanzen oder Getränkekisten zu stapeln, sondern um die firmeneigenen Kulturtechniken nach vorn zu bringen.

Folgende Ziele hatten wir uns gegeben:

1. Lean!
2. Ein überschaubares Projekt mit frischen Technologien.
3. Ein fachliches Ziel: Die Lösung erfüllt die Anforderungen an die Dokumentations-Pflichten aus dem MiLoG, ist also in Bezug auf die Funktion zielorientiert.
4. Die Lösung soll absolut einfach zu handhaben sein.
5. Planvolles handeln mit vorher geplanten Tasks und der umsichtigen Betrachtung aller zu erwartenden Aufwände.
6. Wir fördern das Teamwork und unsere Hausstandards: eine saubere Architektur, eine ordentliche Umsetzung, ein koordiniertes Betriebskonzept.
7. Die Zusammenarbeit mit einem externen Schnittstellen-Partner, wie das in unserem Bereich praktisch immer passiert.
8. Die exakte Messung der Performance unseres Teams. Also Bewertung der Termintreue und des verwendeten Ressourceneinsatzes.
9. Wir wollen damit Geld verdienen.

Gestarten sind wir am 11. Dezember 2014 mit einem initialen Meeting. Als Schnittstellen-Partner im Projekt konnten wir einen echten Projektpartner gewinnen, die Firma Neomatt aus Essen. Es folgten Meetings mit unserem Projektpartner, die Prognose der Aufwände und die Bestimmung einer Zeitschiene. Natürlich wäre ein Launch zur Inkraftsetzung des MiLoG am 1.1.2015 schön gewesen, aber es war bereits sehr schnell klar, dass das nichts werden konnte.  Da hätten wir vor Jahreswechsel kaum noch 5 Personentage zusammen bekommen. Denn immerhin stand Weihnachten vor der Tür mit samt der damit verbundenen Urlaubsphase und den laufenden Projekten und Budgets, die zum Jahreswechsel geschlossen werden wollten.

Nach einer Zerlegung in Arbeitspakete und deren Sequenzierung schien es planbar, dass wir dafür zum 1.2.2015 produktiv sein werden. Launch sollte der 23. Januar sein – gut eine Woche vor genau dem Monatswechsel, zu dem die ersten Arbeitszeitlisten bei den Arbeitgebern archiviert sein sollten.

Und nun haben wir es geschafft. Natürlich war es am Ende etwas aufregend und es war der Nachmittag und nicht der Morgen des 23. TamTeim.de ist seit diesem Datum in Produktion.

Was ist nun mit den Zielen?

Wir sind noch nicht ganz fertig. Wir sind ja erst in der Einführungsphase. Es gibt also noch keinen Gewinn.
Wobei – das stimmt nicht ganz. Denn das Team hat jetzt schon gewonnen. Wir haben gezeigt, dass wir effizient, schnell, gut handeln können. Es hat Spaß gemacht. Zu den Zielen:

1. Yes, die Lösung ist Lean. Es ist ja so schwer, bei den ganzen Features, die uns eingefallen sind, den Ball flach zu halten. Aber es ist auch ein gutes Gefühl zu widerstehen. Insbesondere, wenn man das schlanke Ergebnis sieht.
2. Yes, die Technologien sind für uns relativ frisch. Darunter auch eine responsive Webapplikation für die Zielgruppe IT-Laie und die Integration mit einer extern entwickelten iOS-App.
3. Yes, die Lösung erfüllt die Anforderungen an die Dokumentations-Pflichten. Es sind alle Informationen drin und auch die Abgabe-Fristen halten wir ein, indem wir zu späte Meldungen sanktionieren, also gar nicht erst rein lassen.
4. Yes, die Lösung ist überraschend einfach zu bedienen. Wir haben wirklich nichts eingebaut, was nicht wirklich sein musste. Wir können wirklich alles erklären.
5. Yes, wir haben geplant und wir haben es gehalten. Unsere Aufwände waren mit 25 Personentagen geplant. Aktuell haben wir noch gut 2,5 Tage für Produktions-Reviews und potentielle Bugfixes offen. (Einen habe ich noch entdeckt – nur Einen!)
6. Yes, das Team hat eine Arbeit gemacht. Marketing, Entwicklung, Infrastruktur, Deployment – eine Zusammenarbeit, die Spaß gemacht hat.
7. Yes, die Zusammenarbeit mit dem Projektpartner verlief absolut problemlos. Meinen herzlichen Dank dafür, es war und ist mir eine Freude!
8. Yes, wir haben alles beisammen. Wir werden noch ein Aftermath-Meeting machen um Emotionen und Zahlen zu betrachten. Aber formal haben wir zweifelsfrei eine klare Bewegung auf dem CMMI-Pfad gemacht.
9. 😀 hey, wir arbeiten dran.