Pro­blem­Draft – Erst­ge­sprächs­me­tho­de

Was ist Pro­blem­Draft

Pro­blem­Draft ist eine struk­tu­rier­te Erst­ge­sprächs­me­tho­de, die die wich­tigs­ten Star­t­an­nah­men aus Busi­ness, Tech­nik und Pro­jekt­lo­gik sicht­bar macht. Sie setzt im frü­hen Pro­blemSpace an – in der Phase, in der Pro­blem, Kon­text, Ri­si­ken und An­nah­men ver­stan­den wer­den, bevor eine Lö­sung de­fi­niert wird. Damit er­wei­tert sie die Grun­d­i­dee des Proto-Pro­blem-State­ments um die Re­a­li­tät, in der di­gi­ta­le Vor­ha­ben tat­säch­lich star­ten: ein­ge­bet­tet in be­ste­hen­de Sys­te­me, Er­war­tun­gen und Vor­ga­ben.

Wann. Im Kick­off oder Erst­ge­spräch eines Pro­jekts – bevor An­for­de­run­gen, Lö­sun­gen oder Pläne for­mu­liert wer­den.

Wer. Der Be­ra­ter mo­de­riert, der Auf­trag­ge­ber lie­fert die Aus­sa­gen.

Wie. Im Re­gel­fall wird Pro­blem­Draft ge­mein­sam mit dem Auf­trag­ge­ber im Ge­spräch aus­ge­füllt, in Echt­zeit. Das ist die stär­ke­re Va­ri­a­n­te, weil Lü­cken, Wi­der­sprü­che und un­aus­ge­spro­che­ne An­nah­men di­rekt sicht­bar wer­den. Al­ter­na­tiv füllt der Be­ra­ter das Ras­ter nach dem Ge­spräch für sich, um die mit­ge­brach­te Sicht zu sor­tie­ren. Beide Wege sind gül­tig; der ge­mein­sa­me deckt mehr auf.

Warum. Das Er­geb­nis ist keine fer­ti­ge Pro­blem­stel­lung, son­dern eine struk­tu­rier­te An­nah­men­ba­sis: sicht­bar ge­macht, was heute an­ge­nom­men wird. Der ei­gent­li­che Wert liegt im Sicht­ba­r­wer­den der Lü­cken – wo die Auf­trags­an­nah­me un­voll­stän­dig ist, wo Er­war­tun­gen un­aus­ge­spro­chen blei­ben oder wo ein Lö­sungs­an­satz im Raum steht, der nicht auf das be­schrie­be­ne Pro­blem passt.

Ein­satz­kon­text. Pro­blem­Draft zahlt sich aus, wenn ein Vor­ha­ben nicht auf der grü­nen Wiese star­tet – Mo­der­ni­sie­rung be­ste­hen­der Fachap­pli­ka­ti­o­nen, Ab­lö­sung alter Sys­te­me, B2B-Pro­duk­te mit ge­wach­se­ner Sys­tem­land­schaft, viele Sta­ke­hol­der, hoher Zeit­druck. Bei einem kom­plett neuen Pro­dukt ohne be­ste­hen­de Sys­te­me ist die Me­tho­de über­di­men­sio­niert; dort reicht das klas­si­sche Proto-Pro­blem-State­ment.

Die drei Per­spek­ti­ven

Jede Per­spek­ti­ve hat ihre ei­ge­nen Ru­bri­ken — kein ein­heit­li­ches Ras­ter über alle drei hin­weg.

Was auf den Kar­ten steht

Jede Ru­brik wird mit kur­z­en Ein­trä­gen ge­füllt — eine Karte pro Aus­sa­ge. Ein Ein­trag ist ein Stich­wort oder ein knap­per Satz, keine Aus­for­mu­lie­rung. So sieht das am Bei­spiel Spe­sen­er­fas­sung aus.

Die Busi­ness-Kette

Die ers­ten vier Ru­bri­ken der Busi­ness-Sicht – User, Pro­blem, Ziel, Lö­sungs­an­satz – hän­gen zu­sam­men. Sie bil­den eine Kette, kein loses Ne­ben­ein­an­der:

 User ──▶ Pro­blem ──▶ Ziel ──▶ Lö­sungs­an­satz

 Ein User hat meh­re­re Pro­ble­me.
 Jedes Pro­blem kann meh­re­re Ziele haben.
 Das Ziel ist aus dem Pro­blem ab­leit­bar.
 Der Lö­sungs­an­satz kommt zu­letzt – und ist nur eine Hy­po­the­se.

Diese Rei­hen­fol­ge ist be­wusst: Erst der User, dann sein Pro­blem, dann das Ziel, das sich aus dem Pro­blem ab­lei­tet – und erst da­nach der Lö­sungs­an­satz. Wird der Lö­sungs­an­satz vor­ge­zo­gen, be­schreibt das Ras­ter eine Lö­sung, bevor das Pro­blem steht.

Die Kette von links nach rechts zu lesen, prüft, ob die Ge­dan­ken des Auf­trag­ge­bers in sich schlüs­sig sind: Löst der Lö­sungs­an­satz wirk­lich das Ziel, das aus dem Pro­blem die­ses Users ent­steht?

Mit­a­r­bei­ten­de
  → Be­le­ge gehen ver­lo­ren
      → Ziel: keine ver­lo­re­nen Be­le­ge
          → App mit Be­legs­can            ✓ Lö­sung trifft Pro­blem, Nut­zen beim User

Buch­hal­tung
  → ma­nu­el­le Kos­ten­stel­len-Prü­fung
      → Ziel: we­ni­ger Nach­a­r­beit
          → App mit Be­legs­can            ? Lö­sung trifft die­ses Pro­blem nicht

Mit­a­r­bei­ten­de
  → Frei­ga­ben un­ein­heit­lich (Pro­blem des Ma­nage­ments)
      → Ziel: prüf­ba­re Com­pli­ance
          → strik­ter Frei­ga­be-Work­flow   ⚠ User trägt die Last ohne Ei­gen­nut­zen

Drei Les­ar­ten, drei Er­geb­nis­se. Die erste ist schlüs­sig: Die Lö­sung trifft das Pro­blem, und der User hat selbst etwas davon. Die zwei­te wa­ckelt: Die App scannt Be­le­ge, prüft aber keine Kos­ten­stel­len – der Lö­sungs­an­satz be­ant­wor­tet die­ses Pro­blem nicht.

Die drit­te ist die wich­tigs­te. Hier trägt ein User die Last einer Lö­sung, die das Pro­blem eines an­de­ren löst – des Ma­nage­ments, nicht sei­nes. Er hat kei­nen Ei­gen­nut­zen. Wenn ein Nut­zer ein frem­des Pro­blem lösen muss, ohne selbst etwas davon zu haben, wird die Ein­füh­rung zum or­ga­ni­sa­to­ri­schen Zu­satz­auf­wand: Das Fea­ture muss durch­ge­setzt wer­den, weil der Ei­ge­n­an­trieb fehlt. Die Kette macht das sicht­bar, bevor das Fea­ture ge­baut ist.