Nadelöhr Software-Entwickler – Effizienz und Qualität

Wie angekündigt, mache ich mir zur Zeit zusammen mit dem Herausgeber eines anderen Blogs Gedanken zu der Frage, was man aus der Sicht unserer jeweiligen Profession gegen den Mangel von qualifizierten technischen Mitarbeitern tun kann.

Ausgangspunkt ist die Feststellung, die in der Tagespresse zu lesen ist, daß in Deutschland Ingenieure/ Ingenieurinnen generell fehlen, und IT-Fachkräfte im Besonderen.

Auch spielt sicher eine Rolle, daß selbst unsere Bundeskanzlerin anlässlich der diesjährigen CEBIT gefordert hat, daß wir mehr tun müssen, um den Anschluss an die IT nicht zu verpassen.

Nadelöhr Software-Entwickler

Die Rolle der Anforderungen

In seinem Artikel →Nadelöhr Software-Entwickler nennt der erwähnte Blogger einige konkrete Zahlen der BIKOM zur Anzahl fehlender ITler, und er kommt zu dem Ergebnis, daß ein Grund für die fehlende Kapazität die mangelnde Effizienz ist, mit der Softwareentwickler arbeiten müssen, wenn die Produktanforderungen unklar formuliert sind.

Er beschreibt, wie man es mit Hilfsmitteln, und Vorgehensweisen, wie Personas, Anwendungsszenarien, und UI Prototyping hinbekommen kann, daß Anforderungen präziser formuliert sind, und wie damit der Bedarf abnimmt, die Software zu ändern (was Zeit spart).

Wertung aus der Praxis

Grundsätzlich sind die erwähnten Vorgehensweisen sinnvoll, und sie leisten in der Praxis oft den gewünschten Beitrag zur Güte der Produktanforderungen. Sie tragen damit zu der Stabilität der entwickelten Lösung bei, und steigern die Effizienz der Entwickler generell. Vor Allem erlauben sie aber, daß man überhaupt „gute“ Produkte entwickeln kann.

Meiner Meinung nach bringen diese Vorgehensweisen dann besonders viel, wenn man sie miteinander verzahnt, indem man sich zum Beispiel Gedanken über die Aufgaben des späteren Nutzers macht (Persona), und dann fragt, welche Anwendungsszenarien sich diesen Personas stellen. Der UI Prototype ist dann die natürliche Folge.

Dabei bietet es sich an – wenn man den Prozess nicht gleich als Design Thinking Session aufsetzt – daß man mindestens die beiden ersten Arbeitspakete in einem Workshop zusammen mit Nutzern abarbeitet.

Qualität und Portfolioprozess

Mindestens ebenso wichtig für die Effizienz mit der eine Entwicklungsabteilung arbeiten kann (und damit den Bedarf an ITlern), sind aus meiner Sicht die Qualität und der Portfolioprozesses.

Entwickeln wir die richtigen Produkte?

Einstein hat einmal sinngemäß gesagt, daß, wenn er 5 Stunden Zeit hätte, um ein Problem zu lösen, er sich die ersten viereinhalb Stunden Zeit nehmen würde, um das Problem zu verstehen.

Dahinter steckt ein wichtiger Punkt, der auch die Effizienz betrifft: Bevor man überhaupt über konkrete Personas, Szenarien oder Prototypen nachdenkt, sollte man  sicher sein, daß man an den richtigen Fragestellungen und Produkten arbeitet. Deshalb ist ein guter Portfolioprozess erforderlich.

Unter den weiterführenden Artikeln am Artikelende finden Sie mehrere Aufsätze. Darunter einen der Firma Pragmatic Marketing, der mit mehreren Fehleinschätzungen hart ins Gericht geht, die in der Praxis oft zu Mängeln im Portfolio führen.

Hierbei haben diese Kollegen es insbesondere auf die folgenden Mythen abgesehen:

  • Innovation Is Everything
  • Revenue Cures All
  • Customers Know Best

Entwickeln wir die Produkte richtig?

Je später im Entwicklungsprozess sich Produktanforderungen ändern, desto teurer wird es im Allgemeinen, die notwendigen Änderungen vorzunehmen. Ein Punkt, der hier oft übersehen wird, ist, daß Änderungen dann besonders teuer, oder gar unmöglich werden, wenn man keine Möglichkeiten hat, die Software automatisiert zu testen.

Auch wird der Entwicklungsprozess schnell ineffizient, wenn die Qualität nicht stimmt, und man sich eher um Bugfixing, als um die Neuentwicklung kümmern kann (wie ein gerade kursierender Bericht zu angeblichen Qualitätsmängeln beim iPhone erahnen läßt).

Dies bedeutet, daß es durchaus sinnvoll ist, auf Features zu verzichten, wenn man stattdessen automatisierte Tests erstellen kann, die einem dabei helfen, sich auf Änderungen in der Software einzustellen („Test Driven Development“).

Mitarbeiterförderung

Bis hier ging es eher um Maßnahmen, mit denen man die Effizienz des Entwicklungsprozesses im weiteren Sinne verbessern kann.

Mindestens ebenso entscheidend für die Softwareentwicklerkapazität, die man zur Verfügung hat, ist die Frage, wie man Mitarbeiter fördert, und damit, wie es um die Qualifikation der Mitarbeiter bestellt ist.

Die Informationstechnik ist sehr schnelllebig. Daher müssen Fachkräfte hier sehr viel Zeit in die Weiterbildung investieren, um up-to-date zu bleiben.

Auf der anderen Seite stellen qualifizierte Mitarbeiter mit einer langen Betriebszugehörigkeit einen großen Wert für das Unternehmen dar.

Ich habe Ihnen einen Artikel angefügt, der zeigt, daß anscheinend nach wie vor viele Firmen „verschwenderisch“ mit knappen Ressourcen umgehen – indem sie langjährigen Mitarbeitern wenig bieten, und indem sie gelegentlich an der falschen Stelle sparen (Training).

Zusammenfassung

Die Tagespresse spricht von Fachkräftemangel.

Zusammenfassend läßt sich festhalten, daß man mit die Methoden des Produktmanagements dazu beitragen, daß die knappen Entwicklerressourcen sinnvoll eingesetzt werden, und, daß diese an den richtigen Produkten arbeiten können.

Die agilen Methoden der Softwareentwicklung helfen auf ähnliche Art und Weise dabei, die Situation zu verbessern z.B. indem sie das Eingehen auf Änderungen besser unterstützen (die ja immer vorkommen, egal wie gut die Anforderungen waren).

Generell ist aber eine gute Personalarbeit mindestens ebenso wichtig, damit die knappen Ressourcen fachlich „up-to-date“ bleiben, sowohl innerbetrieblich, als auch europaweit.

Weiterführende Informationen

Das Original dieses Artikels ist auf Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

2 Responses to “Nadelöhr Software-Entwickler – Effizienz und Qualität”

  1. Steffen sagt:

    Die genannten und ergänzenden Punkte zur schnelleren Entwicklung bei höherer Qualität teile ich. Gleichzeit gaben Sie mir Denkanstöße für weitere Ansätze mit denen Software Entwickler Zeit sparen: https://www.apliki.de/usability-engineering/nadelohr-software-entwickler-zeit-kosten-und-qualitat/

  2. Sie sagen, „automatisiertes Testen ersetzt keinen Usability Test“. Das stimmt. Im Grunde genommen geht es darum, die Produktqualität auf mehreren Ebenen sicherzustellen. Das Thema „Gebrauchsfertigkeit“ ist besonders wichtig, und läßt sich kaum automatisieren. Da gebe ich Ihnen recht