“Ich habe ein schlechtes Bauchgefühl”, sagte die Entwicklerin plötzlich in die arbeitssame Stille, “ich fühle mich etwas überfordert, das Feature B umzusetzen. Also du weißt schon, ich könnte, aber ich müsste mich dazu zwingen.”
Die Produktmanagerin schaute rüber: “Okay, also Feature B ist ja schon recht minimal geplant. Im Vergleich ist es schon wenig Aufwand. Wollen wir das nicht durchziehen?” Die Entwicklerin schüttelte den Kopf: “Wenn es schwierig zu programmieren ist .. “ - “ist es auch schwer zu benutzen”, vervollständigte die PM, “ja, danke, ich erinnere mich. Also, lass uns nochmal in das Feature rein schauen.”
Die PM legte ihren lass-mich-mal-intensiv-nachdenken-Blick auf. “Aber wir können nicht vollständig auf Feature B verzichten. Feature A ist wichtiger, klar, aber ohne B würde für A etwas fehlen.” Die Entwicklerin schaltete sich dazu: “Feature A haben wir heute vormittag ja ausführlich getestet. Und wir waren uns beide einig, dass nicht mehr viel fehlt, nicht? Und der Code steht auch. Da habe ich ein gutes Gefühl. Ich finde es schade, dass wir dann so viel Aufmerksamkeit in B stecken.”
“Auf was können wir dann verzichten? Wie können wir die Arbeit reduzieren?”, fragte die PM. Die Entwicklerin hakte ein: “Können wir das Backend rauslassen? Ich möchte das vermeiden. Wie wäre es, wenn wir B nicht selber hosten, sondern die eine Hälfte über Google Forms und die andere Hälfte über Github lösen?”. Die PM war plötzlich voll dabei: “Ja, ja! Das können wir in eine spätere Iteration packen. Wir müssen das Feature nicht selber bauen. Ich kann dir ein grünes Licht geben: lasst uns das so lösen, wie du vorgeschlagen hast.”
“Danke! Ich setze mich gleich dran!”
Das ist natürlich ein fiktives Gespräch, aber wenn ich Software schreibe, habe ich doch öfters solche Diskussionen mit mir selbst und finde mich in verschiedenen Rollen wieder. Als Entwicklerin bin ich auf eine gewisse Art pflichtbewusst. Daher fällt es mir in dieser Rolle schwer, zu widersprechen. Aber falls es nicht mehr geht, muss ich das Thema eskalieren und das Gespräch mit der PM suchen. Die PM hat das Recht, ihre Entscheidung durchzuziehen, aber wenn sie merkt, dass da vielleicht etwas dran ist, dann lassen sich gute Anpassungen treffen. Denn bei der Entwicklung neuer Features herrscht eine große Unsicherheit. Und im Angesicht von Unsicherheit sollen Aufwände so weit wie möglich vermieden werden. Eine Variante, die gut genug ist bei weniger Arbeit ist immer gerne gesehen.
Doch die Verantwortung über die Entscheidung liegt bei der PM. Sie muss für ihre Entscheidung einstehen, sie hält der Entwicklerin den Rücken frei. Falls es nicht klappt, wird die PM von sich aus aktiv. Die Entwicklerin darf dem angepassten Plan folgen.
Damit eine solche Dynamik entstehen kann, braucht es ein hohes Vertrauen. Denn viele der Entscheidungen basieren auf Bauchgefühlen. Während die endgültige Rückmeldung vielleicht erst paar Wochen oder Monate später erfolgt. Und gleichzeitig ist es sehr schön, wenn die Produktentwicklung mit einem solchen Dialog zum Leben erwacht.