Aller Anfang ist schwer. Aber wenn man sich einmal für einen Weg entschlossen hat, soll man diesen konsequent beschreiten – zumindest solange der gewählte Weg machbar und sinnvoll ist. Das gilt sowohl fürs Bergsteigen als auch für die Softwareentwicklung. Beim Klettern steht man irgendwann mal vor dem Berg und kennt zwar das Ziel – nämlich den Gipfel –, man weiss aber noch nicht genau, wie man ihn erreicht. Verschiedene Unsicherheitsfaktoren spielen dabei eine Rolle: etwa die Wetterverhältnisse, die Schwierigkeit der Wand oder vielleicht kennt man seine Begleiter nicht gut und weiss nicht, wie sie in brenzligen Situationen reagieren. Und trotzdem: Will man auf den Gipfel, bleibt einem nichts anderes übrig, als in die Route einzusteigen.
In der Softwareentwicklung ist dies oft sehr ähnlich. Man beginnt ein Projekt mit einem definierten Endziel, weiss aber noch nicht, wo das Projekt welche Schwierigkeiten birgt, wie man genau zum Endprodukt gelangt und wie sich die Zusammenarbeit im Team und mit dem Kunden gestaltet. Aber auch hier muss man mit dem Programmieren beginnen, wenn das Produkt irgendwann an den Markt soll.
Commitment verhilft zum Erfolg
Egal, wie die Voraussetzungen auch sind: Ist man einmal in der Wand oder im Projekt drin, ist Engagement von allen Beteiligten notwendig, ansonsten dümpelt man einfach so vor sich hin. Es braucht ein Commitment, um den eingeschlagenen Weg konzentriert und ohne Ablenkung gehen zu können. Im Idealfall kommt man in einen Flow, der einen fokussiert und ohne Zögern arbeiten oder klettern lässt. «Committed sein» heisst, sich für ein Projekt zu verpflichten, ganz involviert zu sein. Mit einem expliziten Bekenntnis für die Sache vermittelt man sich selbst und den anderen Beteiligten, dass man alles daransetzt, das vereinbarte Ziel zu erreichen.
Fürs Softwareprojekt heisst das: Man verpflichtet sich dem Produkt – auch dann, wenn es schwierig wird. Manchmal braucht es etwas Biss und Ausdauer, um weiterzugehen. Aber je weiter man fortgeschritten ist, desto grösser werden tendenziell die negativen Auswirkungen bei einem Abbruch. Bricht man mittendrin ab, hat man unter Umständen viel Geld verschwendet. Man muss sich im Klaren sein, dass es schwierige Phasen gibt, die anstrengend sein können – sowohl in der Kletterwand als auch im Softwareprojekt. Man leidet, es wird zäh, Probleme treten auf. Doch wer sich wirklich für das Projekt bekennt, ist auch bereit, sich darauf einzulassen.
Gleichzeitig heisst das auch, Verantwortung für sein Tun zu übernehmen: Wählt man auf der Kletterroute einen neuen, herausfordernderen Weg als den geplanten, mag das zwar spannend sein, doch hat es zur Folge, dass auch der Rest der Seilschaft diesen Weg einschlagen muss – auch wenn die Schwierigkeit sich merklich erhöht hat. Fällen Ingenieure eine technische Entscheidung im Projekt, betrifft das auch die Personen, die in Zukunft mit der Weiterentwicklung des Produkts betraut werden.
Risikoabwägung und Risikobereitschaft
Nicht nur die Entwickler, sondern auch der Auftraggeber muss «committed» sein. Steht der Kunde voll hinter dem Projekt und ist gewillt, mit Investition, Rat und Tat dabei zu sein, sinkt das Risiko, dass das Projekt scheitert. Wenn sich ein Auftraggeber plötzlich schwer tut, seine Vorstellungen vom Projekt zu äussern, dann hat vielleicht das Commitment gefehlt. Doch es gibt noch weitere Risiken, die ein Scheitern provozieren können. Da sind einerseits die kalkulierbaren bzw. reduzierbaren Risiken und andererseits die Restrisiken, die sich nicht vermindern lassen: In den Bergen können sich die Wetterverhältnisse schnell verändern, ein Stein kann sich lösen oder Material kann versagen. Analog dazu kann die Wirtschaft einbrechen, neue Konkurrenz auftreten oder eine Pandemie wirft alles über den Haufen. Solchen – oft sehr unwahrscheinlichen – Risiken ist man mehr oder weniger ausgeliefert. Sie lassen sich kaum reduzieren.
Andere Risiken hingegen lassen sich sehr wohl reduzieren. Dazu gehören die drei hauptsächlichen Risikofaktoren Unwissen, fehlende Ernsthaftigkeit und Ablenkung. Wiederum gelten diese sowohl fürs Klettern als auch für die Softwareentwicklung.
Unwissenheit lässt sich mit Lernen vermindern, also mit Sammeln von Erfahrung und regelmässigem Training. Gegen fehlende Ernsthaftigkeit hilft (gemeinsames) Reflektieren, um eine gewisse System awareness zu erreichen und den Kontext der Situation zu erfassen. Dadurch kann man Risiken besser einschätzen, entsprechend handeln und die Risiken entsprechend senken. Gegen Ablenkung hilft Commitment und Fokus auf das Problem.
Risiko und Commitment beeinflussen sich gegenseitig
Durch die Kombination von Fokus und Commitment schafft man Verbindlichkeit und vermindert somit die Risiken. Wenn wir an einem Produkt arbeiten, das für den Auftraggeber nur ein unwichtiges Nebenprojekt ist, dem er kaum Bedeutung zuspricht, erhöht sich das Risiko, dass wir das Ziel nicht wie geplant erreichen. Die Gefahr ist gross, dass man sich in der Zieldefinition verzettelt oder die verantwortlichen Personen nur unzuverlässig erreicht.
Auch ein Kletterer, der nicht bei der Sache ist, gefährdet die gesamte Seilschaft. Die wahrgenommene Gefahr lenkt ab und der Fokus sinkt. Es entsteht eine Wechselwirkung zwischen Fokus und Commitment: «Die Ablenkung durch die risikobehaftete Situation erschwert es den Beteiligten, ein verbindliches Commitment abzugeben. Umgekehrt werden die Risiken als höher eingestuft, wenn ein Commitment fehlt. Es entsteht ein Teufelskreis, dem es zu entkommen gilt.
Es gibt verschiedene Ansätze, die zum Erfolg führen. Einerseits sollen sowohl Entwickler als auch Kletterer über ihre Risikowahrnehmung reflektieren und lernen, den Fokus trotz Angst vor dem Fall zu behalten. Dazu kommt, dass Erfahrung mit den risikobehafteten Situationen hilft, die Situation angemessen ernst zu nehmen. Dabei sollte man aber nicht überreagieren. Je öfter man sich kontrolliert den Risikosituationen aussetzt, desto besser kann man mit dem Risiko umgehen. Sind wir uns als Individuen und Gruppen über diese Wirkungen bewusst, steigt die Wahrscheinlichkeit, dass man gemeinsam das Ziel erreicht. Ob das nun ein Berggipfel ist oder ein Softwareprodukt, das die Benutzer begeistern soll.
Der Autor
Dominik Berner
Dominik Berner war Senior Software-Ingenieur bei bbv. Dank seines Know-hows im MedTech-Bereich kennt er die Wachstumsgrenzen von Start-ups und Kleinunternehmen, aber auch die Verhältnisse in Grossfirmen. Als Agilist betrachtet Berner Softwareentwicklung als Teamsport, der eine starke Unternehmenskultur erfordert.