Sind Terminüberschreitungen bei Programmieraufträgen üblich? [geschlossen]

18

Es war mein freiberuflicher Job bei oDesk. Ich habe mehrere Jobs früher in der vorgegebenen Zeit erledigt, aber es war das erste Mal, dass ich die Frist verpasst habe. Es war ein sehr langer Job und ich habe mein Bestes gegeben, aber ich habe die Deadline immer noch verpasst. Jetzt habe ich große Angst. Weil es meine Schuld ist, dass ich die Frist verpasst habe.

Meine Frage ist: Ist dies ein großes Problem oder sind versäumte Fristen bei Programmierjobs üblich, deshalb sollte ich mir darüber keine allzu großen Sorgen machen?


quelle
1
Kommt ganz auf die Umgebung an. Zum Beispiel war mein letzter Job bei einer Digitalagentur, die Kunden nach Schätzungen abrechnete. Wenn Sie die Frist dort verpasst haben, hat das Unternehmen Geld verloren. Mein jetziger Job ist so dynamisch, dass es überhaupt keine wirklichen Fristen gibt. Wenn meine Aufmerksamkeit an anderer Stelle benötigt wird, bekomme ich angemessene Zeit, um mich dem zu widmen. Vielleicht hilft es bei der Beantwortung, dies in Ihre Frage aufzunehmen.
Simon Whitehead
3
Terminüberschreitungen sind in allen Jobs üblich
Steven A. Lowe
2
Ich hoffe wirklich, Sie haben mit dem Kunden über die versäumte Frist gesprochen. Es kommt vor, dass Termine verpasst werden, aber es sollte nicht unerwartet sein, wenn dies der Fall ist. Normalerweise ist es einfacher, als nur "Nein, noch nicht fertig" zu sagen.
Bobson
6
Mach es schnell, mach es billig, mach es gut: nimm zwei.
Reactgular

Antworten:

45

Ja. Versäumte Fristen sind in der Softwareentwicklung weit verbreitet.

Viele Freiberufler halten ihre Termine ein, indem sie technische Schulden machen oder den Schmutz unter dem Teppich verstecken.

Umschreibung von Frederick Brooks ' The Mythical Man Month :

Frederick Brooks, Autor von The Mythical Man Month

  • Fristen werden oft versäumt, weil die Projektleiter Software-Aufgaben weiterhin genauso bewerten wie Tiefbau-Aufgaben. Dies ist ein fehlerhafter Ansatz, da Software eine neuartige, handwerkliche Industrie ohne klare Normen ist. Dies ist so wahr, dass Sie weder die "Erlaubnis" eines Programmierers , Code für einen Fehler zu verwenden, widerrufen noch jemanden für das Programmieren ohne Titel verklagen können.

  • Die Softwareentwicklung weist eine Komplexität auf, die anderen Disziplinen fehlt. Ein großes Programm kann mehr Komponenten als ein Auto enthalten, und diese Komponenten können auf unterschiedliche Weise miteinander interagieren.

  • Software ist schwer zu visualisieren, daher werden verschiedene Arten von Diagrammen verwendet, um verschiedene Aspekte eines Projekts zu sehen, und diese Aspekte sind möglicherweise nicht orthogonal. Der Tiefbau hingegen verfügt über Baupläne, mit denen Sie Rohrleitungen, Kabel usw. auf orthogonale Weise in derselben Karte (oder in denselben Ebenen) anzeigen können.

  • Es ist nicht üblich, dass der Kunde nach dem Bau einer Brücke oder eines Gebäudes den Umfang des Projekts vollständig ändert. Dies ist häufig bei Softwareprojekten der Fall.

  • Der Stand der Softwareentwicklung ist noch nicht so weit fortgeschritten, dass Softwareprojekte reproduzierbar und nahezu risikofrei sind. Selbst die größten Softwareunternehmen wie Microsoft können Termine um Monate oder Jahre verfehlen.

  • Die meisten Vaporware-Produkte sind nichts anderes als Softwareprojekte, die aufgrund solcher Probleme geschnitten wurden.

Abschließend:

Aufgrund des handwerklichen Charakters des Softwareentwicklungsprozesses führen schlechte Schätzungen und die Unterschätzung der Komplexität dazu, dass der Prozess noch nicht ausgereift ist.

Tulains Córdova
quelle
11
+ Gute Antwort, aber nach einigen Erfahrungen mit Maschinenbau und Bauingenieurwesen ist es amüsant, wie Programmierer einfache Vergleiche mit dem Bau von Brücken und anderen Dingen anstellen, wenn sie nicht die geringste Ahnung haben, wie diese gebaut werden.
Mike Dunlavey
3
Ich würde der Idee zustimmen, dass die Software ein Plan ist (in Bezug auf den Plan im Engineering - der jedes Detail des Projekts beschreibt). Im Ingenieurwesen dominiert die Zeit der physischen Konstruktion, so dass große Abweichungen in der Planung keine Rolle spielen. Da Software jedoch nur aus Plan besteht ... "Der Stand der Technik in der Softwareentwicklung ist noch nicht so weit fortgeschritten, dass Softwareprojekte reproduzierbar und nahezu risikofrei sind" - warum dann überhaupt? Wenn sich etwas wiederholt und automatisiert werden kann, muss es nicht mehrmals ausgeführt werden, sondern kann einmal ausgeführt und kopiert werden.
Maciej Piechotka
2
@ user61852: Du hast mich falsch verstanden. Der "Plan" für das Ingenieurwesen ist eine "Quelle" für die Informatik - dh eine detaillierte Beschreibung jeder Komponente - aber sobald wir ihn haben, können wir ihn erstellen (eingeben makeoder was auch immer). Was "Plan" in der Informatik ist, wäre ein "Plan" of plan 'ingenieurwesen. Der Unterschied besteht darin, dass makein der Informatik das Schreiben von Quellcode (einschließlich Tests und Integration) höchstens einige Stunden dauert, während die Planung im Ingenieurwesen Monate (einschließlich statischer Berechnungen) dauern kann, während das Bauen Jahre dauert auf letzterem.
Maciej Piechotka
1
@ user61852: In Bezug auf die Wiederholbarkeit - eine Sache, in der Computer großartig sind, ist die Automatisierung. Angenommen, Sie müssen ein einfaches Blog erstellen - an dem Punkt, an dem Sie genaue „Schätzungen“ haben, wird WordPress (oder ein anderes Blogging-System) installiert, sodass Sie nichts davon tun müssen (im Falle von Bridge) Sie haben immer noch eine andere Umgebung, daher müssen Sie sich sorgfältiger anpassen, da der Fels möglicherweise anders ist oder ein Vogelhabitat vorhanden ist oder die Ansicht zerstört wird. Die Programmierer sind möglicherweise mehr für die Erstellung der Werkzeuge verantwortlich (das Standard-Brückenmodell).
Maciej Piechotka
2
Bonus für das Zitieren des Monats des mythischen Mannes; Frederick Brooks hält nach all den Jahren durch, weil er sich auf Menschen konzentriert, nicht auf Technologie.
Michael Shopsin
3

Versäumte Fristen sollten nicht zur üblichen Praxis werden, wenn Sie weiterhin Jobs erhalten möchten.

Vor diesem Hintergrund möchten Sie sich normalerweise einen zusätzlichen Spielraum in Ihren Schätzungen lassen, falls etwas passiert (und das tut es immer). Sie müssen nicht offenlegen, dass Sie in der Verlängerung hinzugefügt haben, machen Sie es einfach nicht unvernünftig. Möglicherweise zwischen 5 - 10% der Gesamtzeit? Der einzige Weg, wie Sie es herausfinden, ist, es ein paar Mal zu tun.

Um wirklich gute Schätzungen zu erhalten, müssen Sie wissen, wie lange es dauert, einen bestimmten Widget-Typ zu codieren. Nehmen wir beispielsweise an, Sie müssen ein unendliches Scroll-Widget für Client X erstellen. Wenn dies eine Woche dauert, müssen Sie dies tun Um es fehlerfrei in der Produktion zu implementieren, können Sie es als Basis für Ihre unendlichen Bildlaufschätzungen verwenden.

TJ Trapp
quelle
2
Ich gebe immer 20% Raum bei der Schätzung. 5-10% ist zu wenig. Ich denke, es hängt davon ab, wie sehr Sie abgelenkt sind. Solo-Entwickler können überhaupt nicht abgelenkt werden
BЈовић
Ich bin ein Solo-Entwickler und ich nehme normalerweise 10% Marge für meine Projekte.
Konsole
Hmmm ... siehe Hofstadter's_law
Philip
1
Im Vergleich zu 5-20% halte ich eine Marge von 100% für besser. Ernst. So können Sie Ihre Möglichkeiten viel besser ausloten. Beantworten Sie weitere Fragen zu Stack Exchange.
Acumenus
Oh ja, es ist die Schuld des Entwicklers, wenn ein 15-jähriger erfahrener Projektmanager einen 1,5-jährigen Rookie-Software-Ingenieur unter Druck setzt, um ihm eine Schätzung zu geben. Dann wird die Schätzung noch aggressiver und verhält sich so, als ob der Entwickler nachlässt, wenn das Projekt ohne Knochen ist . Ich habe noch nie für einen Manager oder PM gearbeitet, der überhaupt Software schreiben konnte, und Sie sagen mir, Terminüberschreitungen sollten nicht zur gängigen Praxis werden, wenn Sie weiterhin Jobs bekommen möchten? Versäumte Fristen sind endemisch, da die meisten PMs an ihrem Arbeitsplatz buchstäblich inkompetent sind. Mein bester Manager war noch kein Softwareentwickler, kannte nur seine Grenzen.
pessimistisch
3

Fehlende Termine sind in der Softwareentwicklung keine Seltenheit. Es ist fast unmöglich, genau abzuschätzen, wie lange ein Softwareprojekt dauern wird.

Professionalität zeigt sich im Umgang damit. Wenn Sie wissen, dass Sie eine Frist verpassen, informieren Sie Ihren Kunden so früh wie möglich darüber, damit er entsprechend planen kann.

Philipp
quelle
2

Es ist ziemlich üblich, aber man kann es besser machen. Möglicherweise möchten Sie die Schätzung anhand abstrakter Informationen wie Story Points untersuchen und Ihre Geschwindigkeit verfolgen , um Ihre tatsächlichen Schätzungen zu berechnen. Diese Konzepte werden am häufigsten mit Scrum in Verbindung gebracht, können jedoch auch verwendet werden, wenn Sie kein Scrum ausführen.

Das Erstaunliche an der Geschwindigkeit ist, dass sie alle immateriellen Dinge wie Unterbrechungen und unerwartete Komplexität umfasst, die Entwickler bei ihren Schätzungen nur schwer berücksichtigen können. Alle Wahrscheinlichkeiten werden im Laufe der Zeit gemittelt. Im Durchschnitt über 10 Wochen waren unsere Geschwindigkeitsschätzungen innerhalb von etwa 5% genau. Wenn wir jedoch dieselben Aufgaben in Stunden schätzen, unterschätzt dasselbe Team immer wieder um 30-50%.

Karl Bielefeldt
quelle
1

Meine (unbewiesene) Theorie besagt, dass sich Menschen dazu entwickelt haben, komplizierte Jobs um zwei oder drei zu eins zu unterschätzen. Immer wenn der Kongress die NASA nach etwas fragt, was es kostet, ein Shuttle zu bauen oder zum Mond zu reisen, kommen sie innerhalb einer Woche mit einer Nummer zurück. Nachdem sie alle erwarteten Kosten aufgebraucht haben, werden sie das Dreifache kosten.

Wir hatten in den 1970er Jahren einen Witz: Nehmen Sie eine Schätzung eines Programmierers, verdoppeln Sie die Zahl und verschieben Sie sie dann auf die nächste Zeiteinheit. Wenn also ein Programmierer angibt, dass dies in zwei Wochen möglich ist, wird er es in vier Monaten fertigstellen.

Wenn jemand eine Küche umgestaltet hat, denkt er im Allgemeinen, dass das in zwei Wochen erledigt sein wird. Sie beenden es ungefähr sechs Wochen später.

Meredith Poor
quelle
1
Was hat die NASA mit meiner Frage zu tun?
1
Genauer gesagt, was hat die menschliche Evolution mit Ihrer Frage zu tun? Die NASA ist ein klar dokumentiertes Beispiel in der öffentlichen Aufzeichnung, dass geschulte und erfahrene Personen große Projekte unterschätzen. Kurz gesagt, Ihre Erfahrung ist "natürlich".
Meredith Poor
Ich stimme zwar zu, dass die Schätzungen der meisten Leute um mindestens das Doppelte abweichen, aber die nächste Zeiteinheit ... hmmmm. Wie auch immer, die NASA ist sehr gut darin, Aufgaben abzuschätzen, von denen sie bereits weiß, wie sie zu erledigen sind. Das Problem ist, dass die Leute nicht sehr gut darin sind, Aufgaben einzuschätzen, wenn sie nicht wissen, was sie nicht wissen. Da die NASA eine Menge Pionierarbeit leistet, ist es kein Wunder, dass sie nicht viel darüber wissen, was sie tun, bis sie anfangen, es zu tun. Dies ist der Grund für die anfängliche Unterschätzung. Auch sind manche Menschen optimistisch und andere pessimistisch eingestellt. Nicht sicher, ob Evolution involviert ist.
Dunk