Jo, schätzen können wir am alleraller-schlechtesten. Wir liegen immer um Faktor 2-20 zu niedrig.
Jedesmal poppen Teilaspekte auf, die anfangs übersehen wurden, und die die Aufwände irrwitzig in die Höhe treiben - bei noch so akribischer anfänglicher Untersuchung und Planung.
Ich hab den Eindruck, es gibt keinen Schutz davor.

Ich plane meine Zeit eigentlich immer eher schlecht ein.

Gut getroffen brauche ich manchmal 50% weniger der Zeit als ich für ein Projekt einplane, allerdings öfter als selten verschätze ich mich in der Länge.

Hauptfaktoren die man immer einplanen muss sind generelle Projektplanung, welches meistens mein Grund für die Verzögerung ist da ich kaum bis keine habe und es somit das Projekt unnötig in die Länge zieht.

Auch scheitert es bei mir oft an der Motivation, was dazu führt das ich ein Projekt auf Eis lege.
Das kann bei mir dann einige Tage bis sogar Monate dauern.

Ich habe gerade ein Projekt am laufen welches ich auf 1 Jahr geschätzt hatte, welches mittlerweile bald die 3 Jahresgrenze überschreiten wird.
Deshalb schätze ich die Zeit bei mir immer in Jahren ein und erweitere die Deadline von meinem derzeitigen Projekt von 1 Jahr auf 5 Jahre.

Das funktioniert natürlich nur für private Projekte, im professionellen Bereich ist das absolut undenkbar.
Aus diesem Grund gibt es speziell versierte Personen die Statistik auf dem Kasten haben wie sonst keiner.
Die wissen genau wie man die Mitarbeiter einschätzen kann. Außerdem werden auch Eventualitäten eingeplant wie mögliche Ausfälle durch Erkrankungen ect.

Für eine Einzelperson wird das aber schwierig.
Selbsteinschätzung ist eines der schwierigsten Aufgaben die es zu bewältigen gilt, sowohl auf Emotionaler als auch auf Leistungsebene.
Man kann es schon fast als Lebensaufgabe bezeichnen.
Dem kann natürlich mit viel Erfahrung entgegengewirkt werden.

Wichtig ist das du deine Abläufe protokollierst und genau aufzeichnest.
Auch wenn gewisse Planungseigenschaften von Mensch zu Mensch übertragen werden kann, ist dennoch Individualität im Spiel.
Du kannst dir Tipps holen und auch wiedergeben...
Am Ende gilt es aber, diese so zu verwerten das sie auf dich abgestimmt werden.

Ich habe momentan das Glück, keine Schätzungen abgeben zu müssen. Denn dadurch müsste man belastbare ähnliche Fälle in der Vergangenheit gehabt haben, um auf die Zukunft schließen zu können. Wenn Du ein Feature oder gar ein Projekt hast, was komplett neu ist, wäre es absolut unrealistisch, einen Zeitraum anzugeben. Du kannst dann einfach keine zuverlässigen/belastbaren Angaben machen. Eine scheinbare Mammutaufgabe kann fix gehen, ewig dauern, unlösbar sein. Genauso scheinbarer Pipifax. Solange Du noch nicht mit so ziemlich allen Aspekten des Problems irgendwann mal gearbeitet hast, felht Dir einfach die Grundlage für eine Schätzung. Selbst die Angabe von Zeiträumen (im Sinne von »kommt drauf an, wie sich das Problem gestaltet; im besten Fall 2 Wochen, wahrscheinlich 5 Wochen, wenn alles bis auf einen Atomkrieg eintritt, dann 4 Monate«) ist m.E. ein stückweit fahrlässig, wenn Du mit Punkten umgehen musst, mit denen Du vorher noch nie gearbeitet hast. Wenn Du Deine Zeiträume dokumentierst, die Du für alte Probleme gebraucht hast, kannst Du eine leidlich valide Datengrundlage schaffen. Aber Planungssicherheit ist damit noch lange keine erreicht.
Es stellt sich auch die Frage, wie detailliert und kristallklar die Anforderungen sind. Je genauer, desto besser kann man jeden einzelnen Entwicklungsschritt in eine Kalkulation miteinberechnen. Je schwammiger alles ist, desto mehr Rückfragen muss man stellen, um nicht irgendwann in die falsche Richtung bzw. am Kunden vorbei zu programmieren.

Wenn Du etwas Zeit hast, kannst Du Dir ja das Gespräch mit Ralf Westphal zu dem Thema anschauen (Video beginnt ab nach 13,5 Minuten)
oder auch Robert C. Martin zu dem Thema

@xChRoNiKx Einigermaßen vernünftig kann man nur schätzen, wenn man lange in der SW-Entwicklung arbeitet und die Pflichtenhefte selbst schreibt.
Bei mir kann ich sagen, dass ich für die Implementierung einer (unbekannten) Hardware bei Vorliegen guter Beispiele und Vorhandensein eines guten Supports seitens der Firma sagen wir 3 Wochen benötige.
Gibt es keine Beispiele, dauert es 3 Monate.
Ohne Support und ohne Beispiele - Thema weglassen.

@xChRoNiKx Insbesondere bei Kameras und BarcodeScannern (jeweils Plural) habe ich beim Support sehr gute, niemals schlechte Erfahrung gemacht.
Wenn ich dann zum 42. Mal dort anrief, hatte ich das Gefühl, dass die sich freuten, dass ich es war.
Eigentlich nur bei einer einzigen Hardware, das war ein RS232-USB-Adapter, kam supportmäßig gar nix, das hat sogar mein Chef eingesehen und dann die Hardware gewechselt.

@xChRoNiKx Aus diesem Grund habe ich ja erwähnt das dies für den professionellen Bereich nicht infrage kommt.

Auch wenn du ausgelaugt bist und nicht mehr kannst: DU MUSST LEISTEN!

Leider

Menschen können manchmal so unangenehm werden wenn sie etwas wollen und es nicht so funktioniert wie sie es sich in den Kopf gesetzt haben.

Was mir beim Schreiben meines Post einge- und wieder entfallen war: Schätzen neuer Projekte oder Featureeinbauten beinhaltet u.U. auch etwas, was Donald Rumsfeld mal als »unknown unknowns« bezeichnet hat. Und das sind solche Kandidaten, die Dir eine Schätzung später richtig vermiesen können, weil Du Dich plötzlich mit neuen Sachen/Themen rumschlagen musst, von denen Du vor einer Zusage gar nicht wusstest, dass Du Dich damit beschäftigen musst. Dementsprechend ggf. komplettes Einarbeiten in ein neues Thema oder eine neue Technologie. Das macht Schätzungen noch schwieriger.

Ich habe für mich festgestellt, dass ich nur dann etwas korrekt schätzen kann (dabei ist es egal, ob es ums Programmieren oder anderes geht), wenn ich schon Erfahrung damit habe, also was ähnliches gemacht habe. Ohne diese Erfahrung liege ich mit Schätzungen oft ziemlich daneben. Ich orientiere mich oft an den tatsächlichen Stunden von alten Projekten.

Wenn man nicht schonmal was vergleichbares gemacht hat, kann man das fast nicht ordentlich einschätzen. Das ist bei meinen vergangenen Aufträgen so gewesen und auch in der Großindustrie genauso - den Fall habe ich genau so gerade erlebt, als wir nen Auftrag aus der Forschung heraus an ein großes Entwicklungsunternehmen gegeben haben, nen Proof of Concept ordentlich umzusetzen: Immer kommen irgendwo Sachen auf, die man nicht kommen sehen hat, selbst wenn ganze Abteilungen, die nichts anderes machen, den Aufwand abschätzen und das eigentliche Problem schon prototypenmäßig gelöst wurde.

Was ich daraus gelernt habe, ist, dass ich bei meinen Schätzungen immer annehme, dass an jeder Stelle aufwendige Komplikationen auftreten. Viele von denen werden nicht auftreten, aber an manch anderer Stelle werden andere auftreten, wo du sie nicht erwartet hast.

Ist eine schwierige Frage. Ich rechne meistens so

Realistische Zeit * 2 (Unit-Tests schreiben) +20% Puffer

Bei Programmen die größere integrierte Intelligenz benötigen, rechne ich anstelle von 20% Puffer lieber 100% oben drauf. Da weiß man nie im Voraus, wie umfangreich das wird. Bei Projekten zur einfachen Stammdatenpflege sieht das schon wieder anders aus. Da haue ich gar keinen Puffer drauf, sondern sage pauschal 2 Wochen und bin nach 3 Tagen fertig. Die übrige Zeit nutze ich dann um Fehler in anderen Programmteilen zu beheben.

Yanbel schrieb:

Realistische Zeit

Wo kommt die her?

Naja, groben Programmablauf skizzieren, gedanklich zusammenfassen, welche Routinen es geben muss, Aufwand pro Routine schätzen, alles summieren. Wichtig: Nicht auf die Minute genau, sondern mit halben und ganzen Arbeitstagen rechnen.

Grundsätzlich gilt: Der Zeitplan überlebt einen größeren Denkfehler nicht. Deshalb lieber im Vorfeld deutlich großzügiger rechnen.

xChRoNiKx schrieb:

das vieles ja an sich leicht ist und ja nicht viel Zeit kostet.

Wieviele davon sind Softwareentwickler? Nur diese sind berechtigt, da eine Einschätzung abzugeben. Ich kann einem Automechaniker oder Bäcker ja auch nicht sagen: »Was? Wie lange dauert das? Das kann doch nicht so schwer sein und so lange dauern!« Wenn man keine Ahnung hat, sollte man lieber mal schön still sein. Mir ist bewusst, dass nicht jeder, der in der Softwareentwicklung tätig ist, diesbezüglich eine Ausbildung gemacht hat. Aber wenn man für die Entwicklung von Projekten angeheuert wird, geht der Kunde wohl davon aus, dass er das Projekt nicht selber umsetzen kann, sondern jemanden dafür bezahlen muss. Und wenn derjenige sagt, dass es soundso lange dauert, dann kann der Kunde es entweder akzeptieren, sich einen anderen Anbieter suchen oder muss seine Ansprüche beim Leistungsumfang runterschrauben. Das sind die Möglichkeiten, die ich sehe. Klar, wenn man als Entwickler schneller fertig wird, coole Sache. Aber wie oft passiert das? Doch nur, wenn überraschenderweise sich manche Punkte schneller lösen lassen als erwartet. Was aber dazu führen könnte, dass man zukünftige Schätzungen dementsprechend anpasst. Aber anders kann man es nicht beschleunigen. »Oh, der Entwickler könnte quick&dirty-Hacks nutzen und diese zeitfressenden Tests wegfallen lassen.« Klar, man kann auch beim Autobau Gurte und Airbags weglassen. Und die ein oder andere Elektrikisolierung oder Nahtverschweißung kostet eh zuviel Zeit. Wenn dann das Auto bei 210 km/h auf der Autobahn auseinanderbricht oder explodiert - na, dann ist der Fahrer ja selber schuld, wenn er so schnell fährt. Außerdem wollte er ja das Auto schneller und günstiger als sinnvoll konstruiert bekommen.
*ranting mode off*
Ich glaube, es sollte angekommen sein, was meine Meinung ist.

Mein Schlüsselerlebnis diesbezüglich hatte ich bei einem großen Versicherungskonzern.
Es ging darum, einen neuen Server aufzusetzen und mit Software zu bestücken.
Beim Kickoff-Meeting stellten alle betroffenen Abteilungen ihre Aufwände vor und begründeten diese.
Wir hatten realistisch und mit Reserve geschätzt und hatten ein gutes Gefühl.

Am Ende war es so, dass der Einkauf, der für die Beschaffung der Hardware zuständig war, den gleichen Zeitaufwand zugestanden bekam wie die Software-Entwicklung.
Jeder wusste, dass der neue Server ein HP-Standardserver werden würde wie alle bisherigen auch, für den Einkauf ein eingefleischtes Standardverfahren.
Aber die Einkäufer verstanden es, in ihrem Angebot alle klitzekleinen Vorgänge zu listen und zu begründen.
Deren Angebotsvorstellung dauerte am längsten von allen.

Irgendwann später traf ich den Chef-Einkäufer und sprach ihn darauf an.
Er meinte, er baue immer so viel Luft ein, damit er auch den alle Aufwände kompensieren könne, die nicht direkt zum Projekt gehören..

Ich habe aus dieser Begegnung viel gelernt.
Auch das Kaffeetrinken und die Weiterbildung der Mitarbeiter will bezahlt werden.
Und warum sollte das nicht auf die Kunden umgelegt werden?

Seither detailliere ich meine Aufwandschätzungen viel genauer und plötzlich sehen alle ein, wie groß doch mein Aufwand sein muss.

@xChRoNiKx:

Sagt ihr denen die können auch woanders hingehen oder reduziert ihr damit ihr den Auftrag auch bekommt?

Auf keinen Fall. Es ist egal wie du es verpackst beim Kunden kommt das folgendermaßen rüber: "Ich wollte versuchen, Sie mit 5 Wochen übers Ohr zu hauen, aber da Sie mich durchschaut haben, sag ich jetzt mal 3 Wochen."

Bevor du in so ein Gespräch gehst, hast du ja eine Aufwandsschätzung erstellt und weißt in etwas, was wieviel Zeit kostet. Fass das vorher in einfache, für Kunden verständliche Worte zusammen und überzeug ihn davon, dass die Zeiten realistisch sind.

@petaod
Ein Paradebeispiel... Genau so muss es laufen.