Profiling und gescheiterte Softwareprojekte

P

Ich schaute eben dieses Video. Es ging um Profiling, und was man da eigentlich so macht und untersucht. Jetzt habe ich schon einige Krimiserien gesehen und weiß, dass die natürlich Morde und Gewalt im weiteren Sinne untersuchen. Ziemlich spannend das.

Was ich mich gerade frage, gibt’s das auch für gescheiterte IT Projekte? Zu untersuchen gibt es da vermutlich mehr als genug. Allein, wenn ich mal auf die Projekte schaue, wo ich damals immer mit reingeholt wurde als Consultant. Jaja, ich weiß, nur weil ich mit dabei waren sind die fehlgeschlagen. Natürlich yawn yawn.

Jetzt mal ehrlich: Was ich damals schon beobachtet habe ist, dass selbst Gründer / Chefs mit besten Absichten solche Projekte an die Wand gefahren haben. Und warum? Es lag eigentlich selten an der Technik. Es waren eigentlich immer die Menschen, wegen denen es nicht ging. Hier ein paar Beispiele:

In einem Startup wurden verschiedene Zuständigkeiten eingeführt, was die Implementierung von diversen Aspekten der Software anging. Anmeldung / Benutzerverwaltung, Teil 1 der Business Logik, Teil 2 der Business Logik, usw.
Im Team Anmeldung / Benutzerverwaltung kam es irgendwann zum Eklat, weil nachdem neue Versionen in Produktion gegeben wurden auf einmal Datenverlust auftrat. Nach langem hin und her stand fest: Team Backend hat die Schnittstelle geändert, wie Daten angeliefert werden müssen und Team Frontend nichts davon erzählt. Allerdings wurden die Daten auch nicht wirklich (gut) validiert, so dass das  beim Testen auch nicht bemerkt wurde. Die Folge: Datenverlust bei Neuanmeldungen. Hier schien es vordergründig an der Technik zu liegen (Validierung funktioniert nicht wie erwartet), allerdings hat man sich auch nicht wirklich zusammen gesetzt, um das mal durchzusprechen (“Wir validieren nun so und so, und wäre cool, wenn ihr die Daten nun so statt so liefern würdet”).
Dies war allerdings nur ein vergleichsweise kleiner Vorfall in jener Unternehmung. Dazu kam, dass eigentlich alle paar Tage der Scope geändert wurde. Mal sollten im Release noch mehr Features mit dazu kommen, dann wieder weggelassen werden. Oder das Produkt sollte einfach komplett anders funktionieren. Und das war eigentlich der Punkt an der Sache: Das Projekt ging irgendwann den Bach herunter, weil man sich nicht auf eine erste Version einigen und nicht auf Anforderungen festlegen konnte. Irgendwann wurde dann der Deckel zu gemacht, weil man eben vor besagte Wand gefahren ist.

Nach einiger Zeit unterhielt ich mich mit meinen Kollegen und Chefs über diese Zeit. Wir sprachen darüber, was denn eigentlich mit dem Source Code, Tickets usw. passieren würde. Meine erste Reaktion war, einfach alles in die Mülltonne zu verfrachten. Aber einer meiner Chefs hatte einen interessanten Gedanken dazu. Statt alles zu entsorgen, könnte man natürlich mit dem Source Code noch einiges anfangen, aber genauso interessant seien eigentlich auch die ganzen Tickets aus dem Ticketsystem. Mit etwas Zeit könne man darüber dann nämlich rekonstruieren, wo damals “falsch abgebogen” wurde, sprich welche Entscheidung(en) das Projekt zum Scheitern verurteilt hat.

Mich beschäftigt das so sehr, weil sich die Geschichte immer wieder zu wiederholen zu scheint. Wenn ich manchmal Stories höre, wie Projekte geführt werden, dann kenne ich oft schon das Endergebnis. Warum ist das so? Warum lernen wir so wenig von einander? Weil es nicht cool ist, über das Scheitern zu sprechen? Ja, das ist unangenehm. Andererseits ist es auch unangenehm, seinen MitarbeiterInnen eröffnen zu müssen, dass sie ab morgen nicht mehr kommen müssen, weil das Geld alle ist und kein neues mehr kriegt, weil man immer die gleichen Fehler macht. Was macht man also dagegen? Zum einen darüber sprechen, was man schon alles falsch gemacht hat, damit andere nicht ständig und immer wieder gleichen Fehler machen müssen, zum anderen, sich an Leute wenden, die einem dabei helfen können, schlimme / schwierige Situationen abzuwenden, und, besonders wichtig, hört ihnen einfach mal zu und macht, was sie sagen. Dafür habt ihr sie schließlich geholt und bezahlt sie gut.

About the author

By jan