Java >> Java Tutorial >  >> Java

Zwei Gründe, warum sich Schätzungen nicht lohnen

Wenn potenzielle Kunden uns kontaktieren, möchten sie wahrscheinlich zwei Dinge wissen:

  • Wie viel kostet die Implementierung der Anwendung?
  • Wie lange wird es dauern, die Anwendung zu implementieren?

Die ehrliche Antwort auf diese beiden Fragen lautet:

Wir haben keine Ahnung .

Wenn wir potenziellen Kunden diese Antwort geben, stehen die Chancen gut, dass sie unsere Dienstleistungen nicht kaufen werden. Aus diesem Grund verwenden wir Arbeitsschätzungen, um unseren Kunden Antworten zu geben.

Das Problem ist, dass Arbeitsschätzungen nicht die richtigen Antworten liefern . Dieser Blogbeitrag beschreibt zwei Gründe, warum ich denke, dass es sich nicht lohnt, sie zu verwenden.

1. Schätzungen sind Vermutungen

Dies mag unsere Kunden überraschen, aber unsere Schätzungen sind nur Vermutungen. Es ist ziemlich einfach herauszufinden, ob eine bestimmte Aufgabe klein, mittel oder groß ist. Es ist jedoch verdammt schwer herauszufinden, wie viel Arbeit erforderlich ist, um eine einzelne Aufgabe zu erledigen.

Ein Grund dafür ist, dass Schätzungen manchmal auf unzureichenden Informationen beruhen. Das Problem ist, dass wir bei diesen Schätzungen möglicherweise nur Mockups der Benutzeroberfläche oder eine Liste von User Stories haben. Auf keinen Fall können wir wissen, wie lange es dauern wird, diese Software zu implementieren.

Warum?

Weil wir das Unbekannte nicht abschätzen können . Wir wissen es zum Beispiel nicht

  • Wie sollten die Daten validiert werden?
  • Was sind die Geschäftsregeln der Anwendung?
  • Wie soll die Autorisierung umgesetzt werden?

Es gibt viele Fragen ohne Antworten, und doch sollten wir in der Lage sein, genaue Schätzungen abzugeben. Wenn Sie glauben, dass dies möglich ist, träumen Sie.

Jede Schätzung in dieser Situation ist eine Vermutung .

Mit anderen Worten, wenn wir eine "detaillierte Spezifikation" haben, können wir genaue Schätzungen abgeben? Richtig?

Nun, wir können "bessere" Vermutungen anstellen. Eine "detaillierte Spezifikation" hilft uns, die implementierte Anwendung besser zu verstehen. Diese Informationen stellen sicher, dass wir "begründete Vermutungen" über den Umfang der erforderlichen Arbeit anstellen können.

Warum können wir keine genauen Schätzungen abgeben?

  • Es ist "unmöglich", eine Spezifikation zu schreiben, die alles abdeckt, und wenn etwas nicht in der Spezifikation steht, können wir es nicht schätzen.
  • Manche Menschen sind zu optimistisch und manche zu pessimistisch. Das bedeutet, dass wir „zusätzliche Zeit“ zu optimistischen Schätzungen hinzufügen müssen, aber wie viel Zeit müssen wir hinzufügen? Wir nicht. Deshalb vermuten wir.
  • Es ist unmöglich zu wissen, mit welchen Problemen wir während des Projekts konfrontiert werden und wie lange es dauern wird, sie zu lösen. Da wir das Unbekannte nicht abschätzen können, beziehen wir die Problemlösungszeit nicht in unsere Schätzungen ein.

Solange wir das Unbekannte nicht aus Softwareprojekten eliminieren können, müssen wir die Tatsache akzeptieren, dass Schätzungen nur Vermutungen sind . Das bedeutet, dass Schätzungen nicht verwendet werden sollten, um Annahmen über das Budget oder den Zeitplan eines Softwareprojekts zu treffen.

2. Schätzungen ermutigen nicht zur Maximierung des Mehrwerts

Schätzungen werden für zwei verschiedene Zwecke verwendet:

  • Der Kunde möchte wissen, wie lange die Implementierung der Anwendung dauert und wie viel sie kosten wird.
  • Das Softwareentwicklungsunternehmen möchte sicherstellen, dass das Softwareprojekt für es rentabel ist.

Dies bedeutet, dass der Kunde Schätzungen verwendet, um das Budget und den Umfang des Projekts zu steuern, und das Softwareentwicklungsunternehmen Gewinn erzielen möchte.

Mit anderen Worten,

  • Der Kunde denkt, dass der maximale Preis (und Umfang) des Projekts festgelegt ist.
  • Das Softwareentwicklungsunternehmen versucht, sich abzusichern, indem es sicherstellt, dass die Schätzungen "groß genug" sind.

Dies ist ein Rezept für eine Katastrophe. Natürlich ist es durchaus möglich, dass die Schätzungen stimmen und alle zufrieden sind. Wenn jedoch (wenn) die Schätzungen nicht korrekt sind, wird eines der folgenden Dinge passieren:

  • Wenn die Schätzungen zu hoch sind, zahlt der Kunde mehr als er muss.
  • Wenn die Schätzungen zu niedrig sind, versucht das Softwareentwicklungsunternehmen wahrscheinlich, seine Verluste zu minimieren.

Das erste Szenario kann ärgerlich sein, aber die Chancen stehen gut, dass der Kunde mit dem Ergebnis immer noch einigermaßen zufrieden ist.

Was passiert, wenn die Schätzungen zu niedrig sind? Ich kann garantieren, dass das Softwareentwicklungsunternehmen das Projekt so schnell wie möglich abschließen möchte. Mit anderen Worten, der Mehrwert für den Kunden ist nicht mehr ihre Hauptpriorität .

Dies kann zu einer Katastrophe führen.

Ich denke, dass das wichtigste Ziel eines Softwareprojekts darin besteht, den Return of Investment des Kunden zu maximieren . Leider wird uns die Verwendung von Vermutungen (Schätzungen) als Budgetverwaltungstool nicht dabei helfen, dieses Ziel zu erreichen .

Es ist nur ein Spiel

Ich denke, der einzige Grund, warum wir Arbeitsschätzungen abgeben, ist, dass die Kunden dies von uns verlangen. Um ehrlich zu sein, ist das Erstellen dieser Schätzungen ziemlich frustrierend, da jeder, der in einer Schätzungssitzung sitzt, weiß, dass diese Schätzungen nichts mit der Realität zu tun haben.

Es ist nur ein Teil des Spiels, das gespielt werden muss, wenn wir gewinnen wollen (das Projekt bekommen). Wenn unser Kunde Schätzungen wünscht, müssen wir entweder schätzen oder den Kunden entlassen.

Es gibt natürlich einen besseren Weg, aber ich frage mich, wie wir unsere Kunden davon überzeugen können, ihn zu verwenden.


Java-Tag