Aufgabenschätzung für PMs, die keine Entwickler sind

Wenn möglich, tun sie das nicht.

Sie bitten die Entwickler, es zu schätzen.

Schätzungen sollten immer von den Personen vorgenommen werden, die die geschätzte Arbeit ausführen werden. Geschieht dies nicht, gehen Sie folgende zwei Risiken ein:

1. Die Schätzung ist ungenau, da die Person, die sie geschätzt hat, nicht wusste, welche Arbeiten durchgeführt werden mussten
2. Die Leute, die die Arbeit erledigen, haben kein Buy-in für diese Schätzung, und daher ist es weniger wahrscheinlich, dass sie auch ein Buy-in für ein Ziel oder eine Frist für dieselbe Arbeit haben.

Lassen Sie die Ausführenden der Aufgabe Schätzungen abgeben

In agilen Frameworks (und sogar in vernünftigen nicht-agilen Frameworks) sollten Projektmanager Workitems niemals selbst einschätzen. Stattdessen machen die Leute, die die Arbeit tatsächlich erledigen werden ("Task Performer") die Schätzung!

Um die realistischsten Schätzungen zu erhalten, lassen Sie die Task-Performer den Zeitaufwand und die Komplexität der Arbeit schätzen, die sie erledigen werden. Sie möchten, dass sie auf der Grundlage ihrer eigenen Fähigkeiten, Kenntnisse und Ressourcen schätzen, da es nicht wirklich darauf ankommt, wie lange es dauern würde, bis eine andere Person die Arbeit erledigt. Ganz pragmatisch zählt nur, wie lange die dem Projekt zugeordneten Personen brauchen, um eine Aufgabe mit den ihnen zur Verfügung stehenden Ressourcen zu bewältigen.

Wenn Sie sich aus irgendeinem Grund auf Schätzungen von Drittanbietern verlassen müssen (z. B. wenn ein Fachexperte anstelle der Task-Performer eine grobe Planungsschätzung vorlegt), sollten Sie die Annahmen dieser Person erfassen und dann geeignete Konfidenzintervalle und Fudge anwenden Faktoren zu den Schätzungen, die sie erstellen.

Schätzungen als Bereich ausdrücken

Das Endprodukt jeder Schätzung sollte ein Bereich sein, kein einzelner Wert. Viele Praktiker streben ein Konfidenzintervall von 80 % an, klammern das Ziel jedoch auch mit pessimistischen und optimistischen Zielen ein. Zum Beispiel könnten Sie 60-95 % als anfänglichen Spread verwenden, mit einer anfänglichen Erwartung von 80 %. Stellen Sie einfach sicher, dass Sie effektiv mit den Interessengruppen kommunizieren, dass jede Schätzung eine Prognose und keine eiserne Geld-zurück-Garantie ist!

Es ist sehr selten, dass dies möglich ist. Aber es kann passieren, also schauen wir es uns an:

Jede Schätzung basiert auf statistischen Beweisen aus früheren Erfahrungen mit ähnlichen Arbeiten. Wenn unsere Arbeit bemerkenswert ähnlich ist und wir über eine große Menge an Daten verfügen, mit denen wir arbeiten können, können wir Schätzungen weitgehend anhand der Kategorisierung der Aufgabe vornehmen. Ich habe zum Beispiel früher in einem Rechenzentrum gearbeitet und wir haben viele Server gebaut. Anhand statistischer Daten konnte Ihnen jeder (einschließlich PM) sagen, wie lange es voraussichtlich dauern würde, einen Windows-Server auf einer bestimmten Hardware bereitzustellen. Sie könnten sich auch die Warteschlange ansehen, um zu sehen, wie die voraussichtliche Wartezeit für die Arbeit sein würde.

Das ist also die Art von Situation, in der es möglich ist. Der Grund, warum Sie die anderen Antworten erhalten haben (denen ich übrigens vollkommen zustimme), wie Sie die Leute, die die Arbeit erledigen, schätzen lassen müssen, liegt darin, dass fast keine Wissensarbeit in diese Kategorie fällt - insbesondere Softwareentwicklung. Auch wenn zwei Funktionen oder Anwendungen oberflächlich ähnlich aussehen, sind sie hinter dem Bildschirm meist sehr unterschiedlich. Aus Sicht des PM werden sie also entweder keine ähnlichen Aufgaben finden, nicht genug, um eine Vorhersage zu treffen, oder sie verfügen wahrscheinlich nicht über das nötige Wissen, um wirklich zu erkennen, ob eine Aufgabe wirklich ähnlich ist.

Hier geben wir es an das Team weiter. Sie haben auch keine ähnlichen Aufgaben, mit denen sie es vergleichen können, aber sie schauen viel tiefer hinein, bis sie zu ähnlichen Aufgaben kommen. Beispielsweise haben sie zuvor Abfragen für Datenbanken ausgeführt. Sie haben Daten auf dem Bildschirm formatiert. Sie haben die Eingabevalidierung behandelt. Trotzdem wäre es wahrscheinlich viel genauer, diese Vermutungen als Schätzungen zu nennen, aber es handelt sich zumindest um fundierte Vermutungen, die auf früheren Erfahrungen beruhen.

Als ehemaliger Entwickler und agiler PM, hier ist mein 2p.

Einige Aufgaben lassen sich leicht abschätzen, da es sich um eine bekannte Menge handelt und viele Male zuvor ausgeführt wurden. Eine Wurstfabrik weiß genau, wie lange es dauert, eine weitere Wurst herzustellen.

Manche Aufgaben sind nicht einzuschätzen. Ein Biotech-Unternehmen weiß nicht, ob es jemals ein Heilmittel für Krankheit x finden wird [fügen Sie hier eine derzeit unheilbare Krankheit ein], es kann nur organisiert vielversprechende Wege gehen.

Die meisten Entwicklungsaufgaben liegen irgendwo zwischen diesen beiden Extremen, und ein Entwickler hat normalerweise ein gutes Gefühl dafür, wo in diesem Bereich eine bestimmte Aufgabe liegt.

Als Projektmanager können Sie diesen Prozess unterstützen, indem Sie die Entwickler bitten, die riskantesten/unbekanntesten Aufgaben zu identifizieren, und diese Aufgaben in eine separate Phase unterteilen, in der das Ergebnis ein Produktprototyp ist. Der Prototyp wird nicht die Technik oder Robustheit des Endprodukts haben, aber Sie haben die riskantesten Dinge an den Anfang des Projekts gestellt, wenn die geringsten Ressourcen gebunden wurden. Wenn sich herausstellt, dass ein Feature nicht realisierbar ist, haben Sie das so früh wie möglich herausgefunden und können den Kurs zu minimalen Kosten ändern.

Sobald Sie einen funktionierenden Prototyp haben, ist es für Entwickler viel einfacher, die Technik zu planen und abzuschätzen, die erforderlich ist, um den Prototyp in ein lieferbares Projektprodukt zu verwandeln.

Eine letzte Sache, unterschätzen Sie nicht den Unterschied zwischen einem Prototyp und einem lieferbaren Produkt. Dieser Unterschied ist zwar vorhersehbarer, macht aber zwischen 75 % und 90 % des gesamten Projektaufwands aus.