Softwareprobleme dem Management erklären: Ein Leitfaden für den letzten verbliebenen Entwickler

Sie sind der letzte verbliebene Entwickler. Die zwei Leute, die die Zahlungsintegration verstanden haben, haben das Unternehmen im letzten Jahr verlassen, die Dokumentation wurde vor einer Weile eingestellt, und das meiste von dem, was Sie über dieses System wissen, existiert nur in Ihrem Kopf. Sie haben schon mehr als einmal versucht, dem Management technische Probleme zu erklären. Sie haben das Wort „Refactoring" benutzt. Sie haben „Technical Debt" gesagt. Ihr Manager hat genickt, gemeint, das klinge wichtig, und dann gefragt, ob das neue Feature trotzdem im nächsten Sprint ausgeliefert werden kann.

Das liegt nicht daran, dass Ihr Manager nachlässig ist. Es liegt daran, dass „die Codebasis hat viel Technical Debt" kein Satz ist, auf den eine fachfremde Person reagieren kann. Es fehlt eine Zahl, es fehlt ein Termin, und es fehlt eine klare Konsequenz, falls man es ignoriert. Eine Budgetanfrage braucht alle drei, und im Moment geben Sie dem Management nichts, was es genehmigen könnte.

Warum Ihre Erklärung nicht ankommt

Jede Variante dieses Gesprächs scheitert auf die gleiche Weise. Sie beschreiben das Problem in Code-Begriffen: enge Kopplung, fehlende Tests, eine Abhängigkeit, die drei Hauptversionen veraltet ist. Das Management hört eine Beschwerde über etwas, das es nicht sehen, nicht messen und mit keinem der fünfzehn anderen Dinge vergleichen kann, die in diesem Quartal um das gleiche Budget konkurrieren.

Versetzen Sie sich für einen Moment in ihre Lage. Sie wägen Ihre Anfrage gegen eine neue Vertriebsstelle, eine Marketingkampagne und die Verlängerung des Büromietvertrags ab. Bei jedem dieser Punkte steht eine Zahl daneben. Wenn Ihre Anfrage die einzige ist, die wie eine Meinung klingt, verliert sie jedes Mal, egal wie recht Sie haben.

Die Lösung ist nicht, noch energischer für denselben Punkt zu argumentieren. Sie besteht darin, aufzuhören, die Codebasis zu beschreiben, und statt dessen zu beschreiben, was die Codebasis dem Geschäft antut. Genau diese Umformulierung ist die Fähigkeit, die dieser Beitrag Ihnen vermitteln will, und es lohnt sich, sie richtig zu beherrschen, denn Sie bekommen für dieses Gespräch womöglich nur eine echte Chance, bevor der nächste Deadline es wieder verschluckt.

Übersetzen Sie das Problem in Geld, Zeit und Risiko

Das Management denkt in drei Währungen: Geld, Zeit und Risiko. Was auch immer tatsächlich mit Ihrem System nicht stimmt, Ihre Aufgabe ist es, es in mindestens eine dieser Währungen zu übersetzen, bevor Sie den Mund aufmachen.

Geld lässt sich am leichtesten konkret machen, wenn Sie bereit sind, vorher ein wenig zu rechnen. Wie viele Stunden hat Ihr Team im letzten Monat mit Bugs verbracht, die sich auf dieselben zwei Module zurückführen lassen? Multiplizieren Sie das mit den Kosten, die eine Stunde Entwicklerzeit das Unternehmen kostet, inklusive Gehalt, Lohnnebenkosten und Gemeinkosten, und Sie haben eine Zahl, die jemand aus dem Finanzbereich sofort einordnen kann. „Wir geben derzeit rund 4.000 Euro im Monat aus, um immer wieder dieselbe Art von Bug zu beheben" funktioniert. „Der Code in diesem Modul ist schlecht" funktioniert nicht.

Zeit zeigt sich als die Lücke zwischen dem, was ein Feature eigentlich dauern sollte, und dem, was es tatsächlich dauert. Wenn eine Änderung, die in einer gesunden Codebasis eine halbtägige Aufgabe wäre, jetzt drei Tage braucht, weil jede Änderung fünf unzusammenhängende Dateien berührt, sagen Sie genau das, und sagen Sie es über ein Feature, auf das das Management schon seit längerem wartet. Ein Manager, der seit zwei Monaten fragt, „warum dauert das so lange", wird diesen Satz sofort wiedererkennen.

Risiko ist das, was passiert, wenn sich nichts ändert. Nicht ein vages Risiko, sondern ein konkretes Ausfallszenario mit einem plausiblen Auslöser: der einzige Entwickler, der den Authentifizierungsdienst versteht, könnte das Unternehmen verlassen, die Bibliothek für die Kartenzahlungen erhält seit achtzehn Monaten keine Sicherheitsupdates mehr, der Server ist nur eine ruhige Woche davon entfernt, genau während der wichtigsten Verkaufsperiode der Speicherplatz auszugehen. Wählen Sie das Risiko, das wirklich schmerzen würde, nicht das, das am technischsten klingt.

Sie brauchen nicht alle drei. Eine gut dokumentierte Zahl in einer dieser Währungen schlägt drei vage Aussagen in keiner von ihnen.

Das Ein-Seiten-Dokument, das tatsächlich gelesen wird

Schreiben Sie das auf. Eine mündliche Erklärung verflüchtigt sich in dem Moment, in dem das Meeting endet, und Sie brauchen etwas, das bis zum nächsten Budgetgespräch überlebt, zu dem Sie vielleicht gar nicht eingeladen sind.

Beschränken Sie sich auf eine Seite mit vier Teilen. Beschreiben Sie das Problem in einem einzigen Satz, in Geschäftssprache, nicht in Code: „Jede Änderung am Abrechnungssystem dauert jetzt drei- bis fünfmal so lange wie vor einem Jahr, und in den letzten zwei Monaten haben vier Abrechnungsfehler Kunden erreicht." Darauf folgen die Kosten, anhand der Geld- oder Zeitzahlen, die Sie oben ermittelt haben, als monatliche oder vierteljährliche Größe angegeben statt eines vagen „eine ganze Menge". Nennen Sie dann das Risiko in einem Satz: was kaputtgeht, und ungefähr wann, wenn das Problem weiter unangegangen bleibt. Schließen Sie mit einer konkreten Forderung: eine Anzahl von Wochen, eine Budgetsumme oder eine genannte externe Ressource, nicht „wir sollten uns das irgendwann mal ansehen".

Vermeiden Sie die beiden häufigsten Gründe, warum dieses Dokument ignoriert wird. Füllen Sie es nicht mit technischen Details auf, die die Forderung nicht unterstützen; jeder Satz sollte dazu dienen, die Zahl am Ende zu begründen, nicht zu demonstrieren, wie viel Sie über das System wissen. Und formulieren Sie die Forderung nicht offen. „Wir brauchen Hilfe" lädt zu keiner Entscheidung ein. „Wir brauchen vier Wochen eines Senior-Entwicklers, um das Zahlungsmodul vor der nächsten Preisänderung zu stabilisieren" lädt zu einem Ja oder Nein ein, und über ein Nein lässt sich zumindest noch verhandeln.

Wenn Sie einen weiterführenden Beitrag dazu suchen, wie Sie daraus eine dauerhafte Gewohnheit statt eines einmaligen Vorstoßes machen, haben wir bereits darüber geschrieben, wie man einen monatlichen Bericht aufbaut, den das Management tatsächlich liest, der zeigt, wie Sie diese Zahlen sichtbar halten, bevor die nächste Krise das Gespräch erzwingt.

Wissen Sie, worum Sie tatsächlich bitten

Bevor Sie das Dokument versenden, legen Sie fest, um welche Art von Hilfe Sie eigentlich bitten, denn „wir brauchen Hilfe" und „wir müssen jemanden einstellen" sind nicht dieselbe Forderung, und sie zu vermischen ist ein häufiger Grund, warum das Ganze ins Stocken gerät.

Wenn das Problem ein konkreter, abgegrenzter Teil des Systems ist, bietet ein externes Code-Audit dem Management eine Möglichkeit mit festen Kosten und festem Zeitrahmen, eine unabhängige Einschätzung zu bekommen, wie schlimm die Lage wirklich ist, samt einem Bericht, auf dessen Grundlage gehandelt werden kann, ohne sich allein auf Ihr Wort verlassen zu müssen. Diese Unabhängigkeit zählt mehr, als es scheinen mag: Ein Manager, der dieselbe Warnung von jemandem außerhalb des Unternehmens hört, der kein Eigeninteresse daran hat, recht zu haben, handelt oft schneller als einer, der sie von dem einen Mitarbeiter hört, der von einem größeren Team profitieren könnte.

Wenn das Problem architektonischer Natur ist und sich nicht auf ein Modul beschränkt, geht ein externes Engagement zur Modernisierung von Legacy-Code das strukturelle Problem direkt an, statt nur darum herumzuflicken, und gibt Ihnen ein klar abgegrenztes Projekt mit Start- und Enddatum, statt einer zeitlich offenen internen Initiative, die jeden Sprint erneut um Ihre eigene Zeit konkurriert.

Wenn das eigentliche Zögern des Managements darauf beruht, nicht daran zu glauben, dass die ursprünglichen Technologieentscheidungen richtig waren, beantwortet ein kurzes Tech-Stack-Review durch jemanden ohne Vorgeschichte in der Codebasis genau diese Frage, bevor größere Ausgaben genehmigt werden, was oft der schnellste Weg ist, eine ins Stocken geratene Entscheidung wieder in Bewegung zu bringen.

Wenn Sie genau benennen, welche Art von Hilfe Sie wollen, statt das Management herausfinden zu lassen, machen Sie es leichter, Ja zu sagen, und schwerer, die Entscheidung zu vertagen.

Was passiert, nachdem Sie es verschickt haben

Meistens passiert zunächst nichts, und das ist normal. Budgetentscheidungen werden selten in dem Meeting genehmigt, in dem sie erstmals angesprochen werden. Was Sie mit dem Ein-Seiten-Dokument tatsächlich tun, ist, eine schriftliche Spur anzulegen: einen datierten Nachweis, dass Sie das Risiko mit echten Zahlen gemeldet haben, bevor es zu einem Vorfall wurde. Wenn die genannten Abrechnungsfehler im nächsten Quartal zu einem größeren Ausfall führen, macht dieses Dokument den Unterschied zwischen „wir wurden gewarnt und haben uns entschieden zu warten" und „uns hat niemand etwas gesagt".

Wenn das Management tatsächlich vorangehen möchte, oder einfach jemand anderen braucht, der bestätigt, was Sie bereits gesagt haben: Wolf-Tech arbeitet genau mit solchen Situationen: ein Team, das weiß, dass etwas nicht stimmt, bei dem ein Entwickler die ganze Last trägt, und das eine unabhängige externe Einschätzung braucht, bevor Budget bewilligt wird. Melden Sie sich unter hello@wolf-tech.io oder schauen Sie auf wolf-tech.io vorbei, um zu sehen, wie ein solches Projekt normalerweise beginnt.

Den schwierigen Teil haben Sie bereits erledigt, indem Sie dem Problem eine Zahl gegeben haben. Der Rest ist nur noch das Warten darauf, dass diese Zahl groß genug wird, damit auch jemand anderes sie bemerkt, und das sollte lieber nach Ihren Bedingungen passieren als nach deren.