Der Kampf zwischen Sales und Devs…

… und wie jeder seinen ganz eigenen kleinen Krieg führt…

Aus der Sicht von Sales

(So zumindest meine Vermutung -> Kommentare erwünscht!)

Ohne Projekte kein Geld. Ohne Geld kein Lohn. Klar, soweit verstehe ich das auch noch als Entwickler…

Grosse Projekte bringen im Verhältnis mehr Geld, sind spannender, besser als Referenzen zu verwerten und ziehen oft Folgeprojekte nach sich. Alles soweit positiv, nicht? Aber auch kleine Projekte sind soweit nicht verkehrt, hierbei müssten sich die Entwicklungskosten ja ebenfalls in Grenzen halten und hier macht dann die Masse den Gewinn.

Gerade bei grösseren Projekten ist Sales oft sehr gefordert. Dutzende Kundentermine, immer wieder Nachhaken und oft dann doch vertröstet werden. Teilweise zieht sich so eine Projektanfrage tatsächlich über mehrere Jahre, bis dann der Kunde soweit ist und bestellen möchte.

Doch sobald der Kunde sich entschieden hat, muss es schnell gehen. Das Budget ist klar, der Wunsch ist (zumindest in den Augen des Kunden) klar, und in diesem Zustand gefährdet dann jeder zusätzliche Tag bis zur Offerte oder geplanten Umsetzung das Projekt.

Jetzt warten bis Projekt-Management den nächsten theoretisch freien Termin in einem halben Jahr einplanen kann? Das wäre das Aus für das Projekt. Viel Zeit für nichts… Der Kunde erklärt unmissverständlich „Wir brauchen es bis Zeitpunkt XY“. Nun fängt der vermutlich ekligste Teil für Sales an…

Der Spiessrutenlauf zwischen Kunde und Entwickler. „Braucht ihr Wirklich 10 Wochen, kann man das nicht in 9 Wochen machen?“, „Muss es wirklich ganz und gar bis Februar fertig sein, oder reichen Teilfeatures?“, „Schafft ihr es in 9 Wochen, wenn wir dieses Feature streichen?“, …

Irgendwann landet dann etwas auf Papier und man ist sich weder sicher, ob die Entwicklung, noch ob der Kunde damit letztendlich wirklich zufrieden ist. Zudem verlässt hierbei das Projekt dann den Zuständigkeitsbereich von Sales und es startet das „hoffen“.

Aus der Sicht der Entwicklung

Natürlich ist nichts schlimmer wie Däumchen drehen. Und natürlich freut man sich über jedes gewonnene Projekt. Neue Herausforderungen, neuer Wind in den Segeln, neue Aufgaben und natürlich auch neue Technologien.

Trotzdem kann man manchmal das Strahlen im Gesicht von Sales und die Freude über das gewonnene Projekt nicht teilen (selbst wenn man das gerne würde). Für den eigenen Anspruch sind die Projektdetails zu schwammig formuliert, zu viel in den Offerten versprochen und gleichzeitig die Projektpläne zu eng gestrickt. Daily Business ist ohnehin fast übermächtig am Ressourcen fressen, und die Suche nach neuen Entwicklern ist gar nicht so einfach (falls zufällig ein halbwegs fähiger Webentwickler dies liest und Interesse hat *zwinker* http://www.ipeak.ch/jobs.html).

Daneben bleibt die Optimierung und das Bugfixing der bestehenden Produkte und natürlich auch deren Weiterentwicklung. Die grosse Herausforderung ist oft gar nicht mehr der Code oder die Features sondern das Zeitmanagement und die Effizienz. Zwischendurch noch schauen, dass es dem Team gut geht :).

Doch zurück zum Thema. Kommt nun Sales freudestrahlend mit einem neuen Projekt (mit einem sportlichen Zeitplan) an, springe ich teils nicht (wie Sales das erwartet) freudestrahlend auf, falle Sales um den Hals und gratuliere zu der guten Arbeit. Vielmehr entfährt mir möglicherweise ein leichter Seufzer und meine Augen verraten wohl die Gedanken: „Wie sollen wir das nur zeitlich unterbringen?“.

An und für sich eine für mich sehr ungewohnte Rolle, spiel ich doch meist eher den Optimist „mh das kriegen wir schon hin und ’na klar können wir das umsetzen, und wie cool wäre es, wenn wir noch das und jenes mit einbauen?'“. Aber nachdem nun Sales diese Rolle übernommen hat… und ich (wie einige wissen) sehr sehr gerne den Advocatus Diaboli spiele… versuche ich den Optimismus in dem Falle etwas zu bremsen (sehr zum Leidwesen von Sales).

Wenn Zeit und Budget vorgegeben und zu eng gestrickt sind bleibt uns Entwicklern schliesslich im schönen magischen Dreieck nur noch eine Seite an der wir drehen können, die Qualität.

magisches Dreieck

Qualität ist sehr dehnbar…

Ausgehend von einem guten Basis-Produkt kann man in der Regel auch sehr schnell Features entwickeln und Erweiterungen programmieren. Auch wenn der Zeitrahmen zu knapp für eine „saubere Entwicklung“ ist, lassen sich viele Dinge noch „faken“, „pfuschen“ und „hinwursteln“. Das Ergebnis ist von aussen betrachtet zunächst das selbe:

Die Kundenwünsche sind erfüllt, das Projekt abgeschlossen.

Wenn auch bei niedrigerer Qualität und entstehenden technischen Schulden.

Diese Schulden sind leider nicht direkt sichtbar. Ausserhalb der Programmierabteilung weiss niemand etwas damit anzufangen. Möglicherweise kommt man sogar zu dem Schluss, dass die Programmierung ohnehin zu viel jammert, und auch Folgeprojekte in ähnlich straffem Zeitplan erledigt werden können.

Die niedrigere Qualität zeigt sich bei häufigeren Support-Anfragen im Nachfeld und Bugfixes ausserhalb des eigentlichen Projekt-Rahmens. Somit fällt auch die Stundenbuchung nicht mehr auf die Entwicklungsphase des eigentlichen Projektes, sondern geht irgendwo im „Daily Business“ mit unter.

Es folgen weitere zu eng kalkulierte Projekte und die technischen Schulden häufen sich, der Support-Aufwand / das Daily Business steigen ebenfalls überdurchschnittlich am Umfang.

Was sind nun diese technische Schulden?

Ganz grob kann man diese vielleicht durch die relative Häufigkeit von „//TODO“-Kommentaren im Code erkennen, sowie durch unkommentierte Codeblöcke oder durch spezifische „if (spezialFall XY)“-Anweisungen.

Und wie wirken sich diese aus? Der Code wird unflexibel und starr. Was zur Folge hat, dass zukünftige Erweiterungen am Code schwieriger werden. Plötzlich auftretende Seiteneffekte, Fehlersituationen die nicht abgefangen werden, Code-Dopplungen und immer häufigere „WTF“-Momente erschweren die Programmierung.

Man hat nun die Wahl für jedes weitere Feature entweder erheblich mehr Zeit einzurechnen und das ganze versuchen zu „reparieren“ und wieder auf einen „sauberen Stand“ zu bringen, oder man macht weiter in dem „Quick&Dirty“-Stil und verschlimmert die Lage zusätzlich.

Je nach Qualität des Ausgangscodes ist nach X Iterationen im Quick&Dirty-Stil möglicherweise sogar ein Komplett-Refactoring/-Rewrite der Software nötig, da gewisse komplexere Features per se nicht mehr einbaubar sind, oder komplizierte Bugs nicht mehr nachvollzogen werden können.

Software muss gewartet werden

Sobald eine Software regelmässig mit neuen Features versorgt wird, muss diese auch „gewartet“ werden. Im Rahmen der Features wird man (aufgrund des Zeitdruckes) nie ein umfangreiches Refactoring vornehmen können.

Aufgrund sich ändernder Anforderungen und der wohl doch in den meisten Projekten entstehenden technischen Schulden muss zusätzlich Zeit in die Weiterentwicklung der Software gesteckt werden. Damit diese „sauber“ bleibt und die Entwicklungszeit für neue Features auf einem vertretbaren Zeitniveau bleiben kann.

Warum schätzt man die Refactoring-Zeit nicht gleich in die Features mit ein? Nun, weil es für die meisten Features eben so direkt nicht zwingend nötig ist die Core anzupassen, und weil die Zeit für das Refacotring möglicherweise völlig jenseits der Zeit für das jeweilige Feature liegt.

Ein einfaches Beispiel:

Nehmen wir an, wir hätten eine tolle Anzeige programmiert, auf der ein Kundenname angezeigt werden kann. Der Kundenname wird ganz normal in weiss angezeigt.

Nun kommt Sales mit einem Kunden daher, der seine Schrift gerne in grün angezeigt haben möchte. Die Zeit ist kanpp, aber kein Problem!

Sales zufrieden, der Kunde zufrieden.

Sales geht davon aus, dass wir nun ein tolles Feature haben, dass jeder Kunde die Schrift in einer Farbe angezeigt haben kann, also landet das im Basispaket.

Es folgt ein Dutzend weiterer Kunden, folglich ein Dutzend if-Abfragen im Code. Jedesmal musste der Entwickler das Projekt wieder auschecken, die Codestelle suchen, das IF einfügen, die Tests durchlaufen lassen, die Software deployen.

Da die Kunden sehr anspruchsvoll sind melden sie sich zusätzlich alle paar Monate mal wieder und wollen ihre Farbe geändert haben. Ein Telefonat, Aufnehmen der gewünschten Änderung, Zuweisung an das Team, auschecken, code-stelle suchen, ändern, deployen, Kunde informieren, dass alles wie gewünscht geändert ist.

Irgendwann kommt die Frage auf, ob man nicht lieber dem Kunden ein Eingabefeld gegeben hätte, so dass er selbst die Farbe wählen kann. Es würde sowohl Support als auch initiale Entwicklungszeit gespart und der Kunde wäre vermutlich auch zufriedener.

Doch wie kann die Programmierabteilung nun dieses Feature einplanen? Bei der nächsten Schätzung für das Feature dem Kunden das Refactoring in Rechnung stellen? Schlechte Idee…

Wartung… Technische Schulden…

Das Beispiel ist natürlich stark vereinfacht 🙂 – denkt euch anstelle der bunten Namen ein beliebig komplexeres Feature, ich bin mir sicher sowas hat jeder Entwickler bereits erlebt.

Die „Pfadfinder-Regel“

Wie geht man nun vor, wenn das Projekt bereits technische Schulden hat und ein Feature einzubauen ist, man aber nicht beliebig viel Zeit für ein Refactoring hat? „Ach wursteln wir schnell, der Code ist eh schon kaputt“ ist hier eine schlechte Devise. Bewehrt hat sich in meinen Augen die Pfadfinder-Regel:

Hinterlasse eine Codestelle immer ein ganz klein wenig sauberer als vorher.

Was soviel heisst wie: Nicht gleich „so kann ich nicht arbeiten“ und „das muss komplett refactored werden“, sondern darauf achten mit möglichst wenig Aufwand das neue Feature so einzubauen, dass es zumindest ein wenig besser ist als vorher. Vielleicht kann man eine Funktion zusammenziehen / erweitern, ein paar wirre Code-Zeilen zumindest kommentieren, etc.

Wenn sich jeder an diese Regel hält, dürfte (in der Theorie zumindest) der Code insgesamt doch mit jedem Feature wieder ein ganz kleines bisschen besser werden. Die Anhäufung neuer Schulden ist damit verhindert.

Die Zinsen muss man dennoch zahlen: Diese spiegeln sich in dem zeitlichen Mehraufwand für die zusätzlichen Features wieder.

Fazit

Ich bin froh, dass ich nicht Verkaufen muss, und ich glaube auch Sales ist froh, dass sie nicht programmieren müssen ;).

Trotzdem werde ich mich auch in Zukunft nicht über jedes neue Projekt freuen. Auch werde versuchen das Verständnis für die technischen Schulden, den nötigen Wartungsaufwand und die Probleme zu knapper Zeitpläne zu wecken.

Da es schwer messbar ist „ab wann“ die Schuldenlast zu hoch und ein Refactoring dann doch zwingend notwendig ist, sollte man sich stets um möglichst sauberen Code bemühen. So können auch zeitlich engere Projekte abgefangen werden, jedoch sollte dann im Anschluss an diese noch Refactoring Zeit mit berechnet werden.

Gleichzeitig werde ich aber auch versuchen Sales besser zu verstehen und mögliche Lösungswege zu finden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.