Irgendwelche Tipps, wie man nicht-technischen Stakeholdern die Notwendigkeit des Umgangs mit technischen Schulden „verkauft“?

Sie könnten es angehen, indem Sie die Erhöhung der Entwicklungskosten hervorheben, die durch technische Schulden verursacht werden. Das ist auch ein Problem, mit dem wir gerade konfrontiert sind. Unternehmen fordern immer mehr Funktionen, die sie benötigen, wenn mein Team wirklich technische Schulden beseitigen möchte.

Wir haben betont, dass neue Funktionen mit weniger technischer Verschuldung viel schneller ausgeliefert werden können – und schneller bedeutet billiger. Und billiger, mit möglicherweise erhöhter Qualität, geht immer einen langen Weg mit nicht-technischen Leuten :)

Es ist ein bisschen so, als würde man beim Holzhacken eine Pause einlegen, um die Axt zu schärfen.

Gehen Sie proaktiver mit technischen Schulden um

In einem meiner früheren Projekte hatten wir einen großen Teil einer Website, die mit jährlichen Daten betrieben wurde, die vom Unternehmen zusammengestellt wurden. Leider war die Datenbank so konzipiert, dass die Daten jedes Jahres in eine separate Datenbank gehen. Als es an der Zeit war, die Daten des laufenden Jahres zu veröffentlichen, bedurfte es einer Menge Arbeit des Entwicklerteams sowie umfangreicher Tests.

Unser Entwicklerteam hat geschätzt, wie viel Aufwand erforderlich ist, um Änderungen an der Architektur und der Codebasis vorzunehmen. Dann haben wir auch die Zeiteinsparung jedes Jahr als Ergebnis der Änderung geschätzt. Wir setzten uns dann mit dem Geschäftsteam zusammen und erhielten die Genehmigung für den einmaligen Aufwand, diese technischen Schulden zu begleichen.

Ich mag diesen proaktiveren Ansatz, der von Steve McConnell befürwortet wird: How to Categorize & Communicate Technical Debt

1. Bereits zum Zeitpunkt der Übernahme der technischen Schulden sollte das Entwicklerteam den Aufwand, die Arbeit richtig zu erledigen, sowie die Abkürzung einschätzen. Wenn das Unternehmen die Abkürzung wählt, erstellen Sie sofort ein Fehlerticket für die technische Schuld und fügen Sie es in das Backlog ein.
2. Wenn die Schulden älter als 6 Monate sind, wird sie auf Schweregrad 1 angehoben und sollte so schnell wie möglich entfernt werden.

Sie können auch seinen anderen Vorschlag ausprobieren – wenn die Geschwindigkeit zu sinken beginnt, sehen Sie, ob es an zu viel Schulden liegt. Widmen Sie dann eine Iteration, um die technische Schuld zu reduzieren, mit der Erwartung, dass die Geschwindigkeit zunimmt.

In Analogie dazu bitten Sie die Leute, ein perfekt funktionierendes Auto zu ersetzen, weil Sie wissen, dass sich die Kosten für die Wartung des vorhandenen Autos irgendwann nicht mehr lohnen werden. Sie müssen ihnen sorgfältige Schätzungen darüber geben, wann dieser Zeitpunkt sein wird. Mit anderen Worten, der einzige Weg, sie zu überzeugen, besteht darin, einen klaren, vertretbaren Business Case vorzulegen. Wenn Sie die Vorteile in Dollar nicht dokumentieren können, schwimmen Sie nur gegen den Strom.

Um ehrlich zu sein, habe ich nicht viele Leute in IT-Shops gesehen, die bereit sind, ihr Systemwartungsbudget um X $ pro Jahr zu kürzen, wenn sie Y $ für die Aktualisierung ihrer Systeme erhalten. Die meisten positionieren es entweder als Kosten für die Geschäftstätigkeit oder argumentieren, dass das Katastrophenrisiko verringert wird. Das mag alles stimmen, ist aber kein überzeugendes Argument, weil es (wie Sie sagen) nach Jungs riecht, die Spielzeug wollen. Aus PM-Perspektive scheint es mir auch ein guter Weg zu sein, die Nutzenseite der Gleichung nicht zu durchdenken, was ich ärgerlich finde.

Die nicht-technischen Beteiligten müssen nur wissen, wie viel Arbeit erforderlich ist, um die neue Funktion hinzuzufügen. Wie Unit-Tests sollte Refactoring in die Schätzung für das Hinzufügen der neuen Funktion einbezogen werden. Es ist Teil des Entwicklungsprozesses.

Wenn Sie Features gruppieren können, die alle vom Refactoring profitieren, kann die zusätzliche Arbeit über die Gruppe verteilt werden und wird keinem einzelnen Element zugewiesen. Dies ist normalerweise schmackhafter.

Hier ist der Haken: Viele Male haben mich die Stakeholder gefragt, warum eine Änderung länger dauern wird als das letzte Mal, als wir eine ähnliche Änderung vorgenommen haben. Gut - die Stakeholder sind nicht dumm und sie passen auf! Meine Antwort lautet: „Wir sind dem ursprünglichen Design entwachsen. Basierend auf der Anzahl früherer Änderungen im Zusammenhang mit dieser neuen Funktion müssen wir ein neues Design implementieren. Dadurch können wir diese neue Funktion hinzufügen und in der Produktion unterstützen.“

Was Sie suchen, ist eine Analogie, die ihnen hilft, das Problem in einfachen, alltäglichen Begriffen zu verstehen.

Ich empfehle das unten verlinkte Video, das einen Mechaniker zeigt, der einem Auto auf völlig unorganisierte Weise Funktionen in einem solchen Ausmaß hinzufügt, dass beispielsweise das Hinzufügen eines GPS dazu führt, dass das Auto nicht in der Lage ist, rechts abzubiegen.

https://www.youtube.com/watch?v=u5reSgbrVrM

Ward Cunningham entwickelte ursprünglich die Metapher der technischen Schuld, um die Vorstellung zu „verkaufen“, dass die Kosten für das Refactoring von Code „im Voraus“ die Kosten für den Zeitaufwand „nachträglich“ für die Erstellung zusätzlicher Funktionen auf einer Codebasis mit eingeschränktem Code erheblich überwiegen Erweiterbarkeit. Er benutzte damals die Metapher von „Schulden“, weil die Leute, die er zu überzeugen versuchte, Finanzleute waren und er mit ihnen in einer Sprache in Kontakt treten wollte, die sie verstehen konnten.

Wenn Sie die gleiche Grundidee „verkaufen“ müssen, aber die Metapher der technischen Schulden nicht ausreicht, liegt das vermutlich daran, dass die Leute, die Sie überzeugen wollen, keine Finanzexperten sind. In diesem Fall lohnt es sich, nach einer neuen Metapher zu suchen, mit der sich Ihre Zielgruppe gut identifizieren kann.

Hier ist eine einfache Idee, wie man eine andere Metapher erstellt:

Ein junger Mann, nennen wir ihn Mike, bekommt seinen ersten bezahlten Job und beschließt, dass es an der Zeit ist, aus seinem Elternhaus in seine erste Wohnung auszuziehen. Zunächst nimmt Mike ein geräumiges, aber einfaches Zimmer, in dem er schlafen und seine Sachen aufbewahren kann, in dem er jedoch ein Gemeinschaftsbad mit anderen Mietern im Block nutzen muss.

Nach seiner ersten Gehaltserhöhung beschließt Mike, es wäre schön, ein bisschen mehr Komfort zu haben, indem er sein eigenes Waschbecken hätte, anstatt das auf dem Flur zu benutzen. Er ruft jemanden an, der ihm bei der Umsetzung hilft, und obwohl man ihm rät, ein geschlossenes Badezimmer zu bauen, in dem das Waschbecken installiert werden kann, entscheidet er sich für die kostengünstigere Variante, es neben seinem Bett zu installieren.

Die Zeit vergeht und Mike wird bei der Arbeit befördert, und an diesem Punkt beginnt er zu denken: „Diese Sache mit Komfort und Privatsphäre ist großartig! Ich glaube, ich werde hier auch mal duschen!“ Also ruft er den Waschbecken-Typen an und beginnt, Optionen zu besprechen. Jetzt bietet der Waschbecken-Typ wieder einige kostengünstigere und teurere Alternativen, aber dieses Mal besteht er ziemlich darauf, dass die teurere Option, ein eigenständiges Badezimmer zu bauen, das Richtige ist, weil es Mike die Möglichkeit gibt, ein WC und eine Badewanne darin zu installieren Zukunft. Mike denkt lange und gründlich darüber nach - neben den Kosten für den Bau des Badezimmers fallen auch die Kosten für den Einbau seines Waschbeckens an. Und er ist sich nicht einmal sicher, ob er überhaupt ein WC oder eine Badewanne will.

Diese Geschichte hat ein Happy End. Die Alternative (weniger Happy End) sieht vor, dass Mike sich dafür entscheidet, seine neue Dusche neben seinem Fernseher zu installieren und später gezwungen ist, sowohl Waschbecken als auch Dusche sowieso in sein Badezimmer zu verlegen.

In dieser Metapher empfiehlt der Waschbecken-Typ (d. h. das Entwicklungsteam) die Schaffung eines eigenständigen Badezimmers sowie die Verlagerung vorhandener Einrichtungen (d. h. eine Umgestaltung der vorhandenen Einrichtung), um die Installation eines WCs oder einer Badewanne (d. h Entwicklung zukünftiger Funktionen).

Es ist ein ziemlich heimisches Beispiel, aber hoffentlich hilft es Ihnen, an andere zu denken, die für Ihre Domäne besser geeignet sind.