Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Terminplanung: Fertig! – Fertig?

    Jörg Hinrichs

    Das Statusmeeting ist in vollem Gange und der Projektleiter geht gerade seine ToDo-Liste durch: “Ok, als nächstes haben wir hier Feature Nr 49, ‘Batchauswertung von Vertriebsdaten’. Das ist Dein Feature, Thomas, wie sieht es damit aus?”.

    Thomas guckt ein bisschen unsicher und sagt dann: “Ist so gut wie fertig, wir müssen nur noch den Webservice für die Ermittlung der Währungskurse anbinden.”

    Der Projektleiter fragt weiter: “Und, was denkst Du wie lange das dauert?”. “Nicht lange”, antwortet Thomas, “damit sind wir wahrscheinlich bis mittags durch, spätestens heute Abend”.

    “Ah, sehr gut!”, sagt der Projektleiter und trägt den Termin in seine Liste ein. Da Projektleiter immer gern den Status quantifizieren fragt er noch einmal nach: “Also zu 90% fertig, ist das in etwa richtig?”. Thomas druckst ein wenig herum, möchte sich eindeutig nicht definitiv festlegen. Der Projektleiter beruhigt ihn noch einmal: “Es kommt hier wirklich nicht auf 5% mehr oder weniger an, ich möchte nur eine ungefähre Vorstellung haben, wo wir stehen”. Schließlich stimmt Thomas zu: “Ja, ich denke 90% kommt ganz gut hin”.

    Nächstes Statusmeeting, eine Woche später…

    “Hmm, als Termin für Feature 49 hatten wir hier letzten Montag eingetragen, kann ich das jetzt abhaken?”. Thomas rutscht etwas unruhig auf seinem Stuhl herum: “Na ja, noch nicht ganz, wir haben noch zwei Bugs, die wir beseitigen müssen bevor wir den Code zum Abnahmetest geben können”.

    Der Projektleiter ist etwas verwundert, da das Feature ja schon vor einer Woche fertig sein sollte. Je nach persönlichem Naturell wird er das sofort ansprechen oder eine Weile beobachten und, wenn es häufiger passiert, dann zur Sprache bringen. Früher oder später wird es aber auf jeden Fall ein Thema werden, weil der Projektleiter sich nicht auf die Angaben seiner Entwickler verlassen kann und das ein Problem für seine Terminplanung darstellt.

    “Fertig” ist ein binärer Zustand!

    Es gibt ein wunderbares Zitat dazu: “Wir sind zu 90% fertig, jetzt kommen die anderen 90%!”. Da steckt viel Wahrheit drin.

    Schauen wir uns noch einmal unseren konkreten Fall mit Feature 49 an: Da die Geschichte authentisch aber nichtsdestotrotz erfunden ist, spekuliere ich mal was in der zurückliegenden Woche passiert ist:

    • Thomas hat wie beabsichtigt die Anbindung an den Webservice durchgeführt. Dabei hat er allerdings festgestellt, dass die Datenstruktur, welche der Webservice beim Aufruf zurück gibt, nicht mit der im Batch verwendeten Strukturierung übereinstimmt. Ich weiß, mit einem sorgfältigen Design hätte man das von Anfang an vermeiden können, aber unsere Welt ist leider nicht immer perfekt (meist gibt es nicht genug Zeit für soviel Sorgfalt).
    • Thomas ändert also die Datenstruktur innerhalb des Batches, was weitreichende Auswirkungen hat und zu vielen Änderungen in der Batch-Logik führt. Wer Erfahrung mit Softwareentwicklung hat weiß, dass jede Codeänderung das Potential zu neuen Fehlerquellen beinhaltet. Thomas konzentriert sich aber zunächst mal auf die Anbindung des Webservice und die funktioniert jetzt auch zufriedenstellend. Mittlerweile sind zwei Tage vergangen.
    • Um die vielen Änderungen im Batch zu überprüfen führt Thomas stichprobenartig ein paar Tests durch. Tatsächlich offenbaren diese Test auch neue Fehler und Thomas beginnt mit deren Beseitigung. Da der Algorithmus für die Batchverarbeitung relativ kompliziert ist, sind die Tests auch entsprechend aufwendig. Thomas benötigt weitere 3 Tage dafür und ist auch bis zum Statusmeeting noch nicht fertig.

    So unbefriedigend das für das Projektmanagement ist, aber bei der Entwicklung kann bis zur letzten Minute immer etwas schief gehen. Die meisten Probleme lassen sich schnell und ohne große Auswirkungen beheben. Ob das so ist, hängt ganz wesentlich von der Qualität der Vorarbeit ab, also von der Anforderungsermittlung, dem Design der Anwendung und nicht zuletzt auch von der Qualität des Codes, welchen der Entwickler für dieses Feature geschrieben hat. Gut strukturierter Code lässt sich praktisch immer leichter anpassen als Code mit vielen Abhängigkeiten.
    Trotzdem, ganz sicher können Sie erst sein, wenn das Feature vollständig entwickelt und getestet wurde.

    Also lassen Sie am besten die ganzen Prozentzahlen weg. “Fertig” ist ein binärer Zustand. Entweder ist etwas fertig oder es ist nicht fertig. Punkt.

    Wenn das für ihre Fortschrittskontrolle ein Problem ist, dann sind die Einheiten zu groß. Ich würde immer versuchen Tasks zu verfolgen, die 1-3 Tage dauern (maximal eine Woche). Wenn die Tasks größer sind: Einfach so lange zerlegen, bis es passt.

    Definieren Sie “Fertig”!

    Es ist ganz wichtig, dass alle die gleiche Vorstellung haben, was “Fertig” tatsächlich bedeutet. Das mag sich auf den ersten Blick recht komisch anhören. Im Wesentlichen geht es darum, welche Tätigkeiten erfüllt sein müssen, damit ein Task wirklich als abgeschlossen gilt:

    • Implementierung
      Das versteht sich eigentlich von selbst. Ich habe auch noch niemanden getroffen, in dessen Definition von “Fertig” die Implementierung nicht enthalten ist.
    • Entwicklertest
      Eigentlich auch selbstverständlich, fällt aber unter Zeitdruck gerne mal unter den Tisch.
    • Unit-Tests
      Wenn Unit-Tests Bestandteil der Implementierung sind, dann gehören sie natürlich auch dazu. Leider unterliegen sie denselben Beschränkungen wie Entwicklertests, d.h. sie werden im Zweifelsfall einfach weggelassen.
    • Dokumentation
      Da wird es schon schwieriger. Wenn die Dokumentation ein laufender Prozess zusammen mit der Entwicklung ist dann gehört das auf jeden Fall auch mit rein. Vielleicht ist die Dokumentation aber auch ein separater Arbeitsschritt, der erst am Ende der Implementierung stattfinden soll. In beiden Fällen gilt dasselbe wie beim Test: Wird bei Zeitdruck gerne komplett weggelassen.
    • Integration / Bereitstellung
      Kann man in “Fertig” integrieren, muss aber nicht unbedingt sein. Das hängt davon ab, wie im Team entwickelt wird. Es ist durchaus auch vorstellbar, dass die Integration bzw. Bereitstellung in regelmäßigen Abständen von beispielsweise 4 oder 8 Wochen erfolgt, statt jedes Feature einzeln bereit zu stellen.
    • Qualitätssicherung
      Wenn Sie eine Qualitätssicherung z.B. in Form eines Code-Reviews durchführen, dann gehört das für mich ebenfalls zur Definition von “Fertig”. Bedenken Sie, dass diese Maßnahme zu (eventuell aufwendigen) Änderungen im Code und damit zu einer signifikanten Verlängerung der Fertigstellungsdauer führen kann.
    • Abnahme durch Kunden / Auftraggeber
      Da kann man auch geteilter Meinung sein. Sicherlich ist das Feature wirklich erst dann “fertig”, wenn der Kunde es so akzeptiert. Auf der anderen Seite würde ich eher dazu tendieren, für etwaige Beanstandungen bei der Abnahme einen neuen Task aufzumachen.

    Schweigen ist nicht immer Gold!

    An der obigen Liste sehen Sie, dass es sehr unterschiedliche Vorstellungen in Bezug auf “Fertig” geben kann. Sorgen Sie deshalb unbedingt gleich am Anfang dafür, dass Sie deutlich an das Team kommunizieren, wie ihre Definition aussieht.

    Ganz wichtig: Ohne Kontrollmöglichkeit können Sie kein effektives Projektmanagement betreiben. Definieren Sie deshalb zusätzlich etwas “handfestes”, was als Abschluss der jeweiligen Tätigkeit vorliegen muss. Das kann beispielsweise für die Dokumentation ein entsprechendes Dokument sein. Oder für den Test ein Testprotokoll. Oder für den Code-Review eine schriftliche Bestätigung des Reviewers. Auf jeden Fall muss es etwas sein, was Sie als Projektleiter in die Lage versetzt einen Haken zu machen (und zwar ohne vorher großen Aufwand zu treiben).

    Über eines müssen Sie sich dabei im Klaren sein: Es gibt nur sehr wenige Teammitglieder, die von sich aus darauf achten werden alles zu ihrer Zufriedenheit zu erledigen. Das hat nichts mit Bosheit oder Boykott zu tun. Selbst wenn ein Teammitglied von diesen Maßnahmen überzeugt ist – unter Zeitdruck gelten auf einmal ganz andere Regeln.

    Das bedeutet in der Praxis: Es muss eine fortwährende Kontrolle stattfinden und Sie müssen dafür sorgen, dass das so bleibt. Entweder Sie kontrollieren selbst, oder Sie finden jemanden, der das für Sie erledigen kann. Das heißt aber auch: Definieren Sie für den Zustand “Fertig” nur die Arbeitsergebnisse, die Sie dauerhaft kontrollieren wollen und können.

    Psychologie und Arbeitskultur

    Nehmen wir einmal an, Sie haben alle oben genannten Ratschläge befolgt. Das Team hat eine gemeinsame Vorstellung von “Fertig” und es gibt klare Arbeitsergebnisse, die eine einfache Kontrolle ermöglichen. Trotzdem können Sie immer noch folgende Situation erleben:

    “Also, Thomas, wie sieht es mit Feature 49 aus?”.

    “Ist Fertig.”

    “Sehr gut, wir gucken uns das gleich im Anschluss zusammen in der Entwicklungsumgebung an.”

    “Äh, na ja, man kann es da schon aufrufen, ich würde aber gerne noch ein paar abschließende Tests durchführen!”

    Vielleicht hat Thomas noch gar keine Tests durchgeführt. Vielleicht hat er auch Tests in einer anderen Umgebung gemacht, ein Testprotokoll erstellt und möchte nur noch einmal sicher stellen, dass auch in der Entwicklungsumgebung alles reibungslos funktioniert. So oder so, warum hat er gesagt, er wäre fertig obwohl er es eigentlich noch nicht ist?

    Die Antwort ist ganz einfach: Zum Einen ist es ihm unangenehm und zum Anderen hat er sicherlich nicht damit gerechnet, dass der Projektleiter sich das Feature sofort ansehen möchte. In aller Regel gibt es zu jedem Task auch einen Termin für die Fertigstellung. Ich kenne kaum einen Entwickler dem es nichts ausmacht zu sagen: “Ich habe es nicht geschafft, rechtzeitig fertig zu werden!”. Selbst wenn er gute Gründe für eine Verzögerung hat – es kostet die allermeisten Menschen Überwindung, das unumwunden zuzugeben.

    Ganz viel hängt davon ab, wie die Arbeitskultur innerhalb des Projektes aussieht. Hier können Sie als Projektleiter ansetzen und durch ihr eigenes Verhalten für Offenheit und Ehrlichkeit sorgen.

    Akzeptieren Sie es, wenn ein Entwickler eine Verspätung zugibt. Sie dürfen aber nicht nur so tun als ob, sie müssen es wirklich akzeptieren. Es nützt nichts, wenn Sie “kein Problem” sagen und dabei die Stirn runzeln oder mit den Augen rollen. Sagen Sie den Teammitgliedern, wie wichtig Ihnen eine ehrliche Kommunikation ist und dass Sie keinem den Kopf abreißen, wenn er schlechte Nachrichten hat.

    Es ist sehr motivierend, Dinge als fertig abhaken zu können. Sie können für jeden Task eine Checkliste mit den einzelnen Schritten entwickeln und diese vom Team abhaken lassen. Dadurch motivieren Sie die Teammitglieder (denn sie können regelmäßig Fortschritte verzeichnen) und sparen sich vielleicht auch einiges an Zeit bei der Statusermittlung im Meeting. Oder vielleicht braucht man das Statusmeeting dann gar nicht mehr…

    Eine Bitte an den Entwickler

    Ein Projektleiter fragt nicht nach Terminen, damit er etwas in der Hand hat um seine Leute unter Druck zu setzen. Er fragt auch nicht danach, damit er Ihnen die Schuld geben kann, falls der Termin nicht gehalten wird. Jedenfalls sollte er das nicht. Er fragt nach einem Termin, damit er planen kann. Damit er Ressourcen- oder Terminkonflikte rechtzeitig erkennen kann. Er braucht einen Termin, damit er seine Arbeit tun kann. Und je präziser der Termin ist, desto besser.

    Wenn Sie als Entwickler sehen, dass es bei einem Task zu Problemen kommt, die ein Einhalten des Termins unmöglich machen, dann ist es sehr wichtig, das so früh wie möglich zu kommunizieren. Zögern Sie nicht und sagen Sie dem Projektleiter (oder wer immer der korrekte Ansprechpartner ist), wo die Probleme liegen und das der Termin aller Voraussicht nach nicht zu halten ist.

    Natürlich wird der Projektleiter nicht in Begeisterungsstürme ausbrechen. Vielleicht sagt er es Ihnen auch nicht direkt aber er weiß eine solche Art der Kommunikation mit Sicherheit zu schätzen.

    Vielleicht fragt er Sie, wie lange es Ihrer Meinung nach dauert die Probleme zu beseitigen. Wenn Sie eine gute Vorstellung davon haben, dann teilen Sie diese ruhig mit. Wenn nicht, dann machen Sie keine mehr oder weniger vagen Angaben. Sagen Sie einfach: “Ich kann das zum jetzigen Zeitpunkt nicht sagen. Jede Angabe wäre kaum besser als zu raten.” Wahrscheinlich können Sie aber sagen, welche Arbeiten nötig sind, um eine präzisere Angabe zu machen. Teilen Sie das dem Projektleiter mit und er wird sehen, dass Sie Ihr Bestes geben, um ihn so gut wie möglich zu unterstützen.

    Zusammenfassung

    1. Verzichten Sie für einzelne Tasks auf Prozentangaben zur Fertigstellung.
    2. Definieren Sie genau, was Sie unter “Fertig” verstehen und welche Tätigkeiten dieser Begriff umfasst.
    3. Wenn möglich, definieren Sie Arbeitsergebnisse, die sich einfach und dauerhaft kontrollieren lassen.
    4. Fördern Sie eine offene und ehrliche Kommunikation im Team, indem Sie Verzögerungen akzeptieren.
    5. Erstellen Sie für jeden Task eine Checkliste mit Zwischenergebnissen.

     

    All diese Maßnahmen verhindern nicht, dass es überhaupt zu Verzögerungen kommt. Es gibt Menschen die behaupten, das gehört zum Projektmanagement von IT-Projekten dazu. Ich sehe das anders. Wenn es immer wieder zu relevanten Verspätungen kommt, dann muss man das nicht als gegeben hinnehmen sondern sollte die Ursachen dafür ermitteln. Darüber werde ich in einem späteren Artikel noch Einiges schreiben.

    Wichtig ist hier, dass Sie über Verzögerungen rechtzeitig informiert sind. Nur dann haben Sie die Möglichkeit, angemessen darauf zu reagieren.

    1 Comment

One Response to “Terminplanung: Fertig! – Fertig?”

  1. Hallo,

    ein guter Beitrag wie ich finde. Ich möchte anmerken, dass das tatsächliche Projekt natürlich nie unter diesen Idealbedingungen abläuft. Auch die Erstellung und Bewertung der Tasks kostet Zeit. Und eine zu große Stückelung kann sich auch schnell in einem organistorischem Overhead widerspiegeln.
    Aber für solche Fälle gibt es ja Projektmanagement Software. Klar ist da schnell was zugeklickt, deswegen finde ich die Aussage im Text zur offenen Kommunikation absolut wichtig.

    Danke und weiter so

    Grüße
    Wolfgang

Leave a Reply