Entwickler-Produktivität: Mythen, die dein Projekt langsamer machen

Ein Entwickler, der pausenlos tippt, wirkt beschäftigt. Über die Qualität des Ergebnisses sagt das wenig. Wer Entwicklungsarbeit einkauft oder ein kleines Team steuert, misst Produktivität oft an den falschen Dingen, weil man Code schlecht anfassen kann. Ein paar hartnäckige Annahmen sorgen dabei regelmäßig dafür, dass Projekte teurer und langsamer werden. Ich gehe die fünf durch, die mir am häufigsten begegnen.

Ein Beispiel vorweg: Eine kleine Agentur beauftragt einen freien Entwickler für ein Buchungsmodul. Nach zwei Wochen fragt der Projektleiter nervös nach, es seien ja kaum Commits im Repo aufgetaucht, ob das Projekt stockt. Der Entwickler hatte in dieser Zeit das Datenmodell umgebaut, weil die erste Version bei Doppelbuchungen kollabiert wäre. Sichtbar war davon fast nichts. Am Ende lief das Modul stabil, doch die zwei Wochen fühlten sich für den Kunden nach Stillstand an. Genau hier fangen die Missverständnisse an.

Wer viel tippt, kommt schnell voran

Sichtbare Aktivität lässt sich leicht mit Fortschritt verwechseln. Ein großer Teil guter Entwicklungsarbeit besteht aus Lesen und Nachdenken, manchmal auch aus dem Löschen von Code. Der beste Code für ein Problem ist manchmal der, den man am Ende gar nicht schreibt, weil eine bestehende Funktion ausreicht.

Wenn du den Fortschritt an der Zahl der Zeilen oder Commits festmachst, belohnst du das Falsche. Jemand kann in einer Stunde 200 Zeilen produzieren, die drei Wochen später drei andere Leute wieder aufräumen müssen. Frag lieber nach dem, was funktioniert: Welche Teilfunktion läuft jetzt durch, was fehlt noch, wo hakt es. Eine kurze Demo sagt mehr als jede Commit-Statistik.

Mehr Stunden bringen mehr Ergebnis

Bei körperlicher Arbeit stimmt das oft. Beim Programmieren fällt die Qualität nach einer gewissen Konzentrationszeit spürbar ab. Müde geschriebener Code enthält mehr Fehler, und diese Fehler tauchen selten sofort auf. Sie kommen zurück, wenn der Kunde die Seite schon live hat.

Ein Entwickler, der regelmäßig zwölf Stunden macht, ist selten doppelt so weit wie einer mit acht konzentrierten. Die Rechnung geht meistens nicht auf, weil die Nacharbeit die gesparte Zeit wieder auffrisst. Wenn ein Projekt nur mit Dauerüberstunden im Plan bleibt, liegt das Problem selten an der Arbeitszeit. Meistens war die Schätzung von Anfang an zu knapp. Das ehrlich anzusprechen ist billiger als der stille Aufschlag durch Bugs.

Eine kurze Frage kostet doch nichts

Sie kostet mehr, als man denkt. Programmieren heißt, viele Details gleichzeitig im Kopf zu halten: welche Funktion was zurückgibt und welche Randfälle noch offen sind. Eine Unterbrechung räumt diesen Zwischenstand weg. Danach dauert es je nach Aufgabe zehn bis zwanzig Minuten, bis der Kontext wieder da ist.

Für dich als Auftraggeber oder Teamleitung heißt das nicht, dass du keine Fragen stellen darfst. Sammle sie. Statt fünf einzelner Nachrichten über den Tag verteilt lieber eine gebündelte Nachricht oder ein kurzer fester Slot am Nachmittag. Das kostet dich fast nichts und schützt genau die Zeit, in der die eigentliche Arbeit passiert. Wer den ganzen Tag erreichbar sein muss, kommt zu den anspruchsvollen Aufgaben oft erst abends, und da sind wir wieder beim vorigen Punkt.

Der eine geniale Entwickler löst alles allein

Es gibt Leute, die schneller und sauberer arbeiten als andere. Aber die Vorstellung vom Einzelkämpfer, der das ganze Projekt trägt, ist für dein Unternehmen ein Risiko. Wenn nur ein Mensch versteht, wie das System aufgebaut ist, hängst du an dieser Person. Urlaub, Krankheit oder ein Wechsel legen dann das Projekt lahm.

Produktiv ist auf Dauer das Team, das sein Wissen teilt. Ein zweites Paar Augen auf dem Code hilft, dazu eine kurze Doku für die kniffligen Stellen und Commits, die man später noch nachvollziehen kann. Das wirkt kurzfristig wie Verzögerung, weil zwei Leute auf dieselbe Sache schauen. Über die Laufzeit eines Projekts spart es dir aber mehr Zeit, als es kostet, weil Fehler früher auffallen und niemand unersetzlich wird. Bei einer Person, die allein arbeitet, ist die einfache Version davon eine ordentliche Übergabe-Doku.

KI-Tools verdoppeln einfach die Geschwindigkeit

Code-Assistenten sind nützlich, keine Frage. Beim ersten Entwurf einer Funktion, bei Standard-Aufgaben oder beim Erklären fremden Codes sparen sie echt Zeit. Was sie nicht abnehmen, ist das Verständnis dafür, ob der generierte Code zu deinem Projekt passt und wo er im Randfall bricht.

Der Zeitgewinn beim Tippen wird schnell wieder aufgezehrt, wenn niemand den Vorschlag prüft und er später Ärger macht. Ein realistisches Bild: KI beschleunigt Teile der Arbeit, andere dauern gleich lang oder länger, weil das Prüfen dazukommt. Wer verspricht, ein Projekt sei mit KI in der Hälfte der Zeit fertig, hat den Prüf- und Testaufwand meist unterschlagen. Der Fortschritt ist real, er zeigt sich aber eher in besserer Qualität und weniger Grundlagenarbeit als in halbierten Zeitplänen.

Was daraus für deine Projekte folgt

Die fünf Punkte hängen an einem gemeinsamen Faden: Produktivität in der Entwicklung sieht anders aus, als sie sich von außen anfühlt. Die ruhigen Phasen, in denen wenig sichtbar passiert, sind oft die, in denen die teuren Probleme vermieden werden. Und die hektischen Tage mit vielen Zeilen erzeugen häufig genau die Fehler, die dich später Geld kosten.

Wenn du Entwicklungsarbeit steuerst, frag regelmäßig nach lauffähigen Ergebnissen, also nach einer kurzen Demo. Halte deinem Team die konzentrierte Arbeitszeit frei, statt sie mit Zwischenfragen zu zerstückeln. Und nimm eine zu knappe Schätzung ernst, bevor sie sich später als Überstunden und Bugs bemerkbar macht. Dann wird das Projekt nicht garantiert schneller, aber planbarer. Und planbar ist am Ende meistens günstiger als vermeintlich schnell.