Einen Weg finden oder einen schaffen

Stellen Sie sich vor, Sie arbeiten in einem Softwareentwicklungsteam und wollen wissen, welche Funktionalitäten die Benutzer Ihrer Software wie oft und wann verwenden. Wie gehen Sie vor? Welche Problemlösungsstrategie wenden Sie an?

Diese oder ähnliche Fragen stelle ich meinen Teilnehmern im Kurs «Problem Solving für Softwareentwickler» zu Beginn. Es geht dabei nicht um die Lösung, sondern ums Vorgehen. Nur wenige können diese Frage mit einem strukturierten Vorgehen beantworten. Und so bleiben die Antworten meist schwammig. Aussagen wie: «Wir überlegen im Team, wie wir es machen könnten und entscheiden dann zusammen», höre ich oft.

Klar ist: Als Softwareentwickler sind wir professionelle Problemlöser. Darum sollten wir diese Fähigkeit auch üben und verbessern.

Moment! Erst mal das Problem verstehen

Als Softwareentwickler springen wir sehr gerne in den Lösungsmodus und es wird sofort über die mögliche Lösung diskutiert. Der erste Schritt in einer guten Problemlösung ist aber, das Problem richtig zu verstehen: Wer hat dieses Problem? Wie zeigt sich das Problem? Unter welchen Umständen? Was ist die Ursache des Problems (Root-Cause-Analysis)? Welches Ziel verfolgen wir mit einer Lösung?

Je nach Art des Problems ist ein entsprechendes Vorgehen zu wählen. Cynefin zum Beispiel unterscheidet fünf Domänen von Problemen: offensichtliche, komplizierte, komplexe, chaotische und unklare Probleme. Während bei komplizierten Problemen eine Analyse angewendet werden kann, um eine gute Lösung zu finden, die dann ausgeführt werden kann, erfordern komplexe Probleme das Sondieren, Wahrnehmen und dann das Reagieren.

Jetzt aber los!

Die erste Idee für eine Lösung ist meist nicht die beste. Bevor in die Lösungsumsetzung gewechselt wird, sollte das Team verschiedene Lösungswege betrachten. Wenn es dem Team hier schwerfällt, verschiedene Varianten zu erarbeiten, dann kann eine Kreativmethode helfen. Beispielsweise Design Studio oder Lateral Thinking.

Wie entscheiden wir, wie wir entscheiden?

Welche Lösung soll denn nun verfolgt werden? Es gibt sehr unterschiedliche Vorgehen, um zu einer Entscheidung im Team zu gelangen. Dies aus gutem Grund, denn es gibt kleine, einfache Entscheidungen bis hin zu komplexen Entscheidungen, mit grossen involvierten Risiken und vielen betroffenen Personen. Gewisse Entscheidungen benötigen wenig Vorwissen, andere setzen eine intensive Auseinandersetzung mit der Thematik voraus. Schliesslich unterscheidet sich der Entscheid, einen Zeilenumbruch im Code zu machen, grundsätzlich vom Entscheid, Software-as-a-Service anzubieten. Darum muss die Entscheidungsmethode zur Art des Entscheides passen.

Entscheidungsmethoden gibt es einige, vom Spontanentscheid für kleine Entscheide über Konsens für eine breite Akzeptanz bis hin zum konsultativen Einzelentscheid für komplexe Entscheidungen. Einen Überblick von Entscheidungsmethoden ist hier zu finden.

Alles klar!

Sobald die gewählte Lösungsvariante klar ist, geht es ans Umsetzen. So einfach wie es klingt, ist es jedoch auch hier nicht. Eine Umsetzung sollte immer schrittweise geschehen, und nach jedem Schritt muss überprüft werden, ob man noch auf dem richtigen Weg ist. Denn durch Feedback lernt man beim Umsetzen dazu und versteht mehr über das Problem und dessen mögliche Lösungen. Nach jedem Schritt muss daher das Vorgehen reflektiert werden und allenfalls angepasst werden. Ganz nach dem Motto: Plan-Do-Feedback-Adjust.

Fertig! Oder doch nicht?

Schliesslich ist die Lösungsvariante umgesetzt. Und trotzdem ist das Team noch nicht ganz am Ende des Problemlösungsvorgehens. Es gibt noch drei Dinge zu erledigen:

• Erstens muss überprüft werden, ob das Problem wirklich gelöst ist. Bei Problemen, welche unregelmässig aufgetreten sind, kann dies einige Beobachtungszeit in Anspruch nehmen.
• Zweitens sollte das Team eine Retrospektive zur Problemlösung durchführen und Verbesserungen im Vorgehen identifizieren für das nächste Problem.
• Drittens soll die Problemlösung mit etwas Abstand nochmals betrachtet werden und wenn möglich vereinfacht und aufgeräumt werden. Dies reduziert spätere Wartungsaufwände.

Die kontinuierlichen Aktionen im Problemlösungsvorgehen.

Denkt an die Konsequenzen

Während der ganzen Problemlösung müssen die betroffenen Personen miteinbezogen und informiert werden. Denn ein Entscheid, der nicht akzeptiert wird, oder der den Betroffenen nicht bekannt ist, zeigt nicht die gewünschte Wirkung. Wenn zum Beispiel ein Designentscheid von zwei Personen im Team gefällt wird, dann können sich die anderen Teammitglieder nur daran halten, wenn sie auch davon wissen. Dies tönt trivial, geht aber viel zu oft vergessen.

Und jetzt?

Sprechen Sie mit Ihrem Team – zum Beispiel in der nächsten Retrospektive – über das Problemlösen und die in diesem Artikel verlinkten Informationen. Reflektieren Sie das Vorgehen Ihres Teams und passen Sie es den Erkenntnissen der Diskussion an.