Ob das Budget eines Softwarevorhabens in eine Lösung fließt, die dem Betrieb tatsächlich hilft, entscheidet sich bereits vor der Entwicklung. Genau dort setzt Discovery an. Sie klärt, welches Problem hinter dem Vorhaben steht, ob dafür überhaupt eine Software entstehen soll und was diese können muss. Ihr Ordnungsprinzip ist die Trennung von Problemraum und Lösungsraum. Auf der einen Seite steht das Problem, das ein Betrieb lösen will, auf der anderen die Gestalt der künftigen Software. Nötig ist diese Klärung, weil die Erfahrung aus der täglichen Arbeit nur in der Umgebung gilt, in der sie entstanden ist. Wer sein Geschäft seit Jahren oder Jahrzehnten führt, kennt dessen Abläufe, nicht aber die Abläufe der Softwareentwicklung. Beim Entwickler ist es umgekehrt. Verlässlich ist ein Urteil deshalb überwiegend dort, wo besonders viele eigene Erfahrungswerte gesammelt wurden.
Discovery klärt vor der Entwicklung, ob und was entstehen soll
Der Begriff Discovery stammt von Marty Cagan, einem Autor und Berater aus der amerikanischen Produktentwicklung. 2008 arbeitete er das Konzept in seinem Buch „Inspired“ systematisch aus. Das Vorgehen selbst hat er nach eigener Aussage nicht erfunden, die Idee ist also älter als ihr Name. Bei Cagan bildet Discovery die eine Hälfte der Produktarbeit. Die andere heißt Delivery und überführt die gefundenen Antworten in fertige, betriebsreife Software. Delivery beantwortet die Frage, wie eine Lösung umgesetzt wird. Discovery klärt vorher, ob es die Lösung überhaupt geben soll und was sie leisten muss.
Der Zweck der Discovery ist, Zeit und Geld auf den tatsächlichen Bedarf zu lenken, um Mehrwert für die künftigen Anwender der Software zu schaffen. An eine bestimmte Methode ist Discovery dabei nicht gebunden. Ob Gespräche, Prototypen oder Probeläufe mit künftigen Nutzern zum Einsatz kommen, richtet sich nach der Frage, die geklärt werden soll. Diese Klärung liegt in jedem Fall vor der eigentlichen Softwareentwicklung, dem teuersten Abschnitt des Vorhabens, und läuft bei Bedarf auch parallel dazu weiter.
Jedes Vorhaben hat einen Problemraum und einen Lösungsraum
Jeder der beiden Räume bündelt eine eigene Art von Fragen.
- Der Problemraum umfasst alle Fragen, die sich stellen, bevor von einer Lösung die Rede ist. Welches Problem zählt wirklich, in welchen Abläufen zeigt es sich, woran wäre eine gute Lösung zu erkennen?
- Zum Lösungsraum gehört jede konkrete Gestalt der Lösung. Welche Funktionen enthält die Software, wie ist sie aufgebaut, wie fügt sie sich in die vorhandenen Systeme ein?
Diese Trennung ist ein Denkwerkzeug. Cagan warnt selbst davor, sie für eine Mauer zu halten, denn die besten Lösungsideen entstehen nach seiner Beobachtung gerade dort, wo beide Räume einander berühren. Vor der Entwicklung, wenn sich entscheidet, ob ein Problem eine Software verdient und welche Gestalt sie annimmt, bleibt die Unterscheidung dennoch der Schlüssel, weil sich jede Frage eines Vorhabens einem der beiden Räume zuordnen lässt. Ist eine Frage ihrem Raum zugeordnet, schließt sich die Folgefrage an, wer sie aus Erfahrung beantworten kann.
Erfahrung entsteht durch Wiederholung und schnelle Rückmeldung
Die Frage nach der Erfahrung wiederum führt in die Entscheidungsforschung, ein Feld fernab der Softwareentwicklung. Der Psychologe Gary Klein untersuchte bereits 1985, wie erfahrene Einsatzleiter der Feuerwehr unter Zeitdruck entscheiden (Klein u. a. 2010). Sein Team erwartete, dass die Einsatzleiter dem klassischen Modell der Entscheidungstheorie folgen, also mehrere Optionen aufstellen und gegeneinander abwägen. Die Überraschung der Studie war, dass genau das fast nie geschah. In mehr als 80 Prozent der ausgewerteten Entscheidungen erkannten die Einsatzleiter die Situation wieder und leiteten daraus unmittelbar ihr Handeln ab. Was im Alltag Intuition heißt, ist in dieser Forschung genau dieses Wiedererkennen erlernter Muster.
Gemeinsam mit dem Psychologen Daniel Kahneman arbeitete Klein später zwei Bedingungen heraus, unter denen dieses Wiedererkennen bzw. diese Intuition verlässlich ist (Kahneman/Klein 2009):
- Die Umgebung muss so regelhaft sein, dass sich Situationen wiederholen.
- Wer in diesen Situationen wiederholt entscheidet, braucht schnelle, eindeutige Rückmeldungen über seine Entscheidung, damit sich richtige Muster von falschen trennen lassen.
Beide Bedingungen bauen auf einer älteren Vorarbeit auf. Der Forscher Robin Hogarth beschrieb 2001 in seinem Buch „Educating Intuition“ Umgebungen, die genau diese beiden Bedingungen erfüllen, als „freundliche Lernumgebungen“, im Original kind learning environments. Kahneman und Klein stützen sich ausdrücklich auf ihn. Die deutsche Strategiepraxis übernimmt dieses Konzept unter dem Namen Lernumwelt. Die Berliner Beratung Dark Horse Innovation etwa arbeitet in ihrem „Future Organization Playbook“ damit. Eine Lernumwelt hat drei Merkmale:
- Wiederkehrende Situationen
- Schnelle und eindeutige Rückmeldungen
- Die Möglichkeit, etwas im kleinen Rahmen auszuprobieren
Die ersten beiden Merkmale decken sich mit den Bedingungen von Kahneman und Klein und damit mit Hogarths Definition. Das dritte Merkmal stammt aus der Strategiepraxis. Es ist ein Erfahrungswert ohne wissenschaftlichen Beleg. In die Liste gehört es trotzdem, denn von den drei Merkmalen ist es das einzige, das sich gezielt herstellen lässt. Ob Situationen wiederkehren und Rückmeldungen schnell kommen, gibt die Umgebung vor. Das Ausprobieren im Kleinen dagegen lässt sich in ein Vorhaben holen.
Im Regelfall hat der Unternehmer Erfahrung im Problemraum und der Entwickler im Lösungsraum
Der Unternehmer, der ein Softwarevorhaben in Auftrag gibt, und der Entwickler, der es umsetzt, lassen sich an denselben drei Merkmalen messen. Das Tagesgeschäft des Unternehmers ist eine Lernumwelt. Die Abläufe wiederholen sich täglich, ein Fehler fällt schnell auf und kleine Änderungen lassen sich im laufenden Betrieb erproben. Sein Urteil darüber, wo im eigenen Geschäft das Problem sitzt, ist deshalb Expertise im Sinne der Forschung, gebunden an den Problemraum. Ein Softwarevorhaben dagegen steht im Arbeitsalltag des Unternehmers selten an. Entscheidet er bei einem solchen Vorhaben falsch, zeigt sich das erst, wenn die fertige Software im Betrieb ist. Diese Rückmeldung kommt so spät, dass sie sich kaum noch einer einzelnen Entscheidung zuordnen lässt. Auch ein Probelauf findet vor der Beauftragung eher nicht statt. Somit ist im Fall eines einmaligen Softwarevorhabens keines der drei Merkmale einer Lernumwelt erfüllt.
Beim Entwickler liegen die Dinge spiegelbildlich. Entwürfe, Umsetzungen und Fehlschläge wiederholen sich über viele Projekte, jede ausgelieferte Softwareversion bringt schnelle Rückmeldung. Ausprobieren gehört zum Handwerk. Seine Erfahrung ist ebenso belastbar wie die des Unternehmers und ebenso an einen Raum gebunden, in seinem Fall an den Lösungsraum. Über die Abläufe eines fremden Betriebs sagt seine Erfahrung jedoch nichts aus, weil dem Entwickler dort jede Wiederholung fehlt.
Die Forschung beschreibt dieses Nebeneinander als „fraktionierte Expertise“, im Original fractionated expertise (Kahneman/Klein 2009). Expertise ist danach in einem Teilbereich belastbar, während sie in einem benachbarten Teilbereich gänzlich fehlt. Dem Experten selbst bleibt diese Grenze verborgen. Die eigene Erfahrung fühlt sich grenzenlos an, weil sie sich in ihrem Teilbereich immer wieder bewährt hat.
Da Erfahrung so spiegelbildlich verteilt ist, ergänzen sich die beiden Rollen im Regelfall. Der Unternehmer ist dort stark, wo dem Entwickler die Wiederholung fehlt, der Entwickler glänzt dort, wo dem Unternehmer die Erfahrung fehlt. Die Trennung, die Cagan methodisch zieht, verläuft damit an derselben Stelle wie die Grenze aus der Entscheidungsforschung. Dass beide Linien zusammenfallen, ist jedoch eher eine Deutung und kein Messbefund, denn Softwarevorhaben hat die Forschung nicht explizit untersucht. Und der Regelfall kennt natürlich Ausnahmen, etwa den Unternehmer, der schon mehrere Softwarevorhaben begleitet hat und für den solche Vorhaben zur wiederkehrenden Situation geworden sind.
Was keiner aus Erfahrung weiß, erprobt Discovery im Kleinen
Aus dieser Rollenverteilung ergibt sich die Arbeitsteilung während der Discovery. Die Fragen des Problemraums beantwortet der Unternehmer, dessen Urteil dort durch seine Erfahrungen gedeckt ist. Die Fragen des Lösungsraums, allen voran die nach der technischen Machbarkeit, beantwortet der Entwickler. Dazwischen bleiben Fragen offen, die keiner der Beteiligten aus Erfahrung beantworten kann. Nimmt die Belegschaft die neue Software im Alltag an und was wird aus dem vertrauten Ablauf, wenn die Software ihn verändert? Solche Fragen fallen keiner der beiden Rollen zu, weil hier beiden die Wiederholung fehlt.
Für diese offenen Fragen holt Discovery das Ausprobieren im Kleinen, also das dritte Merkmal der Lernumwelt, in das Vorhaben. Ein Prototyp zeigt, ob ein Ablauf verständlich ist, bevor die Programmierung beginnt. Ein von Hand nachgestellter Ablauf prüft, ob eine Idee im Alltag besteht, bevor Software daraus wird. Auf dem Prüfstand stehen dabei die Annahmen aller Beteiligten.
Das Ausprobieren im Kleinen schont zugleich das Budget. Jede Funktion, die auf bloßen Verdacht entsteht, verursacht Kosten weit über die Umsetzung hinaus. Den größeren Teil macht die dauerhafte Pflege aus. Unser Artikel über das YAGNI-Konzept erklärt diesen Zusammenhang. Discovery setzt genau aus diesem Grund eine Frage früher an und prüft, ob der Betrieb eine Funktion überhaupt braucht, bevor sie entsteht.
Gibt es für ein Problem eine bewährte Lösung, erübrigt sich Discovery
Nicht jedes Vorhaben braucht eine Discovery. Ob sie nötig ist, entscheidet sich am Problem. Auch ein kleines Vorhaben kann auf ein offenes Problem stoßen, auch ein großes auf ein bereits gelöstes. Wo das Problem längst verstanden ist und eine bewährte Lösung bereitsteht, gibt es nichts zu entdecken; die Entscheidung schrumpft zur Wahl zwischen bekannten Angeboten. Eine Discovery – und das ist ganz wichtig – darf kein Selbstzweck sein. Wenn ihr Ergebnis bereits vorher feststeht, wird sie zum Ritual ohne Mehrwert. Die Praxisliteratur nennt so etwas treffend „Discovery-Theater“.
Für die Wahl zwischen bekannten Angeboten stehen vier Wege offen, vom fertigen SaaS-Produkt bis zur eigenen Entwicklung. Jeder verlagert Kontrolle auf einen Anbieter, einen Dienstleister, eine Community oder das eigene Team. Wie weit diese Abhängigkeit reicht, entscheidet dabei die Umsetzung, nicht der Vertragstyp. Die vier Wege und die Abhängigkeiten, die jeder Weg mit sich bringt, ordnet der Beitrag „Buy vs. Make: Vier Wege zu Software, vier Formen von Abhängigkeit“. Die Wahl zwischen ihnen setzt ein geklärtes Problem voraus und fällt leichter, wenn vorher feststeht, ob für das Problem eine bewährte Lösung bereitsteht oder ob eine Lösung erst entstehen muss.
Sicherheit verrät nicht, ob ein Urteil aus Erfahrung stammt
Ein letzter Befund von Kahneman und Klein wiegt im Alltag am schwersten. Wie sicher sich jemand seines Urteils ist, sagt nichts darüber aus, ob das Urteil aus einer Lernumwelt stammt. Das Gefühl ist dasselbe, ob belastbare Erfahrung dahintersteht oder nicht. Als Prüfung bleibt die Frage nach der Herkunft eines Urteils. Sie gilt zuerst dem Dienstleister, also dem Entwickler, der das Vorhaben umsetzen soll. Woher weiß er, dass sein Vorschlag das Problem löst? Hat er die Abläufe gesehen, die sich ändern sollen, oder kennt er nur ähnliche Betriebe? Erst danach gilt dieselbe Frage dem Unternehmer. Beruht das eigene Bild der Lösung auf Wiederholung und Rückmeldung oder allein auf dem Gefühl, sicher zu sein?
Fragen dieser Art lassen sich klären, bevor die erste Zeile Code entsteht. Wer sie früh stellt, erkennt, welche Annahmen durch Erfahrung gedeckt sind und welche eine Erprobung im Kleinen brauchen. Eine Korrektur kostet zu diesem Zeitpunkt nicht mehr als ein Gespräch oder einen Prototyp. Fällt derselbe Irrtum erst nach der Entwicklung auf, steckt er bereits in programmierten Funktionen und eingespielten Abläufen. Ihn zu beseitigen erfordert erneut Entwicklungszeit, während der Betrieb mit der unpassenden Lösung weiterarbeitet. Ein Vorhaben, das diese Fragen beantwortet hat, baut auf geprüftem Wissen auf. Vom ersten Tag der Umsetzung an fließt das Budget in eine Lösung, die dem Betrieb tatsächlich hilft.