Wie kann man einer nicht-technischen Person erklären, warum die Aufgabe viel länger dauert, als sie denkt? [geschlossen]

Fast jeder Entwickler muss geschäftliche Fragen beantworten, wie zum Beispiel:
Warum dauert es 2 Tage, um dieses einfache Kontaktformular hinzuzufügen?

Wenn ein Entwickler diese Aufgabe einschätzt, kann er sie in Schritte unterteilen:

• Nehmen Sie einige Änderungen an der Datenbank vor
• DB-Änderungen auf Geschwindigkeit optimieren
• Front-End-HTML hinzufügen
• Schreiben Sie den serverseitigen Code
• Validierung hinzufügen
• Fügen Sie clientseitiges Javascript hinzu
• Verwenden Sie Komponententests
• Stellen Sie sicher, dass das SEO-Setup funktioniert
• E-Mail-Bestätigung implementieren
• Refactor und optimieren Sie den Code für die Geschwindigkeit
• ...

Dies ist für eine nicht-technische Person, die die gesamte Aufgabe als Zusammenstellung von HTML-Code und Erstellung einer Tabelle zum Speichern der Daten ansieht, möglicherweise schwer zu erklären. Für sie könnten es maximal 2 Stunden sein.

Gibt es eine bessere Möglichkeit zu erklären, warum die Schätzung für einen Nichtentwickler hoch ist?

Sie haben es gerade in Ihrer Frage getan.

Teilen Sie die Aufgabe in die einzelnen Schritte auf und geben Sie Schätzungen für jeden Schritt an. Dies zeigt, dass Sie alle Optionen in Betracht gezogen und (hoffentlich) alle Eventualitäten abgedeckt haben.

Wenn die Zeitskalen zu groß sind, können Sie mit konkreten Daten diskutieren, welche Teile (z. B. E-Mail-Bestätigung) in diesem Fall nicht benötigt werden, anstatt nur zu versuchen, einen Liter in einen Pint Pot zu stopfen.

Wenn Sie dies oft genug tun, werden Sie ihnen hoffentlich beibringen, dass eine Entwicklung in der Regel mehr beinhaltet, als auf den ersten Blick zu erkennen ist.

Das Auflisten von Aufgaben ist nahezu perfekt, aber denken Sie daran, dass Aufgaben, die für einen Ingenieur absolut sinnvoll sind, für eine nicht technische Person nur sehr wenig Sinn ergeben. In der obigen Liste weiß ich zum Beispiel, dass "Optimieren von DB-Änderungen auf Geschwindigkeit" eine oder mehrere zeitaufwändige Aufgaben sein kann, die das Erstellen von Profilen für den Code, das Ausführen und Suchen nach langsamen Punkten, das Überprüfen mit Experten oder das Durchlaufen von a umfassen Reihe vordefinierter produktspezifischer Tests. Und dann haben Sie wahrscheinlich mehrere Stunden, wenn nicht Tage, um Ihren Kopf auf Ihren Schreibtisch zu hämmern, während Sie versuchen, einen Weg zu finden, um die Bereiche zu reparieren, die zu langsam sind.

Möglicherweise haben Sie jedoch Ihr Projektmanagement für das Wort "DB" verloren, wenn nicht das Wort "optimieren".

Ich drücke dieses Zeug dem Projektmanagement im Allgemeinen in GROSSEN Schritten mit Worten aus, die das Risiko in Bezug auf das Geschäft beschreiben. Wenn ich Ihre Liste aufnehme, würde ich es auf diese Weise zusammenfassen, wenn ich mit meinem Projektmanagement sprechen würde:

1. Erstens besteht diese Sache aus zwei Teilen: der Webseite, die der Benutzer sieht, und dem Server, der das schwere Heben übernimmt. Beide Teile müssen vorhanden sein, damit diese Funktion funktioniert.
2. Der erste Teil besteht darin, eine für den Benutzer sinnvolle Webseite zu erstellen (Front-End-HTML hinzufügen, clientseitiges Javascript hinzufügen). Der Schlüssel dabei ist, dass die Webseite so aussehen muss, als ob sie Teil dieses Produkts ist, dass sie in allen von uns unterstützten Browsern funktioniert und dass sie auffällig sein muss. Das sieht der Benutzer. Wenn es also schlecht aussieht, wird der Benutzer denken, dass unser Produkt schlecht ist. Das Entwickeln und Testen dauert X Tage.
3. Als nächstes muss sich unter der Webseite etwas befinden, das die Arbeit erledigt. In diesem Fall bedeutet dies, dass hier eine Beschreibung der Funktion eingefügt wird (Zuordnung zu - Änderungen an der Datenbank vornehmen, serverseitigen Code schreiben, E-Mail-Bestätigung implementieren, Validierung hinzufügen, Komponententests verwenden). Ich kann das nicht einfach zusammenwerfen. Wenn der Code entwickelt und dann getestet wird, besteht die Gefahr, dass die Daten ALLER Benutzer beschädigt werden. Das bedeutet, dass eine einfache Neuerung die Reputation des Produkts auf ganzer Linie schädigen kann - auch für Benutzer, die diese spezielle Funktion nicht nutzen. Unsere Entwicklungspraktiken decken dies ab - wir führen zahlreiche Tests durch, um sicherzustellen, dass dies nicht passiert - aber das bedeutet, dass ich die Zeit einplanen muss, um es ordnungsgemäß zu testen. Das wird mich Y Tage dauern.
4. Geschwindigkeit ist eine große Sache in unserem Produkt. Wenn etwas nicht schnell geht, werden Benutzer denken, dass das Produkt nicht gut ist. Nachdem ich all diese Sachen geschrieben habe, muss ich die Arbeit durchgehen und sicherstellen, dass sie in Bezug auf die Leistung auf dem neuesten Stand ist. Dies ist eine große Sache in Sachen Web - wenn Leute feststellen, dass eine Website langsam wird, wenden sie sich schnell einem anderen Produkt zu, um den gleichen Bedarf zu decken, da es wirklich schwierig ist, den Unterschied zwischen langsam und kaputt zu erkennen. Diese Art von Arbeit dauert in der Regel Z Tage (Optimieren von DB-Änderungen hinsichtlich Geschwindigkeit, Umgestaltung und Optimieren des Codes hinsichtlich Geschwindigkeit).

Ich würde jede Schätzung vermeiden, die weniger als einen halben Tag beträgt. Sie müssen auf einer gewissen Ebene darauf vertrauen, dass Sie wissen, wovon Sie sprechen. Und wenn sie wirklich glauben, dass es nur 2 Stunden sind, dann laden Sie sie ein, 2 Stunden bei Ihnen zu sitzen, während Sie genau durch die 2 Stunden im Leben eines SW-Entwicklers gehen - dann machen Sie eine Coding-101-Klasse für ungefähr 2 Stunden, um genau zu zeigen, was alles in Betracht gezogen werden muss, um überhaupt das Problem zu lösen.

Am wichtigsten sind folgende Dinge:

• Wenn Sie mehr über Kundenwahrnehmung und Produktnutzung sprechen, sind Sie nicht in der Lage, deren Sprache - die Sprache von $$ - zu sprechen. Der Punkt ist, dass Sie, wenn der Code auf eine miese Art und Weise gehackt wird, irgendwann das Geschäft verlieren - wenn nicht Bei dieser Funktion und bei einigen nachfolgenden Funktionen, bei denen schlechte Entwicklungspraktiken eine Erweiterung des Codes unmöglich gemacht haben.
• Legen Sie eine Abfolge von Ereignissen fest. Die nächste nicht-technische Frage wird lauten: "Wenn wir mehr Entwickler haben als Sie, würde das schneller gehen? Wenn ja, wenn es 40 Stunden dauern wird, können 40 Leute das heute Nachmittag schaffen?" Die Antwort lautet natürlich "NEIN! SIND SIE AUSSERHALB IHRES VERSTANDES?". Aber das ist nicht das Beste. Das Beste ist, dass es hier eine logische Abfolge von Schritten gibt. Sache B kann nicht getan werden, bis Sache A vorhanden ist (wenn Sie keinen Code geschrieben haben, können Sie ihn nicht wirklich optimieren oder testen ...). Die Dinge A und A 'könnten jedoch zusammen erledigt werden. Wenn sie also den Schlauen da drüben verschonen könnten, könnten Sie die Zeit von einer Woche auf vier Tage verkürzen, und wenn sie die großartige Testunterstützung garantieren können, könnten Sie wahrscheinlich dazu kommen 3 Tage. Dort'
• Konzentrieren Sie sich auf das Risiko und seien Sie darauf vorbereitet, dass sich einige Risiken derzeit lohnen. Dafür bekommen die Geschäftsleute das große Geld - herauszufinden, welche Risiken es wert sind, eingegangen zu werden. Wenn zum Beispiel die Geschwindigkeit der Markteinführung die Leistung beeinträchtigt, weil Ihr Unternehmen kurzfristig über genügend Bargeld verfügt, um eine lächerliche Anzahl von Servern bereitzustellen, werden Sie möglicherweise aufgefordert, all diese Dinge in Schritt 4 zu überspringen (die Code- / Datenbankoptimierung) ). Das ist ihr Recht - es ist nur Ihre Aufgabe, die mit dieser Entscheidung verbundenen Risiken zu erklären.
• Wenn Sie diesen Leuten jedoch nicht vertrauen, erhalten Sie eine schriftliche Bestätigung - es muss nicht konfrontativ sein, nur eine kurze E-Mail mit der Aufschrift "Hier ist, wie ich glaube, was wir besprochen haben, hier ist, was ich nicht tue, hier ist die Ich werde es jetzt tun, also lass es mich wissen, wenn du nicht einverstanden bist. Da das Produktmanagement das Zentrum für den Verlust des Kurzzeitgedächtnisses sein kann, ist dies für alle sehr hilfreich.

Es gibt ein Sprichwort: "Sie können nicht zehn Pfund (Mist) in eine Fünf-Pfund-Tasche passen." Ihre Aufgabe ist es, zu zeigen, dass die Aufgabe zehn Pfund wiegt und sie es in einem Zeitrahmen von fünf Pfund haben wollen.

Das einzige, was Sie vermissen, sind die Zeitschätzungen. Stellen Sie für jede Aufgabe eine Zeitschätzung auf und zeigen Sie, wie sich all diese Dinge zu der von Ihnen angegebenen Schätzung summieren. Lassen Sie keine Schätzung größer als 4 Stunden zu. Wenn Sie eine Aufgabe haben, bei der Sie "ein Tag" oder "10 Stunden" sagen, unterteilen Sie diese in kleinere Teilaufgaben.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Jetzt haben Sie eine detaillierte Kostenabrechnung. Insgesamt sind das bis zu 27 Arbeitsstunden.

Sie können dies nun Ihrem Kunden zeigen und sagen: "Dies sind die Dinge, die zu den Kosten eines jeden getan werden müssen." Verwenden Sie das Wort "Kosten", da Zeit Kosten sind und das Management die Kosten versteht. Erklären Sie, dass Sie möglicherweise die beiden Optimierungsaufgaben am Ende fallen lassen könnten, diese sich jedoch später negativ auswirken und nur 15% der Gesamtschätzung ausmachen.

Stellen Sie außerdem sicher, dass Sie Ihre Stunden / Tag realistisch erklären. Wenn Sie beispielsweise technischen Support leisten oder Datenbanken oder ähnliches verwalten müssen, sollten Sie dies in Ihre Schätzung einbeziehen. Sagen Sie nicht "Nun, ich kann 7,5 Stunden am Tag gut programmieren", weil Sie das wahrscheinlich nicht können. Es ist wahrscheinlich eher 5 oder 6.

Verfolgen Sie dann vor allem Ihren Fortschritt. Angenommen, Sie können 5 Stunden pro Tag codieren. Dann sollten Sie in der Lage sein, die ersten beiden Aufgaben (in meinem Beispiel) am Montag abzubrechen, die dritte zu beenden und die vierte am Dienstag zu starten und so weiter. Machen Sie eine Checkliste, die dies zeigt, damit Sie sie am Mittwoch zeigen können, wenn sie vorbeikommen, und sagen Sie: "Wie läuft es, werden Sie bis Ende Freitag noch fertig sein?"

Siehe meine Folien für meinen Vortrag „ Krisenprävention: Projektschätzung und Verfolgung, die funktioniert“ , den ich vor einigen Jahren bei OSCON gehalten habe. Schauen Sie sich Folie 21 "Planen der Woche" an. Es gibt auch ein Beispiel-Velocity-Diagramm .

Frag sie:

Wie würdest du es machen? Welche Module würden Sie ändern? Wie viele Codezeilen? Was sind die Auswirkungen auf die Sicherheit? Änderungen am Datenbankschema? Wenn Sie Änderungen an der Datenbank vornehmen, wie viele Dateien sind betroffen? Wie lange hat es gedauert, das letzte Formular hinzuzufügen? Was ist der Durchschnitt (arithmetisches Mittel) für das Hinzufügen eines Formulars? Was war das längste Ich schätze, es dauert eine Minute weniger als die längste. Wenn Sie nicht wissen, wie lange es gedauert hat, die letzten N Formulare hinzuzufügen, ist diese Schätzung garantiert nur auf eine Größenordnung genau.

Ich könnte Ihnen erklären, dass ihre Software wie eine 100-Tonnen-Maschine mit 10.000 verschiedenen Teilen ist, von denen viele auf komplizierte Weise miteinander verbunden sind. Das Einpassen eines 1-Zoll-Stücks in diese Maschine erfordert einige Technik, damit die Maschine nicht beschädigt wird, ABER die bessere Antwort lautet:

Wenn Sie eine bessere Codearchitektur hätten, würde dies Aufgaben wie diese vereinfachen? Und die Antwort ist, dass die meisten Softwareteams keine guten Architekten sind (weil sie einfach keine Tonnen von generischen, architektonischen Vorlagen angehäuft haben oder nicht die Problemdomäne beherrschen, die ausreicht, um jedes Problem zu antizipieren) und nicht immer gute Ingenieure sind Sie sind also nicht zuversichtlich, Schätzungen abzugeben oder Versprechungen zu machen.

Genau wie es das 20. Jahrhundert gedauert hat, um gute Architektur und Technik für den Bau großer Gebäude zusammenzubringen, sind die Werkzeuge für die Softwareentwicklung noch nicht im Mainstream angekommen. Sie werden entwickelt: Es bedarf einer neuen Denkweise. Siehe Zen Code unter wiki.hackerspaces.org/Hacking_with_the_Tao.