Wie kann ich Projekte schätzen, wenn ich eine Lernkurve für neue Technologien einbeziehen muss?


11

Manchmal gibt es Forschungs- und Entwicklungsprojekte, bei denen im Voraus nichts über Technologie, Konzepte und Kunden bekannt ist. Der Manager benötigt jedoch noch Zeitschätzungen. Was kann ich tun, um nützliche Schätzungen zu erstellen?


5
Nehmen Sie, was auch immer Ihre Schätzung in einer bekannten Technologie wäre, und verschieben Sie die Dezimalstelle um eine Stelle: P
Rig

5
Lesen Sie das Software-Schätzbuch von Steve McConnoll und verstehen Sie, was eine gute Schätzung ausmacht. Eine Schätzung ist unsicher - wenn dies nicht der Fall wäre, wäre es keine Schätzung. Die Aussage "Dies kann zwischen drei und sechs Monaten dauern, nachdem ich einen Monat damit verbracht habe, kann ich es eingrenzen" sollte akzeptabel sein.

1
@ MichaelT - toller Kommentar. Das einzige, was garantiert, um ungenaue Schätzungen schmackhafter zu machen, ist, sie im Laufe der Zeit zu verfeinern, damit das Management eine immer genauere Schätzung der verbleibenden Arbeit erhält. Das einzige, was sie garantiert verärgert, ist ein Projekt, das zwei Wochen vor Abschluss steht.
Carson63000

Dafür sind Prototypen da.

@ Carson63000 Ich hatte eine vereinfachte Version des Kegels der Unsicherheit in dieser Formulierung. Der Schlüssel zu dieser Abbildung ist, dass eine Schätzung von 2-12 Monaten nicht bedeutet, dass sie am Ende bei 7 Monaten endet, sondern dass die Schätzung von 2-12 auf 4-12 auf 8-12 konvergieren kann Beachten Sie auch, dass der ursprüngliche Kegel nach Fertigstellung des ursprünglichen Konzepts eine Reichweite von 16x hat.

Antworten:


13

Ehrlich gesagt, wie Nassim Nicholas Taleb in seinem Buch The Black Swan schreibt: "Wir können es einfach nicht vorhersagen". Hauptsächlich wegen der Unbekannten. Im Allgemeinen ist es am besten, genau diese Tatsache mitzuteilen, die Sie nicht vorhersagen können, anstatt eine Schätzung mitzuteilen.

Wie Taleb schreibt: Es ist besser, im Großen und Ganzen richtig zu sein, als genau falsch. Teilen Sie also unbedingt die Tatsache mit, dass Sie Schwierigkeiten beim Schätzen haben, und verwenden Sie Dinge wie "Lernkurven in neuen Technologien" als eines der Argumente. Dies bedeutet, dass der Bereich Ihrer Schätzung groß sein wird: "Dieses Projekt wird zwischen 100.000 und 500.000 kosten."

Wenn man so etwas sagt, erkennt derjenige, der Sie bittet, etwas einzuschätzen, dass die Dinge nicht so einfach sind.


3
+1: Dies ist die einzig richtige Antwort. Bringen Sie Ihrem Manager bei, Unbekanntes zu akzeptieren - es ist viel einfacher, als sie zu schätzen. - Schauen Sie sich auch die Arbeit von Steve McConnoll auf construx.com an.
Mattnz

2
Dies ist eine der falschesten Antworten hier. Sie können immer alles abschätzen. Es gibt Werkzeuge und Techniken, um dies zu unterstützen. Der einzige Unterschied ist die Unsicherheit. Möglicherweise haben Sie eine 4- oder 5-fache Abweichung zwischen Ihrer Schätzung und dem tatsächlichen Wert (insbesondere zu Beginn eines Projekts). Dies bedeutet jedoch nicht, dass Sie nicht versuchen sollten, eine Schätzung vorzunehmen, um als Ausgangspunkt für zukünftige Schätzungen zu dienen.
Thomas Owens

2
@ThomasOwens Du hast recht, du solltest nicht einfach weggehen. Aber meine kühne Aussage sollte interpretiert werden: Machen Sie sich nichts vor oder täuschen Sie Ihren Chef, sondern seien Sie offen dafür, dass die Einschätzung schwierig sein wird! Denn ehrlich gesagt erkennt nicht jeder Manager, der nach Schätzungen fragt, wie schwierig / unmöglich es ist, eine zu erstellen.
Marten Sytema

Nach meiner persönlichen Berufserfahrung ist mein durchschnittlicher Stundensatz bei freiberuflichen Arbeiten zu Festpreisen bei kleinen Projekten (wie kleinen Ergänzungen zu bestehenden Projekten) viel höher als bei größeren Projekten (oft von Grund auf neu). Es ist nicht einmal linear. Im Nachhinein hätte ich diese größeren nicht zu einem festen Preis nehmen oder zumindest im Voraus diskutieren sollen, dass die Schätzung sehr schwierig ist, und versuchen sollen, den Kunden davon zu überzeugen, auf einer anderen Basis zu arbeiten, um die Risiken ein wenig zu verteilen .
Marten Sytema

3

Das absolut erste, was Sie brauchen, ist eine Vorstellung vom Umfang. Je konkreter desto besser, aber jede Form von Anforderungen kann verwendet werden, um erste Schätzungen zu erstellen. Kundenanforderungen, Vision und Umfang sowie Konzeptdokumente können frühzeitig verwendet werden. Wenn die Anforderungen und das Betriebsumfeld klarer werden, werden sich die Schätzungen verbessern. Ein besseres Verständnis des Kunden (insbesondere der Schnittstellen zwischen dem Kunden und der sich entwickelnden Organisation), dem Team, das die Arbeit ausführt, den zu verwendenden Technologien, der Systemarchitektur und einem detaillierten Design tragen zu einer genaueren Schätzung bei. Dies ist im Kegel der Unsicherheit sichtbar.

Wenn Sie ein parametrisches Modellierungswerkzeug wie SLIM oder COCOMO verwenden (nur für Fortgeschrittene oder Fortgeschrittene, da Basic keine Kostentreiber berücksichtigt), sollten Anpassungsfaktoren für die Unbekanntheit der Technologie vorhanden sein. Zum Beispiel hat COCOMO eine große Anzahl von Kostentreibern , darunter einige, die speziell auf die Vertrautheit mit der Zielplattform sowie der Sprache und den Tools ausgerichtet sind, die zur Entwicklung des Systems verwendet werden. SLIM berücksichtigt auch die Gesamterfahrung des Entwicklungsteams, die Überlegungen zu den verwendeten Tools und Technologien enthalten sollte.

Mit dieser Technik wird die Ausgabe der Modellierungswerkzeuge in der Regel validiert, da sie in vielen Organisationen erfolgreich zur Schätzung früherer Softwareprojekte über viele Jahre verwendet wurden. Die Ausgabe ist jedoch nur so gut wie die Eingabe in das Werkzeug.

Wenn Sie keine parametrischen Modelle für die Schätzung verwenden, müssen Sie diese Faktoren bei der Erstellung Ihrer Schätzungen einfach berücksichtigen. Es wird eher zu einem Urteilsspruch, aber Sie können Aktivitäten wie das Lesen der Dokumentation, das Einrichten der neuen Entwicklungsumgebung und das Entwickeln von Beispielanwendungen auf der Zielplattform oder mit den Zielsprachen in Betracht ziehen.

In diesen Fällen müssen Sie Ihre Schätzungen nach Aufgaben aufschlüsseln und Ihr professionelles Urteilsvermögen nutzen, um sie zu sichern. Hoffentlich haben Sie historische Daten und andere konkrete Beweise, auf denen Ihre Schätzungen basieren. Ansonsten ist es eher ein harter Kampf.


3

Trennen Sie die Hauptschulungs- und Forschungszeit von der Entwicklungszeit. Teilen Sie das Projekt in mehrere Teilprojekte auf, die ein Happy End haben. Stellen Sie sicher, dass Sie nach dem Training einen Proof of Concept erstellen.

Wenn Sie neu in der Technologie sind, werden Sie nie an die tatsächliche Entwicklungszeit herankommen. Erhöhen Sie dies zu Beginn des Projekts als Risiko und schätzen Sie Ihre Schätzung großzügig ein. Dies gilt für Kerntechnologien, mit denen Sie und Ihr Team nicht vertraut sind.


1

Abhängig davon, dass ich die meiste Zeit FPA ( Function Point Analysis ) verwendet habe, aber wir befassten uns mit dieser "unternehmerischen Webentwicklung", ich meine, wissen Sie, Forbes 500-Webunternehmen.

Dort kann die Aufgabe immer in zwei Teile unterteilt werden: einen, der sehr gut zu FPA passt: Sie haben Eingabeschnittstellen, Ausgabeschnittstellen, interne logische Dateien (auch zu exportierende Datenbanktabellen / -typen genannt) und Sie haben diese komplexen, unbekannten Systeme .

In der einfachen Version ist die komplexe Aufgabe eine bereits geschriebene Komponente. Es ist nur schwer und unbekannt, mit ihr zu kommunizieren.

Die harte Version ist, wenn es geschrieben werden muss, dann pilotbasierte Schätzungen, COCOMO, was auch immer.

Zwei Dinge sind jedoch wichtig:

  1. Jede Art von Schätzsystem muss eine Kalibrierungszeit für Ihr Unternehmen haben. Sie entwickeln sich nie alleine, zumindest wartet ein Kunde auf Ihren Code (oder Sie wären nicht so verzweifelt, wenn Sie Code für sich selbst schreiben würden). Die Frage ist nicht "wie schnell kann es entwickelt werden?", Sondern "wie schnell kann es mit euch allen entwickelt werden?"

  2. Einmal hatte ich einen Manager, der diesen Black Swan-Roman las und verrückt danach war. Er sagte uns, dass es unmöglich ist zu schätzen, und ich machte meine üblichen präzisen Schätzungen von + -10% unerbittlich ...


-2

Ich mache regelmäßig Projekte, die dieser Beschreibung entsprechen, und ich habe das noch nicht herausgefunden! Zum Glück habe ich dort, wo ich arbeite, den Spielraum, das zu tun, was ich brauche, und habe keine vergeblichen Fristen. Die Projekte sind nicht immer erfolgreich und das ist nur ein Teil der Arbeit mit so vielen Unbekannten. Das Unternehmen gewinnt jedoch jedes Mal an Wissen.

Entschuldigung, das hilft überhaupt nicht.


-4

Schätzen Sie, wie lange es dauern wird, ein ähnliches Projekt mit vertrauter Technologie durchzuführen. Mit 4 multiplizieren. Lernzeit hinzufügen.

Wenn die Schätzung zu kurz ist, sehen Sie naiv und arrogant aus. Wenn die Schätzung zu groß ist, sehen Sie ignorant und inkompetent aus. Wählen Sie mit Bedacht aus.


4
Warum 4? Warum nicht 5? 10? 33,3? ... Gibt es Wissenschaft hinter Ihrer Antwort oder wählen Sie nur eine Zufallszahl? Wenn Sie dies in Ihre Antwort aufnehmen, wird dies möglicherweise nützlicher.
Bryan Oakley

Scheuen Sie sich nicht vor großen Zahlen. Mein Kollege hat einmal geschätzt, dass einige Module in 935 (neun, drei, fünf) Tagen überarbeitet wurden. Boss sagte, wir hätten nicht so viel und bestellte 60 Tage. Der Kollege tat, was in 60 möglich war. Das Ergebnis war ziemlich mühsam, aber er wurde nie dafür verantwortlich gemacht. Ich muss zugeben, dass die 60-Tage-Version, so problematisch sie auch sein mag, es uns ermöglicht hat, einen ziemlich wichtigen Kunden zu gewinnen - dh der Push des Chefs war wirtschaftlich ziemlich sinnvoll. Übrigens haben wir es am Ende geschafft, dieses Modul in Form zu bringen, aber das geschah einige Jahre später und die Anstrengungen waren mit einer Schätzung von 935
Mücke
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.