Hilfe in meinem Projekt stimmt die Qualität nicht mehr

Diese Situation ist nicht neu: Ein grösseres Softwareentwicklungsprojekt wurde mit einer 10 köpfigen Mannschaft begonnen. Man hat gute Fortschritte gemacht, der Auftraggeber ist mit den ersten Resultaten zufrieden. Alle Entwicklungstasks sowie die internen Test sind nahezu abgeschlossen, das Projekt neigt sich dem Ende zu. Längst können nicht mehr alle 10 Team Mitglieder beschäftigt werden sondern diese sind teilweise bereits wieder in anderen Projekten tätig. Plötzlich merkt der Projektleiter, dass die Qualität im Projekt nicht mehr stimmt. Wann die Fehler aufgetreten sind, ist an dieser Stelle gar nicht mehr wichtig, sondern viel mehr, was der Projektleiter in einer solchen Situation tun kann, respektive wie er solche Situationen vermeiden kann:

1. Das Team bleibt bis zum Schluss ein Team
Obwohl das Projektteam nicht mehr ausschliesslich für dieses Projekt arbeitet, bleibt es bis zur Projektabnahme ein Team. Es kann durchaus sein, dass einige Leute auf anderen Projekten arbeiten und nahezu nicht mehr für das eigene Projekt tätig sind, dennoch muss der Projektleiter sicherstellen, dass die Informationen an alle Team Mitglieder verteillt werden. Statusmeeting, oder persönliche Updates an Leute, die keine konkrete Tasks mehr haben sind unerlässlich. Und warum?

• Der Entwickler soll bis zum Schluss für seine Komponenten verantwortlich sein und wenn möglich auch darin gefundene Fehler beheben. Wenn er sich jedesmal für eine Fehlerkorrektur komplett neu orientieren muss, so dauert das unter Umständen viel zu lange. Ist er aber informiert, was im Projekt gelaufen ist, so kann er geziehlt mit der Fehleranalyse beginnen. 
• Wird die Verantwortung plötzlich abgegeben, so müssen andere Personen die Fehler glatt ziehen. Das ist nicht im Sinne eines Teams, in dem jeder seine Verantwortung übernommen hat.
• Wird das Team Mitglied nicht mehr informiert, verliert es sehr schnell die Motivation. Selbst wenn dann Fehler behoben werden müssen, wird dies allfällig lieblos und ohne ausführliches Testing / Review erledigt.  

Wenn ein Team Mitglied gar keine Zeit für das Projekt mehr hat, so muss der Projektleiter eine saubere Übergabe an einen anderen Entwickler sicher stellen, damit dieser die Verantwortung über die entsprechende Komponente übernimmt.

2. Nach den ersten Erfolgen darf die Qualitätssicherung nicht vernachlässigt werden
Ist der Auftraggeber mit den bisherigen Leistungen zufrieden, besteht sehr schnell die Gefahr, keine ausführliche Qualitätssicherung mehr zu machen wie bis anhin. Das Vertrauen des Auftraggebers hat man ja durch die ersten Erfolge für sich gewonnen. Sehr schnell kommt jetzt die Denkweise "die können ja auch mal testen" auf. Das ist kontraproduktiv und nicht sinnvoll. Code Reviews, Überprüfung der Code Qualität ist auch in einer späteren Phase des Projektes unerlässlich. Durch eine schnelle Fehlerkorrektur können sich auch schnell Folgefehler einschleichen. Darunter leidet die (Code) Qualität zwangsläufig. Ein sorgfältiges Retesting der Fehlerkorrektur durch Entwickler und Tester ist in dieser Phase besonders wichtig.

Das hier Beschriebene klingt sehr stark nach dem "Idealfall". Mir ist bewusst, dass oftmals weder Zeit noch Budget für eine ausführliche Qualitätssicherung resp. für regelmässige Updates im gesamten Projektteam vorhanden ist. Dennoch soll sich der Projektleiter der Thematik bewusst sein und früh gegen dieses Problem steuern.