Warum weichen die Schätzungen von Softwareentwicklungsaufgaben regelmäßig um den Faktor 2-3 ab?

Warum weichen die Schätzungen von Softwareentwicklungsaufgaben regelmäßig um den Faktor 2-3 ab?

Dies ist eine Antwort auf die Quora-Frage: Warum sind Schätzungen nicht genau?

Dafür gibt es mehrere Faktoren. Hier einige gängige:

1) Der Kunde ist nicht technisch und hat das Gefühl, dass „alles einfach ist“

Eine Software zu entwickeln ist nicht so einfach, wie es aussieht.

Auch wenn es einfach aussieht, ist es manchmal besser, bestimmte Aufgaben wegzulassen.

• Um eine Analogie zu nehmen:

Es gibt einen riesigen Hügel und wir müssen eine Bahnstrecke bauen. Die Entwickler raten: „Vermeiden Sie den Hügel besser und bauen Sie die Strecke um den Hügel herum. Auf diese Weise sparen wir 5 Monate zusätzliche Arbeit.“

Hier wäre es offensichtlich, dass es viel länger dauert, einen Tunnel durch den Hügel zu bohren und der Kunde würde dem „Workaround“ zustimmen.

• Kommen wir nun zur Softwareentwicklung:

Der Entwickler sagt: „Es wäre besser, nur eine mobile Version mit einer Bildschirmgröße und eine Desktop-Version mit einer Bildschirmgröße zu haben. Wir sollten auf eine Mobile App verzichten und auch ein komplett responsives Design vermeiden, denn das sieht nicht gut aus.“

Hier wird der Kunde höchstwahrscheinlich sagen: „Warum? Andere Websites sind ebenfalls responsive und können auf alle Bildschirmgrößen umgestellt werden. Es ist eine leichte Aufgabe.“

Aber: Es kann mehrere und gute Gründe geben, warum der Entwickler dies vorgeschlagen hat. Vielleicht sieht ein responsives Design nicht gut oder professionell aus. Vor allem einige Tasten können leicht bösartig sein usw. usw.
Was jetzt also passieren wird, ist, dass der Entwickler es tut 1) Erstellen Sie die Seite responsive und 2) erhöht die Stunden.

• Für die Stundenerhöhung erfolgt keine Zustimmung des Auftraggebers: „Warum mehr Stunden? Es ist einfach, oder?“
• Wenn die Aufgabe erledigt ist, schaut sich der Kunde mit seinem Handy die Website an und sagt: „Alles ist falsch ausgerichtet, wenn ich die Website auf dem Handy überprüfe. Warum? Ich habe viel mehr bezahlt und jetzt das?“.

Hätte der Kunde der vorherigen Vorgehensweise zugestimmt (nicht reagierend, mit nur zwei Versionen), wäre die Website billiger (weniger Stunden) und würde auf fast jedem mobilen Bildschirm und Desktop-Browser einwandfrei funktionieren.

Das Hauptproblem ist auch hier: Es ist nicht gut, mit jemandem zu streiten. Vor allem mit dem Kunden zu streiten ist keine gute Idee. Der Entwickler/Dienstleister wird also immer sagen „Ja, Sie haben Recht, machen wir das so“.

Und wenn der Kunde einmal nicht wirklich zufrieden ist, dann sollte der Entwickler wieder die Schuld auf sich nehmen (obwohl er weiß, dass es nicht an ihm lag, sondern dass die Anforderung so war).

2) Es ist nicht möglich, viel Zeit für eine genaue Schätzung zu nehmen

In der realen Welt erhält ein Softwareunternehmen täglich oder wöchentlich Anfragen für Softwareanwendungen.

Wenn jede Anfrage exakt geschätzt würde, hätten die Entwickler nichts anderes zu tun, als genaue Schätzungen zu erstellen. Sie könnten nicht an realen Projekten arbeiten, da die Erstellung dieser genauen Schätzungen sehr zeitaufwändig ist.

Was also tatsächlich passiert ist: Sie schauen sich das Projekt an und „schätzen“ die benötigte Zeit. Deshalb wird sie „Schätzung“ genannt, weil sie nicht genau ist.

Außerdem: Der Kunde selbst ist nicht daran interessiert, eine oder mehrere Wochen zu warten, um den Bedarf zu spezifizieren. Es wird maximal ein 5-seitiges Dokument erstellt und das ist die Grundlage für die Entwicklung.

3) Jede Anforderung ändert sich während des Projekts

Ich zitiere gerne Andrew Rose aus dem Quora-Thread / Link vom Anfang dieses Artikels:

„Egal wie groß oder klein ein Projekt ist, es wird immer etwas passieren, nachdem Sie das Projekt begonnen haben. Wahrscheinlicher ist, dass viele Dinge auftauchen werden. Es ist einfach die Natur des Tieres. Als Produktmanager ist es Ihre Aufgabe, mit Ihren Kunden zusammenzuarbeiten, um das zu finden, was sie brauchen und wofür sie bereit sind zu bezahlen. Sie müssen sich auch überlegen, was Sie mit Hilfe Ihrer Entwickler vernünftig liefern können. Während Sie daran arbeiten, diese Ziele zu erreichen, werden Sie Änderungen im Umfang, falsche Zeitschätzungen und manchmal auch Änderungen bei den Leuten erleben, die an der Fertigstellung des Projekts arbeiten.“

Während des Projekts ändern sich viele Dinge. Wie Andrew erwähnte, werden sich nicht nur die Anforderungen ändern. Sogar Menschen können vor dem aktuellen Projektabschluss in andere Projekte einsteigen.

Hier eine Analogie:

Ein 100-Meter-Sprinter trainiert 10 Jahre lang, um die 100 Meter in weniger als 10 Sekunden zu laufen.

Am Tag des Sprints, sagt der Kunde, brauchen wir auch 5 Hürden auf dem Weg.

Dann sagt der Sprinter: „Aber dann schaffe ich es nicht unter 10 Sekunden“ und der Kunde sagt: „Was hast du in den letzten 10 Jahren trainiert, bitte unter 10 Sekunden“.

Das gleiche auch in Softwareprojekten. Kunden und Projektmanager werden neue Anforderungen einbringen, denn „Oh, ich habe diese sehr wichtige Funktionalität vergessen. Es muss in der Software sein, sonst wird es für uns nicht nützlich sein.“

Diese Anforderungsänderungen werden normalerweise während des gesamten Projekts auftreten. Es ist, als würde man dem Sprinter einen Teich, eine Mauer, eine Leiter usw. in den Weg legen und erwarten, dass er/sie es immer noch unter 10 Sekunden schafft.

4) Architektur nicht richtig geprüft

Vor allem, wenn Dinge nicht von Grund auf neu gemacht werden und Tools von Drittanbietern (WordPress, TYPO3, Drupal, Magento, Shopware und viele andere) verwendet werden und diese angepasst werden sollen, um etwas Besonderes zu tun, zu dem es kommen kann falsche Schätzungen .

In diesen Tools von Drittanbietern können wir nicht einfach alles ändern, was wir wollen. Einfache Dinge wie die URL-Struktur oder andere Dinge müssen beachtet werden.

Wie in Punkt 1) in diesem Text ist nicht alles einfach umzusetzen. Sobald festgestellt wurde, dass die aktuelle Architektur des Drittsystems eine bestimmte Funktionalität nicht unterstützt, ist es immer besser, diese spezifische Funktionalität zu vermeiden und einen Workaround zu verwenden, der die gleiche Aufgabe erfüllt, jedoch die vorhandene Architektur verwendet.

Hinweis: Dieses Problem/Problem tritt auch auf, wenn das Projekt von Grund auf mit Tools wie PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js usw. und einigen anfänglichen, falschen Annahmen erstellt wird wurden über die Architektur des Systems gemacht.

5) Der „ein Satz“ oder „ein Wort“ zeigt Stopper

Ich hatte bereits das Beispiel des 5-seitigen Dokuments erwähnt, das vom Kunden bereitgestellt wird. Wenn die Entwicklung fast abgeschlossen oder im Gange ist, sagt der Kunde: „Es fehlt eine wichtige Funktionalität. Auf Seite 3 in Zeile 22 wird erwähnt, dass wir – ein Reporting-Tool – brauchen“.

Aber der Aufbau dieses Berichtstools, das im Dokument nur kurz erwähnt wird, wird genauso viel kosten wie das gesamte Projekt. Und weil das „Reporting-Tool“ im Dokument erwähnt wird, wird der Auftraggeber natürlich auf dessen Umsetzung bestehen.

6) Das Projekt gewinnen

Nehmen wir an, Sie haben das Gefühl, dass sich viele Unternehmen für das gleiche Projekt bewerben. Jetzt möchten Sie definitiv nicht der Vorschlag sein, der die meisten Stunden berechnet. Sie möchten derjenige sein, der die niedrigste Anzahl von Stunden anzeigt. Wenn ein Kunde zwischen 100 Stunden und 500 Stunden wählen kann, wird sich definitiv jeder für die 100 Stunden entscheiden.

In Wirklichkeit brauchen in einer idealen Welt alle gleich viele Stunden. Obwohl 100 Stunden angegeben wurden, werden es am Ende 500 Stunden sein.

7) Unbekannte/Wartezeiten

Es gibt mehrere Unbekannte in Softwareprojekten:

• a) Technologiewechsel: Wenn eines der Entwicklungstools (zB Android) ein größeres Update erhält, muss mehr Arbeit geleistet werden, um diese technologischen Änderungen zu integrieren.
• b) Erfahrung der Teammitglieder: Wenn ein Senior-Entwickler an dem Projekt arbeitet, dauert es weniger Zeit, wenn es ein Junior-Entwickler ist, wird es höchstwahrscheinlich mehr Zeit in Anspruch nehmen.
• c) Rückmeldung kommt spät: Kunden sind normalerweise nicht sehr an dem Projekt interessiert, sie wollen großartige Ergebnisse. Wenn der Kunde während des Projekts angesprochen wird, ist er möglicherweise nicht bereit, innerhalb einer Stunde zu antworten. Es kann mehrere Tage dauern. Während dieser Zeit liegt das Projekt im Leerlauf und der Dienstanbieter kann während dieser Zeit sogar Stunden berechnen, wenn die Entwickler aufgrund der Verzögerung der Antworten im Leerlauf sitzen.

8) Das Projekt ist zu groß, um richtig geschätzt zu werden

Nehmen wir an, es handelt sich um eine Aufgabe, die mehrere Entwickler über einen Zeitraum von mehreren Monaten benötigt.

Es ist fast unmöglich, die Aufgaben in so kleine Arbeitsblöcke zu zerlegen, um die richtige Schätzung zu erhalten.

Die anderen in diesem Artikel erwähnten Dinge werden natürlich auch eine Rolle spielen.

Fazit

Der beste Ansatz ist:

• Machen Sie eine ungefähre Schätzung
• Erwähnen Sie, dass es am besten ist, die Funktionalitäten zu reduzieren, wenn das Projekt zu lange dauert und viele Stunden dauert (z. B. eine Prioritätenliste von Funktionalitäten erstellen, nur die wichtigsten ausführen)
• Nutzen Sie die agile Methodik für Entwicklung und Abrechnung

Wenn Sie einen genauen Preis/Stunden wünschen, ist dies in der Regel nur bei kleineren Projekten möglich, die einige Wochen dauern.

Weitere interessante Artikel zum Thema:
So schätzen Sie ein Softwareentwicklungsprojekt in Mannstunden realistisch ein
Warum die Schätzung der Softwareentwicklungszeit nicht funktioniert und alternative Ansätze

Bildquelle: Flickr.com/ Michael Kappel/ Judit Klein/ Markus Spiske

Der Autor: Sascha Thattil arbeitet bei Software-Developer-India.com die zur YUHIRO Gruppe gehört. YUHIRO ist ein deutsch-indisches Unternehmen, das Programmierer an IT-Unternehmen, Agenturen und IT-Abteilungen vermittelt.