Wir wurden vom Management gebeten, einen sehr kurzen Zeitraum für die „Größenbestimmung“ eines Softwareprojekts aufzuwenden – das heißt, ihnen einen sehr groben Zeitrahmen für die Implementierung des Ganzen zu geben.
Es gibt drei Hauptkomponenten (Backend, ios, android), die jeweils in der Verantwortung eines Entwicklers mit Fachkenntnissen liegen. Jede Person hat 30 Minuten Zeit, um eine Zahl zu finden.
Wir haben ein einseitiges Anforderungsdokument erhalten, einige grobe User Stories extrapoliert und ein grobes Flow-Dokument. Wir sind Entwickler, keine Projektmanager, und es gibt keinen Projektbesitzer, da sich unser Unternehmen im Vorverkauf für dieses Projekt befindet und dem potenziellen Kunden eine lose Nummer geben möchte.
Als Entwickler fühlen wir uns unwohl, Zahlen auf einer so begrenzten Grundlage anzugeben. Während der Entwicklung machen wir im Allgemeinen Scrum (Storys, Punkte, Sprints, Standups, Geschwindigkeit usw.). Wenn wir also an einem Projekt arbeiten, kommen unsere Schätzungen leicht und haben eine gewisse Grundlage in der Realität. In diesem Fall gibt es jedoch noch kein Projekt und wir sind uns nicht sicher, wie wir am besten vorgehen sollen.
Wie sollen wir damit umgehen? Und was könnte unser Unternehmen in Zukunft noch besser machen?
Ich habe mit vielen Entwicklern und Entwicklungsmanagern zusammengearbeitet, die sehr zurückhaltend sind, eine Schätzung mit solch begrenzten Informationen und begrenzter Zeit abzugeben. Sie wurden in der Vergangenheit zu oft gebissen. Der Hauptgrund dafür ist, dass selbst wenn die Personen, die nach einer solchen Schätzung fragen, die Risiken verstehen und zusichern, dass sie sorgfältig verwendet werden, wenn sie diese Zahlen an andere weitergeben, werden sie oft als Lieferverpflichtung zum Festpreis missverstanden.
Andererseits wird das Management nicht die Zeit und Mühe investieren, um eine genauere Schätzung zu entwickeln, wenn es hier keine potenzielle Geschäftsmöglichkeit gibt. Noch wichtiger ist, dass der Kunde nicht die Zeit investiert, Ihnen detailliertere Anforderungen zu stellen, wenn die Kosten in der Größenordnung nicht im Bereich der potenziellen Erträge liegen.
Wie durchbrechen Sie diese Sackgasse? Wenn Ihr Unternehmen Geschäfte tätigen muss, müssen Sie alle einen Weg finden, diesen Stillstand zu überwinden.
Es gibt keine Wunderwaffe. Hier sind ein paar Vorschläge:
Nehmen Sie Ihre Schätzung so streng wie möglich mit den verfügbaren Informationen vor.
Nennen Sie bei der Schätzung alle Annahmen, die Sie explizit treffen, um zu der Schätzung zu gelangen.
Verwenden Sie andere Projekte, die Sie durchgeführt haben, um sie mit diesem zu vergleichen. Wenn sich dieses größer anfühlt als ein anderes Projekt, das Sie durchgeführt haben, korrigieren Sie die Schätzung entsprechend nach oben.
Treffen Sie Vorkehrungen für Design- und Funktionsänderungen: Etwa so: „Wenn wir mehr über die Anwendung erfahren, tauchen neue Anforderungen auf. Normalerweise werden einige Funktionen gekürzt oder erweitert. Neue Funktionen werden entdeckt und hinzugefügt.“ Fügen Sie der Schätzung beispielsweise 20 % hinzu, um solche Änderungen zu berücksichtigen.
Geben Sie das obere Ende des Bereichs an: In der Regel werden die Finanzmitarbeiter des Kunden dies höchstwahrscheinlich verwenden, um eine Budgetgenehmigung zu erhalten. Wenn Sie eine niedrigere Zahl angeben, wird es für alle sehr schmerzhaft sein, zurück zum Vorstand zu gehen und mehr Geld zu verlangen. Aber wenn Sie später etwas Geld sparen, werden alle glücklich sein.
Verwenden Sie eine grobe Terminologie: Etwa so: „Mit einem Team aus 3 Vollzeit-Entwicklern, einem Vollzeit-Tester und einem Halbzeit-Designer, einem Scrum Master und einem Product Owner, die sich mit einem anderen Team teilen, können wir eine minimale Funktionsversion in 2 Quartalen liefern. Darüber hinaus werden die folgenden 2 Hauptfunktionen jeweils ein Viertel dauern."
Geben Sie Design- und Funktionsauswahlempfehlungen ab, die, wenn sie akzeptiert werden, Geld von den hohen Schätzungen sparen.
Erstens, Sie machen keine Schätzung. Du machst Vermutungen . Dies ist ein Wiki-Artikel zu diesem Begriff.
Schätzwert ist definiert als eine Schätzung, die ohne Verwendung angemessener oder vollständiger Informationen vorgenommen wird, oder, noch stärker, als eine Schätzung, die durch Vermutungen oder Vermutungen erzielt wird.
Mit anderen Worten: Offensichtlich ist Guesstimation etwas zwischen Rate und Schätzung. Beim Schätzen muss man sich mehr auf die Intuition verlassen.
Hauptpunkt (wie in anderen Antworten gesagt wurde), um die Manager wissen zu lassen, dass es sich um Vermutungen handelt. Es ist nicht einmal eine Schätzung (wie WBW sagte), es ist eher eine Prognose! Wie Wettervorhersage. Mit der gleichen Genauigkeit ;-)
Denken Sie daran, dass es sich um eine Schätzung handelt, nicht um eine Verpflichtung.
Ich würde die folgenden Fragen rund um die Schätzung empfehlen:
-Warum erhalten Sie so begrenzte Informationen/Zeit, um den Kostenvoranschlag abzugeben? -Wofür wird der von Ihnen bereitgestellte Kostenvoranschlag verwendet? - Wer haftet für die Genauigkeit der Schätzung? - Wer ist für die Genauigkeit der Schätzung verantwortlich?
Nun zum Kostenvoranschlag selbst. Geben Sie zusammen mit Ihrer Schätzung ein Konfidenzmaß an, um der Person, die die Schätzung verwendet, das Risiko mitzuteilen, das mit der Verwendung einer einzelnen Zahl zum Treffen einer Entscheidung verbunden ist. Es könnte so gehen wie...
„Nun, da wir ein 1-seitiges Dokument und 30 Minuten Zeit haben, um darüber nachzudenken, schätze ich die Zeit, die erforderlich ist, um diese Arbeit abzuschließen, auf durchschnittlich 60 Tage plus oder minus 30 Tage. Ich behalte mir das Recht vor, meine Schätzung zu überarbeiten, falls neu Informationen zur Verfügung gestellt werden oder sich bestehende Informationen ändern.“
Natürlich ist es auch fair, zurückzuschlagen und keinen Kostenvoranschlag abzugeben, wenn Sie zu Recht der Meinung sind, dass Sie sehr geringes Vertrauen in den von Ihnen abgegebenen Kostenvoranschlag haben. Schließlich ist eine Schätzung mit 0 Konfidenz nur eine Vermutung.
Der Zweck der Softwaredimensionierung besteht normalerweise darin, die Daten im Kosten-Nutzen-Analyseprozess bereitzustellen, damit Entscheidungsteams (dh Kunden) eine Auswahl treffen können. Es ist besser, die Angebote anderer Wettbewerber zu kennen, damit das Team den Gewinnervorschlag machen kann. Die Schätzung sollte eher einem Phasenansatz entsprechen, da das Entwicklungsteam mehr über die Kunden weiß. Das Beispiel ist wie folgt: Normalerweise könnte der Zeitrahmen mit jedem Quartal übereinstimmen, abhängig vom Lieferzyklus des Teams….
Phase I - Prototyp:
Phase II – Pre-Launch
Phase III – Große Eröffnung
Phase N – Überarbeitung – Liste der Funktionalitäten – Größe der Benutzer – Zielzeitrahmen
(abhängig davon, ob Entwickler mehreren Aufgaben wie QA-Tests oder Produktionsunterstützung zugewiesen werden, sollten mindestens 20 % zusätzliche Zeit zusätzlich zur tatsächlichen Schätzung des Entwicklers hinzugefügt werden)
MCW