Ein dediziertes Entwicklungsteam bietet fortlaufende Kapazität für eine veränderliche Produktplanung. Ein Projekt mit festem Umfang organisiert die Lieferung anhand vereinbarter Ergebnisse und Abnahmekriterien. Beide Modelle können funktionieren. Entscheidend sind die Stabilität des Ergebnisses, die Zuständigkeit für Produktentscheidungen und die Finanzierung von Änderungen. Die Vertragsbezeichnung allein beantwortet diese Fragen nicht.
Umfang und Preismodell unterscheiden
Fester Umfang und Festpreis sind unterschiedliche Vereinbarungen. Ein klar begrenztes Projekt kann nach Zeitaufwand, mit Budgetobergrenze oder zum Festpreis abgerechnet werden. Ein dediziertes Team kann eine monatliche Bindung mit separat vereinbarten Ausgaben haben. Lassen Sie Umfang, Preisbildung, Besetzung und Abnahme getrennt beschreiben. Sonst kann eine Budgetschätzung mit einem verbindlichen Preis oder Kapazität mit einer garantierten Funktionsliste verwechselt werden.
| Frage | Dediziertes Team | Projekt mit festem Umfang |
|---|---|---|
| Was wird geplant? | Kapazität und priorisierte Aufgaben | Definiertes Ergebnis mit Abnahmekriterien |
| Wer priorisiert? | Ihr Produktverantwortlicher gemeinsam mit dem Umsetzungsteam | Vereinbarter Umfangsverantwortlicher; Änderungen folgen einem schriftlichen Prozess |
| Wo liegt die Flexibilität? | Arbeit nach neuen Erkenntnissen umpriorisieren | Arbeit durch ausdrückliche Umfangsentscheidungen tauschen oder ergänzen |
| Hauptrisiko des Käufers | Bezahlte Kapazität hat keine rechtzeitigen Entscheidungen oder sinnvollen Prioritäten | Fehlende Anforderungen führen zu Änderungen oder strittiger Abnahme |
| Nachweise beim Abschluss | Aktueller Code, Entscheidungen, Zugriff und Übergangsplan | Abgenommene Ergebnisse, bekannte Grenzen und betriebliche Übergabe |
Nach der tatsächlichen Unsicherheit entscheiden
Ein dediziertes Team passt zu einem dauerhaften Produktbereich, wenn Kundenfeedback die Prioritäten verändert und auf Ihrer Seite regelmäßig entschieden werden kann. Kontinuität kann Wissen erhalten, ersetzt aber kein klares Ziel. Fragen Sie nach dem Umgang mit Personalwechseln und danach, wie Wissen beim Ausscheiden einer Person erhalten bleibt. Vereinbaren Sie Prüfpunkte, damit die Fortsetzung eine bewusste Entscheidung bleibt.
Ein Projekt mit festem Umfang passt zu einer begrenzten Migration, Integration oder ersten Version, wenn Eingaben und Abnahmebeispiele bekannt sind. Eine verantwortliche Kalkulation wird schwieriger, wenn Zugriffe fehlen oder Beteiligte über das Ergebnis uneinig sind. Eine kurze Analyse kann dann den Ausgang klären, bevor sich beide Seiten auf einen größeren Liefervertrag festlegen.
Kostenrisiken mit gleichen Annahmen vergleichen
Ein hypothetischer Vergleich: Ein fortlaufendes Team kostet drei Monate lang 12.000 € monatlich, insgesamt 36.000 €. Ein begrenztes Projekt wird mit 28.000 € angeboten, zuzüglich angenommener 6.000 € Änderungsreserve und 2.000 € Übergabebudget, ebenfalls 36.000 €. Diese erfundenen Zahlen illustrieren nur den Vergleich. Sie sind keine Byteforge-Preise, Marktwerte oder Zusagen gleicher Kosten beider Modelle.
Prüfen Sie nun die Grenzen. Was passiert, wenn Entscheidungen einen Monat länger dauern, die Datenaufbereitung verspätet ist oder eine Integration vom Muster abweicht? Bei einem Kapazitätsmodell kann Verzögerung bezahlte Zeit verbrauchen. Bei einem begrenzten Auftrag kann dasselbe Ereignis eine Änderung auslösen oder die Abnahme verschieben. Lesen Sie die konkreten Bedingungen: Kein Modell überträgt automatisch jedes Lieferrisiko auf den Anbieter.
Vergleichen Sie gleichwertige Fähigkeiten, Mitwirkung, Testumfang, Bereitstellung und Support. Rechnen Sie die Zeit Ihrer eigenen Mitarbeitenden für Produktentscheidungen, Prüfungen und Koordination hinzu. Ein niedrigerer Stundensatz bedeutet keine niedrigeren Gesamtkosten, wenn viel Arbeit bei Ihnen bleibt. Verlangen Sie Annahmen, Ausschlüsse und einen Prozess für aktualisierte Prognosen neben dem kommerziellen Betrag.
Verantwortung während der Umsetzung sichtbar machen
- Benennen Sie Produktentscheider, technische Leitung, Abnahmeprüfer und Betriebsverantwortlichen. Legen Sie deren Entscheidungsrechte fest.
- Halten Sie Quellcode, Aufgabenhistorie und Liefernachweise während der Arbeit für die vereinbarten Parteien zugänglich.
- Vereinbaren Sie die Kontrolle über Hosting, Dienstkonten, Domains und Zugangsdaten; dokumentieren Sie Übertragung und Zugriffsentzug.
- Regeln Sie Rechte an Projektergebnissen und Drittanbieterkomponenten im Vertrag. Setzen Sie nicht voraus, dass das Preismodell die Eigentumsrechte bestimmt.
Fordern Sie Vorführungen funktionierenden Verhaltens und eine kurze Dokumentation von Risiken und Entscheidungen. Prüfen Sie bei fortlaufenden Teams den Fortschritt anhand von Produktzielen und nicht nur anhand von Aktivitäten. Ordnen Sie bei begrenzten Projekten Vorführungen den Abnahmebeispielen zu. Machen Sie in beiden Fällen blockierte Arbeit früh sichtbar und benennen Sie, wer sie freigeben kann.
Den Ausstieg vor Beginn der Zusammenarbeit planen
Eine praktische Übergabe enthält Repository-Zugriff, Build- und Bereitstellungsanweisungen, Testergebnisse, offene Fehler, Architekturentscheidungen und Supportkontakte. Lassen Sie einen übernehmenden Entwickler die Anweisungen vor dem endgültigen Übergang ausführen. Vereinbaren Sie Übergangszeitraum, Umgang mit unfertiger Arbeit und laufende Supportkosten. Ein Dokumentenordner genügt nicht, wenn niemand das Produkt betreiben kann.
Siehe dedizierte Entwicklungsteams für fortlaufende Kapazität und Produktentwicklung für begrenzte Lieferung. Ist die erste Version Ihr Entscheidungspunkt, nutzen Sie den Leitfaden zum MVP in 30 Tagen. Bringen Sie Produktplanung, bekannte Abhängigkeiten und Ihren verfügbaren Produktverantwortlichen mit. Das Zusammenarbeitsmodell soll zu diesen Fakten passen.