Wie lässt sich die Dauer eines IT-Projekts schätzen und wann sollte es überhaupt nicht durchgeführt werden?

Published on July 22, 2018

Wie lässt sich die Dauer eines IT-Projekts schätzen und wann sollte es überhaupt nicht durchgeführt werden?

Ursprünglicher Autor: Johanna Rothman
  • Übersetzung


Jeder möchte wissen, wie lange das Projekt dauert. In diesem Artikel erklären wir, wie Sie dem Manager gleichzeitig eine genaue und unsichere Prognose geben können, die Zykluszeit verwenden und Geschichten zählen, und Tipps geben, wann eine Bewertung vermieden werden kann.

Celeste spürte Druck. Ihr Manager Barry wollte vierteljährlich eine Prognose über die Arbeit ihres Teams erstellen. Die Aufgabe wurde durch die Tatsache erschwert, dass die Gruppe Celeste nicht an einem Produkt arbeitete: Barry wollte eine Prognose für drei gleichzeitig erhalten. Jeder von ihnen war Teil eines anderen Projekts.

Die Programmierer der Celeste-Gruppe hatten nicht genügend Informationen, um zumindest für ein ganzes Quartal zumindest eine Prognose zu erstellen.

Celeste beschloss, Barry zuzugeben und zu sehen, wozu sie kommen würden. Sie vereinbarte am nächsten Tag einen Termin und sammelte die Daten.

Das Mädchen kam genau um 10 Uhr in Barrys Büro an. Als sie an die Tür klopfte, telefonierte Barry noch immer. Er bedeutete ihr zu kommen und hob einen Finger, um klar zu machen: Er würde in einer Minute fertig sein.

Sie saß auf dem Besucherstuhl gegenüber seinem Schreibtisch.

Barry legte auf und drehte sich um: „Nun, lass uns den Zeitpunkt der Projekte besprechen, richtig?“

Celeste nickte und sagte: „Ja. Es scheint, dass dies in einer solchen Situation möglich ist. “

Barry runzelte die Stirn: „Es scheint? Ich brauche konkrete Verpflichtungen. Kein "scheint"! "

Celeste saß bequem:" Barry, werden Sie unter Druck gesetzt, diese drei Produkte zu veröffentlichen? "

„Woher weißt du das? - Barry schüttelte den Kopf. - Wenn Sie den Jungs von Vertrieb und Marketing zuhören, ist es eine Katastrophe, wenn wir sie jetzt nicht veröffentlichen. Ich weiß nicht, was ich darauf antworten soll, außer dass alles sein wird. "

"Aber letzten Monat haben Sie über ein Portfolio von Projekten diskutiert", erinnert sich Celeste. "Ich dachte, Produkt A habe oberste Priorität."

"So ist es", sagte er. "Beide Produkte B und C haben ebenfalls höchste Priorität."

Celeste verdrehte die Augen: „Aber du weißt, dass es nur eine oberste Priorität geben kann, oder?“

„Ich weiß das und du weißt es“, sagte er. "Aber meine Kollegen wissen es nicht." Ich brauche eine Prognose, die Sie machen können - nun, Verpflichtungen - und dann können Sie ruhig ein wenig atmen. “

"An welchem ​​Produkt sollten wir überhaupt arbeiten?", Fragte Celeste.

"Produkt A natürlich", sagte er. "Er ist am meisten zurückgezahlt."

"Nun, das machen wir", sagte Celeste. - Wir werden A innerhalb eines Monats belasten und freigeben. Ihre Aufgabe ist es, diese lieben Menschen jede Woche zu unseren Präsentationen zu bringen. Sie sollten sehen, was wir in einer Woche machen. Wenn sie nicht zur Demo kommen, lehne ich es ab, ihnen Informationen zu geben. “

Barry lehnte sich zurück: „Warte. Ich habe die Demo verstanden. Und was ist mit den anderen zwei Monaten? Und warum geben Sie ihnen keine Informationen? “

Celeste sagte:„ Wenn wir nur an einem Produkt gearbeitet hätten, könnte ich die Schätzung basierend auf unserem Entwicklungszyklus berechnen. Für Produkt A veröffentlichen wir drei oder vier Geschichten [Code für Benutzeraufgaben] pro Woche. Aber wir kennen den wirklichen Entwicklungszyklus für die Produkte B und C nicht. "

Barry nickte: "Warum nicht?"

"Die Produkte B und C sind in zwei und drei Monaten geplant", sagte Celeste. - Das ist ziemlich weit für das Marketing. Das Problem ist, dass die Marketingabteilung mit der jeweiligen Arbeit weniger Zeit braucht, um mit den Inhabern des Produkts zu klären. Wir wissen nicht, welche Funktionen in zwei und drei Monaten implementiert werden müssen. Wir müssten wissenschaftlich wild sein, SWAG. Das ist normal, ich mache das gerne mit meinen Jungs, aber wir brauchen mehr Details. Welches nicht ist. "

"Warum erzählst du ihnen nichts, wenn sie nicht zur Demonstration kommen?", Fragte Barry.

"Wenn es nicht wichtig ist, dass sie unsere Fortschritte beobachten und Feedback geben, ist das Timing nicht sehr wichtig", sagte Celeste. "Sie möchten, dass wir uns verpflichten, ohne dafür unsere Verpflichtungen aufzugeben." Warum sollte ich Zeit verbringen, um zu bewerten, ob sie nicht beitragen wollen? “

Barry erklärte sich bereit, eine monatliche Zeitbox an Manager zu verkaufen , die Druck auf ihn ausüben , um Zeitpläne festzulegen. Celeste wird sicherstellen, dass sich das Team nur auf das Produkt A konzentriert. Außerdem hat sie wöchentliche Demonstrationssitzungen abgehalten, damit das Team seine Arbeit zeigte und Feedback erhielt.

Würdest du versucht sein, noch etwas zu tun?

Timing - nicht triviale Arbeit


Das Timing ist auch ein Job. Viele Teams legen solche Verfahren in ihren regulären Arbeitsplan ein. Eine genaue vierteljährliche Schätzung erfordert jedoch häufig mehr als eine oder zwei Stunden Arbeit.

Bei der Bewertung der vierteljährlichen Arbeit gibt es mindestens zwei Probleme. Zu oft sind die Anforderungen nicht vollständig definiert, und wie beim Celeste-Team führt das Assessment dazu, dass das Team keine dringenden Arbeiten am Projekt vornimmt.

Das Problem ist, dass die Planung von Softwareentwicklung nicht wie eine Roadtrip-Planung ist. Wenn es in Ihrer Stadt mehr als eine Ampel gibt, sind Sie mit den Verkehrsschwankungen vertraut. Ich wohne in einem Vorort von Boston, von wo aus eine Fahrt zum Flughafen 20 und 90 Minuten dauern kann. Meistens 30 bis 45 Minuten. Dies ist eine signifikante Variante für eine 13 km lange Reise.

Und auf dieser Reise gibt es keine Innovation. Ich war oft am Flughafen und kenne verschiedene Wege, um dorthin zu gelangen. Ich habe mobile Apps, die dabei helfen , die schnellste Route auf dem Weg zu finden. Obwohl einige Optionen etwas vorhersehbarer sind, kann keine von ihnen garantieren, dass diese bestimmte Fahrt in 20 Minuten abgeschlossen wird.

Die Fahrt zum Flughafen erfolgt auf einer vorgegebenen Route und mit gut verstandenen Hindernissen. Produktentwicklung ist jedoch eine andere Sache. Das ist Innovation. Mit anderen Worten, wir haben so etwas noch nicht gemacht. Andernfalls müssten wir keine neue Anwendung schreiben oder ein veraltetes System aktualisieren - wir würden das alte System verwenden.

Für eine vernünftige Beurteilung haben wir mehrere Möglichkeiten. Eigentlich drei:

  • Sie können die Größenordnung schätzen. Ich denke, das ist nützlich für das gesamte Projekt. „Wir gehen von fünf bis neun Monaten Arbeit aus. Wir werden besser lernen, wenn wir diese Fragen beantworten und diesen Teil der schwierigen Arbeit beenden. “ Die SWAG eignet sich gut für solche Bewertungen.
  • Sie können sich ausreichend über die Anforderungen informieren und eine angemessene Schätzung abgeben. Das Team muss möglicherweise mit User Storys arbeiten, um eine Prognose mit einer relativ geringen Zeitspanne zu erstellen.
  • Es gibt eine Option, um die Arbeit für einen kurzen Zeitraum zu bewerten, beispielsweise für eine oder zwei Wochen. Möglicherweise ist die endgültige Prognose nicht ganz korrekt. Normalerweise ist er dem Ergebnis jedoch nahe genug, um die Leute nicht zu enttäuschen, die darum gebeten haben.

Welche Prognose braucht der Manager?


Ich habe festgestellt, dass Manager oft eine Schätzung der Größenordnung benötigen . In diesem Fall kann das Team eine Prognose erstellen und wie folgt berichten:

„Wir glauben, dass dieses Projekt fünf Monate dauern wird, wobei die Genauigkeit dieser Prognose zu 50% überzeugt ist. Bei der Einschätzung von acht Monaten sind wir zu 80% sicher. Zehn Monate sind 90% Vertrauen. "

Dies hilft den Managern zu verstehen, dass es eine Reihe von Vertrauen gibt. Wenn sie 100% Vertrauen haben wollen, kann es mehr als 14 Monate dauern.

Sie können die Spiralmethode verwenden: „Wir konzentrieren uns auf das erste Quartal des nächsten Jahres. Wir wissen nicht genau, wann genau wir im ersten Quartal sind, aber wir glauben, dass wir damit umgehen können. “ Im Verlauf des Projekts stellen Sie klar: "Wir aktualisieren die Bewertung für einen Zeitraum zwischen Mitte Januar und Mitte März." Noch mehr gelernt, sagen Sie: "Irgendwo im Februar, wenn es keinen Schneesturm gibt." Im Januar kann man dann sagen: "Die dritte Februarwoche."

Ich würde auch drei Termine empfehlen: „Der optimistische Termin ist Januar. Am realistischsten ist Ende Februar. Am pessimistischsten ist Ende April. “

Geben Sie auf keinen Fall eine Bewertung ab. Es verführt Saint Murphy (aus Murphys Gesetz), Ihr Projekt in Angriff zu nehmen und unangenehme Dinge zu machen.

In einigen Fällen und in einigen Teams benötigt der Kunde möglicherweise zusätzliche Informationen. Hier können Sie mit ihm spezifische realisierbare Funktionen besprechen, um die Unsicherheiten zu verstehen.

Verwenden Sie die Zykluszeit anstelle der Bewertung


Ich mag keine Prognosen für die Implementierung von Softwareprojekten oder anderen IT-Projekten, insbesondere von Agile. Stattdessen ziehe ich dem Team vor, sehr kleine Geschichten zu veröffentlichen oder die Arbeit nach Zykluszeit zu bewerten.

Wenn Sie mit der Terminologie nicht vertraut sind:

  • User Stories beschreiben, wie ein Kunde oder Benutzer ein Produkt zu einem bestimmten Zweck einsetzt („Ich möchte einen Platz reservieren“ oder „Ich muss Smart City-Daten veröffentlichen, um die Transparenzanforderungen zu erfüllen“). Die Storys unterscheiden sich vom Aussehen eines Entwicklers, der ein Produkt in Bezug auf Datenbanken und APIs betrachtet.
  • Die Zykluszeit bezieht sich auf die Gesamtzeit, die ein Team benötigt, um die Arbeit an einer Story freizugeben. Dies umfasst sowohl aktive Entwicklungszeiten als auch Ausfallzeiten, wenn die Arbeit auf etwas wartet.

Die Idee ist, die durchschnittliche Zeit zu verstehen, die benötigt wird, um etwas Nützliches (Geschichte) zu erzeugen.

Im Fall von Celeste wusste sie, dass ein Team für Produkt A drei bis vier Geschichten pro Woche produzieren kann. Für viele Teams funktioniert das Story Counting wie andere Bewertungsmethoden.

Wenn das Team noch nie an einem ähnlichen Produkt gearbeitet hat, gilt die vorherige Zykluszeit nicht für dieses neue Produkt. Das Team weiß möglicherweise nicht, wie die Geschichten verfeinert und aufgeteilt werden müssen, um mehrere pro Woche zu veröffentlichen. Darüber hinaus ist sie möglicherweise nicht über den Status des Codes und das Vorhandensein einer ausreichenden Anzahl von Tests informiert. Wenn Ihr Team länger als drei Tage an Geschichten arbeitet, kümmern Sie sich nicht um die Prognose. Zähle die Geschichten und versuche nicht mehr als üblich zu machen.

Als das Team innerhalb von ein bis zwei Tagen damit begann, sich mit den Geschichten auseinanderzusetzen, müssen Sie auch keine Bewertung vornehmen. Oft ist eine einfache Berechnung einfacher und genauer.

Warum nicht Geschwindigkeit verwenden?


Sie haben festgestellt, dass ich Zykluszeit und Storyzählung empfehle, und nicht die Arbeitsgeschwindigkeit, um die Projektzeit zu schätzen. Weil Geschwindigkeit ein Ersatzwert ist.

Zum Beispiel gehe ich jeden Tag um fit zu bleiben. Ich folge jeden Tag der gleichen Route und verfolge meine relative Geschwindigkeit. An einem schönen sonnigen Tag gehe ich ungefähr 5,6 km pro Stunde. An regnerischen oder heißen und feuchten Tagen sinkt die Geschwindigkeit auf 4 km / h. Im Schnee oder Eis kann überhaupt nicht ausgehen, in diesem Fall ist meine Geschwindigkeit gleich 0.

Ich gehe die gleiche Route. (Ja, es ist langweilig, aber das ist mein Problem). Obwohl ich dieselbe Strecke zurücklegen muss, dauert die Straße je nach den Bedingungen unterschiedlich. Die Bedingungen sind hier ähnlich wie bei der Codebasis und den Tests Ihres Teams.

Wenn die Geschichten klein genug sind, entspricht die Geschwindigkeit der Zykluszeit. Aber zu oft versuchen Manager, Projekte mit sehr großen Geschichten zu bewerten. Die Zählung wird einfacher: „Wir können ein oder zwei Geschichten pro Zyklus beenden. Welche oder zwei Geschichten möchten Sie wählen? "

Die Bewertung zu verweigern ist kein Scherz.


Als Barry die Angelegenheit mit seinen Kollegen besprach, sagte einer von ihnen

: "Es ist kein Betrug, die Fristen einzuschätzen!", Antwortete Barry: "Das stimmt nicht. Sie möchten, dass wir ein Produkt veröffentlichen, oder? “Die

Antwort lautete:„ Natürlich. Sowohl B als auch C.

"Das Problem ist, dass sie abwechselnd gemacht werden müssen", sagte Barry. - Wenn Sie Produkt A benötigen, was ist der Sinn einer Prognose für den Rest? Wir können uns an die Arbeit machen und unseren Fortschritt zeigen. Wenn wir genug getan haben, werden wir das Verfahren für B und C wiederholen. Außerdem haben Sie Zeit, die Anforderungen für B und C zu klären, um Geschichten für uns vorzubereiten. “

Celestes Team hat den Großteil von Projekt A in einem Monat abgeschlossen. Die Produktversion B dauerte länger - näher an zwei Monaten. Und da das Unternehmen durch die Veröffentlichung der Produkte A und B ausreichende Einnahmen

erzielt hat , hat es den Druck auf die Veröffentlichung von Produkt C verringert. Wissen Sie, welche Punktzahl Ihr Manager benötigt. Gib es so, wie es braucht. Und wenn Sie wenig Zeit haben, machen Sie sich an die Arbeit.

Bewertung von IT-Projekten: Unterricht


  • Geben Sie keine bestimmten Zahlen oder Daten an. Geben Sie stattdessen eine Schätzung der Größenordnung an, die das Vertrauen in die rechtzeitige Veröffentlichung anzeigt. Oder bieten Sie kurzfristige Beurteilungen an, die auf Faktoren beruhen, die unter Ihrer Kontrolle liegen.
  • Trennen Sie Projektaufgaben in User Storys, die die Funktionalität der Software definieren. Nehmen Sie dann Ihre Schätzungen basierend auf der Anzahl der User Storys vor, die Sie verarbeiten können.
  • Stellen Sie sicher, dass Sie die Anforderungen verstehen, bevor Sie Verpflichtungen eingehen.