Wie antworte ich: "Wann wird es fertig sein?"

Wir alle haben es, Probleme, die sich als schwierig zu beheben erweisen und durch obskuren Code und bizarre unerwartete Funktionen behoben werden können. Arbeiten Sie sich langsam und logisch durch den Versuch, Muster, Fehler und Irrtümer zu finden. Dieser Prozess braucht Zeit und die Probleme sind für den Kunden oft nicht leicht zu verstehen.

Wie antwortet man auf die Frage "Wann wird es gemacht?", Insbesondere wenn der Kunde die inhärente Komplexität der Softwareentwicklung möglicherweise nicht versteht?

Sie beantworten die Frage ehrlich.

Sie sagen ihnen, dass es ein schwieriges Problem ist, die Lösung nicht offensichtlich ist und Sie nicht sicher sind, wie lange die Lösung dauern wird. Versprechen Sie, sie alle [Zeitrahmen] über Ihren Fortschritt zu aktualisieren, damit sie wissen, dass Sie daran arbeiten, und senden Sie ihnen natürlich die Aktualisierungen.

Entwickler nähern sich einem komplexen Problem, indem sie es in kleinere zerlegen und separat lösen.

In einer idealen Welt wäre das Lösen eines Problems ein komplexes Problem A, und Sie könnten es in einer bestimmten Zeit in eine kurze Liste kleiner Probleme A ₁ bis A _n zerlegen , da jede Bewertung der Zeit einfach ist Die zur Lösung des anfänglichen komplexen Problems erforderliche Zeit wäre:

wobei D der Zersetzungsprozess selbst ist.

In der realen Welt besteht das einzige Problem darin, dass t ( D ) tatsächlich größer ist als die Zeit, die Sie für die Lösung der kleinen Probleme aufwenden. Mit anderen Worten, um zu dieser Ebene der Zerlegung des Problems zu gelangen, müssen Sie das Problem praktisch selbst lösen.

Du kannst immernoch:

• Teilen Sie die gegebene Aufgabe (Lösen des Problems) in kleinere Teile auf, wobei jeder Teil immer noch ein komplexes Problem darstellt.

• Bewerten Sie die erwartete Zeit für jeden Block und das entsprechende Risiko.

  Zum Beispiel benötigt die Aufgabe 1 ca. 5 Stunden, aber das Risiko, blockiert zu werden, ist hoch. Geben Sie dem Kunden 12 Stunden als Ihre Erwartung.

• Bewerten Sie die Abhängigkeiten und wie sie sich auf die Zeit auswirken.

  Zum Beispiel benötigt die Aufgabe 19 2 Stunden und das Risiko ist so gering, dass man sagen kann, dass es mit Sicherheit 2 Stunden sind. Nicht 1. Nicht 3. Aber Aufgabe 19 stützt sich auf Aufgabe 24: Die Aufgabe 24 kann die Aufgabe 19 auf eine Weise beeinflussen, die Sie benötigen würden, um den Code der Aufgabe 19 unter Verwendung eines anderen Ansatzes vollständig neu zu schreiben.

• Geben Sie all diese Details an Ihren Kunden weiter. Gib nicht die Summe.

Der letzte Punkt ist wichtig. Wenn Sie die Summe angeben, sagen wir 192 Stunden, glaubt der Kunde, dass es sich um eine sehr genaue Metrik handelt, und die Zeit, die Sie verbringen werden, beträgt beispielsweise 189 bis 195 Stunden.

Wenn Sie stattdessen die Details angeben,

• Der Kunde, der sich interessiert, wird verstehen, dass es nicht 192 Stunden sind. Es sind 192 Stunden, wenn angesichts des bei der Bewertung ermittelten Risikos alles schief geht. Es sind auch 238 Stunden, wenn alles noch schlimmer wird. Es ist auch 85 Stunden, wenn alles in Ordnung ist.

• Der Kunde, der sich nicht darum kümmert, wird Ihre Antwort nicht in allen Fällen lesen. Er will nur eine Nummer, um dich später beschuldigen zu können. Wenn Sie eine sehr detaillierte Antwort geben, die er nie lesen wird, wissen Sie, dass er Sie nicht nach der Zeit fragen kann, die es wieder dauern wird: Sie haben das bereits beantwortet. Er kann Ihnen auch später keine Vorwürfe machen, da er die Antwort nicht gelesen hat, um die Summe zu berechnen.

Was auch immer Sie schätzen, vergessen Sie nicht, das Hofstadter-Gesetz aufzunehmen : Es dauert immer länger als erwartet, auch wenn Sie das Hofstadter-Gesetz berücksichtigen.

Normalerweise verwende ich eine modifizierte Formel von CPM / PERT. Es ist ungefähr so:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Ich bin mir nicht sicher, wie ich all die ausgefallenen mathematischen Formatierungen durchführen soll. Wenn jemand dies dafür bearbeiten möchte, kann er sich frei fühlen.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Ich möchte betonen, dass es je nach Projektverlauf erheblich variieren kann. Wenn Sie Ihr Projekt alle paar Tage neu bewerten, können Sie sogar ein wöchentliches Update bereitstellen. Es trägt wesentlich dazu bei, gereizte Kunden zufrieden zu stellen. :) :)

Nicht-technischen Benutzern vage Zeitpläne zu erklären, ist schwierig. Dies gilt sowohl in kreativen Phasen eines Projekts als auch beim Aufspüren eines lästigen Fehlers. In beiden Fällen funktioniert das traditionelle "Zerlegen der Arbeit in kleinere Stücke" nicht so gut.

Die ursprüngliche Aufgabe konzentriert sich auf den letzteren Fall, also lassen Sie uns darauf eingehen. Wenn Sie keine Zeitleiste angeben können, teilen Sie dem Benutzer mit, was Sie versuchen und wann Sie zu ihm zurückkehren. Wenn Sie den halben Punkt auf der selbst auferlegten Zeitachse erreicht haben, geben Sie ein kurzes und ehrliches E-Mail-Update. Geben Sie mindestens eine Stunde vor Ablauf der Frist Ihre formelle Antwort. Jetzt haben Sie Glaubwürdigkeit. Wenn das Problem nicht gelöst ist, scheinen Sie zumindest etwas Licht. Es mag wie Zeitverschwendung erscheinen, ist es aber nicht.

Da Sie die unbekannten Straßensperren und unvorhergesehenen Überraschungen nicht berücksichtigen können, kann es schwierig sein, sie mit Sicherheit zu schätzen. Ideen:

• Probieren Sie einen Bereich aus - "Ich bin sicher , dass es mindestens N Tage dauern wird (z. B. 3), aber möglicherweise bis zu 4N."
• Bitten Sie mehr erfahrene Ingenieure um Unterstützung bei der Schätzung und Verteidigung von Schätzungen.
• Arbeiten Sie in kürzeren Iterationen (Agile / Scrum-Stil), um einen minimalen Code zu erstellen, der den geschäftlichen Mehrwert erhöht (Vertrauen gewinnen), und wiederholen Sie den Vorgang.
• Lernen Sie Verhandlungsgeschick aus einem Buch wie dem klassischen Getting to Yes (http://www.amazon.com/gp/aw/d/0143118757).

Für Neuentwicklungen, insbesondere für agile Entwicklungen:

"Perfektion wird erreicht, nicht wenn nichts mehr hinzuzufügen ist, sondern wenn nichts mehr wegzunehmen ist." - Antoine de Saint-Exuper

Wenn Sie den Aufwand und die Zeit für die Behebung einiger nahezu unmöglich zu reproduzierender Fehler in einem schrecklich übermäßig komplexen System mit sehr wenigen bis gar keinen Entwicklern mit intimen Domänenkenntnissen des Systems schätzen, lautet die einzig richtige Antwort "Wenn es behoben ist".

Normalerweise würde ich ihnen nur die Wahrheit sagen. Ich würde ihnen sagen, dass ich sie momentan nicht kenne, und ich könnte in einer Woche einen besseren Einblick haben. Ich würde ihnen dann einen Ballpark mit so vielen Schnörkeln vor sich geben, wie Sie auf das Papier passen können, um anzuzeigen, dass es sich um eine auf Bauchgefühl basierende Vermutung handelt. Wenn sie anfangen, dich hart zu schlagen, beginne einfach jeden Satz mit "Es ist möglich ...". Normalerweise ist jeder, für den ich etwas tue, mit dem "Check in einer Woche oder so, aber jetzt kann ich nur noch sagen, dass es ungefähr 2 Monate sind" zufrieden. oder sowas ähnliches.

Der Personal Software Process (PSP) konzentriert sich auf die Verbesserung von Schätzungen. Dies wird durch disziplinierte Protokollierung von Aufgaben erreicht. Dies "beschleunigt" im Wesentlichen den "Erfahrungsteil" der Schätzung etwas, da Sie über tatsächliche Daten zu typischen Aufgaben verfügen. Natürlich erfordert dieser Beruf immer noch einzigartige Lösungen für viele Probleme, aber meiner Erfahrung nach sind Schätzungen nach der Verwendung von PSP besser.