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

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?

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 :

• 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.

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.

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.

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%.

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.