Ultimative Qualität für Software!

Das Bewusstsein für die Relevanz von „Software“ als kritischer Faktor für den Unternehmenserfolg ist gestiegen. Auch in Deutschland richten jetzt große Konzerne ihr Augenmerk immer mehr auf ihre IT-basierenden Anwendungen und untersuchen gezielt die Qualität derselbigen um sie dann zu verbessern.

Mir stellen sich – mal völlig ungeordnet – ein paar Fragen:

  • Warum gibt es immer noch so große Software-Projekte mit 100 und mehr Programmierern?
  • Wieso glaubt man immer noch, man könne durch hohe Spezialisierung (Requirement Engineering, Architektur, Qualität, Implementierung, Konfiguration oder Projekt Management …) und Arbeitsteiligkeit in globalen Entwicklungs-Dreiecken wie Indien-USA-Europa erfolgreich und kostengünstig entwickeln?
  • Wieso lernt das Management aus den zahlreichen Fehlschlägen und Krisen bei so vielen IT-Projekten nichts?

Hier ein paar Antworten und Thesen, wie man es besser machen könnte:

  • Konzentration auf die Zukunft!
    Um Qualität zu schaffen und so wirklich wertvolle Software zu gewinnen würde ich mich zuerst mal auf die neuen Software-Projekte in den Unternehmen  konzentrieren. Das ist an sich schon eine große Herausforderung. Die „alten“ Applikationen würde ich nur soweit anfassen, wie dies unbedingt notwendig ist (es sei denn, ich verfüge über zu viel Ressourcen und Geld). Denn zu groß sind hier in der Regel organisatorische, systemische und menschliche Widerstände, so dass jede hier erzielte Verbesserung sehr teuer erkauft ist.
    Bei neuen Projekten dagegen kann ich zumindest projekt- und methodentechnisch auf grüner Wiese starten und in aller Strenge dafür sorgen, dass falsche Strukturen und Entwicklungen erst gar nicht entstehen.
  • Das Können der Mitarbeiter ist alles!
    Ich habe jetzt in über 30 Jahren Erfahrung in SW-Entwicklung gesammelt und immer wieder erlebt, dass nur ein Viertel bis maximal ein Drittel der Menschen, die als Programmierer in den Projekten arbeiten – ganz gleich mit welchen Titeln und Zertifikaten versehen – in der Lage sind, ultimative Qualität abzuliefern. Von den verbleibenden zwei Dritteln sehe ich bei vielleicht der Hälfte das Potential einer gewissen Verbesserung durch intensive Ausbildungs- und Trainingsmaßnahmen. Der Rest wäre besser nie Programmierer geworden. Dieses Verhältnis ist nach meiner Beobachtung in den letzten Jahren nicht besser sondern schlechter geworden. So tummeln sich viele nicht so gut ausgebildete und/oder talentierte Programmierer eifrig in übergroßen Projekten herum und verstecken sich dort in der Masse.
    Ich will damit keinesfalls einen Berufsstand schlecht machen. Ich brauche aber in der Software-Entwicklung durchgängig Ergebnisse mit einer „ultimativen Qualität“. Und die wird in der Tat nur von einem recht kleinen Teil der in den Projekten tätigen Programmierern erbracht.
    Bei „Architekten“ oder „Requirement Engineers“ dürfte die Quote der wirklich qualifizierten noch geringer sein als bei den „Implementierern“, was die Software-Entwicklung noch kritischer macht.
    Die Zahlen sind übrigens bei anderen Branchen nach meinem Eindruck nicht viel anderes. So habe ich auch bei „Handwerkern“ bemerkt, dass in der Regel nur ein Drittel ihren Job so beherrschen, dass qualitativ wirklich gute Werkstücke herauskommen. Und auch da hätte zirka ein Drittel besser einen anderen Beruf gewählt.
    Bei dem Aufbau eines neuen Teams dürfen also nur Kollegen ins Projekt aufgenommen werden, die ihr Handwerk wirklich beherrschen. Das gilt für alle Rollen, diese Selektion ist alles andere als einfach, das ganze viel leichter gesagt als getan – denn zu oft muss man „NEIN“ sagen. Obwohl man dringend Leute braucht. Aber Kompromisse gerade hier rächen sich in der Regel bei der Qualität der Ergebnisse. Und wenn man nur die „guten“ nimmt, dann braucht man viel weniger …
  • Kommunikation
    Die Kommunikation im Entwicklungsteam wie zwischen allen Beteiligten im Projekt muss funktionieren! Wie soll das gehen, wenn in vielen Projekten schon gar keine gemeinsame Sprache mehr gesprochen wird? Oder wenn zwar alle Englisch sprechen, jeder dabei aber sein „eigenes Englisch“ dabei hat, das der andere kaum versteht?
    Wichtig ist hier die Anzahl von Meetings stark zu begrenzen. Die Meeting-Flut muss eingedämmt werden. Denn der Nutzen von Meetings sinkt mit der Anzahl von Personen, die teilnehmen und der Länge der Zeit, die sie dauern. Der Schaden steigt in gleichem Maße an. Eine Lösung dieses Dilemmas ist eine Organisation von Kommunikation durch sinnvolle „peer2peer“-Mechanismen.
  • „Requirement Engineering“
    Der Versuch, Anwendungs-Software präzise und komplett vor der Implementierung zu beschreiben, hat noch nie zu optimalen Ergebnissen geführt. Immer stellt sich bei solchem Vorgehen heraus, dass dann vieles Unnötiges gebaut wird und dafür aber wesentlich Notwendiges fehlt. Die Folgen sind aufwendige und oft zu implementierten Funktionen widersprüchliche Change Requests. So hängt der Erfolg eines jeden Projekts wesentlich von der Qualität der Person oder den Personen ab, die den „Product Owner“ ausmachen.
    Gute Product Owner wissen nie alles im Voraus, sondern lernen im Entwicklungsprozess laufend dazu. Ein iterativer und agiler Prozess des „Requirement Engineerings“ ist zwingend notwendig. Bei neuen Projekten empfiehlt es sich hier in „user stories“ zu denken und dann (begrenzt) die dazugehörigen „use cases“ zu beschreiben. Das kann aber nur gehen, wenn die Architektur flexibel ist.
  • „Flexible Architektur“
    Aufgrund des Lernprozesses der Product Owner und der sich iterativ verändernden Funktionalität wird eine offene und belastbare Architektur zur zentralen Voraussetzung für den Erfolg eines Projektes. Das erhöht die Anforderung an die Architekten aber auch den Anspruch an die Kommunikation zwischen „Product Owner“ und „Architekten“ und letzten Endes dem ganzen Team. Die beiden letzten Punkte gelten nach meiner Meinung übrigens auch nicht nur für Software-Projekte.
  • Geisteshaltung
    Die Geisteshaltung streift viele Dimensionen. So müssen alle Projektteilnehmer sich vom ersten Tag einem ultimativen Qualititätsanspruch verpflichten. Sie müssen verstehen, dass sie Qualität in aller erster Instanz für sich selber schaffen. Eine gemeinsame Projektvision muss vorhanden sein. Die Zusammenarbeit muss auf Augenhöhe und gegenseitigem Respekt erfolgen, Politik im Projekt ist ein NOGO. Qualitätssichernde Maßnahmen wie Peer2Peer-Reviews werden zum Standard, Meetings extrem kurz und selten stattfinden und sich auf zwingend notwendige Abstimmungsprozesse beschränken. Dafür kann dann gerne mal öfter der Erfolg gefeiert werden.
    Unnötiger bürokratischer Aufwand ist ein weiteres NOGO, eine „gute“ Projektkultur macht Bürokratie überflüssig. Das Projekt und sein Status sind immer für alle transparent, „Insider“-und „Herrschafts-Wissen“ wird zur Ausnahme. Auf unnötige Aufwände für „estimate“ und „planning“ wird soweit möglich verzichtet!
  • Verantwortung
    Die Projektteilnehmer dürfen sich nie auf eine Verantwortungs-Rolle reduzieren. Jeder muss in der Lage sein, „hands on“ anzulegen. Jeder ist zu einem – vielleicht auch nur kleinen Teil – für alles verantwortlich, für Requirement Engineering, Projektsteuerung, Architektur, Qualität, Integration, Konfiguration und Implementierung. Jeder muss mithelfen, unnötige Hürden für freie Kommunikation zwischen allen zu reduzieren. Das gilt für alle, denn alle sind für den Projekterfolg verantwortlich, entsprechend ihrer Qualifikation und Rolle dies natürlich auf unterschiedliche Art und Weise.
  • Craftsmanship
    Und alle Beteiligten müssen sich ständig in ihrem Handwerk üben. Sie müssen bereit sein „vom Meister zu lernen“ und ihre besondere „Meisterschaft“ zu vermitteln, sprich auch ihr Können weiterzugeben und ihr Wissen zu teilen.

Wenn diese Bedingungen erfüllt sind, können auch überschaubare Teams Unglaubliches  sowohl in Qualität wie auch funktionaler Quantität leisten. Der oft unnötige Overhead der großen Teams fällt weg. Und die Verwunderung beim Management ist groß, dass ein Zehn-Mann-Team etwas schafft, an dem ein Team mit einer Hundertschaft vorher gescheitert ist.

RMD

5 Antworten

  1. Full Ack. Ich bin erst 10 Jahre dabei, aber ja, mit 1/4 der Leute (den guten) hätte man zumindest die Chance, etwas gutes aufzubauen.

    Aber Geiz ist geil, daher wird kein Dienstleister mit guten Leuten genommen, weil der kostet 120 statt sich auf 80 Euro drücken zu lassen (pro Stunde). Solche Firmen, und damit auch gute Entwickler, werden einfach nicht nachgefragt/bezahlt, deshalb überlege ich auch, aus der Entwicklung auszusteigen, und mehr in Richtung Anforderungen zu arbeiten, und das, obwohl mir in der Entwicklung keiner etwas vormacht.

    Warum soll man sich aufreiben und kaputtmachen, wenn ein Großteil der eigenen Arbeit darin besteht, die Fehler der Dumpfhirne wieder geradezubiegen? Ergo: wenn man eine Mischung im Projekt hat, canceln die schlechten Entwickler die guten wieder aus. Der schlechte Entwickler sorgt dafür, dass der gute nicht mehr 5x-10x Performance liefert, sondern gerade mal die Fehler eines anderen behebt. Aber hauptsache die Kosten pro Stunde etwas gedrückt! Da haben wir aber fein gespart, was?

  2. Nachtrag: den Status Quo kennen wir ja. Ich glaube, die Ursache ist, dass es tatsächlich zuviele Leute scheinbar billig gibt.

    Software-entwicklung ist viel zu BILLIG, deshalb leisten sich viele ganz miese Zusammenarbeit/Prozesse/Architekturen, geben miesen Entwickler Entscheidungskompetenzen in die Hand – man kann es sich offensichtlich noch leisten.

    Automatisierungsgrad = 0. Wir frickeln einfach mal etwas herum, und nach ein paar Wochen wird alles wieder umgeworfen: der nächste planlose Plan.

  3. Hi,

    ich bin ja erst gut 20 Jahre dabei, aber aus meiner Praxis-Erfahrung halte ich einen Anteil von 30% guter Leute für enorm überoptimistisch. Realistisch wäre wohl etwa 10%.

    Bei manchen – angeblich besonders professionellen – Dienstleistern sind es eher 0%.

    An der Stelle muß ich mal auf meine Lieblings-Idioten von der ITK einhacken. Viel buntes Papier, große Klappe, aber ansonsten völlig unfähig. Was die abliefern ist einfach nur unbrauchbarer Abfall. Mittlerweile hat das auch meine aktuelle Kundschaft endlich begriffen – jetzt hat man die aus dem (Teil-)Projekt rausgenommen, und alles wird weggeworfen. Besser ein Ende mit Schrecken als ein Schrecken ohne Ende.

Schreibe einen Kommentar

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

Suche

Kategorien

Aktuelle Umfrage

Wie würden Sie die EURO-Krise meistern?

Ergebnisse anzeigen

Wird geladen ... Wird geladen ...
"Management braucht Führungskräfte" von Peter Gruber

"Management braucht Führungskräfte" von Peter Gruber

Arbeiten mit Sinn - Arbeiten mit Ermutigung - Arbeiten mit Aufrichtigkeit.
Carls überraschende  KI-Blindheit

Carls überraschende KI-Blindheit

Carl und Gerlinde (80) „Ist Carl wirklich so blind…? Oder will er die diversen Tretmienen auf dem Weg zu seiner…
SUCHE
Drücken Sie "Enter" zum Starten der Suche