Warum es besser ist, die Sicherung der Software-Qualität in eine Hand zu legen


Jörg Fischer, Senior Consultant Testing

Teamplayer, wie oft liest man diese Anforderung. Die Fähigkeit zur Integration eines Menschen in eine bestehende Struktur ist heute die Grundvoraussetzung, um überhaupt einen Job zu bekommen. Zumindest gilt das für eine feste Anstellung. Bei der Zusammenstellung von Projektteams ist hiervon keine Rede mehr, hier zählen nur Stundensatz und Skill. Und genau hier könnten einige Probleme eines Projekts, wie Kostenexplosion oder das Überschreiten terminlicher Vorgaben ihren Ursprung haben.

Über den Autor

Sehr viel Tester, Softwareentwickler, Teamplayer, ein bisschen Psychologe und ein Quäntchen Verkäufer

Seit über einem Vierteljahrhundert arbeite ich als externer Software-Entwickler und Qualitätssicherer. Dabei durfte ich jede Variante der Einstellung zur Qualitätssicherung in den Unternehmen kennenlernen, vom Testen als ungeliebte Pflicht bis zu expliziten Teststrukturen modernster Ausprägung.

Steigern Externe IT-Experten die Produktivität?

Wo bleibt die erhoffte Leistung?

Sie haben sich entschlossen, die Qualitätssicherung Ihrer Software an externe Profis zu delegieren, die bei Ihnen im Haus als Testteam ihrer Arbeit nachgehen sollen. Meistens in einem Team mit Ihren eigenen Fachkräften.

Sie stellen fest, dass sowohl die Quantität, als auch die Qualität der Arbeit nicht Ihren Vorstellungen entspricht. Termine können nicht eingehalten werden, die Kosten überschreiten das Budget, Das Resultat ist so nicht geplant gewesen, Ressourcen stehen nicht zur Verfügung, ….

Projekt

Ein paar statistische Daten:

  • Nur 61,9 % der Projekte haben ihre Ziele erreicht, das heisst Zeit und Budget konnten eingehalten werden1
  • Als wichtigste Faktoren für den Erfolg agiler Projekte werden genannt: (Unternehmens-)Kulturwandel mit 63 %, Managementunterstützung mit 61 %, dann schon „das Team“ mit 42 %, während das „Know How“ mit nur 17 % am Ende auftaucht1
  • 46% der IT-Vorhaben haben zumindest teilweise nicht die Wünsche und Anforderungen der Auftraggeber erfüllt. Jedes fünfte Projekt ist ein Totalausfall. („Chaos Report“ der Standish Group)2

Ursachen

 Sie fragen sich, liegt es an uns ….

  • Ist es zu laut
  • Ist die Ausstattung mangelhaft
  • Sind die Anforderungen unklar
  • Ist das Projekt unstrukturiert

Alles und noch mehr kann eine der Ursachen sein, das muss natürlich erwähnt werden, dann sollten Sie hier schnellstens Abhilfe schaffen. Viele der genannten Faktoren lassen sich kostengünstig optimieren, vor allem im Verhältnis zu den Folgekosten qualitativ minderer Software, was unter Umständen sogar als Geschäftsrisiko einzustufen ist.

…. oder an den externen Testern?

  • Sind sie nicht so erfahren, wie im CV angegeben
  • Mangelt es an der Motivation
  • Ist die Aufgabe zu langweilig
  • Sind es doch keine Teamplayer

Hier noch eine Statistik, die sehr schön die möglichen Ursachen des Scheiterns eines Projekts aufzeigt.

Statistik-scheitern

Eine andere Untersuchung des „Business Magazin für Unternehmer“3 hat die Top-25 Gründe für das Scheitern von Projekten aufgestellt. Die in unserem Kontext hier aufgeführten Gründe sind

  • 2. Das WM-Team-Problem: Nur sehr selten beendet man ein Projekt mit dem Team, mit dem man anfing
  • 3. Das Teamgrößen-Problem 1: Wenn Du zu wenig Leute im Team hast, werden sie mit den Problemen nicht fertig.
  • 4. Das Teamgrößen-Problem 2: Wenn Du zu viele Leute im Team hast, erzeugen sie mehr Probleme als sie lösen können.

….

  • 20. Das Kommunikationsproblem 1: Es wird nicht ausreichend oder nicht effizient genug kommuniziert. Niemand weiß, was die anderen machen.
  • 21. Das Kommunikationsproblem 2: Es wird viel zu viel kommuniziert, ständig gibt es Meetings und E-Mails für alle. Keiner arbeitet. Alle kommunizieren.
  • 22. Das Wer-macht-was-Problem: Niemandem ist klar, wer welche Rolle hat. Jeder macht, worauf er Bock hat. Keiner macht, worauf er keinen Bock hat.

Es wäre schön, wenn es eine Möglichkeit gäbe, das Problem der häufigsten Ursache und noch weitere mit nur einer Massnahme zu lösen.

Ursachen für Teambildungs-Probleme

Das neu zusammengestellt Team

Meistens wird ein Team zusammengestellt, aus den verschiedensten Personen verschiedener Anbieter, Disziplinen, Fähigkeiten, Kompetenzen, Altersstufen, Geschlechter, Erfahrungen. Die Personen kennen sich nicht, werden zu einem Team zusammengewürfelt und sollen nach einer rein fachlich begründeten Einarbeitungsphase voll loslegen.

Kaum jemand berücksichtigt, dass es sich um Menschen handelt, und nicht um personifizierte Rollen. In der Theorie, auf dem Papier haben wir nach bestem Wissen ein optimales Team zusammengestellt, den Kompetentesten zum Teamleiter ernannt, die Rollen entsprechend der CVs besetzt. Also sollte doch alles wie geölt laufen.

Aber Sie haben es eben mit Menschen zu tun.

ein bisschen Psychologie – aus dem realen Leben

Team

Haben Sie denn wirklich ein Team zusammengestellt, oder nur eine Anhäufung von Spezialisten? Ein Team sollte wie ein Organismus interagieren und sich nicht verhalten wie ein Wolfsrudel im Frühling.

Hierarchiegerangel

Was ich immer wieder erlebt habe, da wurde ein Team zusammengestellt, und natürlich auch ein Teamleiter ernannt. Schließlich hat er laut seinen Unterlagen schon andere Teams erfolgreich geleitet, dann kann er das hier doch auch. Wäre da nicht der äußerst beliebte interne Kollege, der sich Hoffnungen auf diese Rolle gemacht hat, hat er doch die größte Erfahrung auf diesem speziellen Fachgebiet. Und schon haben wir aus einem tollen Kollegen einen Intriganten gemacht, der einen guten Teil seiner Kapazität benötigt, dem Teamleiter zu schaden. Und damit auch Ihnen.

Und die beiden neuen Kollegen, die gemeinsam an einem Thema arbeiten? Müssen auch Ihre Hierarchie regeln, wer ist der Beste? Und bin ich nicht besser, dann mache ich den Anderen halt schlechter.

Kompetenzen

Und wie war das noch mal – wer ist hierfür zuständig? Du? Ach nein – der da? OK, danke schön.
Kann mir einer sagen, wie ich das hier machen soll? Du kannst das doch eigentlich viel besser.
Die Liste ließe sich noch fortsetzen, ich habe das alles und noch viel mehr real erlebt.
Und natürlich auch die Konsequenzen.

Interessant finde ich übrigens, dass nach einer Umfrage1 direkt nach der im Bereich des Testing geforderten Hauptkompetenz „Fachwissen“ die Kompetenzen „soziale Kompetenz“, „Methodenwissen“ und „kommunikative Kompetenz“ genannt werden. Ich denke daher, dass sich die Bedeutung der Soft Skills bereits durchaus etabliert, aber noch nicht in seiner gesamten Tragweite erschlossen hat.

 

Die vier Phasen in der Entwicklung von Teams nach Tuckman

Sie kenne doch bestimmt die

Phasen in der Entwicklung von Teams nach Tuckman

  1. FORMING: Testphase / Formierung: höflich, unpersönlich, gespannt, vorsichtig
  2. STORMING: Nahkampfphase / Konflikt: unterschwellige Konflikte, Konfrontation der Personen, Cliquenbildung, mühsames Vorwärtskommen, Gefühl der Ausweglosigkeit
  3. NORMING: Organisierungsphase:Entwicklung neuer Umgangsformen, Entwicklung neuer Verhaltensweisen, Feedback wird gegeben, Konfrontation der Standpunkte
  4. PERFORMING: Arbeit / Verschmelzungsphase:  ideenreich, flexibel, offen, leistungsfähig, solidarisch und hilfsbereit

In der graphischen Darstellung:

Teamentwicklung

 

Die Praxis lehrt, dass viele Teams noch nicht einmal bis zur Norming-Phase kommen.

Zumal, laut der Akademie für Manager4, die Zeitdauer der Phasen nicht sicher vorhergesagt werden kann. Dies ist von Situation zu Situation unterschiedlich, jedoch sind gerade bei größeren Projekten mehrere Monate für Teamentwicklung und Einarbeitung einzuplanen.

Wäre doch toll, wenn Ihr neues Team bereits von Beginn an in der Arbeitsphase wäre.

…. gibt’s nicht!

… GIBT’S SEHR WOHL

Statt sich ein Team zeitaufwändig selber zusammenzustellen, warum lassen Sie das nicht andere machen?

Statt herauszufinden, ob dieses Team gut, effektiv und effizient arbeitet, warum nehmen Sie nicht ein Team, das sich als high performing schon bewiesen hat?

Das gilt für Test-Teams, mit Testmanager, (technischem) Testanalyst, Automatisierer und Testern, wie für agile Teams mit Product Manager, Product Owner, Srum Master, agile Coach, embedded Tester … oder … oder …

Und bitte, die Businessanalyse und das Requirement Engineering nicht vergessen.

WARUM – ein paar gute Gründe für externe Teams vs. externe Einzelkämpfer

  • Weil Sie weniger Aufwand haben – alles aus einer Hand, ein einziger Ansprechpartner, besser geht es nicht.
  • Weil die Qualität höher ist – alle Teammitglieder sind hervorragend ausgebildet und haben ihre Fähigkeiten schon oft bewiesen.
  • Weil die Einarbeitungszeit kürzer ist – Forming, Storming und Norming hat das Team hinter sich
  • Weil Sie ein eingespieltes, echtes Team haben
  • Weil bereits in frühen Projektphasen ein Wissenstransfer innerhalb des Teams – Teammitglieder, die bereits zu Beginn des Projekts einbezogen werden (z.B. Testmanager, Testanalysten) können ihr Wissen bereits vorab an die später kommenden Mitglieder weitergeben
  • Weil es kostengünstiger ist – mag der Stundensatz des einen oder anderen auch höher sein, am Ende sparen sie viel Geld
  • Weil das Projekt besser planbar wird – das Team ist von Beginn an performend

ABER – ein paar scheinbare Gegenargumente

  • Sie verlieren die Kontrolle – Nein, Sie brauchen weniger Kontrolle, ein echtes Team kontrolliert sich selber
  • Sie werden abhängig von einem einzigen Partner – Das ist ein gutes Argument, der Partner muss sorgfältig ausgewählt werden. Andererseits, das mindestens gleich hohe Risiko trägt Ihr Partner. Schlechte Leistung, Projekt weg, Reputation weg
  • Spezialwissen, das kein einzelner externer Anbieter in einem bestehenden Team bieten kann (Securitytest) – nun, keine Regel ohne Ausnahme, Top-Spezialisten sind sowieso oft als Einzelkämpfer unterwegs. Und niemand hindert Sie daran, mehrere Teams von verschiedenen Anbietern zu engagieren, wichtig ist nur: ein Team – ein Partner

Beide Aufzählungen sind selbstverständlich noch erweiterbar, allerdings gibt es wesentlich mehr Gründe es zu tun, als Gegenargumente. Und diese lassen sich eigentlich immer entkräften.

Fazit: Verantwortung an bewährte Teams abgeben

Haben Sie den Mut, Verantwortung abzugeben, und überlassen Sie die Zusammenstellung des Teams denen, die darauf spezialisiert sind oder sogar schon eingespielte Teams anbieten können. Übertragen Sie nicht demjenigen diese verantwortungsvolle Aufgabe, der Ihnen 150 Superprofi-Einzelkämpfer rund um die Uhr verspricht, vertrauen Sie lieber dem, der Ihnen ein schlagkräftiges, sich gegenseitig verstärkendes und eingespieltes Team in der benötigten Größe bieten kann.

Damit entlasten Sie sich und die Teammitglieder, sorgen für beste Qualität und sparen nebenbei auch noch bares Geld.

Im ersten Schritt haben Sie sicher schon viele einzelne Aufgaben ausgelagert, vielleicht RE, Projektleitung, Datenhaltung, vielleicht sogar die gesamte Softwareentwicklung. Und Sie haben hoffentlich gute Erfahrungen damit gemacht.

Warum nicht den nächsten Schritt machen, und das gesamte Testing ebenfalls in bewährte Hände legen.

Ich versichere Ihnen, dass das, was ich hier vorschlage, nicht meiner Verkäuferseele entspringt, sondern meinen Beobachtungen der letzten Jahre.

In diesem Sinne, beziehen Sie das doch einmal als Option in Ihre Überlegungen mit ein. Spätestens, wenn wieder einmal ein Test-Projekt in Schieflage gerät.

Vielleicht liegt die Lösung des Problems gar nicht so weit weg.

Quellen
1 2017 / 2016 Trends and Benchmarks, SwissQ
2 die Projektmanager: http://dieprojektmanager.com/scheitern-von-it-projekten/
3 Business Magazin für Unternehmer. http://www.foerderland.de/organisieren/news/artikel/top-25-warum-projekte-staendig-scheitern/
4 2017 Akademie für Manager, Wilhelm Gerbert, München; https://www.akademie-fuer-manager.de/die-5-phasen-der-teamentwicklung/
http://pm-blog.com/wp-content/uploads/2009/07/warum_scheitern_projekte-1024×565.png
http://gpm-blog.de/killerfaktor-forced-ranking-in-der-projektarbeit-oder-wie-sie-ihr-projektteam-garantiert-gegen-die-wand-fahren/

0 thoughts on “Warum es besser ist, die Sicherung der Software-Qualität in eine Hand zu legen”


Schreibe einen Kommentar