KI-Entwicklungssprint
Ihr nächstes Release wird in 15 Tagen ab dem Kickoff-Workshop spezifiziert, gebaut und übergeben.
Sie bringen die Anforderungen. Wir schreiben sie fest, bauen dagegen und übergeben lauffähige Software samt Quellcode. Fünfzehn Arbeitstage ab dem Kickoff-Workshop, konform zum Vereinbarten, mindestens 75% unter der Schätzung, mit der Sie heute arbeiten.
Fünfzehn Arbeitstage ab dem Kickoff-Workshop. Nicht ab der ersten E-Mail. Die Uhr läuft ab dem Tag, an dem die Anforderungen abgenommen sind, und dieser Tag steht im Vertrag.
Die Anforderungen stehen schriftlich fest, bevor gebaut wird. Was ausgeliefert wird, wird gegen dieses Dokument gemessen. Was nicht passt, gilt nicht als fertig und wird nicht als fertig verrechnet.
Die Sprint-Liefergarantie. Zu spät, nicht anforderungskonform oder über 25% Ihrer mitgebrachten Schätzung, und Sie erhalten Ihr Geld zurück.
Das Release, das längst draußen sein sollte
Die Anforderungen liegen vor. Jemand hat sie geschrieben, jemand hat darüber gestritten, und seit einer Weile sind sie stabil. Was fehlt, ist die Kapazität zum Bauen, und sie fehlt, weil alle, die es könnten, etwas stützen, das bereits produktiv läuft.
Also geht die Anfrage in die Ausschreibung. Zurück kommt eine Zahl, die eine Discovery-Phase einkalkuliert, eine Einarbeitung und ein Team, das Ihre Domäne erst lernen muss, bevor es eine Zeile schreibt. Der größte Teil der Schätzung ist nicht die Software. Es sind die Kosten des Ankommens.
Währenddessen rutscht das Release ein weiteres Quartal, und der Grund dafür ist kein technischer.
Warum fünfzehn Tage eine belastbare Zahl sind
Der Sprint ist kurz, weil die Discovery in den Workshop verdichtet wird statt sich über sechs Wochen Termine zu ziehen. Vier bis acht Stunden, alle mit einer Meinung im Raum, und das Ergebnis ist ein schriftliches Anforderungsdokument, das beide Seiten unterschreiben.
Der Bau ist kurz, weil KI genau die Teile einer Codebasis schreibt, die schon millionenfach geschrieben wurden: Gerüst, Datenzugriff, Tests an den Rändern, der Boilerplate, der den größten Teil einer Schätzung und keinen Teil des Denkens verbraucht. Was sie nicht übernimmt, ist die Entscheidung, was gebaut wird, und das Urteil, ob das Ergebnis korrekt ist. Das ist die Arbeit, und dafür werden die fünfzehn Tage tatsächlich aufgewendet.
Das Ergebnis ist gewöhnliche Software in einem gewöhnlichen Repository. Sie wird nicht generiert und liegengelassen. Sie wird Zeile für Zeile geprüft, gegen das Anforderungsdokument getestet und mit dem Quellcode übergeben, denn ein Release, das Sie nicht warten können, ist kein Release.
Was Sie erhalten
Ein fester Umfang, schriftlich vereinbart, bevor der Sprint beginnt.
Ein Anforderungsworkshop, vier bis acht Stunden. Hier wird der Umfang festgelegt und schriftlich fixiert. Was nicht ins Dokument kommt, kommt nicht in den Sprint, und beide Seiten wissen vor dem Start, was was ist.
Ein zehntägiger Bau-Sprint. Gebaut gegen die abgenommenen Anforderungen, in Ihrem Repository oder in einem, das Ihnen am Ende übergeben wird. Zu jeder Anforderung im Dokument gibt es eine Prüfung, und darüber wird die Garantie abgerechnet.
Ein Präsentations- und Übergabetag. Ein Durchgang durch das Gebaute, das bewusst Weggelassene und den nächsten sinnvollen Ausbauschritt.
Quellcode und schriftliche Dokumentation. Architektur, Abhängigkeiten, Betrieb, Deployment. So geschrieben, dass ein anderer Anbieter ohne Rückfrage übernehmen könnte. Was am Übergabetag übergeht und zu welchen Bedingungen, steht vor dem Sprintstart im Vertrag.
Wie die fünfzehn Tage aussehen
Tag 0
Der Anforderungsworkshop. Vier bis acht Stunden. Der Umfang wird festgelegt und abgenommen. Die Uhr läuft ab hier.
Tag 1 bis 10
Der Bau-Sprint. Am Ende jeder Woche ist ein lauffähiger Stand sichtbar, nicht erst am Schluss.
Tag 11 bis 14
Tests gegen das Anforderungsdokument und die Korrekturen, die daraus folgen.
Tag 15
Präsentation, Übergabe von Quellcode und Dokumentation, dazu eine schriftliche Empfehlung für den nächsten Ausbauschritt.
Fünfzehn Arbeitstage, gezählt ab dem Tag der Anforderungsabnahme. Steht ein Zugang zu einem benötigten System noch aus, pausiert die Uhr bis zur Freigabe, und Sie erfahren am selben Tag davon.
Die Sprint-Liefergarantie
Geliefert innerhalb von fünfzehn Arbeitstagen ab dem Kickoff-Workshop, konform zu den abgenommenen Anforderungen, zu höchstens 25% der von Ihnen mitgebrachten Schätzung. Wird eines der drei verfehlt, erhalten Sie Ihr Geld zurück.
Das Anforderungsdokument ist der einzige Maßstab. Es wird vor dem Sprint abgenommen. Was ausgeliefert wird, wird ausschließlich dagegen gemessen. Keine Seite kann es nachträglich verschieben.
Der Kostenvergleich läuft gegen eine Zahl, die Sie liefern. Bringen Sie die schriftliche Schätzung mit, mit der Sie für denselben Umfang arbeiten, gleich aus welcher Quelle. Diese Zahl wird als Basis in den Vertrag aufgenommen. Ohne eine solche Zahl gilt diese Klausel der Garantie nicht, und der Vertrag sagt das ausdrücklich.
Mängel gegen die Anforderungen werden kostenlos behoben. Niemand kann Software ohne Mängel garantieren. Garantiert wird, dass alles, was den abgenommenen Anforderungen nicht entspricht, ohne weitere Rechnung korrigiert wird.
Was von Ihnen gebraucht wird. Teilnahme am Workshop durch jemanden mit Entscheidungsbefugnis, Zugang zu den betroffenen Systemen und eine benannte Ansprechperson für Rückfragen während des Sprints.
Wie Sie die Garantie geltend machen. Eine E-Mail an info@peakcodeconsulting.ch innerhalb von dreißig Tagen nach der Übergabe, mit der verfehlten Anforderung oder der überschrittenen Zahl. Sie erhalten binnen zehn Arbeitstagen eine Antwort.
Diese Bedingungen kommen vor dem Sprint in den Vertrag, in genau diesem Wortlaut. Sie können uns an jeder einzelnen messen.
Für wen das gedacht ist
Passend, wenn
- die Anforderungen vorliegen und seit einigen Wochen stabil sind.
- ein Release oder ein abgeschlossener Teil davon den Rest freimachen würde.
- jemand auf Ihrer Seite den Umfang in einer einzigen Sitzung festlegen kann.
- Sie Zugang zu den Systemen geben können, mit denen das Release sprechen muss.
Nicht passend, wenn
- der Umfang noch verhandelt wird. Fünfzehn Tage können keine Discovery-Phase auffangen.
- Sie ein Team für ein Jahr einbinden wollen. Das ist ein anderes Vorgehen und ein anderes Gespräch.
- das Release von einem Dritten abhängt, der sich auf kein Datum festgelegt hat.
- Sie den Sprint wollen, aber nicht die schriftlichen Anforderungen. Die Garantie wird dagegen abgerechnet.
Was uns gefragt wird
- Was kostet das?
- Das wird nach dem ersten Gespräch schriftlich offeriert, bezogen auf den Umfang, den Sie mitbringen. Es gibt keine Preisliste, denn ein Release zu bepreisen, ohne die Anforderungen gesehen zu haben, wäre Raten. Das Honorar steht vor dem Sprintstart fest und ändert sich danach nicht.
- Schreibt KI den Produktivcode, der ausgeliefert wird?
- KI schreibt die Teile, die in jeder Codebasis gleich sind, und diese werden vor dem Commit Zeile für Zeile geprüft. Architektur, fachliche Entscheidungen und das Urteil über Korrektheit werden nicht an sie delegiert. Was ausgeliefert wird, hat jemand gelesen.
- Wem gehört das Ergebnis?
- Eigentum und Übertragungsbedingungen stehen im Vertrag, und der wird vor dem Sprintstart unterzeichnet. Quellcode und Dokumentation werden am Übergabetag übergeben. Nach dem Bau bleibt davon nichts mehr zu klären.
- Was, wenn fünfzehn Tage für den Umfang nicht reichen?
- Dann sagt das der Workshop, und der Umfang wird auf das Passende gekürzt oder der Sprint kommt nicht zustande. Ein Umfang, der nicht passt, ist an Tag null eine nützliche Information und an Tag vierzehn ein Problem.
- Was passiert nach dem Sprint?
- Entweder ein weiterer Sprint auf dem nächsten Ausbauschritt, oder nichts. Die Übergabe ist so geschrieben, dass ein weiterer Sprint eine Wahl bleibt und keine Abhängigkeit wird, und die Empfehlung an Tag fünfzehn sagt deutlich, wenn kein weiterer Bedarf besteht.
Sagen Sie uns, was das Release leisten muss
Das erste Gespräch ist kostenlos.
Beschreiben Sie das Release. Wir melden uns innerhalb von 48 Stunden dazu, ob es in fünfzehn Tage passt, was gekürzt werden müsste, wenn nicht, und was der Workshop abdecken müsste.
Wenn die ehrliche Antwort lautet, dass dies die falsche Form der Zusammenarbeit für Ihr Vorhaben ist, steht das in der Rückmeldung.