6 Dinge, die Du wissen musst, wenn Du mit Developern arbeitest

Regelmäßig bin ich in Situationen wo Business-Leute mit Entwicklern in Projekten zusammenarbeiten. Diese Zusammenarbeit klappt schon viel besser als z. Bsp. vor 10 Jahren. Dennoch gibt es immer wieder Situationen wo Spannungen auftreten – in der Mehrheit der Fälle schlicht darum, weil eben diese Business-Leute von Softwareentwicklung und Developern herzlich wenig Ahnung haben. Hier 6 Punkte die Sie als Business-Mensch, wie z. Bsp. Projektleiter oder Stakeholder beachten sollten. Und nein, die Liste ist nicht abschliessend.

Dieser Computer-Freak!

Sehr oft höre ich, dass Leute aus dem Business die Developer als Computer-Freaks bezeichnen und sie als introvertierte Sonderlinge hinstellen welche komische Algorithmen und Sprachen entwickeln und pflegen. Ein Freak ist nichts Nettes. Und sonderbar oder komisch ist die Arbeit auch nicht. Sie ist eher komplex und abstrakt und nicht sehr einfach zu durchschauen, wenn man sich nicht im Detail damit auseinandersetzt. Und eben genau dies tun die allermeisten Business-Leute nicht.

Developer

Und: Nur, weil jemand gut programmieren kann, heißt das noch lange nicht, dass er sich mit dem allgemeinen Computer-Alltags-Gedöns gut auskennt. Wenn Sie also Ihren Neffen der bei Google Applikationen programmiert an der Weihnachtsfeier fragen, ob er sich kurz „das Problem“ mit Ihrem uralten Windows 95 Rechner ansehen könnte, ist das in etwa so vermessen wie wenn Sie einen Motorenspezialisten bitten würden Ihre Garage rauszukehren. Tun Sie es nicht.

„Das ist doch ganz einfach“

Dieser Spruch ist der ultimative Beweis, dass Sie wahrscheinlich von Entwicklung nicht so viel Ahnung haben. Vorausgesetzt natürlich, es ist wirklich nicht ganz einfach. Wie oft habe ich doch diesen Satz in den letzten zehn Jahren z. Bsp. von Kunden gehört. Meist geht er einher mit dem Unwillen sich mit den Zusammenhängen und Details im Hintergrund zu befassen. Der Kunde reduziert sich auf das Visuelle und ja, da ist es meist wirklich ganz einfach à la: „Der blaue Button muss nach oben und beim Klicken noch die Kredit-Limite abfragen.“ Dass dazu aber Daten benötigt werden, die vielleicht just in seinem ERP System so gar nicht vorliegen sind Details mit denen er sich nicht aufhalten will.

Über die „richtige“ Technologie streiten

Fragt man 5 Entwickler nach Ihrer Meinung zu einer Technologie, erhält man in der Regel 7-10 Antworten. Die „richtige“ Technologie gibt es nicht und wenn ich eines gelernt habe, dann das, das Technologien auch Geschmacksache sind und Modeströmungen unterliegen. Es gibt immer mal Frameworks die gerade angesagt sind und jeder Entwickler legt in seiner Arbeit auf unterschiedliche Bereiche wert. Das dümmste was Sie als Business-Mensch nun tun können, ist in dieser Diskussion mitmischen zu wollen. Denn Sie haben weder wirkliche Kenntnisse der verschiedenen Technologien, noch ist diese Diskussion etwas das Sie allgemein weiterbringt.

Developer in firmeninterne, politische Meetings mitschleppen

Auch ein typischer Klassiker ist, Entwickler in diese superwichtigen, firmeninternen Meetings mitzunehmen. Für die allermeisten Entwickler, vor allem die „radikalisierten“ und guten, sind diese Meetings langweilig. Für sie ist da meist viel Zuviel „Noise“ im Verhältnis zum „Signal“. Und es kann für Sie als Business-Mensch auch eher gefährlich werden, denn vielen Entwicklern geht (bewusst oder unbewusst) ein gewisses Feingefühl fürs politische und taktische ab. Das führt dann bisweilen dazu, dass einfach mal die ungeschminkte Wahrheit vor allen Senior Executives auf den Tisch kommt. Und diese Wahrheit, ist z. Bsp. in Projekten ja manchmal nicht sonderlich erfreulich. Bemühen Sie also Ihre Entwickler nicht mit firmeninternem Kram, außer er oder sie wünscht eine Teilnahme am Meeting explizit.

8 Stunden sind nicht gleich 8 Stunden

Viele Business-Leute sind der Meinung, dass Entwicklungsarbeit zielgerichtet und gradlinig verläuft. Genau das tut sie aber nicht: Manchmal müssen Dinge ausprobiert werden, manchmal kommt man zum Schluss, dass ein Teil des Codes besser neu geschrieben werden muss. Je komplexer die Anforderungen an die Applikation, desto weniger gradlinig verläuft die Entwicklung. Zudem ist die Arbeit als Entwickler anstrengend; Sie fordert eine lange Aufmerksamkeitsspanne. Diese Anstrengung muss kompensiert werden um die Leistungsfähigkeit zu erhalten. Diese Legenden von Leuten welche 16 Stunden am Stück „durchgecodet“ hätten halte ich für Unfug. Sicher ist das irgendwie möglich, nur ist es weder produktiv, gesund und/oder der Qualität des Codes zuträglich. Verstehen Sie also aus Business-Sicht, dass Entwicklung Zeit braucht, Zeit zum Entwickeln einerseits – aber auch Zeit um Bestehendes und zu erschaffendes zu hinterfragen und zu validieren. Und Zeit um zwischendurch mal zu entspannen.

„Jetzt brauchen wir hier mal eine ganz genaue und belastbare Schätzung“

Die ganz genaue Schätzung ist sozusagen der Treppenwitz der Digitalbranche. Erstaunlicherweise vergeht aber kein Monat in dem ich das nicht aus irgendeiner Ecke höre. Und ich kann diesen Wunsch von Kunden ja auch verstehen, natürlich wäre es schön, genau zu wissen wann etwas geliefert werden kann und was es kosten wird. Paradoxerweise wünschen sich meist exakt diejenigen Kunden genaue Schätzungen die gar noch nicht genau sagen können was sie denn im Produkt alles haben möchten.

Ich wiederhole es gerne hier stellvertretend für alle Entwickler auf dieser Welt: Eine genaue Schätzung gibt es nicht. Das ist eine schlechte Nachricht für alle Fixpreis-Fanatiker. Aber eigentlich nichts Neues, denn auch komplexe Projekte außerhalb der Software-Entwicklung können nicht wirklich genau geschätzt werden wie viele prominente Beispiele zeigen.

Der Zwang nach genauen Schätzungen führt dazu, dass Entwickler übermäßige Sicherheitsmargen einbauen, damit später nicht überschossen wird. Die so aufgeplusterten Budgets verleiten dann erstmal dazu die verfügbare Zeit zu überschätzen. Ein Teufelskreis.

Viel besser ist es, mit Szenarien und Annäherungswerten zu arbeiten. Das ist in der Regel eine von / bis Schätzung die Abstufungen kennt welche an Sachverhalte, die noch nicht komplett klar sind, geknüpft werden. Z. Bsp. für „Schnittstelle xy“ benötigen wir zwischen 20 und 40 Personentage. Ca. 20 PT, wenn System a) bereits eine API hat, rund 30 PT, wenn System a) bereits Konnektoren mitbringt oder 40 PT, wenn alles entwickelt werden muss. Tun Sie also sich und Ihren Entwicklern einen Gefallen und lassen Sie das mit der „genauen Schätzung“ einfach sein.

t3n - digital pioneers
Dieser Artikel erschien ursprünglich  im Rahmen meiner „Transformiert!“ Kolumne auf t3n.

Artikel auf Social Media teilen:

2 Kommentare zu 6 Dinge, die Du wissen musst, wenn Du mit Developern arbeitest
  1. Jean Maurice Port Antworten

    Genaue Schätzungen? Hockey Sticks sind eine Form der Realität, die bei BWLern so leider nie ganz ankommen wird, befürchte ich. Der Artikel fasst sehr schön ein grundlegendes Problem auf, das ich in meiner eigenen noch recht jungen Karriere ein gefühltes Dutzend Mal erleben durfte: Der „ITler“ wird als Exot betrachtet. Fachlich sowie menschlich. Business Leute haben oftmals erschreckend wenig Ahnung selbst von grundlegenden IT Prozessen und wenn’s schon an der Terminologie hapert, ist es mit der Katastrophe nicht weit hin.

    Ich selbst bin schon fast verzweifelt am Unwillen eines Kunden, sich doch bitte Mal einen Tag Zeit zu nehmen um gemeinsam mit mir das Backend der Applikationen zu bestaunen, deren reibungsloses Funktionieren die Grundvoraussetzung für das gesamte Geschäftsmodell darstellte. Da werden Katzen mit Mäusen verglichen (In dem Fall Shopify mit Shopware) und der IT-Freak grundsätzlich als auswechselbar empfunden. Es lässt sich doch jederzeit eine billige Alternative aus Indien finden auf Upwork und Co. & so kompliziert kann Funktion x ja nicht sein – hat die Konkurrenz schließlich ebenfalls implementiert und man weiß aus sicherer Quelle, dass deren Shop der Cousin vom Kommanditisten pflegt usw. usf.

    Du hast beim Stichwort Development ja noch gut Reden mit den zuletzt aufgegriffenen Annäherungswerten. Versuch doch Mal, einem mittelständischen Unternehmen ohne jegliche Vorkenntnisse sowohl im Bereich digital wie auch im zugehörigen Marketing zu erklären, dass anfangs von mir erwähnter Hockey Stick im Worst Case auch bedeuten kann, dass in den ersten drei Jahren überhaupt kein (!) Traffic zustande kommt. Oder bei allzu schlanker Finanzierung bereits kurzweilige Fluktuationen als unumgängliche Konsequenz der grundsätzlichen Volatilität von „Digital“ schneller in die Insolvenz führen, als man sich auf Fiverr den nächsten Pakistani geordert hat.

    Kommen wir aber zum entscheidenden Punkt, wegen dem es mir nach Lektüre des Artikels in den Fingern zu Kribbeln begann: Ausgebildete Betriebswirte, Wirtschaftsleute, Unternehmer, Investoren, Manager (…), kurz „Nicht-ITler“, die mit Aufgaben betreut werden, für die ausschließlich ausgebildete ITler zuständig sein dürfen, möchte man das Projekt nicht unnötigen Risiken und die involvierten Personen sinnlosem Stress aussetzen.

    Wie oft habe ich es schon erlebt, dass die Geschäftsleitung der Ansicht ist, man sollte bspw. die Entscheidung über zu installierende Erweiterungen einer Applikation der Projektleitung überlassen, während sich die beauftragten Entwickler im Anschluss damit herumschlagen dürfen… Irgendwo ist dieses Verhalten schon ziemlich „von oben herab“: Auf der einen Seite betrachtet man den ITler als „Freak“ von einem anderen Stern, dessen Sprache man nicht spricht. Auf der anderen Seite schätzt man besagte Sprache unterschwellig als in ihrer Primitivität für das Wesen des Sprechenden charakteristisch genug ein, um ihn bevormunden zu wollen.

    Es wird Zeit für einen frischen Kaffee.
    Wie immer ein toller Artikel!

  2. Edwin Palesch Antworten

    Toller Artikel

Schreibe einen Kommentar

Deine E-Mail Adresse wird nicht veröffentlicht. Bitte mache folgende Angaben: Dein Name, Deine E-Mail Adresse und Dein Kommentar.