Wie lange dauert individuelle Software: die kurze Antwort
Wie lange dauert individuelle Software? Die ehrliche Antwort hängt vom Umfang ab: ein Minimum Viable Product dauert meist 2 bis 4 Monate, ein mittelgroßes Geschäftssystem 3 bis 6 Monate und eine komplexe Unternehmensplattform 6 bis 12 Monate oder länger. Diese Bereiche setzen ein festes Team, stabile Anforderungen und wenige größere externe Verzögerungen voraus. Wenn Sie in 8 bis 10 Wochen etwas Funktionierendes brauchen, beschreiben Sie höchstwahrscheinlich ein MVP, kein komplettes System. Wenn Sie eine ERP-große Plattform in drei Monaten erwarten, ist die Schätzung entweder falsch oder das Ergebnis unvollständig. Dieser Leitfaden gliedert den Zeitplan nach Projektgrößen, schätzt jede Phase, nennt die Faktoren, die den Termin verschieben, und erklärt, wie sich der Zeitplan straffen lässt, ohne Qualität zu kürzen. Das Ziel ist eine realistische Erwartung: Die meisten individuellen Softwareprojekte, die nicht pünktlich fertig werden, scheitern am unterschätzten Umfang, nicht an einem langsamen Team. Nutzen Sie die Bereiche dieses Leitfadens als Planungsgrundlage, und lassen Sie sich dann vom Anbieter die Annahmen hinter jeder genannten Zahl zeigen. Ein Zeitplan, den Sie nicht hinterfragen können, ist ein Zeitplan, dem Sie nicht vertrauen können.
Der Zeitplan eines MVP: 2 bis 4 Monate
Ein MVP (Minimum Viable Product) braucht 2 bis 4 Monate bis zur Produktion. Die ersten 2 bis 4 Wochen gehören der Discovery, die nächsten 2 bis 4 Wochen dem Design, der Großteil des Zeitplans dem Bau der Kernfunktionen und die letzten 2 bis 3 Wochen dem Testen und Launch. Ein MVP lässt Komfortfunktionen bewusst weg, damit ein funktionierendes Produkt schnell echte Nutzer erreicht. Beispiele: ein Kundenportal mit den Grundabläufen, ein internes Tool, das Tabellen ersetzt, oder ein Marktplatz mit einer einzigen Zahlungsmethode. Die zentrale Disziplin ist die Definition der kleinsten Funktionsgruppe, die Wert liefert: alles darüber gehört in die Warteschlange für ein späteres Release, statt jetzt gebaut zu werden. Teams, die ein MVP als verkleidetes Komplettprodukt behandeln, enden meist bei einem 6 bis 9 Monate langen Projekt. Weil ein MVP früh ausgeliefert wird, erhält das Unternehmen zusätzlich den Vorteil echten Nutzerfeedbacks, solange das Produkt noch günstig zu ändern ist, was die zweite Version meist besser macht als einen Plan, der im stillen Kämmerlein entsteht.
Mittelgroße Geschäftssysteme: 3 bis 6 Monate
Ein mittelgroßes Geschäftssystem dauert 3 bis 6 Monate. Diese Kategorie umfasst interne Betriebssoftware, CRM- oder ERP-Erweiterungen, kundenorientierte Webplattformen mit mehreren Rollen sowie Systeme, die mit ein oder zwei vorhandenen Tools verbunden sind. Die Discovery dauert 3 bis 5 Wochen, weil die Anforderungen wirklich komplexer sind: mehrere Nutzerrollen, Reporting, Berechtigungen und Integrationen mit Buchhaltung, Lager oder Zahlungssystemen. Das Design braucht 3 bis 6 Wochen. Die Entwicklung nimmt den längsten Abschnitt ein, meist 6 bis 12 Wochen für ein Team von 3 bis 5 Personen. Tests und Bereitstellung addieren 3 bis 5 Wochen, besonders wenn Daten ohne Betriebsunterbrechung aus einem Altsystem migriert werden müssen. Sobald die Kernabläufe abgenommen sind, wird der Zeitplan berechenbar; alles danach ist Ausführung.
Was in jeder Phase passiert (und wie lange jede dauert)
Ein individuelles Softwareprojekt ist keine einzige lange Programmiersession. Es ist eine Abfolge von Phasen mit jeweils eigener Dauer und eigenem Lieferobjekt, und eine realistische Planung weist jeder Phase einen Bereich zu statt einer einzigen Zahl für das Ganze. Discovery und Anforderungsanalyse übersetzen Ihre Geschäftsanforderungen in einen schriftlichen Umfang, Drahtmodelle und Abnahmekriterien. UI/UX-Design erzeugt die Bildschirme und Interaktionen. Die Entwicklung macht die freigegebenen Entwürfe zu funktionierendem, getestetem Code. Die Qualitätssicherung begleitet den Bau und gipfelt vor dem Launch. Die Bereitstellung führt die Software in die Produktion über, migriert Daten und schult das Team. Die Wartung nach dem Launch behebt die Fehler, die nur echte Nutzer finden. Jede Phase speist die nächste, und eine Phase auszulassen, um Zeit zu sparen, kostet hinterher fast immer mehr Zeit durch Nacharbeit. Fragen Sie nach einem Phasenplan mit benannten Dauern und einem Puffer; eine einzige Sammelschätzung verbirgt genau, wo das Risiko sitzt.
Discovery und Design: die Phase, in der der Termin gewonnen oder verloren wird
Discovery und Design zusammen dauern 4 bis 8 Wochen, und hier werden die meisten Zeitpläne gewonnen oder verloren. Eine hastige zweitägige Discovery bedeutet meist drei Monate Rückfragen während der Entwicklung. Eine saubere Discovery liefert ein Ergebnis auf einer Seite, eine priorisierte Funktionsliste, Drahtmodelle der kritischen Bildschirme und eine Integrationskarte, die zeigt, mit welchen externen Systemen Ihre Software sprechen muss. Das UI/UX-Design dauert dann 2 bis 6 Wochen, je nach Anzahl der Bildschirme und Rollen. Je billiger eine Entscheidung zu ändern ist, desto früher sollte sie fallen: Einen Knopf in einer Designdatei zu verschieben dauert Minuten, ihn im Produktivcode zu verschieben Tage. Teams, die hier übermäßig investieren, sind nicht langsam; sie schützen den späteren Zeitplan vor Zappelei. Wenn Discovery teuer erscheint, denken Sie daran, dass sie meist einen Bruchteil der Nacharbeit kostet, die sie verhindert, und sie ist der billigste Ort, um eine Anforderung zu erwischen, die Sie falsch verstanden haben.
Die Entwicklung: die längste Phase
Die Entwicklung ist die längste Phase und frisst 40 bis 60 Prozent des Gesamtzeitplans. Ein MVP kann 6 bis 10 Wochen aktive Entwicklung brauchen; ein mittelgroßes System 10 bis 20 Wochen; eine Unternehmensplattform 5 bis 9 Monate. Die Dauer hängt weniger vom rohen Aufwand ab als davon, wie die Arbeit strukturiert ist. Ein Team aus einem einzigen Entwickler braucht länger und trägt mehr Risiko als ein Dreierteam, das parallel arbeitet, denn Code kann nicht reviewt werden, Wissen lässt sich nicht teilen, und eine einzige Abwesenheit lähmt alles. KI-gestützte Entwicklungswerkzeuge komprimieren heute Routinearbeit mit messbarem Vorsprung, ersetzen aber weder Architekturentscheidungen noch Tests und Reviews. Realistische Zeitpläne gehen von zwei bis vier aktiven Ingenieuren plus einem Designer und einem QA-Mitarbeiter aus, mit wöchentlichen Demos funktionierender Software. Mehr Ingenieure verkürzen den Bau nicht immer: Leute mitten im Projekt dazuzuholen kann ihn durch Kommunikationsaufwand ausbremsen, deshalb schlägt ein stabiles, passend dimensioniertes Team ein großes, das sich ständig wandelt.
Testen, Bereitstellen und Launch: 2 bis 6 Wochen
Testen, Bereitstellung und Launch dauern 2 bis 6 Wochen, und hier scheitern optimistische Schätzungen leise. Funktionstests sollten die gesamte Entwicklung über laufen, aber ein dedizierter Regressionstest vor dem Launch addiert 1 bis 3 Wochen. Die Datenmigration ist oft die verborgene Zeitsenke: Altdaten zu reinigen, zu mappen und einzuspielen kann Wochen dauern, wenn die Quelldaten unsauber sind. Die Produktivbereitstellung selbst dauert Tage, nicht Wochen, aber der Puffer darum sollte großzügig sein. Der Support nach dem Launch, meist eine Gewährleistungsfrist von 30 bis 90 Tagen, ist nicht optional: Die ersten echten Nutzer werden Randfälle finden, die kein interner Test abgedeckt hat. Diese Fenster einzuplanen verhindert, dass aus dem Launch ein Dauerfeuer wird. Vereinbaren Sie die Abnahmekriterien für den Launch schriftlich, bevor die Tests starten, damit fertig eine gemeinsame Definition ist und kein Streit an der Ziellinie.
Die Faktoren, die Ihren Zeitplan verlängern oder kürzen
Vier Faktoren verschieben Ihren Zeitplan stärker als alles andere. Erstens, die Stabilität des Umfangs: Jede neue Anforderung addiert Zeit, und ein Projekt mit wöchentlichen Änderungswünschen kann seinen Zeitplan leicht verdoppeln. Zweitens, Teamgröße und Erfahrung: Ein festes, erfahrenes Team liefert schneller als ein teilzeit- oder juniorbesetztes Team, weil es weniger Fehlwege nimmt. Drittens, die Komplexität der Integrationen: Die Anbindung an Zahlungsgateways, ERPs oder Dritt-APIs bringt externe Abhängigkeiten und deren Genehmigungszyklen mit sich. Viertens, das Tempo Ihrer eigenen Entscheidungen: Zwei Wochen auf ein Logo, Zugangsdaten oder eine Freigabe zu warten, addiert zwei Wochen zum Kalender. Den Anbieter um einen fixen Termin zu bitten, ohne diese Faktoren anzuerkennen, erzeugt eine Zahl, die selbstbewusst klingt und nichts bedeutet. Beobachten Sie auch das Scope-Governance: Ein formeller Änderungsanfrageprozess, der Zeit und Kosten neu schätzt, hält kleine Wünsche davon ab, sich leise aufzuschaukeln.
Warum Schätzungen den vereinbarten Termin überschreiten
Die meisten Verzögerungen haben drei Gründe, keiner davon ist mysteriös. Scope Creep kommt als wohlgemeinte Kleinwünsche, die sich zu unsichtbarer Arbeit aufstauen. Nacharbeit entsteht, wenn sich eine frühe Entscheidung als falsch erweist und neu gebaut werden muss. Versteckte Integrationen tauchen auf, wenn das Team entdeckt, dass Ihre Software auch mit einem Altsystem sprechen muss, das niemand erwähnt hat, oder dass Compliance- und Sicherheitsprüfungen länger dauern als erwartet. Eine realistische Schätzung reserviert genau für solche Überraschungen einen Puffer von 15 bis 25 Prozent und behandelt den Termin als Bereich statt als einzelne Zahl. Anbieter, die einen fixen Termin ohne Puffer versprechen, schützen meist den Verkauf, und der Zeitplan wird verhandelt, sobald die Realität eintritt.
Wie Sie den Zeitplan sicher verkürzen
Sie können einen Zeitplan komprimieren, ohne Qualität zu zerstören, indem Sie vier Dinge tun. Frieren Sie den Umfang des ersten Releases ein und schieben Sie alles andere nach hinten. Liefern Sie in Phasen: Bringen Sie das MVP in 2 bis 4 Monaten an den Start und ergänzen Sie Funktionen in bemessenen Iterationen statt in einer einzigen Großlieferung. Lassen Sie Phasen parallel laufen, wo immer möglich: Designen Sie das nächste Modul, während das aktuelle gebaut wird, und halten Sie die Qualitätssicherung durchgehend aktiv. Und entscheiden Sie schnell: Stimmen Sie Zugänge, Inhalte und Beteiligte vorher ab, damit kein Warten auf dem kritischen Pfad liegt. Was Sie nicht tun sollten, ist Tests entfernen, Dokumentation überspringen oder die Gewährleistungsfrist kürzen, um einen Termin zu treffen. Diese Abkürzungen rücken den Abgabetermin um Wochen vorwärts und schieben technische Schulden in Ihre Zukunft, wo die Tilgung ein Vielfaches kostet. Setzen Sie schließlich einen harten Go-live-Termin mit einer eingefrorenen Funktionsliste; eine Frist ohne Scope-Grenze ist nur eine Andeutung, und sie rutscht, sobald eine neue Idee eintrifft.
Kostenloses Angebot anfordern
Erhalten Sie in 48 Stunden einen realistischen Zeitplan für Ihr Projekt. Schicken Sie Quanmei Tech ein einseitiges Briefing: Ergebnis, Umfang und Termin, und Sie erhalten einen fixen Bereich, die dahinterstehenden Annahmen und eine Risikoeinschätzung, egal ob wir es bauen oder nicht.