Wie kann ich antworten, wenn ich um einen Kostenvoranschlag gebeten werde?

Als Programmierer werden wir ständig gefragt, wie lange es dauern wird.

Und Sie wissen, die Situation ist fast immer so:

• Die Anforderungen sind unklar. Niemand hat alle Auswirkungen eingehend analysiert.
• Die neue Funktion wird wahrscheinlich einige Annahmen, die Sie in Ihrem Code getroffen haben, brechen und Sie werden sofort über alle Dinge nachdenken, die Sie möglicherweise umgestalten müssen.
• Sie haben aus früheren Aufträgen andere Aufgaben zu erledigen und müssen einen Kostenvoranschlag erstellen, der diese andere Arbeit berücksichtigt.
• Die Definition von "erledigt" ist wahrscheinlich unklar: Wann wird es erledigt? "Fertig", wie gerade beim Codieren, oder "Fertig", wie bei "Die Benutzer verwenden es"?
• Egal wie bewusst Sie sich all dieser Dinge auch sind, manchmal lässt Sie der Stolz Ihres "Programmierers" kürzer geben / akzeptieren, als Sie ursprünglich angenommen hatten. Besonders wenn Sie den Druck von Fristen und Managementerwartungen spüren.

Viele davon sind organisatorische oder kulturelle Probleme, die nicht einfach und leicht zu lösen sind. Letztendlich werden Sie jedoch nach einem Kostenvoranschlag gefragt und erwarten von Ihnen eine angemessene Antwort. Das gehört zu deinem Job. Man kann nicht einfach sagen: Ich weiß es nicht.

Infolgedessen gebe ich immer Schätzungen ab, von denen ich später feststelle, dass ich sie nicht erfüllen kann. Es ist unzählige Male passiert und ich verspreche immer, dass es nicht wieder passieren wird. Aber es tut.

Was ist Ihr persönlicher Prozess zur Entscheidung und Abgabe eines Kostenvoranschlags? Welche Techniken haben Sie als nützlich empfunden?

Vom Pragmatischen Programmierer: Vom Gesellen zum Meister :

Was ist zu sagen, wenn Sie nach einem Kostenvoranschlag gefragt werden?

Sie sagen: "Ich melde mich wieder bei Ihnen."

Sie erzielen fast immer bessere Ergebnisse, wenn Sie den Prozess verlangsamen und einige Zeit damit verbringen, die in diesem Abschnitt beschriebenen Schritte durchzuarbeiten. Schätzungen, die an der Kaffeemaschine abgegeben wurden, werden (wie der Kaffee) zurückkommen, um Sie zu verfolgen.

In diesem Abschnitt empfehlen die Autoren das folgende Verfahren:

• Bestimmen Sie die Genauigkeit, die Sie benötigen. Basierend auf der Dauer können Sie die Schätzung mit unterschiedlicher Genauigkeit angeben. "5 bis 6 Monate" zu sagen ist etwas anderes als "150 Tage". Wenn Sie ein wenig in den siebten Monat schlüpfen, sind Sie immer noch ziemlich genau. Aber wenn Sie in den 180. oder 210. Tag schlüpfen, nicht so sehr.
• Stellen Sie sicher, dass Sie verstehen, was gefragt wird. Bestimmen Sie den Umfang des Problems.
• Modellieren Sie das System. Ein Modell kann ein mentales Modell, Diagramme oder vorhandene Datensätze sein. Zerlegen Sie dieses Modell und erstellen Sie Schätzungen aus den Komponenten. Weisen Sie jedem Wert Werte und Fehlerbereiche (+/-) zu.
• Berechnen Sie die Schätzung anhand Ihres Modells.
• Verfolgen Sie Ihre Schätzungen. Notieren Sie Informationen zu dem von Ihnen geschätzten Problem, Ihrer Schätzung und den tatsächlichen Werten.
• Andere Dinge, die Sie in Ihren Kostenvoranschlag aufnehmen sollten, sind das Entwickeln und Dokumentieren von Anforderungen oder Änderungen an Anforderungsspezifikationen, das Erstellen oder Aktualisieren von Konstruktionsdokumenten und -spezifikationen, das Testen (Einheit, Integration und Akzeptanz), das Erstellen oder Aktualisieren von Benutzerhandbüchern oder READMEs mit den Änderungen. Wenn zwei oder mehr Personen zusammenarbeiten, entstehen Kommunikationskosten (Telefonanrufe, E-Mails, Besprechungen) und das Zusammenführen von Quellcode. Wenn es sich um eine lange Aufgabe handelt, berücksichtigen Sie bei der Auswahl eines Liefertermins Dinge wie andere Arbeiten, Freizeit (Feiertage, Urlaub, Krankheitszeiten), Besprechungen und andere Gemeinkosten.

Die Softwareschätzung ist die schwierigste Einzelaufgabe in der Softwareentwicklung - eine knappe Sekunde ist die Ermittlung der Anforderungen.

Es gibt eine Menge Taktiken, um sie zu erstellen, die alle darauf basieren, dass zuerst gute Anforderungen gestellt werden. Aber wenn dein Rücken an der Wand ist und sie dir keine besseren Details geben wollen, fälsche es:

1. Sehen Sie sich Ihre Anforderungen genau an.
2. Machen Sie Annahmen, um die Lücken auf der Grundlage Ihrer besten Vermutung, was sie wollen, auszufüllen
3. Schreiben Sie alle Ihre Annahmen auf
4. Lassen Sie sie sich setzen, lesen und Ihren Annahmen zustimmen (oder, wenn Sie Glück haben, sie dazu bringen, nachzugeben und Ihnen echte Anforderungen zu stellen).
5. Jetzt haben Sie detaillierte Anforderungen, die Sie abschätzen können.

Es ist so, als hätte meine Mutter als Kind gedroht: "Beeil dich und such dir ein paar Klamotten aus, oder ich suche sie für dich aus!"

Ich habe die Entwicklung für einen Typen gemacht, der sehr darauf aus war, genaue Schätzungen zu wollen. Was wir beschlossen, was sehr gut funktionierte, war Folgendes:

• Ich habe die ganze Zeit in Rechnung gestellt, die ich mit dem Schätzen verbracht habe. Es kam zu ungefähr 20-25% von, was ich berechnete.
• Ich habe die Aufgaben sehr genau untersucht. Kein Schießen aus der Hüfte. Ich ging in den Code ein, fand heraus, welche Zeilen geändert werden mussten, welche anderen Teile des Programms davon betroffen waren, wie viele Tests ich durchführen musste, um sicherzustellen, dass die Dinge noch funktionierten. Ich würde jedes Stück in Einheiten von 0,1 Stunden (6 Minuten) schätzen.
• Ich schickte ihm meinen Kostenvoranschlag für jede Aufgabe zusammen mit dieser detaillierten Aufschlüsselung.

20-25% der Abrechnung klingt nach viel.

Aber er hat mich gebeten, XYZ zu ändern, weil ich dachte, es würde ungefähr 2 Stunden dauern. In einer Stunde detaillierter Schätzung würde ich bestimmen, dass es 8,5 Stunden dauern würde. Also würde er entscheiden, ob es 8,5 Stunden Lohn wert war. Wenn nicht, dann sparte er 7,5 Stunden mehr, als es ihn gekostet hätte, wenn ich es ohne Schätzung getan hätte.

Und wenn er hat wollen die 8,5 Stunden investieren, die Detailarbeit ich für die Schätzung tat , war Arbeit , die ich gehabt haben , würde auf jeden Fall zu tun.

Ich stellte fest, dass ich mit dieser Methode die meisten Aufgaben pünktlich oder sogar früh einbringen konnte, ohne sie stark überschätzen zu müssen. Weil die Zeit so kurz war, konnte ich früh erkennen, ob ich ausrutschte. Wenn ich Straßensperren traf, so dass ich nach 3 Stunden feststellen konnte, dass meine 8,5-Stunden-Aufgabe 12 Stunden dauern würde, konnte ich mit ihm darüber sprechen, bevor mehr Zeit verging, damit er das Feature neu bewerten und herausziehen konnte, wenn er sich Gedanken über die Kosten machte .

War er vernickelt? Nein, ich habe es so gesehen, dass er sein Geld dort einsetzen konnte, wo er den größten Nutzen sah. Und ich war froh, Erfahrungen im Schätzen zu sammeln, in denen ich immer schrecklich gewesen war.

Wir werden oft bei Meetings nach einem "Baseball-Kostenvoranschlag" gefragt, bei dem wir sehr umfassende und genaue Vorstellungen darüber bekommen, was sie gerne tun würden. Ich sage immer: "Wenn Sie heute eine Antwort wünschen, sind es ein Jahr und eine Million Dollar. Wenn Sie mir viel mehr Details und etwas Zeit zum Überprüfen geben möchten, kann ich diese Zahlen für Sie verfeinern."

Sie verstehen fast immer, worum es geht.

Es kommt darauf an, wofür die Schätzung ist.

Für eine erste hochrangige Schätzung für einen Geschäftsfall sind dann die Schlüsselsachen:

1. Geschwindigkeit. Unabhängig davon, welche Methode Sie verwenden, muss es schnell gehen. Der springende Punkt ist, dass die Stakeholder nicht sicher sind, ob es sich überhaupt lohnt, das Projekt durchzuführen - weshalb sie die Zahlen für den Business Case benötigen. Wenn der Business Case solide wäre, bräuchten sie Ihre Schätzungen nicht. Der Großteil dieser Projekte wird nicht durchgeführt, daher ist es wichtig, dass nicht zu viel Aufwand aufgewendet wird, um die Schätzung abzugeben.
2. Geben Sie eine Reichweite an. Mach es breit. Sie hatten keine Zeit, um Anforderungen zu analysieren, Workshops mit Stakeholdern durchzuführen und Annahmen zu validieren. Ein breites Spektrum sagt dem Empfänger des Kostenvoranschlags: "Softwareprojekte sind von Natur aus komplex und riskant. Wenn Sie einen richtigen Kostenvoranschlag wünschen, müssen Sie mir mehr Details und mehr Zeit geben." Das Problem bei der Angabe einer einzelnen Zahl oder eines engen Bereichs besteht darin, dass Sie dadurch in eine Ecke getrieben werden, dass Sie Erwartungen setzen, bevor eine echte Analyse durchgeführt wird.

Ich finde die beste Technik, um ein vergleichbares Projekt auszuwählen, das sich gleich "anfühlt". "Gefühl" ist völlig subjektiv - aber mit dieser Art von Schätzung können Sie meiner Erfahrung nach keine objektiven Messungen finden. Dann sorgen Sie für ein breites Spektrum. Ich habe einige Bücher gelesen, die sagen, ein Bereich von -50% bis + 100% ist gut, aber es hängt von vielen Faktoren ab.

Für eine detaillierte Schätzung auf niedriger Ebene:

1. Sie brauchen eine Grundlinie. Wenn die Basislinie nicht stabil ist, ist die Schätzung bedeutungslos.
2. Bottom-up ist am besten. Holen Sie sich eine detaillierte Aufschlüsselung der Arbeit, schätzen Sie jede Komponente und rollen Sie sie zu einer größeren Anzahl zusammen. Ich finde, dass das Planen von Poker hier eine großartige Technik ist.
3. Dokumentenkontingenz. Stellen Sie klar, wo eventuelle Eventualitäten hinzugefügt werden. Wird es zu jeder Werbebuchung hinzugefügt? Oder zur ganzen Schätzung? Oder zu bestimmten Risiken? Oder gibt es keine?
4. Geben Sie Ihre Annahmen an. Bestätigen Sie so viele wie möglich innerhalb des vorgegebenen Zeitrahmens.
5. Geben Sie ausdrücklich an, was in der Schätzung enthalten und ausgeschlossen ist. Ist beispielsweise eine Überprüfung enthalten? Sind technische Verzögerungen enthalten?

Einige Ratschläge von der dunklen Seite von jemandem, der es auf die harte Tour gelernt hat.

Die Anforderungen sind unklar. Niemand hat alle Auswirkungen eingehend analysiert.

Machen Sie zu diesem Zeitpunkt noch keine Schätzung. Man schätzt nicht, wie viele Soldaten benötigt werden, um eine Schlacht zu gewinnen, ohne die feindlichen Zahlen zu kennen. Die Schätzung erfolgt nach dem Scouting. Es sei denn, Sie haben diesen Feind bereits bekämpft.

Die neue Funktion wird wahrscheinlich einige Annahmen, die Sie in Ihrem Code getroffen haben, brechen und Sie werden sofort über alle Dinge nachdenken, die Sie möglicherweise umgestalten müssen.

Dies liegt in Ihrer Verantwortung zu berücksichtigen, es sei denn, Sie erwarten von anderen, dass sie das Fachwissen in diesem Bereich haben.

Sie haben aus früheren Aufträgen andere Aufgaben zu erledigen und müssen einen Kostenvoranschlag erstellen, der diese andere Arbeit berücksichtigt.

Das Gleiche gilt für unerwartete Arbeiten, die von einem Teamkollegen neben Ihnen mit einem nahezu nicht existierenden Testverfahren erstellt wurden, bei dem der Code fehlerhaft ist und der nicht im Voraus perfekt vorhergesagt werden kann. Es ist eine Wettervorhersage.

Die Definition von "erledigt" ist wahrscheinlich unklar: Wann wird es erledigt? "Fertig", wie gerade beim Codieren, oder "Fertig", wie bei "Die Benutzer verwenden es"?

Verstehen Sie die Benutzeranforderungen hier, denken Sie wie ein Benutzer. Tun Sie nicht das, was Ihre Kollegen tun, wenn sie einschätzen, dass etwas "erledigt" ist, nur weil einige grundlegende Funktionen mit einem Barebone-Workflow, die möglicherweise kein Benutzer tolerieren kann, ihrer Meinung nach "erledigt" sind . Denken Sie vom Standpunkt des Benutzers aus daran, denn das ist alles, was der Kunde, für den Sie eine Schätzung vornehmen, normalerweise versteht. Schätzen Sie in Bezug auf die vollständigen Benutzeranforderungen und nicht in Bezug auf die technischen Anforderungen des Barebones. Und stellen Sie fest, dass Ihre Kunden, die nach Schätzungen fragen, hier völlig ungenau sind, wie sie Dinge formulieren und die technischen Aspekte Ihrer Aussagen verstehen.

Egal wie bewusst Sie sich all dieser Dinge auch sind, manchmal lässt Sie der Stolz Ihres "Programmierers" kürzer geben / akzeptieren, als Sie ursprünglich angenommen hatten. Besonders wenn Sie den Druck von Fristen und Managementerwartungen spüren.

Mach das nicht! Sie klingen wie ein selbstmotivierter harter Arbeiter und möglicherweise einer, der leicht dem Zwang nachgibt.

Das Problem hierbei ist Folgendes: Nehmen wir an, Sie und Joe haben Zeitschätzungen für dieselbe Aufgabe vorgenommen (jedoch zwischen zwei verschiedenen Mitarbeitern, die beide Schätzungen nicht gleichzeitig kennen). Sie schätzen tapfer, "eine Woche" . Du denkst, du arbeitest mehr als 100 Stunden pro Woche, unbezahlte Überstunden. Jetzt bist du drei Tage zu spät.

Inzwischen schätzt Joe 5 Monate. Du denkst, das ist lächerlich, du denkst, du kannst das in einer Woche schaffen. Wie viel arbeitet Joe? 10 Stunden pro Woche? ... außer dass er pünktlich in genau 5 Monaten fertig ist.

Ratet mal, wer als der Esel wahrgenommen wird? Das stimmt, du. Joe scheint ein großartiger Arbeiter zu sein, Sie scheinen jetzt unzuverlässig zu sein. Es ist nicht so wichtig, dass Sie in ~ 7% der von Joe in Anspruch genommenen Zeit ein noch besseres Ergebnis erzielt haben. Was zählt ist, dass Sie 3 Tage von einer Woche Schätzung entfernt waren.

Nie auf der Seite der engeren Schätzung irren. Err auf der Seite der lockereren Schätzung. In Ihrem Unternehmen muss ein guter Ruf aufgebaut werden, der nicht so sehr auf der Länge Ihrer Schätzungen basiert wie auf der Genauigkeit Ihrer Schätzungen. Bei einer zu langen Schätzung ist es einfach, genau zu sein. Sie haben einfach mehr Zeit, um an dem Problem zu arbeiten und es besser zu lösen. Eine Schätzung, die zu kurz ist, lässt überhaupt keinen Raum zum Atmen. Entweder treffen Sie sie verzweifelt oder Sie sind durchgedreht.

"Zwei Wochen!"

Ernsthaft. Meine erste Schätzung ist immer zwei Wochen. Weil ich irgendeine bizarre mentale Blockade habe, die mich denken lässt, dass alles so klingt, als ob es zwei Wochen dauern würde.

Ich versuche, es zu umgehen, wirklich darüber nachzudenken, wie lange ich denke, dass etwas dauern wird, und versuche, alle potenziellen Krisenherde und Teile zu identifizieren, die zu unsinnig erscheinen, als dass ich sie genau einschätzen könnte. Und versuchen Sie zu erkennen, dass ich das wahrscheinlich versäumt habe, wenn meine Antwort "Zwei Wochen!" Ist.

So ziemlich jeder gute Manager, den ich hatte, hat gelernt, "Zwei Wochen!" als Antwort, die eine leichte verbale Zuhälter-Ohrfeige erfordert.

Es gibt einen Blogeintrag , in dem beschrieben wird, wie Sie aufzeichnen, wie genau Ihre vorherigen Schätzungen waren. Wenn Sie dann das nächste Mal jemandem sagen, dass es zwei Wochen dauern werden, können Sie sich Ihren vorherigen Verlauf ansehen und sehen, wie lange er dauert Das letzte Mal, als Sie sagten, es sind zwei Wochen.

Ich habe es selbst nicht ausprobiert, möchte aber gerne sehen, wie genau meine Schätzungen sind.

Dies hängt von der Organisation und der Verwendung der Schätzungen ab.

Wenn die Schätzung nur eine allgemeine Vorstellung davon geben soll, wann sie fertig sein wird, kann ich im Allgemeinen eine schnelle Schätzung auf der Grundlage meiner Erfahrungen vornehmen. Oft schließe ich Unsicherheiten oder mögliche Abweichungen in die Schätzung ein, ebenso wie die Auswirkungen der Änderungen auf andere Bereiche des Systems und den Umfang der erforderlichen Regressionstests.

Wenn die Schätzung für irgendetwas Vertragliches oder in einem Szenario verwendet wird, in dem ein genaueres Timing erforderlich ist, führe ich eine vollständige Arbeitsunterbrechung durch. Dies ist aufwändiger und erfordert eingehendere Überlegungen zum Design und zu Änderungen am System, ist jedoch viel genauer, insbesondere bei größeren Arbeiten.

In jedem Fall ist eine kontinuierliche Kommunikation der Schlüssel. Wenn Sie auf etwas Unerwartetes stoßen, machen Sie es zu diesem Zeitpunkt bekannt, anstatt auf die Frist zu warten. Wenn die Anforderungen nicht klar sind, stellen Sie sicher, dass Sie Ihr Verständnis der Anforderungen und der Funktionen dokumentieren, die Sie bereitstellen möchten. Dies ist auch hilfreich, wenn Sie Vermutungen anstellen. In Bezug auf konkurrierende Prioritäten sollten Sie sich darüber im Klaren sein, wie sich dies auf den Zeitplan auswirkt, wenn eine Arbeit auf eine andere stößt.

Schätzungen für was? Kleine Aufgaben oder Komplettlösungen.

Letzteres mache ich selten, aber dann rate ich einfach, füge ein bisschen hinzu, lasse den Manager ein bisschen hinzufügen und mache es in einen Bereich, mit einer kleinen Notiz daneben, die besagt, dass das Obige eine Vermutung ist.

Kleine Aufgaben - Planung von Poker Ich fand, dass es sehr gut funktioniert (nicht perfekt, einige 1-Punkte-Aufgaben haben viel länger gedauert und einige 5-Punkte-Aufgaben haben Minuten gedauert, aber am Ende ist alles ausgeglichen).

Präsentieren Sie ein Sortiment, das auf dem basiert, was Sie heute wissen. Verwenden Sie den Konus der Unsicherheit , um den Bereich um Ihre anfänglichen Schätzungen herum anzugeben.

Berechnen Sie jede Woche, wie viel noch zu tun ist, und schätzen Sie nach Ihren Kenntnissen neu. Wenn Sie genug Stichprobengröße haben, um zu bestimmen, wie viel Arbeit Sie pro Woche erledigen, geben Sie ein 90% iges Konfidenzintervall für die verbleibenden Daten an, um einen (normalerweise) immer enger werdenden Zeitraum im Verlauf des Projekts und den verbleibenden Arbeitsaufwand anzugeben (hoffentlich) ) schrumpft.

Zuversichtlich. Ich kann Ihnen nicht sagen, wie oft ich ein erstes Treffen mit einem Kunden verpfuscht habe, weil ich bei der Angebotsabgabe nicht auf Professionalität gesetzt habe. Auch wenn Sie Zahlen aus der Luft blasen - stellen Sie sicher, dass Sie immer eine Schätzung haben. Achten Sie jedoch darauf, sich nicht in ein Loch einzuschätzen. Unterschiedliche Dinge erfordern unterschiedlich viel Zeit, Mühe und Ressourcen, um sie zusammenzustellen. Hier ist ein guter Weg, um es zu tun:

Sie: Wie viel wird es kosten?

Ich: Es hängt davon ab, was ich tun soll. Im Allgemeinen beginne ich ein solches Projekt bei ungefähr X $.

Manchmal wird das Schätzen zu einer enormen Herausforderung für Sie und Ihr Team, insbesondere wenn es um das Schätzen von Softwareprojekten geht.

Nachdem wir uns entschieden hatten, unsere Erfahrungen und unser Wissen über den Software-Schätzprozess zu teilen, definierten wir vier verschiedene Arten von Schätzungen :

• grobe Schätzung
• Serviceschätzung
• Feature-Schätzung
• Teilschätzung

Natürlich sind diese Typen verschieden. Baseballstadion ist das, was oft als "Guesstimate" bezeichnet wird. Es handelt sich also um eine ungefähre Zahl oder einen ungefähren Bereich, der eine allgemeine Vorstellung von den Kosten vermittelt und einem potenziellen Kunden bei der Entscheidung helfen kann, ob er die Diskussion fortsetzen möchte.

Kunden benötigen zu Beginn des Projekts in der Regel eine Baseballfigur. Und unser Ratschlag lautet: Die Diskussion des Projekts und die Bereitstellung von Kennzahlen für das Baseballstadion sollten nur Schritte sein, um eine Bauteilschätzung zu erhalten (die flexibel ist und für den gesamten Entwicklungsprozess verwendet werden kann. Es ist nicht erforderlich, von Grund auf neu zu schätzen, wann Sie möchten Funktionen, Dienste usw. hinzufügen, entfernen oder ersetzen.

Jeder sollte die Risiken berücksichtigen, die mit der Schätzung der Softwareentwicklung einhergehen: Unterschätzen, Überschätzen, Total-Epic-Fail-Szenario usw.

Sie können mehr auf unserem Blog lesen!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Hoffe, diese Informationen werden Ihnen helfen!

Am Ende gebe ich immer Schätzungen ab, die ich später nicht erfüllen kann. Es ist unzählige Male passiert und ich verspreche immer, dass es nicht wieder passieren wird.

Es hört sich so an, als würden Sie um eine Verpflichtung gebeten, nicht um eine Schätzung. Dies sind verschiedene Dinge, aber wenn Sie Ihre Verpflichtungen zuverlässig verwalten können, wird dies Ihrer Glaubwürdigkeit und Karriere wirklich zugute kommen.

Einige Ratschläge basierend auf meiner ~ 10-jährigen Erfahrung:

• Geben Sie immer einen Bereich an (dh untere und obere Grenze). Dies wird Ihr Maß an Unsicherheit mitteilen
• Wenn Sie eine sehr große Unsicherheit haben, bitten Sie um einen Aufschub (z. B. 1 Tag, um eine Analyse durchzuführen, und geben Sie dann einen engeren Bereich an).
• Ist die Aufgabe zu groß, brechen Sie sie auf und geben Sie für jedes Stück einen Bereich an

Wenn mir eine Aufgabe zugewiesen worden wäre, würde ich sie zunächst in Unteraufgaben aufteilen. Ich würde die Zeit für jede Unteraufgabe schätzen und wahrscheinlich würde ich mit Unteraufgaben den problematischen Bereich finden und somit prognostizieren können, wie lange er dauern würde nehmen bis zu einem gewissen Grad.

Trotzdem würde die gesamte Planung nur bis zu einem gewissen Grad helfen. Erst wenn Sie mit dem Codieren beginnen, finden Sie die genauen Probleme

Wenn Sie viele Projekte für denselben Chef oder Kunden durchführen, können Sie versuchen, die Komplexität in großen Schritten anstatt in Wochen oder Monaten zu schätzen, möglicherweise in T-Shirt-Größen. Identifizieren Sie einige vergangene Projekte und weisen Sie ihnen die Größen S, M, L, XL zu.

Und dann fragen Sie sich: Welches Projekt hört sich ähnlich an? Und anstatt mit "2 Monate" zu antworten, können Sie mit "klingt wie ein L für mich" antworten (oder wie auch immer sich Ihre Kalibrierung für das Projekt herausstellt).

Dies ist ziemlich einfach zu verstehen, und es ist auch klar, dass diese Vermutungen sehr ungewiss sind.

Wenn sich dann die Anforderungen ändern, können Sie sagen, dass diese Änderung eher wie ein XL klingt.

Ein bisschen spät, aber als ich beim Militär war, wurden wir angewiesen, PERT zu verwenden, um Schätzungen zu ermitteln. Es erfordert etwas Erfahrung auf Ihrem Gebiet und der anstehenden Aufgabe. Es war überraschend genau, als es die geschätzte Fertigstellungszeit bei der Wartung und Reparatur von elektronischen Geräten (komplexen Funkgeräten und Satellitenkommunikationsgeräten) ermittelte, bei denen eine beliebige Anzahl von Dingen falsch oder gefunden sein kann und während der routinemäßigen Wartung behoben werden muss. Die Schätzungen waren wichtig, da andere Einheiten möglicherweise nicht betriebsbereit sind, bis sie ihre Kommunikationsausrüstung zurückerhalten. Einer, den ich verwendet habe, ist dieser kostenlose Online-PERT-Rechner