Was, Wie und Wann in der Softwareentwicklung

Zwar hat jede Softwareentwicklungsinitiative ihre eigenen Merkmale, aber einige Situationen kommen so häufig vor, dass ich das Gefühl habe, ich sollte eine Aufzeichnung haben, die ich beim nächsten Mal abspielen kann, wenn dieselbe Situation auftritt. Eine dieser Situationen ist das "Was", "Wie" und "Wann" der Softwareentwicklung.

Projekte geraten in Schwierigkeiten, wenn nicht klar ist, wer für diese kritischen Entscheidungen zuständig ist, und - was vielleicht noch wichtiger ist - wenn die falsche Person oder Funktion versucht, eine oder mehrere dieser Entscheidungen zu treffen. Wenn die Geschäftsleute versuchen, die Verantwortung für das technische "Wie" eines Projekts zu übernehmen, wissen Sie, dass Sie auf Schwierigkeiten zusteuern.

Ähnlich verhält es sich, wenn Techniker:innen damit beginnen, die Funktionen für die Endbenutzer:innen (das "Was") zu entwerfen, ohne dass die Benutzer:innen oder das Unternehmen mitreden, denn auch das endet oft in einer Katastrophe. Und wenn eine der beiden Funktionen versucht, das "Wann" zu diktieren, ohne Rücksicht auf das "Was" oder das "Wie" zu nehmen, ist das ein großes Problem.

Erst neulich hörte ich einen Geschäftsmann sagen: "Es ist doch offensichtlich, was sie tun müssen - warum können sie nicht einfach mit dem Programmieren anfangen?" Der Geschäftsmann meinte damit im Wesentlichen, dass das "Was" bekannt sei (zumindest in seinem Kopf), so dass das "Wie" auf der Hand liegen sollte - was bedeutet, dass die Ingenieur:innen einfach anfangen sollten, es zu tun.

In solchen Situationen, es sei denn, die Ingenieur:innen sind wirklich inkompetent (was selten vorkommt), ist es sehr zweifelhaft, dass der Geschäftsmann, der hier spricht, das "Was" oder das "Wie" tatsächlich versteht. Die Ingenieur:innen verstehen es sicher nicht, sonst würden sie ja programmieren.

Wenn eine Geschäftsperson eine solche Aussage macht und sich in einer Position befindet, die so mächtig ist, dass die Ingenieur:innen tatsächlich "einfach anfangen zu programmieren", selbst wenn keine Klarheit über das Was oder das Wie besteht, endet das Projekt selten gut. Insbesondere liefert es selten, wenn überhaupt, das, was der Geschäftsmann im Sinn hatte, wann und wie er es wollte.

Und - Sie haben es erraten - es sind die Ingenieur:innen, die im Allgemeinen für das Scheitern verantwortlich gemacht werden, und nicht die Person, die darauf bestanden hat, dass das Projekt auf jeden Fall durchgeführt wird.

Projekte funktionieren am besten, wenn das Unternehmen sagt, "was", die Ingenieure sagen, "wie", und das Unternehmen und die Techniker:innen gemeinsam in gutem Glauben über das "Wann" verhandeln. Manchmal steht das "Wann" fest, z. B. bei einem von einer Messe abhängigen Starttermin oder einer Frist für Investor:innen. In diesem Fall müssen die Geschäftsleute und die Techniker:innen über das "Was" und "Wie" verhandeln.

In ähnlicher Weise kann entweder das "Wie" oder das "Was" feststehen, z. B. weil Sie Änderungen an einem bestehenden System vornehmen und nur begrenzte technische Möglichkeiten haben oder weil Sie sich zur Lieferung einer bestimmten Funktion verpflichtet haben. In diesem Fall müssen das "Wann" und die andere der drei unabhängigen Variablen (entweder das "Was" oder das "Wie") verhandelbar sein. Andernfalls kommt es zu einem vorhersehbaren Scheitern - und/oder zu einem Entwicklungs-Burnout.

Das vielleicht häufigste Problem besteht darin, dass eine einzelne Person oder Funktion versucht, alle drei Aspekte - das Was, das Wie und das Wann - zu beherrschen, indem sie den Ingenieur:innen sagt, was sie entwickeln müssen, wie sie es entwickeln werden und wann das Projekt fertiggestellt werden soll. Wenn es sich bei der Person, die dies tut, nicht um ein Universalgenie handelt - was selten ist -, führt dies unweigerlich zu Problemen.

Ich habe vier Jahre lang mit Steve Jobs bei NeXT zusammengearbeitet, und selbst er hat selten versucht, alle drei Punkte zu diktieren. Zwei von drei hat er versucht, aber selten, wenn überhaupt, alle drei (und dann nicht lange). Steve überließ das "Wie" in der Regel den Ingenieur:innen und akzeptierte oft (wenn auch manchmal zähneknirschend) starke Widerstände beim "Wann". Ich habe zwar nie mit Elon Musk zusammengearbeitet, aber ich habe den Eindruck, dass auch er auf ein Kernteam von Ingenieur:innen hört, denen er vertraut. Wenn Sie sich nicht für klüger halten als Steve Jobs und Mr. Musk, sollten Sie Ihr eigenes Handeln überdenken, wenn Sie versuchen, Ihrem Ingenieurteam vorzuschreiben, was, wie und wann es zu tun hat

Eine weitere, oft übersehene Facette dieses Puzzles ist die Tatsache, dass alle drei Aktivitäten Kommunikation erfordern. Selbst wenn das "Was" im eigenen Kopf klar zu sein scheint, muss es dennoch in Begriffen ausgedrückt werden, die das Entwicklungsteam verstehen kann. Dieser Prozess der "Backlog-Elaboration" offenbart fast immer Lücken in der Klarheit der ursprünglichen Vision, selbst wenn sie Ihnen "offensichtlich" erschien. Auch das "Wie" mag Ihren technischen Führungskräften klar sein, aber es muss dennoch in Architekturdiagrammen, Sequenzdiagrammen, API-Spezifikationen und anderen Artefakten ausgedrückt werden, die die technische Vision an das Entwicklungsteam weitergeben.

Nur wenn das "Was" und das "Wie" ausreichend detailliert ausgedrückt sind, kann ein zuverlässiges "Wann" erstellt werden. Die Tatsache, dass das "Was" im Kopf des Geschäftsmannes oder das "Wie" im Kopf des Architekten oder der Architektin klar ist, bedeutet nicht, dass die Vision des Geschäftsmannes ohne weitere Arbeit erfolgreich operationalisiert werden kann. Aus diesem Grund offenbart "just start coding" eine echte Lücke im Verständnis, wie erfolgreiche Softwareprojekte umgesetzt werden.

All dies kann sehr schnell gehen - in manchen Fällen sogar mündlich und am Whiteboard. Aber im Allgemeinen gilt: Je mehr Input und Verständnis Sie von den Leuten bekommen, die die Arbeit tatsächlich machen, desto besser wird Ihr Rückstand und desto genauer wird Ihr Zeitplan sein.

Die richtige Einschätzung des Wertes jedes Bestandteils ("was", "wie" und "wann"), kombiniert mit dem gebührenden Respekt für die Rollen der jeweiligen Eigentümer:innen, ist das Schlüsselrezept für eine erfolgreiche Softwareentwicklung.