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.

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 10 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, dass 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 einmal 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.

[plain]

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

[/plain]