Die meisten, die sich bei uns melden, haben keine Spezifikation. Sie haben ein Problem, einen Termin und das vage Gefühl, dass Software es lösen könnte. „Wir ersticken in Tabellen.“ „Unser Buchungsprozess verliert die Leute unterwegs.“ „Ich habe eine Idee, aber ich weiß nicht, ob das zwei Wochen oder sechs Monate Arbeit sind.“
Die letzte davon ist die Frage, die wir tatsächlich beantworten.
Ein Gespräch, dreißig Minuten, keine Folien
In diesem Gespräch verkaufen wir Ihnen keinen Prozess. Wir wollen herausfinden, was die Software leisten muss und wer sie benutzen wird, und dafür braucht es ungefähr drei Fragen.
- Was muss die Person, die damit arbeitet, erledigen, und wie macht sie es heute?
- Was ist die eine Sache, die das Bauen lohnend macht, wenn sie funktioniert?
- Was ist schon da? Ein CRM, ein Zahlungsdienstleister, ein Stapel Google Sheets, eine Website, die jemand 2019 gebaut und seitdem niemand mehr angefasst hat?
In der dritten Antwort steckt meistens die eigentliche Arbeit. Ein Buchungsformular kann jeder bauen. Ein Buchungsformular zu bauen, das in ein Buchhaltungssystem schreibt, dem die Buchhalterin bereits vertraut, ist eine andere Aufgabe zu einem anderen Preis, und das erfährt man nur, wenn man früh danach fragt.
Wir hören auf die Form der Sache, nicht auf die Funktionsliste. Eine Funktionsliste, die entsteht, bevor irgendjemand das Problem verstanden hat, ist eine Vermutung mit Aufzählungszeichen, und sie zu schätzen ist Astrologie.
Dann streichen wir
Nach dem Gespräch passiert die Arbeit auf unserer Seite, und der größte Teil davon ist Weglassen. Wir nehmen, was Sie uns erzählt haben, und ziehen eine harte Linie hindurch: was es geben muss, damit Version eins nützlich ist, und was ehrlicherweise später kommt.
Genau hier gehen Projekte schief, und zwar auf eine bestimmte Weise. Die Wunschversion lässt sich leicht planen, weil niemand im Raum zu irgendetwas Nein sagen muss. Alles ist drin, alle gehen zufrieden nach Hause, und die Schätzung ist eine Zahl, die niemand glaubt, auch nicht die Person, die sie aufgeschrieben hat. Zwei Monate später ist das, worauf es ankam, halb fertig, weil das, worauf es nicht ankam, den Sprint aufgefressen hat.
Diese Diskussion führen wir lieber am Anfang. Wenn wir etwas streichen, sagen wir Ihnen schriftlich, was wir gestrichen haben und warum, und Sie können es wieder hineinnehmen.
Die Schätzung selbst kommt von den Leuten, die es auch bauen würden. Nicht von einem Account Manager, der einen Sicherheitsfaktor auf die Vermutung eines Entwicklers legt, und nicht aus einer Vorlage. Wenn sie sich als falsch herausstellt, sitzt die Person, die falsch lag, im Projekt.
Sie bekommen ein Dokument, kein Angebot
Was zurückkommt, ist kurz: was wir bauen, was es kann, was es noch nicht kann und was nötig ist, um dorthin zu kommen. Es ist bewusst unspektakulär. Es gibt keine Folie mit einem Eisberg darauf.
Eine lange Discovery-Phase können wir uns sparen, weil wir mehr als 100 Projekte ausgeliefert haben und die meisten Anfragen sich mit etwas reimen, das wir schon gebaut haben. Ein Buchungssystem. Ein internes Dashboard. Ein Kundenportal. Eine Automatisierung, die eine ungeliebte Aufgabe abschafft. Die Details sind jedes Mal andere. Die Fehlermuster kaum.
Der Punkt, über den wir streiten werden
Wir halten die meisten Discovery-Phasen für Abrechnung im Kostüm der Sorgfalt.
Wochenlange Workshops, bevor irgendjemand Code schreibt, bringen ein schönes Dokument hervor und ein Projekt, das nichts gelernt hat, denn Software lehrt einen etwas dadurch, dass sie läuft, nicht dadurch, dass sie beschrieben wird. Am schnellsten findet man heraus, ob ein Umfang stimmt, indem man die kleinste ehrliche Version davon baut und sie jemandem vorlegt, der das Problem hat.
Der Umfang, den wir Ihnen schicken, soll deshalb nicht vollständig sein. Er soll entscheidbar sein: ja, nein oder kleiner machen. Alle drei sind gute Ergebnisse. Ein Quartal lang zu treiben, ohne zu einem davon zu kommen, ist es nicht.
Wenn Sie eine grobe Idee haben und wissen wollen, was wirklich dahintersteckt, erzählen Sie uns davon.