Ausbildung Anwendungsentwickler bin ich zu langsam?

3 Antworten

Vom Fragesteller als hilfreich ausgezeichnet

Zunächst einmal: 

Mach' dir da mal keinen so großen Kopf drüber. Dass du die deadline überschritten hast, ist unschön. Aber wenn dein Chef auch nur den Hauch einer Ahnung von der Materie hat, dann wird er wissen, dass ein Anfänger (und als Lehrling bist ja einer) realistischerweise gar nicht in der Lage ist, eine echte Abschätzung des Zeitaufwands abzugeben, geschweige denn so etwas einhalten zu können.

Bei meinem ersten Projekt hier habe ich auch die Entwicklungsdauer von 2,5 Jahren um 3 Monate überschritten. (Etwas, das mir gerne bis heute vorgeworfen wird, vor allem von jemandem, der schon Projekte komplett in den Sand gesetzt hat - im Gegensatz zu mir >:) ). Aber ich habe eine Menge Erfahrung aus dem Ganzen ziehen können und mittlerweile läuft das mit den Abschätzungen richtig gut.

Wie WhiteGandalf schon sagte, gibt es in der echten Entwicklung eine Vielzahl von unvorhergesehenen Schwierigkeiten. Deswegen ist es ja Entwicklung. Und für gedankenresistente Chefs, die unbedingt exakte und absolute Zahlen haben wollen (meist BWLer), habe ich mal eine wunderschöne Analogie gehört, die auch ohne technisches Verständnis funktioniert:

Sie verlassen morgens ihr Haus, sperren die Haustür zu und gehen zur Arbeit. Mittags stellen Sie fest, dass sie im Laufe des Tages irgendwann und irgendwo ihren Haustürschlüssel verloren haben.

1. Geben Sie eine exakte Abschätzung (auf 10 Minuten genau), wie lange Sie brauchen, bis sie Ihren Schlüssel wiedergefunden haben.

2. Sagen Sie im Voraus, wo Sie ihren Schlüssel wiederfinden werden.

3. Erklären Sie die Diskrepanzen, sollten Sie die selbst abgegebene Zeitvorgabe von 1. nicht einhalten können oder den Schlüssel an einer anderen Stelle als in 2. angegeben finden.

Eine ganz genaue und exakte Abschätzung mit Zeitangabe ist schlicht und ergreifend unmöglich. Aber eine solche Genauigkeit ist meist auch gar nicht nötig.

Hier ein paar Tips, wie ich es handhabe:

- Auf ad hoc-Abschätzungen lasse ich mich gar nicht erst ein. Und wenn ich 20mal wiederholen muss "ich kann nicht sagen, wie lange es dauert, das muss ich mir erst genauer anschauen", dann wiederhole ich es eben 20mal. Ich lasse mich nicht auf eine unverbindliche Aussage festnageln. Mehr als ein "geht" oder "geht nicht" gibt es von mir nicht aus der hohlen Hand, völlig egal, was sich mein Gegenüber für Zusagen erhofft.

- Wenn eine genauere Abschätzung notwendig ist, nehme ich mir dafür die entsprechende Zeit. Je nach Projekt können das Stunden oder sogar Tage sein, die ich NUR für so eine Zeitabschätzung brauche. Dann zerlege ich das Projekt schon mal in seine groben Teilbereiche, google vielleicht auch schon den einen oder anderen Punkt nach (wurde das schon mal gelöst? Oder bin ich da komplett im Dschungel?) und schätze grob ab, wie lange ich für die jeweiligen Teile brauche.

- Erfahrungsgemäß kann ich auf diese Abschätzung locker 50% draufschlagen. Wenn es was wirklich Komplexes ist, verdoppel ich auch gerne mal die Zeit. Solltest du mit einer realen Abschätzung der reinen Entwicklungszeit zu deinem Chef gehen, wirst du auf brutalst mögliche Art und Weise untergehen. Denn viele bedenken nicht die zahlreichen Zeitfresser, die bei so einem Projekt dazu kommen: Telefonate, Internetrecherche, White papers oder Bücher lesen, Meetings, Projektbesprechungen, Dokumentation etc.pp. Und garantiert wird dir die Zeit für Test und Debug zusammengestrichen. Also gleich vorweg sauber Zeit aufschlagen, dann zieht's dir nicht den Boden unter den Füssen weg, wenn dein Zeitplan zusammengestrichen wird.

- Wenn ich mit Entwicklung anderer zu tun habe (z.B. ich entwickel einen Backend und jemand anderes den Frontend), dann lasse ich mich grundsätzlich auf keine 100%-Aussagen ein. Chefs können auch mit prozentualen Abschätzungen leben, die interessanterweise von vielen Entwicklern gemieden werden (klar, wer programmiert schon ein Programm, das "wahrscheinlich" funktioniert?).
Ich mache dann also Aussagen wie "unter der Prämisse, dass der Frontend fertig ist, könnte ich den Backend mit 80%iger Wahrscheinlichkeit zum Zeitpunkt X fertig haben".
Erfordert aber ein bißchen Übung, weil dann sicher Nachfragen kommen, wieso nicht 100% und man diese Fragen auch beantworten können sollte ("...weil ich z.B. nicht weiss, ob die Verbindung Frontend-Backend so problemlos funktionieren wird, wie ich mir das vorstelle. Ich habe ja nicht alleinig Einfluss darauf...")

- Mache dir selbst einen Zeitplan. Schreibe dir im Voraus auf, was du wann erledigt haben willst. Und sei dir darüber im Klaren, dass dieser Zeitplan keine paar Wochen überleben wird. Dann den Zeitplan passend ändern oder neu formulieren. Wenn sich dabei etwas gravierend ändert, dann umgehend dem Projektverantwortlichen Bescheid geben, damit der auch planen kann. Kommt viel besser, als wenn du 6 Monate vor dich hinwurschtelst und dann merkst, dass du nochmal ein halbes Jahr brauchst und das dann "beichten" musst.    

Da Du in Ausbildung bist , ist für alle Termine überprüfend der Chef verantwortlich . Wenn er meint es ist ein angemessenes Zeitfenster , du aber nicht damit klarkommst , dann rede mit Ihm darüber . Die Ausbildung abbrechen ginge nur bei Fehlverhalten . Du bist kein Angestellter der Verantwortung trägt .


Ahh neeee: Das mit dem Überschreiten von Terminen ist durchaus üblich.

Es geht um folgendes: In der Programmier-Branche führen die Arbeitskräfte prinzipbedingt in fast allen Fällen Arbeiten aus, die mit dem Erfinden von neuen Sachen zusammenhängen. Jedes Schreiben eines Programms ist immer auch ein Stück Erfindung. Es sei denn, man wäre so abgründig mies, dass man alles immer nur bei anderen abkopiert und selbst jede Anpassung auf Fremde abwälzt. Es mag Typen geben, die sowas versuchen, aber das sind dann halt echt nur Nachäffer. Nichts, was ein Programmierer mit ein wenig Programmiererherz in der Hose machen würde.

Wenn man aber Sachen erfindet, ist da zwangsläufig - in der Natur der Sache gegeben - eine Ungewissheit bezüglich dessen, was hinten bei einem Projekt herauskommt, so sehr man auch vorneweg darauf bedacht sein mag, das Ziel so genau wie möglich festzuklopfen. Das wird fast immer dazu führen, dass Du ein Projekt, nachdem es einigermaßen fertig ist und es Dir in der Rückschau durch den Kopf gehen lässt, das nächste Mal völlig anders angehen würdest. Sofern Du es schaffst, Dir immer wieder INTERESSANTE Projekte herauszusuchen (und vor allem Leute, die sie bezahlen), wirst Du immer zwingend dieses Phänomen erleben - weil wiederum in der Natur der Sache liegend nur solche Projekte interessant sind, die einen gewissen unbekannten Anteil haben, der Dir wieder neue Kenntnisse und Einsichten verspricht.

Das ist der Grund, warum Programmierer zwingend und abgehoben vom Rest der Gesellschaft die größten Probleme haben, Terminvorgaben einzuhalten. Unabhängig von der Programmiersprache.

Viele Ansätze der Arbeitsorganisation in der Programmier-Branche zielen denn auch mitnichten darauf, große Projekte planbarer zu machen, sondern sie definieren von vornherein, dass eine Planbarkeit über große Etappen sowieso nicht möglich ist und führen den Zwang ein (und zwar vor allem den Zwang für die Geldgeber und Zielwünscher), Projekte in viele kleine Etappen zu zerlegen, die dann für sich betrachtet und auf kurze Distanz eine bessere Planbarkeit mit sich bringen. Und von vornherein davon ausgehen, dass sich die Planungsvorgaben im Laufe der Erkenntnisentwicklung bei der Umsetzung eines Projekts langfristig sowieso von allen beteiligten Personen aus stark ändern.

Also Fazit: Nimms als ganz normale Lektion in Deinem Ausbildungsfach! So ein Projekt ist auch immer dazu da, den Azubis diesen Aspekt nahezubringen.