Erstens ist Projektmanagement das eine und Produktqualitätsmanagement das andere. Meistens bekommt man Feedback von den Leuten, die die Software kaufen, besonders wenn sie nicht zufrieden sind. Manchmal ist es zu spät, Änderungen an der Software vorzunehmen, wenn sie bereits auf dem Markt ist.

Zweitens können Sie während der gesamten Entwicklung Ihrer Software Qualitätszirkel einbeziehen, um Feedback von potenziellen Kunden zu erhalten. So vermeiden Sie Überraschungen, die zu spät kommen. Es ist eine Sache, ein Produkt zu entwickeln, und eine andere, es zu verkaufen.

Dritte. Sie müssen sich bei der Entwicklung Ihres Produkts klare, messbare und erreichbare Ziele setzen. Ziele, die sich regelmäßig leicht überprüfen lassen. In der Betriebswirtschaftslehre nennen wir das „Qualitätskontrolle“.

Schließlich ist es wichtig, von Anfang an zu wissen, wer dem Erfolg des Produkts gegenüber septisch ist und warum. Manchmal ziehen es einige Mitglieder eines Teams vor, aus dem Prozess Kapital zu schlagen, als ihn von Anfang an für tot zu erklären. Wie sicher ist Ihnen der Erfolg im Produktmanagement? Es dreht sich alles um die Bedürfnisse der Kunden. Niemand ist verpflichtet, Ihr Produkt zu kaufen.

TL;DR

Während Qualität objektiv gemessen werden kann , können Sie sich bei der Definition der domänenspezifischen Qualitätselemente für Ihre Organisation nicht auf eine Standardwörterbuchdefinition verlassen.

Tatsächlich sind die meisten Probleme, die Sie identifiziert haben, überhaupt keine Qualitätsprobleme. Sie scheinen eher organisatorische Probleme zu sein. Wir werden uns einige davon genauer ansehen und dann mit einigen Entwicklungs- und Projektmanagementpraktiken fortfahren, die hilfreich sein können.

Ihre Beispiele, analysiert

1. In letzter Zeit wurden keine großen neuen Funktionen veröffentlicht

   Kontinuierliche Feature-Entwicklung ist kein Qualitätsmerkmal. Wenn ein Produkt „gut genug“ ist, um auf dem Markt verkauft zu werden, und seinen Zweck erfüllt, dann ist Featuritis oft ein Zeichen dafür, dass es dem Unternehmen an Marktvision oder Kundenfeedback mangelt. Zum Beispiel wollten die Leute weder Clippy noch Microsoft Bob; Sie wollten oft nur weniger Bugs, Bluescreens und Viren.

2. Unterschiedliche UX über Unterprodukte hinweg

   Dies ist ein Prozessproblem , kein Qualitätsproblem per se. Wer treibt die Notwendigkeit einer einheitlichen UX voran? Wenn die Kunden dies nicht fordern und Ihr Prozess keine teamübergreifende Integration beinhaltet, dann ist dies eher ein Look-and-Feel-Problem als ein tatsächliches Qualitätsproblem.

3. Einige Softwaremodule werden nach Eigentümerwechsel kaum gewartet

   Das ist zu 100% ein organisatorisches Problem. Ohne kollektiven Codebesitz, eine Kultur des kontinuierlichen Refactorings oder eine IT-Governance, die den Besitz von Komponenten oder Prozessen erzwingt, wird Brownfield-Code fast immer zu ungeliebtem Legacy-Code. Ihre Führung muss den Besitz von Komponenten während des gesamten Produktlebenszyklus zuweisen, da Hoffnung und Wünschen keine eigentlichen Strategien sind.

4. Das Architektenteam ist nicht für die Qualität verantwortlich

   Sollten sie sein? Architektur ist (oft, aber nicht immer) für High-Level-Design verantwortlich. Es sind die Engineering- und QA-Teams (oder besser noch vollständig funktionsübergreifende Teams), die die Lösungen tatsächlich implementieren und die Qualität einbauen und testen.

   Auch hier bedeutet Qualität, was auch immer Ihr Unternehmen dafür entscheidet. Definieren Sie es, vereinbaren Sie es im gesamten Unternehmen und testen Sie es dann kontinuierlich auf die Qualitätsmetriken, auf die Sie sich alle gemeinsam geeinigt haben. Ohne diese Vereinbarung und Tests ist „Qualität“ nur ein Schlagwort.

5. Softwareentwickler begannen, das Projekt zu verlassen

   Abwanderung tritt in allen Projekten auf. Schnelle Talentfluchten weisen jedoch oft auf eine toxische Arbeitskultur, Sackgassenprojekte, Todesmärsche, Budgetkürzungen und andere bekannte organisatorische Anti-Patterns hin. Während das Team sicherlich eine Retrospektive durchführen kann, um potenzielle Probleme zu identifizieren, trägt die Unternehmensführung letztendlich die Verantwortung, die Kultur- und Prozessprobleme zu beheben, die zum Verlust wichtiger Talente führen.

6. Scheint zu viel Koordination zwischen den Teams für neue Initiativen zu sein

   „Analyselähmung“ ist ein bekanntes Antimuster. Große Initiativen, insbesondere für Brownfield-Projekte, erfordern immer mehr Zusammenarbeit als kleine Greenfield-Projekte. Während sich das Tempo des Wandels oft verlangsamt oder ins Stocken gerät, wenn Projekte größer werden, kann das größere Problem darin bestehen, dass Sie ein Framework benötigen, das über ein einzelnes Team hinaus skaliert und über mehrere Teams hinweg funktioniert. Nexus, LeSS und SAFe sind Beispiele aus der agilen Welt.

7. Oft werden Workarounds verwendet, um Kundenanforderungen zu erfüllen

   Obwohl dies eine Form von Tech-Schulden darstellen kann, ist es nicht von Natur aus ein Problem der Qualitätskontrolle. Tech Debt kann zwar die Entwicklung verlangsamen oder einen Quick-and-Dirty-Hack mit nicht optimaler Qualität darstellen, aber die bloße Existenz von Workarounds muss nicht auf eine unzureichende Produktqualität hindeuten.

So verbessern Sie die Qualität

Es gibt mehrere Ansätze, die Sie zur Verbesserung der Softwarequalität verfolgen können, aber alle beinhalten im Allgemeinen das Einbetten der Qualität in Ihre Entwicklungs- und Organisationsprozesse. Einige Beispiele sind:

1. Praktizieren von testgetriebener oder verhaltensgetriebener Entwicklung.
2. Integration moderner Continuous-Integration-Praktiken in Ihre Entwicklungspipeline.
3. Sicherstellen, dass sich das Team und die Organisation regelmäßig Zeit nehmen, ihre Werte und Praktiken zu überprüfen und anzupassen und kontinuierliche Verbesserung zu einer Priorität zu machen.
4. Technische Schulden konsequent nachverfolgen und Ressourcen routinemäßig zuweisen, um diese Schulden zu begleichen.
5. „Stopping the line“, um wichtige Qualitätskontrollprobleme anzugehen.
6. Stellen Sie sicher, dass funktionierende Software und „Fitness for Purpose“ für die Organisation wichtiger sind, als nur Spezifikationen zu erfüllen.
7. Nehmen Sie sich die Zeit, jeden Aspekt des Systems zu überarbeiten und neu zu gestalten, der schwer zu erweitern oder zu warten ist.
8. Veränderung methodisch angehen. Das Schreiben von Tests vor dem Code oder das Befolgen der Mikado-Methode zum Implementieren von Redesigns sind nur zwei relevante Beispiele.
9. Stellen Sie sicher, dass sich Ihre Software immer in einem potenziell versandfähigen Zustand befindet.
10. Nutzung von Feature-Toggles und anderen Continuous-Delivery-Praktiken.

Viele davon fallen eher in das Lager der Entwicklungspraktiken als des Projektmanagements an sich. An dieser Front sind Ihre besten Wetten wirklich:

• effektive Kommunikation (mit dem Team, mit Stakeholdern und mit Kunden),
• sehr enge Rückkopplungsschleifen, und
• ein unermüdlicher Fokus auf die kontinuierliche Verbesserung sowohl Ihres Prozesses als auch des Produkts.

Es gibt keine Wunderwaffe. Am Ende müssen Sie definieren, was Qualität für Sie bedeutet, entscheiden, wie Sie sie messen wollen, und dann Ihre Qualitätskontrollen und Ihre tatsächlichen Ergebnisse während des gesamten Projektlebenszyklus überprüfen und anpassen.

Ich könnte zu jedem Ihrer Punkte etwas sagen, werde aber auf einen eingehen. Wenn Sie diesen ansprechen, werden Sie (irgendwann) alles herausfinden.

„Softwareentwickler begannen, das Projekt zu verlassen“

Frage warum? Frag sie warum? Fragen Sie die Leute, die bleiben, warum?

Halten Sie regelmäßig Retrospektiven ab, finden Sie heraus warum, lassen Sie die Entwickler die Probleme finden und beheben. Geben Sie ihnen so viel Unterstützung, wie sie brauchen/wollen. Achten Sie darauf, es nicht auf sie zu werfen, und achten Sie darauf, nicht weiter zu kontrollieren, wenn sie es reparieren wollen.

Nicht beschuldigen. Bestrafe nicht. Wenn sie dir sagen, dass sie/jemand Mist gebaut hat, dann reagiere nicht: Das sind neue Informationen, du hättest es nicht gewusst, wenn sie es dir nicht gesagt hätten. Fragen Sie, was wir tun können, damit dies nicht noch einmal passiert (keine Schuld). Fragen Sie sie, was sie tun würden, um die Dinge zu verbessern. Experimente durchführen, kurze Iterationen. Schritt für Schritt verbessern. Versuchen Sie nicht, alles auf einmal zu reparieren (Sie werden bankrott gehen, bevor Sie fertig sind).

Außerdem ist Ihre Teamgröße viel zu groß („In letzter Zeit wurden keine großen neuen Funktionen veröffentlicht“, „50+ Personen“). Sie dürfen sie jedoch nicht aus dem Unternehmen werfen. Finden Sie andere unabhängige Arbeit für sie (ein anderes Projekt). Lassen Sie sich vom Vorstand schriftlich versichern, dass es keine Entlassungen aufgrund von Prozessverbesserungen geben wird. Die erste Entlassung wird die Zusammenarbeit zerstören.

„Personalressourcen zu einem späten Softwareprojekt hinzuzufügen, macht es später“. – Fred Brooks in seinem 1975 erschienenen Buch The Mythical Man-Month. Wenn Sie sie entfernen, kann es zu einem früheren Zeitpunkt kommen. Aber konzentrieren Sie sich nicht auf diesen Aspekt. Konzentrieren Sie sich darauf, warum sie gehen (Menschen können in der Zwischenzeit gehen, und Sie müssen herausfinden, wie Sie verkleinern können, ohne die Motivation zu zerstören. Sie können einen Teil des Teams in Tests, andere Support-Rollen oder Prozessverbesserungen versetzen. Dann schließlich in andere Projekte.

Die erste Frage lautet: Welche Qualitätsziele haben Sie? Typische Ziele sind hier aufgelistet .

Wenn Sie eine begrenzte Anzahl von Zielen identifizieren, können Sie diese in Ihrer Definition of Done (DoD) in Form von „Jedes Commit muss beibehalten oder verbessern (Modularität/Sicherheit/was auch immer)“ einfügen.

Die nächste Frage ist dann: Wie kann sichergestellt und durchgesetzt werden? Verwenden Sie Codemetriken? Führen Sie Code-Reviews durch? Und nutzt eigentlich irgendjemand das DoD? :-)