Du bezahlst Entwickler fürs Warten. Und merkst es nicht.

Du hast einen Entwickler beauftragt. Vielleicht einen Freelancer, vielleicht ein kleines Team. Die Stunden laufen. Die Rechnungen kommen. Aber irgendwas fühlt sich komisch an.

Du schaust auf die Rechnung und fragst dich: Was haben die eigentlich die ganze Zeit gemacht? Die Antwort ist oft unangenehm. Denn ein großer Teil der abgerechneten Zeit geht nicht für Programmierung drauf. Sondern fürs Warten.

Warten auf deine Antwort. Warten auf Zugangsdaten. Warten auf eine Entscheidung, die seit zwei Wochen offen ist. Das ist kein böser Wille. Aber es ist ein Problem, das dich richtig Geld kostet. Und die gute Nachricht: Du kannst es ändern.

Warum Warten so teuer ist

Entwickler arbeiten am produktivsten, wenn sie im Fluss sind. Das bedeutet: Sie haben alles, was sie brauchen, und können mehrere Stunden am Stück an einem Problem arbeiten. Unterbrechungen und Wartezeiten zerstören diesen Fluss komplett. Ein Entwickler, der morgens auf eine Antwort von dir wartet, kann nicht einfach was anderes machen und dann nahtlos weitermachen.

In der Praxis sieht das so aus: Der Entwickler stellt dir am Montag eine Frage. Am Mittwoch antwortest du. Dazwischen hat er sich in ein anderes Projekt eingearbeitet. Jetzt muss er sich wieder in dein Projekt reindenken. Das kostet locker eine Stunde, manchmal mehr. Diese Stunde zahlst du. Für nichts, was du siehst.

Ich habe Projekte erlebt, in denen 30 Prozent der Gesamtzeit auf Wartezeiten entfiel. Bei einem Projekt mit einem Budget von 20.000 Euro sind das 6.000 Euro, die nicht in Features, Bugfixes oder Verbesserungen geflossen sind. Sondern in Leerlauf, der vermeidbar gewesen wäre.

Die fünf häufigsten Gründe, warum dein Entwickler wartet

Erstens: Fehlende Zugangsdaten. Das klingt banal, aber es passiert ständig. Der Entwickler braucht Zugang zum Hosting, zur Datenbank, zum E-Mail-Provider oder zu einem Drittanbieter. Du hast die Passwörter irgendwo, aber nicht griffbereit. Oder jemand anderes im Team hat sie, und der ist im Urlaub. Ein Tag Verzögerung. Manchmal eine Woche.

Zweitens: Offene Designentscheidungen. Soll der Button grün oder blau sein? Soll die Tabelle fünf oder zehn Spalten haben? Soll der Kunde eine E-Mail oder eine Push-Nachricht bekommen? Solche Fragen klingen klein. Aber sie blockieren Arbeit. Denn der Entwickler kann nicht raten, was du willst. Und er sollte es auch nicht.

Drittens: Fehlendes Feedback. Der Entwickler schickt dir einen Zwischenstand. Du schaust ihn dir eine Woche nicht an. Dann sagst du: Das ist nicht das, was ich mir vorgestellt habe. Der Entwickler muss jetzt Arbeit rückgängig machen. Arbeit, die er auf Basis deines Schweigens weitergebaut hat. Viertens: Unklare Anforderungen, die erst im Gespräch klar werden, aber das Gespräch findet nicht statt. Fünftens: Interne Abstimmung auf deiner Seite, die länger dauert als die Entwicklung selbst.

Wie du erkennst, dass du der Flaschenhals bist

Die meisten Unternehmer, die ich hier in der Region Neuss und Düsseldorf begleite, sehen sich nicht als Bremse. Das ist verständlich. Du hast dein eigenes Tagesgeschäft. Kundentermine, Buchhaltung, Personalthemen. Das Software-Projekt ist eins von zwanzig Dingen auf deiner Liste. Aber für den Entwickler ist es das Projekt, an dem er arbeiten soll.

Ein klares Zeichen: Du hast ungelesene Nachrichten von deinem Entwickler, die älter als 48 Stunden sind. Oder du schiebst Entscheidungen vor dir her, weil du dir nicht sicher bist. Oder du hast seit dem letzten Meeting neue Ideen, die du noch nicht kommuniziert hast. All das bremst das Projekt.

Ein anderes Zeichen: Der Entwickler fragt dich immer wieder die gleichen Fragen in leicht abgewandelter Form. Das bedeutet nicht, dass er begriffsstutzig ist. Es bedeutet, dass deine ursprüngliche Antwort nicht klar genug war. Oder dass sich etwas geändert hat, ohne dass du es gesagt hast. Das passiert oft. Und es kostet jedes Mal Geld.

Was gute Zusammenarbeit wirklich bedeutet

Gute Zusammenarbeit in einem Software-Projekt ist kein Hexenwerk. Es geht nicht darum, dass du technische Dinge verstehen musst. Du musst keine Code-Reviews machen. Du musst nicht wissen, was eine API ist. Aber du musst erreichbar sein, Entscheidungen treffen und ehrlich sagen, wenn dir etwas nicht gefällt.

Das klingt selbstverständlich. Ist es aber nicht. Viele Auftraggeber denken, sie können ein Projekt beauftragen wie einen Handwerker. Einmal Auftrag geben, dann kommt das Ergebnis. Bei einer neuen Küche funktioniert das vielleicht. Bei Software nicht. Software entsteht im Dialog. Und wenn eine Seite des Dialogs schweigt, passiert entweder nichts oder das Falsche.

Die besten Projekte, die ich gemacht habe, hatten einen Ansprechpartner auf Kundenseite, der innerhalb von 24 Stunden auf Fragen reagiert hat. Nicht mit perfekten Antworten. Manchmal mit einem Satz: Ich bin mir unsicher, lass uns kurz telefonieren. Das reicht. Hauptsache, die Kommunikation steht nicht still.

Konkrete Regeln, die Wartezeiten eliminieren

Regel eins: Bevor das Projekt startet, sammelst du alle Zugangsdaten, Logins und Kontakte zu Drittanbietern. Leg sie in einen Passwort-Manager oder ein gemeinsames Dokument. Das dauert eine Stunde und spart dir Tage im Projektverlauf. Ich schicke meinen Kunden dafür eine Checkliste. Die meisten sind überrascht, wie viele Zugänge tatsächlich gebraucht werden.

Regel zwei: Definiere einen Ansprechpartner. Nicht drei Leute, die sich untereinander abstimmen müssen. Einen Menschen, der Entscheidungen treffen darf. Das ist bei kleinen Unternehmen oft der Chef selbst. Und das ist auch gut so. Aber dann muss der Chef sich die Zeit nehmen. In einem Projekt in Korschenbroich habe ich mal erlebt, dass vier Personen mitentscheiden wollten. Das Ergebnis: Jede Kleinigkeit wurde zur Debatte. Das Projekt hat drei Monate länger gedauert als nötig.

Regel drei: Antworte auf Entwicklerfragen innerhalb von 24 Stunden. Nicht mit einer perfekten Lösung. Sondern mit einer Richtung. Wenn du sagst: Mach es so, wie du denkst, und zeig mir das Ergebnis, ist das besser als Schweigen. Regel vier: Nimm dir wöchentlich Zeit, den aktuellen Stand zu reviewen. Fünf Minuten reichen oft. Aber diese fünf Minuten verhindern, dass der Entwickler eine Woche in die falsche Richtung baut.

Warum dein Entwickler dir das nicht sagt

Hier wird es ehrlich. Die meisten Entwickler sagen dir nicht, dass du das Projekt bremst. Und dafür gibt es Gründe. Erstens: Sie wollen die Geschäftsbeziehung nicht belasten. Du bist der Kunde. Wenn sie sagen, du bist zu langsam, fühlt sich das respektlos an. Also schweigen sie. Und arbeiten an etwas anderem, während dein Projekt stillsteht.

Zweitens: Manche Entwickler profitieren sogar davon. Wenn du nach Stunden bezahlst und der Entwickler in der Wartezeit trotzdem irgendetwas an deinem Projekt tun kann, dann fallen Stunden an. Vielleicht sinnvolle. Vielleicht auch nicht. Ohne transparente Kommunikation kannst du das nicht beurteilen. Das ist kein Vorwurf an die Branche. Aber es ist ein Anreiz, der nicht in deinem Interesse liegt.

Drittens: Viele Entwickler, gerade Freelancer, haben parallel mehrere Projekte. Wenn du langsam antwortest, arbeiten sie an einem anderen Projekt weiter. Wenn du dann plötzlich antwortest, stehst du in der Warteschlange. So kann aus einem Tag Verzögerung schnell eine Woche werden. Nicht aus Bosheit, sondern weil der Kalender des Entwicklers sich in der Zwischenzeit gefüllt hat.

Was das für dein Budget bedeutet

Lass uns rechnen. Ein guter Freelance-Entwickler kostet zwischen 80 und 120 Euro pro Stunde. Nehmen wir 100 Euro. Wenn dein Entwickler pro Woche zwei Stunden auf dich wartet, sind das 200 Euro pro Woche. Bei einem Projekt, das sechs Monate dauert, reden wir über 5.200 Euro. Nur für Wartezeit.

Aber es wird schlimmer. Denn Wartezeit verursacht nicht nur direkte Kosten. Sie zieht das Projekt in die Länge. Und ein längeres Projekt bedeutet: Du hast die Software später im Einsatz. Du fängst später an, den Nutzen zu ernten. Wenn die Software dir pro Monat 2.000 Euro spart, aber zwei Monate später fertig wird, hast du 4.000 Euro Nutzen verloren. Plus die 5.200 Euro Wartezeit. Das sind 9.200 Euro, die du nicht auf der Rechnung siehst, aber trotzdem bezahlst.

Diese versteckten Kosten sind der Grund, warum viele KMU-Inhaber am Ende sagen: Software ist zu teuer. Es ist nicht die Software. Es ist der Prozess drumherum. Und der liegt zum großen Teil in deiner Hand.

So läuft ein Projekt, das nicht auf dich wartet

Stell dir vor, du startest ein Projekt und am Tag eins liegen alle Zugangsdaten bereit. Es gibt ein klares Dokument, das beschreibt, was die Software tun soll. Nicht 50 Seiten. Fünf Seiten reichen. Aber die wichtigen Fragen sind beantwortet: Wer nutzt die Software? Was soll sie können? Was passiert, wenn etwas schiefgeht?

Jede Woche gibt es ein kurzes Update. 15 Minuten. Du siehst, was gebaut wurde. Du sagst, was dir gefällt und was nicht. Offene Fragen werden sofort geklärt oder bis zum nächsten Tag beantwortet. Der Entwickler kann durcharbeiten. Kein Leerlauf, kein Kontextwechsel, kein Rückbau.

In so einem Setting habe ich Projekte in der Hälfte der Zeit fertiggestellt, die andere Projekte gleicher Größe gebraucht haben. Nicht weil ich schneller tippe. Sondern weil niemand gewartet hat. Das ist der Unterschied. Und du bestimmst, auf welcher Seite du stehst.