04.11.2015, 08:03 Uhr Hinweis: Wir haben in diesem Artikel Provisions-Links verwendet und sie durch "*" gekennzeichnet. Erfolgt über diese Links eine Bestellung, erhält t3n.de eine Provision.

Die Zusammenarbeit zwischen Business-Leuten und Entwicklern klappt schon viel besser als noch vor zehn Jahren. Doch immer wieder treten Spannungen auf – oft, weil die Business-Leute von Entwicklung herzlich wenig Ahnung haben. Hier sind sechs Punkte, die du als Projektleiter oder Stakeholder beachten solltest. Und nein: Die Liste ist nicht abschließend. Die Transformation-Kolumne von Alain Veuve.

Dieser Computer-Freak!

Sehr oft höre ich, dass Leute aus dem Business die Entwickler als Computer-Freaks bezeichnen und sie als introvertierte Sonderlinge hinstellen, die 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 das 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 du also deinen Neffen, der bei Google Apps programmiert, auf der Weihnachtsfeier fragst, ob er sich kurz „das Problem“ mit deinem uralten Windows-95-Rechner ansehen könnte, ist das in etwa so vermessen, wie wenn du einen Motorenspezialisten bitten würdest, deine Garage auszukehren. Tu das nicht!

„Das ist doch ganz einfach“

Dieser Spruch ist der ultimative Beweis, dass du wahrscheinlich von Entwicklung nicht besonders viel Ahnung hast. Vorausgesetzt natürlich, es ist nicht doch ganz einfach. Wie oft aber habe ich diesen Satz in den letzten zehn Jahren zum Beispiel von Kunden gehört. Meist geht er einher mit dem Unwillen, sich mit den Zusammenhängen und Details im Hintergrund zu befassen.

Der Kunde beschränkt 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.

Wenn Entwickler über die „richtige“ Technologie streiten

Die richtige Technologie? Frag fünf Entwickler und du kriegst sieben Antworten. (Foto: Codegirl)

Fragt man fünf Entwickler nach ihrer Meinung zu einer Technologie, kriegt man in der Regel sieben Antworten. Die „richtige“ Technologie gibt es nicht – und wenn ich eins gelernt habe, dann, 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 du als Business-Mensch jetzt tun kannst, ist, in dieser Diskussion mitmischen zu wollen. Denn du hast vermutlich weder wirkliche Kenntnisse von den verschiedenen Technologien, noch ist diese Diskussion etwas, das dich weiterbringt.

Entwickler in firmeninterne, politische Meetings mitschleppen

„Viel zu viel ‚Noise‘ im Verhältnis zum ‚Signal‘.“

Auch ein typischer Klassiker ist es, 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 zu viel „Noise“ im Verhältnis zum „Signal“. Und es kann für Dich 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 bisweilen dazu, dass einfach mal die ungeschminkte Wahrheit vor allen Senior-Executives auf den Tisch kommt. Und diese Wahrheit ist zum Beispiel in Projekten nicht immer sonderlich erfreulich. Belaste deshalb deine Entwickler möglichst nicht mit firmeninternem Kram, außer sie wollen explizit an einem Meeting teilnehmen.

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 zu dem 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, die 16 Stunden am Stück „durchgecodet“ hätten, halte ich für Unfug. Sicher ist das irgendwie möglich, nur ist es weder produktiv, noch gesund und/oder der Qualität des Codes zuträglich. Verstehe 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 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 diesen Satz 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 die Kunden genaue Schätzungen, die gar noch nicht genau sagen können, was sie denn im Produkt alles haben wollen.

„Der Zwang nach genauen Schätzungen führt zu aufgeplusterten Budgets.“

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 erst mal 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, die an Sachverhalte geknüpft werden, die noch nicht komplett klar. Zum Beispiel: „Für Schnittstelle XY benötigen wir zwischen 20 und 40 Personentagen, etwa 20, wenn das System a) schon eine API hat, rund 30, wenn das System a) schon Konnektoren mitbringt oder 40, wenn alles entwickelt werden muss.“ Tu dir und deinen Entwicklern deshalb einen Gefallen: Lass das mit der „genauen Schätzung“ sein.

Und welche Erfahrungen habt ihr bei der Zusammenarbeit mit Entwicklern gemacht? Was habt ihr daraus gelernt?