Warum bezahle Sie Ihre Angestellten und externen Mitarbeiter dafür, dass Sie Software entwickeln? Wieso geben Sie Geld für Schulungen und Training aus? Wieso engagieren Sie Berater und Coaches? Denken Sie kurz darüber nach... Alle Gründe, die Ihnen einfallen könnten, laufen wahrscheinlich im Endeffekt auf zwei große Themenbereiche hinaus: Sie wollen entweder durch Ihre Investition Geld verdienen oder Geld sparen. Sie wollen ein "Return on Investment".

Verlieren Sie gerade Geld?

Sie wollen, dass Ihre Softwareentwicklung wie eine gut geölte Maschine läuft - Eine Maschine, die aus Ideen laufende, für die Benutzer wertvolle Software erzeugt. Eine Maschine, die Kundenwünsche in Features umwandelt, und dabei Vorhersagen zulässt: Sie wollen wissen wann Sie mit Ergebnissen rechnen können und welche Qualität sie erwarten können. So funktioniert das aber leider nur sehr selten. Vielleicht können Sie die Qualität Ihrer Ergebnisse nicht genau vorhersagen, weil sich immer wieder Softwarefehler einschleichen und erst im Produktivbetrieb entdeckt werden. Diese Fehler können sehr teuer sein. Wenn Sie Software für "den Markt" entwickeln, können Sie Kunden und Empfehlungen verlieren. Wenn Sie In-House-Software entwicklen, werden Anwender ihrer Software ihre Arbeit durch den Fehler nicht mehr effektiv erledigen können. Auch das kostet Ihrem Unternehmen Geld - Und Ihre Abteilung verliert vertrauen. Und dann muss der Fehler ja auch noch gefunden, behoben, getestet und ausgerollt werden! Vielleicht liegt die Wurzel der Qualitätsprobleme ja noch tiefer: Vielleicht sind ihr Design und ihre Softwarearchitektur nicht so gut, wie sie sein könnten. Vielleicht sind sie einfach nicht mehr ganz geeignet für die neuen Anforderungen. Oder vielleicht sind sie langsam immer schlechter geworden, weil sie den Entwicklern nicht wichtig genug waren, und immer dringendere Dinge anstanden. Was auch immer der Grund ist, diese suboptimale Architektur kostet Sie Geld. Das Entwickeln neuer Funktionalität dauert länger als früher. Mehr Fehler tauchen in Produktion auf. Kostenschätzungen werden immer ungenauer. Vielleicht haben Sie sogar ein noch größeres Problem: Nicht alle Funktionen, die sie Ausliefern, brinden den Benutzern auch wirklich einen Nutzen. Sie haben ein Feature implementiert, und sobald es in Produktion war, hagelte es Change Requests und neue Anforderungen. Haben Ihre Analysten die Benutzer nicht richtig verstanden? Haben die Entwickler das Feature nicht richtig umgesetzt? Oder wussten die Benutzer erst, was sie wirklich wollen, nachdem Sie eine erste Version gesehen hatten? Auf jeden Fall müssen Sie nacharbeiten, und das kostet Geld. Vielleicht verlieren sie auch noch an vielen anderen Stellen Geld in der langen Kette von Dingen, die passieren müssen, damit Software entsteht. Ihr Softwareentwicklungsprozess ist vielleicht zu inflexibel. Die Beteiligten Personen kommunizieren nicht effizient genug. Sie produzieren zu viele Artefakte, die zu wenig Nutzen (gemessen am Aufwand) bringen. Vielleicht dauert es nur sehr lange, bis Sie nach einer Anforderung des Kunden das Ergebnis liefern können.

Alle Teams haben Probleme

Kommt Ihnen die Liste im vorigen Abschnitt bekannt vor? Keine Angst, das ist normal. Alle Teams stoßen immer wieder auf die Probleme, die ich oben beschrieben habe. Aber die besten Teams können diese Probleme schnell aus der Welt schaffen und sich wieder ihren Kernaufgaben widmen. Dafür müssen Sie aber kontinuierlich an ihren Fähigkeiten arbeiten und sich weiterentwickeln. Und: Wenn Ihnen die Probleme oben bekannt vorkommen, dann wissen Sie ja bereits, wo sie mit der Verbesserung beginnen können. Aber solche Verbesserungen gibt es nicht umsonst. Lohnt es sich wirklich, hier Geld zu investieren? Welchen Return on Investmen können Sie erwarten?

Software ist teuer

Jeder weiß es: Softwareentwicklung ist teuer. Die Gehälter der Entwickler, Büros, Arbeitsgeräte, Softwarelizenzen - All das zusammen bedeutet, dass selbst eine relativ kleine Entwicklermannschaft schon einen hohen sechsstelligen Betrag kosten kann. Aber in einem Unternehmen gibt es noch weitere Kosten, die indirekt durch die Entwicklung von Software verursacht werden: Die Personalabteilung, das Management, Controlling, ... arbeiten zumindest teilweise auch für die Softwareentwicklung. Somit sind die wahren Kosten des oben genannten Teams vielleicht sogar im siebenstelligen Bereich. Was wäre, wenn die Entwickler nur etwas besser verstehen würden, was die Benutzer wirklich brauchen? Sie würden mehr Zeit für die Weiterentwicklung von Features verwenden und weniger für Nacharbeiten. Das bedeutet auch, dass Sie schneller einen Mehrwert für die Benutzer liefern können! Was wäre, wenn etwas weniger Softwarefehler in Produktion auftreten würden? Sie müssten weniger Zeit für das Finden und Beheben von Fehlern verwenden und könnten mehr and Funktionalität arbeiten, die dem Benutzer einen Mehrwert bringt. Der Support für die Software würde billiger. Und die Benutzer würden Ihnen mehr vertrauen, Ihre Software weiterempfehlen und könnten effektiver arbeiten. Was wäre, wenn die Architekture und das Design Ihres Systems es den Entwicklern erlauben würde, neue Funktionalität schnell und sicher hinzuzufügen? Fehler würden weniger, da die Entwickler besser beurteilen könnten, welche Seiteneffekte durch ihre Änderungen und Erweiterungen entstehen. Und die Vorhersagbarkeit Ihrer Ergebnisse würde deutlich besser. Auch wenn Sie sich (vorerst) vielleicht nur um wenige Prozent verbessern können, bringt Ihnen das immerhin wenige Prozent von einem sehr großen Betrag, und das jedes Jahr!

Die Sache mit dem Blinden Fleck...

Sie sind also bereit, sich zu verbessern. Jetzt müssen Sie nur einen Problembereich wählen und versuchen, besser zu werden. Können Sie das ohne fremde Hilfe machen? Vielleicht können Sie das. Aber Sie werden wahrscheinlich auf ein Hindernis stoßen: Teams, die bereits länger zusammenarbeiten, entwickeln blinde Flecken. Nach einer gewissen Zeit sind ihnen kleine Ineffizienzen nicht mehr so wichtig. Sie leben einfach damit. Sie sehen die vielen kleinen Hand-Offs und Kommunikationsprobleme, die täglich passieren, gar nicht mehr. Und sie denken nicht mehr an die Probleme, die scheinbar außerhalb ihrer Kontolle liegen. Ich habe das selbst schon öfter erlebt: Wenn ich als Entwickler in ein neues Team gekommen bin, hatte ich viele Ideen für Veränderungen, die wir probieren könnten. Nach einem Jahr kamen nur noch sehr wenige neue Ideen für Verbesserungen dazu. Dadurch dass ich lange als Vollzeit-Entwickler Teil des Teams war, hatte ich die selben blinden Flecken entwickelt. Andererseits kam ich einmal neu in ein Scrum Team, das schon eine lange Zeit zusammen gearbeitet hatte. Alles, was Sie taten, war eingespielt und Routine. Sie hielten regelmäßig Retrospektiven, und es kamen nur noch kleine Probleme auf. Sie dachten, es gäbe nicht mehr viele Möglichkeiten, etwas zu verbessern. Ich wollte herausfinden, wie sie genau arbeiten. Deshalb stellte ich viele Fragen. In der Diskussion, die sich daraus entwickelte, sagte auf einmal ein sehr erfahrenes Teammitglied: "Vielleicht sollten wir herausfinden, warum wir so arbeiten wie wir das tun, und ob das noch immer der beste Weg ist". Von da an konnten wir wieder größere Veränderungen angehen und uns weiter verbessern. Manchmal braucht man nur einen Schubs in die richtige Richtung. Und manchmal kann jemand von Außerhalb, der nicht Teil der Organisation ist, neue Perspektiven und Einsichten bieten.

Wie kann ich Ihnen helfen?

Als Berater: Ich kann Ihnen zeigen, wie Sie die Bedürfnisse und Ziele Ihrer Benutzer besser verstehen können und dieses Wissen besser für die Softwareentwicklung festhalten können. Sie werden genau wissen, was benötigt wird und wenn die Entwicklung abgeschlossen ist. So können sie mehr Zeit für die Weiterentwicklung verwenden, weil Sie weniger für Nacharbeiten benötigen. Ich kann mit Ihren Entwicklerteams an einer besseren Zusammenarbeit arbeiten. Wir werden Kommunikationsprobleme reduzieren. Wir werden die Zusammenarbeit mit dem Umfeld der Softwareentwicklung - Benutzern, Betrieb, Management, ... - verbessern. So werden alle direkt an der Entwicklung beteiligten besser zusammenarbeiten. Als Trainer: Ihre Teams wollen lernen, wie man besser Software entwickelt? Ich kann ihnen helfen, ihre Entwickler-Skills zu verbessern. Ich kann ihnen zeigen, wie man hochqualitative Software erzeugt, wie man oft ausliefert und wie man die Architektur und das Design der Software auf dem neuesten Stand hält. Dadurch können Sie langfristig Geld sparen, da die Geschwindigkeit und Vorhersagbarkeit der Softwareentwicklung hoch bleiben. An der Tastatur: Ich kann mit Ihren Teams direkt am Programmcode arbeiten. Wir werden neue Funktionalität hinzufügen, automatisierte Tests erstellen, die Code- und Testqualität verbessern und das Design auf dem neuesten Stand halten. So werde ich Sie bei der Softwareentwicklung unterstützen und die interne Qualität ihrer Software verbessern. Nebenbei lernen die Entwickler des Teams Techniken, die sie selbst später anwenden können. Ich kann Ihnen helfen, durch effizientere Softwareentwicklung Geld zu sparen. Und ich kann Ihnen helfen, Geld zu verdienen, indem Sie besser verstehen und umsetzen, was Ihre Benutzer wirklich benötigen.

Oder:

Lesen Sie, wie die zusammenarbeit mit mir funktionieren könnte.

Picture of David Tanzer

Mein Name ist David Tanzer und ich berate seit 2006 Unternehmen im Bereich der Softwareentwicklung. Ich helfe meinen Kunden, die richtige Software zu entwickeln und Software richtig zu entwickeln. Ich unterstütze Sie als Trainer, Coach und Berater. Ich spreche auf Konferenzen (wie z.B. W-JAX, Con-Fess, Droidcon, the DOAG conference, Herbstcampus und andere) und schreibe ein Blog über Softwareentwicklung.