Hör auf deine Entwickler.

Hallo. Du bist wahrscheinlich aus einem von zwei Gründen auf diese Seite gestoßen:

1. Du bist Entwickler und hast die URL dieses Artikels gesehen und dachtest: "Ok, ich bin Entwickler und ich will, dass man auf mich hört. Mal sehen, was sich dahinter verbringt."
2. Du bist Manager, kein Entwickler— aber ein Entwickler hat dir diesen Link geschickt und dir gesagt, dass du diesen Artikel lesen sollst.

Es tut mir bereits hier leid, wenn du auf der Entwicklerseite an Technologieprojekten von Unternehmen beteiligt gewesen bist; der Rest dieses Artikels wird dir zeitweise den Blutdruck in die Höhe treiben, während wir in Erinnerungen an den Schmerz und das Leid schwelgen, dass wir durch die Hand des Antagonisten, bekannt als "Das Management", erdulden mussten. Es tut mir wirklich für alle leid, die nachvollziehen können, wie sich dieser Schmerz anfühlt.

Wenn, warum auch immer, du in die zweite oben aufgelistete Kategorie fällst, dann tut es mir für dich nicht leid. Denn der Rest dieser Seite wird nicht nett für dich sein. Warum? Weil du Teil des Problems bist. Hab also Angst oder nicht, ich werden dir den Weg zum Pfad zurück zeigen, den du gehen musst.

Lass uns anfangen.

Wenn das Management einen Entwickler fragt, wie lang ein Projekt mit irgendeinem beliebigen Umfang dauert, wird eine von genau zwei Möglichkeiten eintreten:

1. Der Entwickler wird eine Aufwandsschätzung abgeben, die das Management um einen Faktor zwei oder mehr unbegründet reduzieren wird.
2. Der Entwickler wird dem Management sagen, dass das Projekt aktuell noch nicht (da noch notwendige Recherchen oder Tests ausstehen) eingeschätzt werden kann, worauf das Management einfach von dem Aufwand und dem Abgabetermin ausgehen wird, die dem des Kundenwunsches entsprechen.

"Aber," unterbrichst du, "das Management muss sich doch auch um die Prioritäten der anderen Abteilungen kümmern! Sie haben natürlich Gründe, dass dieses Projekt eher fertiggestellt werden muss."

Das ergibt richtig viel Sinn. Es ist der gleiche Grund, wieso ich einfach zum Lamborghini Händler gehen und, nachdem ich dem Verkäufter erklärt habe, dass ich nicht genug Geld für das Auto habe, da ich mich auch um andere finanzielle Prioritäten (zum Beispiel Unterhalt, Spielschulden und drei Hypotheken auf mein Haus) kümmern muss, den Händler direkt mit einem brandneuen Lamborghini Veneno für die Hälfte des Einkaufspreises verlassen kann.

Nein, Moment, das kann ich gar nicht machen. So funktioniert die echte Welt nicht.

Das Management lebt, wenn es an Technologieprojekten beteiligt ist, in einer Art Blase, die isoliert vom Rest der Realität dafür sorgt, dass das Lieferdatum von erfolgreichen Projekten ganz einfach durch Mitteilung einer Deadline per E-Mail bestimmt werden kann. Dieses Verhalten, was zu Beginn verwirrend ist, kann auf drei Ursachen zurückgeführt werden:

1. Das Management hat buchstäblich keine Idee, welche Arbeit notwendig ist, um das Projekt zu implementieren oder wie diese Arbeit gemacht werden kann. (In vielen Bereichen ist es absolut notwendig, dass das Management sich mit der Arbeit auskennt, die es leitet. Leider ist Softwareentwicklung keiner dieser Bereiche.)
2. Die externen Entwicklungspartner haben zugesagt, dass das Projekt genau in das Budget und den Zeitplan fällt, den das Management vorgibt. (Dies ist, genau wie das Verhalten des Managements zum Abgabetermin, nicht Teil dieser Realität. Mehr dazu jedoch später.)
3. (Dies scheint leider unser Fehler zu sein.) Die Entwickler haben einfach aufgegeben, dass jemand, der oberhalb ihrer eigenen Gehaltsklasse liegt, wert auf ihre Meinung legt, diese ernst nimmt und den Anforderungen des Managements standhält, obwohl klar ist, dass das Projekt direkt gegen die Wand fahren wird.

Der erste Punkt ist leider ein Grundsatz des Lebens geworden. Meine Lieblingsphrase, die während jeder Art von Besprechung vom Management kommt, lautet: "Das sollte nicht so schwer sein". Es braucht jede Faser meines Körpers, damit ich nicht aufspringe und "DU HAST KEINE AHNUNG WIE SCHWER DAS IST" zu schreien oder, noch schlimmer, zu sagen, dass "wenn es nicht so schwer ist, dann mach es doch selber". Leider enden Kommentare wie dieser zumeist in unschöner Beendigung des Arbeitsverhältnisses. (Und ich ziehe es vor ein Gehalt zu bekommen.)

Der dritte Punkt ist bedauerlich, da er zeigt, wie fähige und pragmatische Entwickler sich oft hilflos fühlen, wenn sie mit den Ansichten des Managements über ihre Arbeit konfrontiert werden. Diese Beobachtung ergibt Sinn, besonders, wenn das Management Entwickler oft als einfache Ressourcen sieht, die einfach "ausgetauscht" werden können, wenn sie die unverhältnismäßigen Erwartungen zurückweisen. Das führt mich zum zweiten Punkt, der mich von allen am meisten wütend macht.

Ich habe einen unfassbar brennenden Hass auf externe Entwickler. (Zur Verteidigung: Ich war einer. Ich war auf beiden Seiten des Tisches und ich habe Horrorgeschichten, die das beweisen.) Unternehmen, die Entwicklerteams auslagern, sie die Art von Firmen, die ein Anwesen mit Meerblick mitten in einem von Land umschlossenem Staat versprechen. Der Grund dafür? Total einfach: Kapitalismus! (Versteh mich nicht falsch, ich liebe Kapitalismus. Aber es ist allgemein bekannt, dass viele Leute diesen ausnutzen. Diese Firmen sind genau so jemand.) Der Prozess, durch den Externe gehen, ist dem sehr ähnlich, durch den die eigenen Entwickler gehen, wenn sie eine Einschätzung eines Projektes abgeben; die beauftragten Entwickler werden gefragt, was sie denken, was nötig sein wird, um das Projekt abzuschließen und dann wird dies ohne Begründung genau so ignoriert. Der einzige Unterschied ist, dass Externe den Zeitplan und das Budget, dass das Management vorgibt, erfüllen können. Warum habe ich also nun so einen Hass auf die Externen selber? Weil sie sich bewusst entschieden haben eine Partei zu sein, die das Management und den Einkauf von Firmen betrügen, die es nicht besser wissen.

(Das ist übrigens der Grund, warum ich nicht mehr als Freiberufler arbeite und es niemals wieder tun werde. Die Art und Weise wie Freiberufler arbeiten ist, wie ich weiter unten beschreiben werde, gegen meine ethischen Grundsätze.)

Stell dir für einen Moment vor, dass du einen Anbieter für ein ein Jahr dauerndes und fünf Millionen Dollar teures Projekt angeheuert hast.

Wenn er das Projekt in einem Jahr abschließen wird, es dich fünf Millionen Dollar kostet und es korrekt entwickelt ist, fresse ich einen Besen. (Anschließend werde ich dir meine Bewerbung schicken, da ich Teil dieser Utopie sein will, die du entdeckt hast. Ich bin bisher nicht überzeugt, dass sie wirklich existiert.)

Du hast vielleicht vom Projektmanagement-Dreieck gehört: Es wird oft mit der Phrase "gut, günstig, schnell; wähl zwei" beschrieben. Kommt dir bekannt vor? Wenn du einen externen Partner einkaufst, der dein Projekt entwickeln soll, wirst du keinen dieser Dinge wählen. Das Projekt wird nicht günstig, da Externe, ihrer Natur entsprechend, teurer sind als eigene Entwickler. Das Projekt wird nicht schnell sein, da ein unfassbarer Aufwand an Beschreibungen, was die Externen genau entwickeln sollen, als auch das Testen der Ergebnisse, vorhanden sein wird. Und es wird natürlich nicht gut sein, da Externe darauf spezialisiert sind, nur so gute Ergebnisse für die benötigten Anforderungen zu produzieren, dass sie mit dem nächsten Projekt weiter machen können.

Ich möchte diesen Gedanken unterbrechen, um dich auf den Titel dieses Artikels hinzuweisen. Achte dabei auf das unterstrichene Wort.

Hör auf deine Entwickler.

Warum? Weil am Ende des Tages die Externen keine Stakeholder in deinem Projekt sind. Sie sind nicht deine Kunden, sie werden das Projekt nicht über einen langen Zeitraum pflegen und (am wichtigsten) ihr Arbeitsplatz hängt nicht davon ab, ob so eine Lösung produzieren, die nur notdürftig von Panzerband und Kaugummi zusammengehalten wird. Ihr Job besteht darin ein Projekt abzuliefern, das in etwa den Anforderungen entspricht, bei dem ein paar Ecken und Kanten abgeschliffen wurden, wenn der Kunde (du) schlechtes Feedback gegeben hat und dann verschwinden sie in die Dunkelheit, nachdem sie geliefert haben.

Das mag für einige der Leser eine seltsame Vorstellung sein, aber echte Entwickler sind wirklich stolz auf ihre Arbeit. Sie gehen nicht zur Arbeit, damit sie täglich ihre minimale Zeit absitzen und ihr Gehalt bekommen. Die besten und erfolgreichsten Entwickler investieren mehr Zeit ihres Lebens in Weiterbildung, als sie schlafen und sie sehen ihre beruflichen Projekte als Möglichkeiten Ruhm zu ernten und das Portfolio ihrer Fähigkeiten zu erweitern. In Wirklichkeit sind ihre Projekte mehr Kunst, als Wissenschaft. Deine Entwickler sind keine Bauarbeiter, sie sind Designer, Komponisten, Bildhauer— und sie sind auf der Welt um Meisterstücke zu schaffen.

Du wirst natürlich mit deiner managerartigen Überzeugungskraft fragen: “ Wen kümmert Kunst? Ich bin verantwortlich für ein Projekt von dem entscheidend ist, ob es das tut, was es soll, oder eben nicht.”

…

Du bist genau die Art von Mensch, die ein Loch in der Hose versteckt, indem du das Bein darunter anmalst, oder etwa nicht?

Das, was das Management über Entwickler immer wieder nicht versteht, ist die Tatsache, dass sie keine austauschbaren Teile sind. Sie können nicht von Projekt zu Projekt zugeteilt werden und mehr von ihnen in einen Raum zu stecken wird nicht dazu führen, dass ein Projekt schneller vorwärts kommt. Du weißt, was sie über neun Frauen die alle Köche sind sagen, oder? Das gleiche gilt für Entwickler. Jeder einzelne hat seine eigenen Erfahrungen und Fähigkeiten, die er einbringt. Also, jedes Projekt, das auf ihrem Tisch liegt, ist ein Kunstwerk— funktionelle Kunst, die, wenngleich sie einen Zweck hat, für sie einfach Kunst ist. Deine Entwickler wollen nicht mehr, als ein Projekt abliefern, dass besser ist und mehr leisten kann, als eigentlich beabsichtigt war und das auf ihre Art und Weise zeigt, wie überdurchschnittlich ihre Fähigkeiten sind, die sie in ihre Kreation gesteckt haben. Leider können sie das nicht effizient, wenn sie vom Management unter Druck gesetzt werden, obwohl dieses nicht im Ansatz versteht, wie sie denken und wie sie arbeiten… und nichts setzt einen Entwickler mehr unter Stress, als unrealistische Ansprüche und Deadlines, andauernde Unterbrechungen und die Angst von einem externen Team ersetzt zu werden.

Eigentlich war ich dabei mich über Externe zu beschweren. Ich sollte zurück zum Thema kommen.

Wenn du nicht weißt, was die Phrase "Technische Schuld" bedeutet, schlag es jetzt nach. Verstehe danach, dass die Entscheidung ein Projekt durch Externe umsetzen zu lassen, der schnellste Weg in die technische Schuld ist, den die Menschheit kennt. Es geht nur noch schneller, wenn stattdessen ein Team von Stundenten eingesetzt wird. Rate, wer sich um die technischen Schuld kümmern muss, die die Externen hinterlassen haben?

Als erstes: Deine Entwickler.

(Und du wunderst dich über die Witze über das Management, die Schilder haben "Um Verletzungen zu vermeiden, erklär mir nicht, wie ich meinen Job machen soll" und dann noch jeden Tag um Punkt 16:55 Uhr ausstempeln.)

Als zweites: Deine eigene Firma.

Hattest du jemals ein Projekt, dass alle drei Jahre neu entwickelt werden musste, da es aus dem einen oder anderen Grund aufhörte seine Aufgabe zu erfüllen? Das liegt an technischer Schuld. Wenn deine Entwickler vor dir auf die Knie fallen und um mehr Hilfs- und Wartungspersobal flehen, dann passiert das wegen technischer Schuld. Wenn deine Entwickler aus dem Unternehmen fliehen, weil das Projekt dem sie zugeteilt sind, "unpflegbar" und "ein Albtraum, um daran zu arbeiten" ist, dann ist das wegen technischer Schuld. Aber weißt du: Es gibt eine Möglichkeit alle Gründe für technische Schuld zu vermeiden!

Du wirst ahnen, was es ist:

Hör auf deine Entwickler.

Wenn sie dir sagen, wie lang ein Projekt dauern wird, dann sagen sie dir in Wirklichkeit, wie lange es dauern wird das Projekt richtig umzussetzen. Wenn sie dir sagen, welche Technologien sie für das Projekt einsetzen wollen, dann sagen sie dir in Wirklichkeit, welche Technologien für das Projekt am meisten Sinn machen und welche Technologien auf lange Zeit die richtigen sein werden. (Sie nennen dir, entgegen den Externen, nicht nur eine Liste der Technologien in denen sie "zertifiziert" sind oder mit denen sie am meisten verdienen können.) Wenn ein Entwickler dir sagt, dass er mehr Ressourcen braucht, dann sagt er dir in Wirklichkeit, dass ihm dein Projekt wichtig ist und er wissen will, was notwendig ist, um es erfolgreich abzuschließen. Sie sind deine wahren Stakeholder, denn sie werden so stolz auf ihre Arbeit sein, wie es niemand sonst aus deinem Unternehmen möglicherweise sein könnte. Entwickler sind keine Rädchen im Getriebe die ausgetauscht werden können, wenn sie quietschen; sie sind, wenn man sie angemessen behandelt, die wichtigsten Teile deines Unternehmens, wenn es um die Arbeit mit Technologie geht. Ihre Ideen können deine Firma in die Top-Position auf dem Markt bringen oder etwas entwickeln, an das vorher noch niemand anderes gedacht hat. Aber sie können das nicht, wenn unrealistische Erwartungen des Managements dafür sorgen, dass Projekte zu Externen ausgelagert werden.

Erinnere dich das nächste mal daran, wenn dir wieder einmal ein Anzugträger sagt, dass "das nicht so schwer sein kann."