Blutsauger-Bosse aus dem Zusammenhang geraten oder warum sie immer versagen

Meiner Meinung nach enthüllte der Artikel „Chefs of Bloodsuckers in the Context ...“ nicht den Grund für den Zusammenbruch von Selbstverwaltungsteams, sondern den Grund für die geringe Geschwindigkeit der Verteilung der Produktanforderungen und das mangelnde Verständnis, dass der Leiter immer Teil des Teams ist.

Indem Sie den Ansatz für die Planung der Konstruktionsabteilung während der Entwicklung eines neuen Produkts ändern, können Sie die Geschwindigkeit erhöhen, mit der Informationen verteilt werden. Dies ist für ein Projekt viel wichtiger als nur Informationen.

Klassisches Design

Im klassischen Schema haben der Arbeitsplanungsprozess und der Entwicklungsprozess klare Zeitpläne. In der Regel findet der Planungsprozess vor der Entwicklung statt. Am Ende der Planung für jeden Monat wird ein „Netzwerkarbeitszeitplan“ angezeigt, nach dem der Prozess der Produktentwicklung durch die Konstruktionsabteilung beginnt. Es gibt nicht viele Arten von Netzwerkgrafiken - dies sind hauptsächlich PERT und GANTT . Die Begriffe im Netzwerkplan sind in der Regel deklarativ und werden durch nichts gesichert, was bei der Ausführung von Arbeiten im Entwicklungsprozess durch die Konstruktions- und Entwicklungsabteilung einen imaginären Spielraum schafft. Tatsächlich werden die Fristen im Netzwerkplan mit dem Kunden vereinbart und der Auftragnehmer ist gezwungen, diese einzuhalten, da andernfalls das Versäumnis wichtiger Entwicklungsfristen den Abschluss des gesamten Projekts gefährden könnte. Niemand fragt Entwickler im klassischen Schema, und der Projektmanager senkt einfach die Fristen für jede Arbeit für die Entwickler.

Von der Seite sieht es so aus, als ob der Projektmanager jedem eine Art Angelrute (Werkzeug) gibt und sagt: „Fang während Karausche. Am Ende des Monats werde ich nachsehen, wie viele gefangen wurden. Wir müssen 2 Tonnen fangen. “ Während des Monats hält der Projektmanager Besprechungen ab, bei denen er berichtet, wer, wie viele Tonnen und welche Art von Fisch er gefangen hat. Ende des Monats wird dem Projektmanager ein neuer „aktualisierter“ Netzwerkplan veröffentlicht, nach dem der Kunde nicht Karausche, sondern beispielsweise „Zucchini“ fangen möchte. Der „weise Projektmanager“ hat die Chance, einen Bonus für den Kauf eines neuen Plasmas oder eines neuen modernen SUV zu erhalten. Wenn er Glück hat und es mindestens einen gibt, der den „Zucchinifisch“ fängt, zahlt er sich und dem glücklichen Fischer einen Bonus und verhängt gegen andere eine Geldstrafe.

Diese Arbeitsweise zwingt den Projektmanager, einige der Entwicklungsaufgaben für sich selbst zu übernehmen, und die Entwickler eines solchen Projekts kommen ständig zu spät zur Arbeit, und manchmal müssen sie an Wochenenden arbeiten, um rechtzeitig neue Benutzerinteraktionsschnittstellen mit dem Produkt entwickeln zu können. All dies wird, wie oben erwähnt, durch die Tatsache weiter verschärft, dass sich die Anforderungen für das Endprodukt ändern können und dann der Netzwerkplan angepasst wird und die Anpassung so vorgenommen wird, dass die Schlüsseldaten im Projekt nicht beeinflusst werden.
In einem solchen Schema hängt jede Arbeit vom menschlichen Faktor ab, der eine Schlüsselrolle spielt. Der Faktor Mensch kann durch die Einführung automatisierter Planungs- und Entwicklungssysteme minimiert werden, was im Wesentlichen viele Menschen durch die Implementierung von CAD , CAM , CAE , PDM , ERP , CRM , PLM usw. in ihren Unternehmen tun.

Die Grundlage in Form eines klassischen Schemas, wenn Planung und Entwicklung klare Zeitgrenzen haben, bleibt jedoch unverändert. Infolgedessen müssen Entwickler zahlreiche Ausgaben des Softwareprodukts und der Dokumentation in jedem automatisierten System auf dem neuesten Stand halten und die Systemintegration ständig unterstützen, was unter den aktuellen Wettbewerbsbedingungen des IT-Marktes sehr problematisch ist. Der Kunde braucht letztendlich nur eines - das fertige Produkt oder die optimierte Produktion. Im klassischen Schema ist die vom Auftragnehmer erstellte Liste der Unterlagen immer überflüssig, da weder der Kunde noch der Auftragnehmer volles Vertrauen in die Erreichung des Ziels haben. Dies bedeutet, dass der Prozess maximal dokumentiert werden muss, um festzustellen, wer für die Nichteinhaltung der Fristen verantwortlich ist. Selbst wenn das endgültige Ziel zunächst als spezifisch (spezifisch), messbar, erreichbar, realistisch und zeitbasiert formuliert wird, kann der Künstler nach der ersten zusätzlichen Anforderung das Vertrauen verlieren Erreichbarkeit des Endziels, und daher wird es eine Aufschlüsselung der Fristen und den Abschluss des Projekts geben.

Wie kann dann sichergestellt werden, dass der Kunde die Anforderungen nicht zu oft ändert und der Auftragnehmer alle Anforderungen des Kunden rechtzeitig erfüllt?

Im klassischen Schema wird der Planungsprozess von einem erfahrenen Experten auf dem Gebiet der Projektplanung durchgeführt, der auf der Grundlage seiner Erfahrung die Liste der Aufgaben und deren Bedingungen festlegt. Ich glaube, dass all dies nicht von einem erfahrenen Experten hätte durchgeführt werden können, da das Team selbst die Zeitpläne für die Erledigung von Aufgaben sowie die Liste der für die Ausführung erforderlichen Aufgaben festlegen kann. Dazu muss der Experte des Kunden das Produkt in seiner TK so detailliert wie möglich beschreiben und die Frist, bis zu der das Produkt benötigt wird, und das wars! Das Team kann unter Anleitung des Projektmanagers selbst Arbeitsplanung durchführen, Fallstricke identifizieren, Aufgaben zerlegen, kurz gesagt, die gesamte Arbeit eines erfahrenen Experten.

Das „Problem“ ist, dass in diesem Fall jedes Teammitglied das Endziel kennt, es transparent ist und zu jedem Zeitpunkt bekannt ist, wie weit das Team davon entfernt ist. Der „weise Projektmanager“ wird sein Mega-Ziel nicht in dieses Ziel einbeziehen können: „Kauf eines modernen SUV“. Damit er sein Mega-Ziel zu 100% erfolgreich erreichen kann, muss er die Planungs- und Entwicklungsprozesse trennen und Aufgabenlisten in Chargen ausgeben, wenn „Probleme“ auftreten. In diesem Fall die Aufgabe des Projektmanagers, die Aufmerksamkeit des Teams so weit wie möglich auf das Endziel des Projekts zu lenken und seine Aufmerksamkeit genau rechtzeitig für die spezifische Arbeit des Netzwerkplans auf die Lösung zu richten. Mit anderen Worten: „Füllen Sie das Team mit Routinearbeiten“.

Ein grundlegend anderes Arbeitsschema ist ein Arbeitsschema unter Verwendung flexibler Entwicklungsmethoden, wobei das Hauptprinzip lautet:
häufige kontinuierliche Lieferung eines Wertprodukts an den Kunden.

Um dies zu erreichen, ermöglicht zunächst die Transparenz des Planungsprozesses, dass jedes Mitglied des Teams das endgültige Ziel kennt und für die nächsten 1 bis 4 Wochen an der Bildung des Aufgabenpools teilnimmt. Danach sieht der Kunde die erste Version des Produkts mit neuen Funktionen. Es liegt in der Verantwortung des Projektmanagers, die Genehmigung des Kunden einzuholen oder ihn einfach über die Produktversion mit neuen Funktionen zu informieren, die nach Abschluss der Iteration verfügbar sein wird. Alle zusätzlichen Anforderungen des Kunden sollten bei der Planung des Taskpool-Teams in den folgenden Iterationen berücksichtigt werden.

Um nicht vom Weg zum Erreichen des Endziels abzuweichen, versammelt sich das Team jeden Tag zu 15-minütigen Rallyes, bei denen jedes Teammitglied drei Fragen beantwortet:

1. Was wurde seit dem letzten Treffen getan?
2. Was wird für die nächste Rallye getan?
3. Was sind die Probleme?

Wenn die Planung getrennt von der Entwicklung durchgeführt wird, gibt der Projektmanager die Antwort auf die zweite Frage, ebenso wie die Antwort auf die dritte.

Am Ende jeder Iteration (Sprint) demonstriert das Team dem Kunden das Produkt mit neuen Funktionen. Nach jeder Demonstration versammelt sich das Team getrennt vom Kunden, um eine Retrospektive durchzuführen. Es gibt viele Methoden zur Durchführung von Retrospektiven. Ich möchte eine Retrospektive im „PLUS / DELTA“ -Stil erwähnen, bei der jedes Teammitglied 10 positive Punkte (PLUS) und zehn Punkte ausdrückt, die das Team vom Erreichen des beabsichtigten Ziels abweichen lassen (DELTA).

Bei der Arbeit mit flexiblen Entwicklungstechniken spielen automatisierte Systeme eine Schlüsselrolle, sodass Sie am Ende der Iteration ein Produkt mit den fortschrittlichsten neuen Funktionen erhalten. Nach jeder Iteration kann das Produkt zur technologischen Entwicklung in ERP- oder CRM- Systemen gesendet werden, um die Produktion eines Prototypprodukts zum Testen unter Bedingungen zu starten, die den tatsächlichen Bedingungen so nahe wie möglich kommen. Somit wird nach jeder Iteration das Softwareprodukt verfeinert und neue funktionale Anforderungen aufgebaut. Kunden selbst, die sich bereits in der Phase der technologischen Entwicklung oder eines Pilotprojekts durch Feedback im CRM- System befinden, werden Anforderungen ausdrücken, an die Sie nicht einmal denken würden. Die Hauptsache ist, diese Anforderungen den Entwicklern rechtzeitig zu vermitteln und sie nicht in ihren Hallen der Vernunft zu verstecken, wie es manchmal die „weisen Projektmanager“ tun.

Schlussfolgerungen ziehen

Versuche, den Entwicklungsprozess nach dem klassischen Schema mit flexiblen Methoden aufzubauen, scheitern normalerweise, und wenn man sieht, dass so viele Projektmanager wegen ihrer „Megacels“ oder einfach automatisch dem Grundprinzip „Teilen und Erobern“ folgen, lehnt es ab, modernes Projektmanagementwissen in der Praxis anzuwenden.