Projektklinik

Gedanken und Hilfe zur Führung von Software-Projekten

Tabu: Probleme anderer Leute

Ich behaupte, dass es einer der größten Problemauslöser in Projekten und tatsächlich auch im sonstigen Leben ist, anderer Leute Probleme zu lösen.
Glauben Sie nicht? Ein paar Beispiele:

In erstaunlich vielen Festpreis-Projekten wird die Spezifikation erst nach der Beauftragung des Dienstleisters fertiggestellt. Mein Lieblingsbeispiel ist ein Projekt vor einigen Jahren, bei dem ich für einen Teil des Projekts selbst eine sehr vage Wildcard („muss alles können, was das heutige System auch kann“) in die Leistungsbeschreibung schrieb. Die guten Absichten dahinter: Das Team soll wegen der knappen Deadline schon mal anfangen zu arbeiten. Der Dienstleister will den Auftrag haben und deshalb dem Kunden entgegen kommen. Effekt: Der Abschluss der Spezifikation verzögert sich, weil der Kunde sieht, dass es ja trotzdem vorangeht. Entwickelt das Team etwas, das er gar nicht haben wollte, kann er immer noch sagen: das war gar nicht so spezifiziert. Vielleicht entwickelt das Team auch eine hypergenerische eierlegende Wollmilchsau, um jeder potentiellen Anforderung des Kunden entsprechen zu können – wenn sie denn irgendwann kommt. Gleichzeitig streitet der Auftragnehmer um jede „neue“ Anforderung, um im Budget bleiben zu können, oder er verlangt immer wieder Budgeterhöhungen. Enorme Reibungsverluste sind die Folge.

Das Projektteam hat versucht, das Problem des Kunden zu lösen, die Spezifikation nicht vor Projektbeginn fertigzustellen.

Der Freiberufler beginnt mit der Arbeit, obwohl er noch keinen Vertrag hat („Vertrag ist irgendwo im Einkauf unterwegs. Machen Sie sich keine Sorgen.“). Effekt: Der Vertragsabschluss zieht sich, und die Verhandlungsposition der Freiberuflers über die Bedingungen des Auftrags wird schwächer und schwächer. Im Extremfall heißt es dann am Ende: „Ihre Rechnung zahle ich nicht, wir hatten doch noch gar keinen Vertrag!“ Der Freiberufler muss vor Gericht ziehen und wird ggf. nur ein „marktübliches“ Honorar aufgrund der offensichtlich erbrachten und vom Auftraggeber nicht gestoppten Leistung nachfordern können, das deutlich unter dem angestrebten liegt.

Der Freiberufler hat das Problem des Auftraggeber zu lösen versucht, die eigenen Prozesse nicht im Griff zu haben oder die Beauftragung nicht rechtzeitig angestoßen zu haben.

Das andere Teilteam sollte eine Schnittstelle zum Import von Daten liefern. Sie wird nicht rechtzeitig fertig. Das konsumierende Teilteam programmiert also erstmal gegen einen Mock. Die Schnittstelle ist immer noch nicht fertig. Das Team programmiert die Schnittstelle heroisch selbst, erreicht dafür aber nicht die eigenen Ziele.

Die gelieferte Datenqualität ist grauenvoll. Weil der Zulieferer der Daten so schwer greifbar ist, entwickelt das Team über Wochen einen Bereinigungsalgorithmus und hochflexible Darstellungsmechanismen.

Ein Team-Mitglied performt einfach nicht, aus welchen Gründen auch immer. Die restlichen Team-Mitglieder wollen keine Kollegenschweine sein, decken den Minderleister und arbeiten selbst eine Stunde mehr am Tag, erst über Tage, dann Wochen, dann Monate.

Die Deadline für das neue Projekt ist viel zu eng gesetzt, das Verkaufsteam sagt dem Auftraggeber trotzdem zu, die Entwickler beginnen einen „Todesmarsch“ mit zehn Stunden Arbeit täglich und Wochenendarbeit, oft in dem Wissen, dass die Aufgabe dennoch nicht zu schaffen ist.

Das Management schafft es einfach nicht, auch nur grundlegende Vorgaben zur Arbeitsweise, Qualitätsanforderungen und Zielen der Software-Entwicklung zu machen. Die Teams organisieren selbständig Workshops und Seminare, um das Führungsdefizit auszugleichen. Effekt: Ein Glaubenskrieg zwischen den Teams und am Ende innerhalb der Teams geht los, ob Scrum oder Kanban, Merging oder Baselining, sind Senior-Software-Ingenieure mehr verantwortlich für ein Team-Ergebnis als „normale“ Ingenieure, Cloud oder nicht… und viel Zeit und Motivation gehen verloren.

Das Management lässt die Teams in hallende Großraumbüros mit zu wenig Besprechungsräumen ziehen. Niemand kommt mehr in den Flow, die Arbeitsleistung sinkt um 50-75%. Die Entwickler behelfen sich mit Noise-Cancelling-Kopfhörern oder kommen besonders früh oder bleiben besonders spät, weil es da ruhiger ist. In den regulären Arbeitszeiten wird entweder kaum noch miteinander gesprochen, weil es ja alle stört, oder es schert sich niemand mehr um den Krach, denn es erwartet ja eh niemand mehr hohe Leistungen.

Der Abteilungsleiter trifft einfach keine Entscheidungen. Die Mitarbeiter entwickeln telephatische Kräfte um herauszufinden, was der Chef denn wohl wollen können würde und arbeiten unter Annahmen. Der Chef staucht die Mitarbeiter im Problemfall zusammen („Das habe ich nie so entschieden!“) und streicht im Erfolgsfall die Lorbeeren ein.

Fallen Ihnen mehr Beispiele ein?

Mein Tipp: Lösen Sie nicht anderer Leute Probleme bzw. nehmen sie nicht anderen ihre Verantwortung ab. Weisen Sie den Verantwortlichen auf sein Problem hin und bieten sie die Hilfe an, die Sie im Rahmen Ihrer Fähigkeiten, Möglichkeiten und der eigenen Verantwortung leisten können.

 

Schreibe einen Kommentar