Was tun, wenn die Zeitschätzung schief geht?


26

Angenommen, Sie schätzen die Zeit für einen Fall auf 3 Tage. Am zweiten Tag stellen Sie fest, dass der Fall wächst und neue Szenarien auftauchen, die bei der Zeitschätzung nicht berücksichtigt wurden. Der neue Befund führt zu einer Verlängerung um 2 Tage (insgesamt 5 Tage). Dies ist ein typisches Problem, mit dem Sie früher oder später als Entwickler konfrontiert werden.

  • Mit welcher Strategie können Sie den Projektleiter über den neuen Liefertermin informieren?
  • Oft stellt sich die Frage warum? Wie motivieren Sie den neuen Liefertermin?

Tatsache ist, dass viele Projekte während SDLC nicht viel Zeit für Analyse und Design aufwenden.

BEARBEITEN: In sehr komplexen Projekten gibt es immer Überraschungen, egal wie viel Zeit Sie für Analyse und Design aufwenden, da die Geschäftsregeln zu komplex sind. In solchen Fällen muss sich der Projektleiter meiner Meinung nach der Komplexität bewusst sein und die richtige Einstellung haben, wenn unerwartete Überraschungen auftauchen. Die Frage ist, wie man Projektleiter anpackt, die die Komplexität nicht verstehen.


1
Ich denke, die bessere Frage ist, was tun Sie, wenn die Schätzung korrekt war ? Meistens wird es nicht sein.
Tim Post

@Tim Post Du hast Recht mit "Meistens wird es nicht so sein" Ich wollte reservieren.
Amir Rezaei

1
+1 - Danke für den EDIT, der Worte der Weisheit enthält . Die Tatsache, die Sie hervorgehoben haben ("" Bei sehr komplexen Projekten, egal wie viel Zeit Sie für Analyse und Design aufwenden, gibt es immer Überraschungen, da die Geschäftsregeln zu komplex sind.) "" Ist sehr richtig.
Karthik Sreenivasan

Antworten:


17

Schlechte Nachrichten überbringen

Sie müssen die Angelegenheit unbedingt umgehend zur Sprache bringen. Wenn Sie dies jedoch in einem angemessenen Zeitrahmen tun können (das sind einige Stunden, nicht mehr), sollten Sie zuvor eine Folgenabschätzung durchführen.

Wie bei allen schlechten Nachrichten ist es am besten, detaillierte Informationen zur Verfügung zu stellen (anstatt nur "es wird spät sein" auszusprechen).

1) Überarbeitete Schätzungen / Zeitpläne für die Aufgaben, die verrutscht sind.

2) Überarbeitete Schätzungen / Zeitpläne für zukünftige Aufgaben, die Ihrer Ansicht nach angesichts der Tatsache, dass einige Dinge bereits übergelaufen sind, möglicherweise länger dauern.

3) Sehr kurze Gründe, warum der Schlupf aufgetreten ist (drehen Sie nicht, nur die Wahrheit, aber klingen Sie nicht, als würden Sie Entschuldigungen vorbringen). In diesem Fall geben Sie an: "Wir haben basierend auf den Regeln X und Y geschätzt, aber sie haben jetzt Z eingeschlossen, das nie erwähnt wurde." Möglicherweise kann er dies nutzen, um Kunden die Verzögerung zu erklären und sie über die Wichtigkeit zu informieren, überhaupt gründlich zu sein.

4) Falls mögliche Alternativen vorhanden sind, um die Dinge wieder auf den richtigen Weg zu bringen (in der Regel wird der Umfang verringert, es gibt jedoch möglicherweise andere Optionen - andere Teile des Projekts sind möglicherweise zeitlich vorverlegt und es ist möglich, Aufgaben zu verschieben).

Denken Sie daran, dass die Auswirkungen auf die Psychologie / Glaubwürdigkeit durch Ausrutscher kulmulativ sind. Sie können vielleicht mit einem davonkommen, aber der zweite wird viel härter und der dritte noch härter.

Deshalb ist Punkt 2 wichtig - überarbeiten Sie nicht nur das, was bereits verrutscht ist, sondern auch zukünftige Aufgaben, von denen Sie jetzt glauben, dass sie länger dauern als ursprünglich angenommen. Ausrutschen passiert in ITs, nicht aus Ihren Fehlern zu lernen, ist eine größere Sünde.

Verhindern, dass schlechte Nachrichten geliefert werden müssen

Hier gibt es zwei Szenarien: Erstens haben Sie die Schätzungen nicht selbst vorgenommen. In diesem Fall können Sie nur darauf drängen, das nächste Mal an den Schätzungen teilzunehmen.

Zweitens haben Sie die Schätzungen selbst vorgenommen. In diesem Fall müssen Sie sich überlegen, wie Sie bessere Schätzungen vornehmen können. Für mich lautet der Schlüsselbegriff in der Frage "Es gibt immer Überraschungen, da die Geschäftsregeln zu komplex sind" .

In Bezug auf Respekt sollte es keine Überraschung sein , wenn es immer passiert . Wenn Sie immer nur die Hälfte der Geschäftsregeln erhalten, müssen Sie dies in Ihren Schätzungen annehmen und das Kriechen der Funktionen berücksichtigen.

Sie können dies entweder durch Erhöhen der Schätzungen für die Regeln tun, die Sie haben (es funktioniert, aber Sie unterrichten niemanden darüber, was wirklich passiert) Die Umsetzung der von ihnen angegebenen Regeln wird 3 Tage dauern, wir sollten jedoch weitere 3 Tage für die Regeln einplanen, die nicht erwähnt wurden, aber wahrscheinlich während der Entwicklung und des Testens entdeckt werden. "

Wenn der Ministerpräsident dies in Frage stellt, müssen Sie ihn daran erinnern, wie oft dies der Fall war (mit Beispielen - es ist schwierig, Beispiele zu argumentieren) und behutsam darauf hinweisen, dass es in seinem Interesse ist, nicht nur Ihre, sondern auch Ihre Termine einzuhalten lieber konservativ sein?

Aber das Fazit: Wenn Sie aufgrund eines bestimmten Faktors (in diesem Fall Kriechen) immer unterschätzen, dann rechnen Sie das in Ihre Schätzungen ein.


2
+1 "Wie bei allen schlechten Nachrichten ist es am besten, detaillierte Informationen zur Verfügung zu stellen" Allerdings versteht nicht jeder die Details / Komplexität des Problems.
Amir Rezaei

@Amir - Ich habe ein bisschen mehr hinzugefügt, aber als die Person, die die Komplexität versteht, ist die einfache Wahrheit, dass es in Ihrer Verantwortung liegt, sie zu erklären. Sie werden nicht anders lernen.
Jon Hopkins

Gute Argumente! "mit Beispielen - es ist schwer, Beispiele zu argumentieren" & "mit Bedacht darauf, dass es in seinem Interesse ist, pünktlich zu liefern". In Bezug auf "wenn es immer passiert, sollte es keine Überraschung sein", ist das Problem, dass die zusätzliche Zeit für die Überraschung nicht konstant ist. Sie können also nicht einmal einen Durchschnitt für sie annehmen, da sie tendenziell große Schwankungen aufweisen.
Amir Rezaei

+1 "Denken Sie daran, dass die Auswirkungen auf die Psychologie / Glaubwürdigkeit bei Ausrutschungen kumulativ sind."
Karthik Sreenivasan

16

Zeitbasierte Schätzungen sind Vermutungen über die Zukunft, die auf lange Sicht immer scheitern werden. Es ist ein sinnloser Kampf, den Sie nicht gewinnen können.

Beenden Sie die Schätzung in Tagen und verwenden Sie stattdessen die relative Schätzung . Hier ist ein einfaches Beispiel:

  1. Weisen Sie jeder Aufgabe eine Nummer zu. Die schwierigste Aufgabe kann 10 und die einfachste Aufgabe 1 sein.
  2. Starten Sie die Programmierung, um Ihre Aufgaben abzuschließen.
  3. Unterbrechen Sie nach einer Woche Ihre Arbeit und addieren Sie alle erledigten Aufgaben. Nehmen wir an, Sie haben am Ende 14 Punkte. Das ist Ihre wöchentliche Geschwindigkeit.

Wiederholen Sie den Vorgang nächste Woche erneut. Ich wette, deine Geschwindigkeit wird sich ändern, aber nicht viel. Nach ein paar Wochen sollte Ihre Geschwindigkeit ziemlich stabil sein und das ist, was wir anstreben. Jetzt können Sie mit Zuversicht Pläne schmieden. Wählen Sie Aufgaben aus, die sich nach Ihrer Geschwindigkeit richten, und Sie können sicher sein, dass Ihre PM wie versprochen abgeschlossen wird. So sollten Sie Ihre Projektleiter angehen.


Können Sie ein Beispiel geben, wie Sie die Größe der Aufgaben verfolgen? Erstellen Sie eine Tabelle mit Aufgabentypen (z. B. "Neues Formular erstellen", "Webservice X um eine Methode erweitern") oder ist es eher ein Bauchgefühl?
Cringe

Vergleichen Sie einfach mit Aufgaben, die Sie vorher geschätzt und erledigt haben.
Martin Wickman

+1 - "Zeitbasierte Schätzungen sind Vermutungen über die Zukunft, und das wird auf lange Sicht immer scheitern. Es ist ein sinnloser Kampf, den Sie nicht gewinnen können." Dies ist das erste Mal, dass ich etwas über relative Schätzungen erfahre, und es ist definitiv ein Denkanstoß. Vielen Dank.
Karthik Sreenivasan

Was für eine geniale Idee! Ich werde dies definitiv weiter untersuchen.
Treffen

3

Sobald Sie feststellen, dass die Schätzung falsch ist, müssen Sie die Alarmglocke auslösen. Informieren Sie diejenigen, die die Lieferung erwarten, über die Verzögerung.

Bitten Sie wenn möglich Ihre Teamkollegen um Hilfe. Stellen Sie sicher, dass Sie weiterhin so hochwertige Software wie möglich liefern.

Eine Abkürzung wird am Ende höchstwahrscheinlich mehr Schaden anrichten, und das sollten alle Beteiligten wissen. Oder zumindest sollte es möglich sein, es ihnen zu erklären.


3

Dies kommt so oft vor, dass kein erfahrener Projektmanager viel damit anfangen kann. Seien Sie einfach ehrlich und nehmen Sie keine zu optimistischen neuen Schätzungen vor. Wenn Sie sehen, dass es viel länger dauert, sagen Sie es. Sagen Sie nicht täglich "Ich brauche ein bisschen mehr Zeit".

Sie müssen dem Manager erklären: War die Schätzung an erster Stelle falsch oder waren ungünstige Umstände (ein Tag auf der Suche nach einem Fehler) der Grund für die Verzögerung? Im ersten Fall stimmt etwas mit dem Schätzungsprozess nicht, vielleicht ist es zu optimistisch oder zu naiv. Im zweiten Fall ist es ein Fall für den Puffer, der hoffentlich im Projektplan enthalten war.


2

Halten Sie die relevanten Stakeholder stets über Ihre Fortschritte auf dem Laufenden, einschließlich (insbesondere!) Der Tatsache, dass Ihre Schätzungen zu optimistisch waren. Sie werden nicht glücklich sein, aber sie werden wissen, wo das Projekt wirklich steht und können entsprechend planen.

Im Idealfall wurde Ihre Liste mit Funktionen auf "MoSCoWed" gesetzt - "Muss, Sollte, Könnte, Wird nicht".

Wenn Sie auf der Suche nach einem Überlauf sind, schneiden Sie zuerst die Coulds und dann die Shoulds. Reduzieren Sie Features, damit Sie pünktlich versenden können: Ihr Projekt lebt normalerweise nicht isoliert, und Sie überschreiten das Veröffentlichungsdatum, sodass die nachgelagerten Projekte jetzt auch ihren Zeitplan überschreiten.

Im Idealfall haben Sie nur ~ 60% Musts. Wenn Sie diese schneiden müssen, sind Sie in großen Schwierigkeiten (mit einem sehr schweren Überlauf), in welchem ​​Fall Sie Ecken schneiden müssen.

Stellen Sie sicher, dass Sie sich nach der Freigabe genügend Zeit geben, um die Unordnung zu beseitigen, die durch das Schneiden von Ecken entsteht!


4
+1 @Frank Guter Punkt in Bezug auf "Schnitteigenschaften für pünktliches Versenden". Das Problem hier ist, dass ich nicht der Projektleiter bin.
Amir Rezaei

@Amir In diesem Fall ist Ihr Kunde Ihr Projektleiter. Sie sagen: "Ich bin im Rückstand. Ich kann dieses Feature oder das Feature abschneiden. Was soll ich tun?"
Frank Shearar

@Frank Da wir Scrum machen und der Fall vom Rückstand in den Sprint verschoben wird, scheint er für PM in Stein gemeißelt zu sein, um die Fälle zu reduzieren. Ein erfahrener PM hat jedoch möglicherweise kein solches Problem.
Amir Rezaei

Ich mag MoSCoW nicht. Das einzig Kluge daran ist das Akronym. Halten Sie einfach Ihre Aufgaben in einem priorisierten Rückstand.
Martin Wickman

1
@Martin Achselzucken "Muss" bedeutet "Wenn Sie diese Funktion nicht ausliefern , haben Sie überhaupt nichts". Das sind andere Informationen als bei einem priorisierten Rückstand. Welche Funktion würden Sie zuerst bevorzugen? Mit MoSCoW hätten Sie immer noch einen priorisierten Rückstand.
Frank Shearar

2

Die Projektschätzung ist schlicht und einfach Glücksspiel. Es gibt keine Belohnung ohne Risiko.

Wenn der Manager das nicht versteht, ist das das erste, was ich erklären würde.

Die Frage ist, wer das Risiko deckt.

Wenn Sie einen Festpreisvertrag abgeschlossen haben, übernehmen Sie das Risiko.

Wenn Zeit und Material, dann deckt er das Risiko.

Wenn Sie also schätzen, ist es wichtig zu verstehen, dass Sie raten und eine Vorstellung davon haben müssen, wie unsicher die Schätzung ist und wer das Risiko deckt.


1

Ich glaube, die beste Strategie ist es, Ihre Einschätzung ständig zu verfeinern . Ich weiß, ich sage: Ihre Frage ist irgendwie verlegt.

Beim Lesen von Introducing Deliberate Discovery von Dan North bin ich zu dem Schluss gekommen, dass die Einschätzung in der Anfangsphase gleichbedeutend damit ist, eine Vorhersage zu treffen, wann Ihre Unkenntnis des Problems und der Domäne auf einem maximalen Niveau liegt. Seien Sie ehrlich, Sie können nicht vorhersagen, was ungewiss ist, besonders wenn es noch unbekannt ist .

Agile Methoden lösen dieses Problem, indem sie die Lebensdauer des Projekts in mehrere Teile aufteilen (Sprints, in Scrum) und die Schätzung (Bemessung von Geschichten) jede Woche wiederholen. Jede Woche wird das, was Sie über das Problem wissen, und auch die Schätzung verfeinert.

Für mich kann eine Schätzung nicht wahr oder falsch sein. Es kann nur zunehmend verfeinert werden . Eine Schätzung ist keine Verpflichtung. Deshalb nennt man es Schätzung.

Das Beste, was Sie tun können, wenn Sie sich verspäten (und auch, wenn Sie "Gefahr laufen, im Voraus zu liefern", weil das Problem dasselbe ist: Sie haben es falsch eingeschätzt), ist, eskalieren und den Kunden so schnell wie möglich darauf aufmerksam zu machen. Es heißt Risikomanagement. Je früher Sie eine Rückmeldung geben, desto effektiver wird die Gegenstörung. In der Regel bedeutet dies, dass Sie, wenn Sie Beweise haben, dass Sie nicht alles liefern können, mit Ihrer Kundin sprechen und ihr sagen sollten, dass Sie nur die 70% der Verpflichtung erfüllen können, und sie entscheiden lassen, was für sie mehr geschäftlichen Wert hat und zuerst eingesetzt werden soll .

Ich habe hier darüber geschrieben Falsche Einschätzung, Hilfe! Ich bin spät dran! Schneiden Sie Features und stoppen Sie das Wasserfallen!


1

Es wird eine Schätzung genannt, weil es eine fundierte Vermutung ist. Es ist keine unfehlbare Beschreibung der Zukunft, und ich habe wenig Geduld mit Leuten, die Software-Schätzungen so behandeln. Letztendlich werden viele Dinge länger dauern als erwartet, in seltenen Fällen können sie eine Größenordnung länger dauern. Dies passiert sogar den besten Programmierern der Welt. Wie kann ein Manager erwarten, dass es Ihnen nicht passiert? Wenn Ihr Manager das nicht versteht, hat er nicht viel Erfahrung. Wenn sie vorgibt, es nicht zu verstehen, um Zeitdruck auszuüben, ist sie unvernünftig.

Der beste Ansatz ist der offensichtlichste. Sobald Sie eine klare Vorstellung davon haben, dass eine Funktion länger als erwartet dauern wird, besprechen Sie sie mit Ihrem Manager. Es gibt oft Möglichkeiten, wie Sie vorgehen können, um sowohl Ihre Probleme als auch die Ihres Managers zu lösen. Das heißt, der Teil des Features, der die Geschwindigkeit verlangsamt, ist möglicherweise relativ unwichtig oder lässt sich auf eine Weise ändern, die einen schnelleren Fortschritt ermöglicht. Wie auch immer, lassen Sie sich nicht in eine zweite optimistische Schätzung einmischen.


0

Lassen Sie es das gesamte Team wissen und versuchen Sie, eine Lösung zu finden. Ich empfehle 3 Lösungen von hoher bis niedriger Priorität:

ein. Versuchen Sie, einen temporären Hotfix oder eine schnelle Lösung zu finden

b. Die Arbeit, die Sie tun können, tun Sie es am besten. Bitten Sie den Kunden um Hilfe, nachdem Sie ihm Ihren ausgezeichneten Teil der Arbeit gezeigt haben: Wir können dies tun, aber es gibt ein Problem, und es kann die Produktivität Ihrer Arbeit verlangsamen. Vielleicht können Sie ihn fragen, ob es unnötige Anfragen gibt. Funktion, die fallen gelassen oder gekürzt werden kann.

Schlagen Sie einen alternativen Ansatz für ihr Problem vor, vielleicht eine gute Idee.

c. Überstunden


Ich habe meine Frage aktualisiert. Es ist der Projektleiter, der benachrichtigt wird.
Amir Rezaei

Ich verstehe nicht ganz Sie sind Projektleiter oder nur Programmierer?
Hoàng Long

0

Optionen:

  • Schnitteigenschaften
  • Schnittqualität (lassen Sie Fehlerbehebungen für später)
  • Produktivität erhöhen
    • Blocker suchen und entfernen
    • Pause / Pause
    • Reduzieren Sie die persönliche / Schlafzeit
    • Holen Sie sich mehr Arbeitskräfte
    • Holen Sie sich bessere Werkzeuge
    • Ausbildung
    • Motivation steigern
      • Gratis Essen
      • [Versprechen von] Gehaltserhöhung / Beförderung / Urlaub / Bonus / etc.
      • Drohungen
      • Verbesserung der Arbeitsbedingungen (bessere Hardware, Möbel usw.)
      • Verändere die Umgebung - arbeite in einem Café oder bewege das ganze Team an einen kühlen Ort - eine Berghütte oder ein Seehaus?

1
Es sollte beachtet werden, dass jedes Wort davon eine KURZFRISTIGE Antwort auf die Frage ist, was zu tun ist, wenn die Zeitschätzung schief geht. Insbesondere erhöhen Bedrohungen kurzzeitig die Motivation und haben dann den gegenteiligen Effekt.
Dan Ray

Ich bin damit einverstanden, dass Bedrohungen scheiße sind, obwohl ich sicher bin, dass sie für einige Menschen und in bestimmten Situationen funktionieren, insbesondere wenn Sie vorhaben, sie trotzdem loszulassen.

0

Dies ist ein häufiges Problem :)

Eine der einfacheren Methoden besteht darin, jeder von Ihnen durchgeführten Schätzung einen Puffer hinzuzufügen, da immer unvorhergesehene Probleme auftreten. Die Größe des Puffers hängt von der Größe des Teams und der Unsicherheit der Technologie und des Problems selbst ab.

Größere Teams haben mehr Leute, die krank werden könnten, und weniger Leute, die "alles" wissen.

Neue Technologien sind immer riskanter als die, die Sie bereits kennen.

Und wenn Sie feststellen, dass Sie zum voraussichtlichen Zeitpunkt noch nicht fertig sind, sollten Sie frühzeitig mit den Stakeholdern kommunizieren. Vielleicht können Sie nach einem Gespräch mit dem Kunden / Stakeholder neue Prioritäten setzen oder bestimmte Funktionen verzögern.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.