Das Wichtigste ist, dass Programmierer nicht verstehen, wie sie mit dem Kunden und untereinander kommunizieren sollen. So bauen Sie einen kontinuierlichen Qualitätsproduktentwicklungsprozess auf. So planen Sie Ihren Arbeitstag und Ihre Sprints.
Und all dies führt letztendlich zu Terminstörungen, Überstunden, ständigen Auseinandersetzungen darüber, wer schuld ist, und Unzufriedenheit der Kunden - wo und wie sich alles bewegt. All dies führt sehr oft zu einem Wechsel der Programmierer oder sogar ganzer Teams. Verlust eines Kunden, Verschlechterung des Ansehens und so weiter.
Einmal war ich gerade bei einem solchen Projekt, bei dem all diese Reize waren.
Niemand wollte die Verantwortung für das Projekt übernehmen (ein großer Dienstleistungsmarkt), der Umsatz war schrecklich, der Kunde zerriss und schlug. Der CEO kam einmal auf mich zu und sagte, dass Sie die notwendige Erfahrung haben. Hier sind die Karten in Ihren Händen. Nehmen Sie das Projekt für sich. Sie vermasseln, wir werden das Projekt schließen und alle rausschmeißen. Es wird sich herausstellen, es wird cool sein, dann führen und entwickeln, wie Sie es für richtig halten. Infolgedessen wurde ich Teamleiter des Projekts und alles fiel mir auf die Schultern.
Als erstes entwarf ich einen Workflow von Grund auf neu, der meiner damaligen Vision entsprach, und schrieb eine Stellenbeschreibung für das Team. Es war nicht einfach zu implementieren. Aber irgendwann innerhalb eines Monats beruhigte sich alles, die Entwickler und der Kunde gewöhnten sich daran und alles verlief leise und bequem. Um dem Team zu zeigen, dass dies nicht nur ein "Sturm im Glas" ist, sondern ein echter Ausweg aus der Situation, habe ich die maximale Verantwortung übernommen und die unangenehme Routine aus dem Team entfernt.
Eineinhalb Jahre sind bereits vergangen, und das Projekt entwickelt sich ohne Überstunden, ohne "Rattenrennen" und alle Arten von Stress. Jemand im alten Team wollte nicht so arbeiten und ging, jemand war im Gegenteil sehr daran interessiert, dass transparente Regeln auftauchten. Infolgedessen ist jeder im Team sehr motiviert und kennt das große Projekt sowohl im Front-End als auch im Back-End vollständig. Einschließlich der Codebasis und der gesamten Geschäftslogik. Es ist sogar so weit gekommen, dass wir nicht nur "Ruderer" sind, sondern selbst viele Geschäftsprozesse und neue Funktionen entwickeln, die das Unternehmen nach seinem Geschmack gefunden hat.
Dank dieses Ansatzes entschied sich der Kunde, einen anderen Marktplatz bei unserem Unternehmen zu bestellen, was eine gute Nachricht ist.
Da es bei meinem Projekt funktioniert, kann es vielleicht auch jemandem helfen. Der Prozess selbst, der uns geholfen hat, das Projekt zu retten:
Teamwork-Prozess zum Projekt "Mein Lieblingsprojekt"
a) Interner Teamprozess (zwischen Entwicklern)
- Alle Aufgaben werden im Jira-System erstellt
- Jede Aufgabe sollte so weit wie möglich beschrieben werden und nur eine Aktion ausführen
- Jedes Feature ist, wenn es komplex genug ist, in viele kleine Swaps unterteilt
- Das Team arbeitet an Funktionen wie einer einzelnen Aufgabe. Zuerst machen wir alle zusammen eine Funktion, senden sie zum Testen und nehmen dann die nächste.
- Jede Aufgabe ist für das Backend oder Frontend markiert
- Es gibt Arten von Stoßzähnen und Käfern. Sie müssen sie korrekt angeben.
- Nach Abschluss der Aufgabe wird sie in den Status der Codeüberprüfung versetzt (dies erzeugt eine Pull-Anforderung für Ihren Kollegen).
- Wer die Aufgabe erledigt hat, verfolgt sofort seine Zeit für diese Aufgabe.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- Jeden Tag muss der Entwickler im Chat des Kunden darüber schreiben, an welchen Aufgaben er gestern gearbeitet hat und an welchen Aufgaben er heute arbeiten wird
- Der Workflow basiert auf Scrum. Alles ist in Sprints zerlegt. Jeder Sprint dauert zwei Wochen.
- Sprints erstellen, füllen und schließen einen Teamleiter.
- Wenn das Projekt strenge Fristen hat, versuchen wir, alle Aufgaben ungefähr abzuschätzen. Und wir sammeln einen Sprint von ihnen. Wenn der Kunde versucht, dem Sprint weitere Aufgaben hinzuzufügen, legen wir Prioritäten fest und übertragen einige andere Aufgaben auf den nächsten Sprint.
b) Der Prozess der Zusammenarbeit mit dem Kunden
- Jeder Entwickler kann und sollte mit dem Kunden kommunizieren
- Dem Kunden sollte es nicht gestattet sein, seine eigenen Spielregeln durchzusetzen. Es ist höflich und freundlich, dem Kunden klar zu machen, dass wir Spezialisten auf unserem Gebiet sind, und nur wir müssen Arbeitsprozesse aufbauen und den Kunden in diese einbeziehen
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- Wenn der Kunde anfängt, andere Aufgaben als sein Kopf zu entwickeln, zu phantasieren und an den Fingern zu erklären, bitten wir ihn, uns ein Seitenlayout und einen Logikfluss zur Verfügung zu stellen, der das Verhalten des gesamten Layouts und seiner Elemente vollständig beschreiben sollte.
- Bevor wir eine Aufgabe übernehmen, müssen wir sicherstellen, dass diese Funktion in den Bedingungen unserer Vereinbarung / unseres Vertrags enthalten ist. Wenn dies eine neue Funktion ist, die über unsere ursprünglichen Vereinbarungen hinausgeht, müssen wir diese Funktion definitiv bewerten ((geschätzte Vorlaufzeit + 30%) x 2) und dem Kunden mitteilen, dass wir so viel Zeit dafür benötigen und die Frist verschoben wird um das Zweifache der Schätzung. Lassen Sie uns die Aufgabe schneller machen - großartig, jeder wird davon profitieren. Wenn nicht, sind wir versichert.
c) Was wir im Team nicht akzeptieren:
- Optionalität, mangelnde Montage, Vergesslichkeit
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
Und eine Reihe anderer Fragen / Thesen, die ich meinem Kunden manchmal stelle, um alle Missverständnisse zu beseitigen:
- Was sind Ihre Qualitätskriterien?
- Wie stellen Sie fest, ob ein Projekt ein Problem hat oder nicht?
- Alle Risiken, die gegen alle unsere Empfehlungen und Ratschläge zur Änderung / Verbesserung des Systems verstoßen, werden nur von Ihnen getragen
- Alle größeren Änderungen am Projekt (z. B. alle Arten von zusätzlichen Flows) führen zum möglichen Auftreten von Fehlern (die wir natürlich beheben werden).
- Es ist für ein paar Minuten unmöglich zu verstehen, welche Art von Problem im Projekt aufgetreten ist, und noch mehr, es sofort zu beheben
- Wir arbeiten an einem bestimmten Flow-Produkt (Aufgaben in Fett - Entwicklung - Testen - Bereitstellen). Dies bedeutet, dass wir nicht auf den gesamten Strom von Anfragen und Beschwerden im Chat antworten können
- Programmierer sind nur Programmierer, keine professionellen Tester und können die richtige Qualität der Projekttests nicht sicherstellen
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
In der Regel merkt der Kunde sofort, dass bei der Softwareentwicklung nicht alles so einfach ist und das Verlangen allein eindeutig nicht ausreicht.
Im Allgemeinen ist das alles. Ich lasse viele Verhandlungen und das anfängliche Debuggen aller Prozesse hinter den Kulissen, aber infolgedessen hat alles geklappt. Ich kann sagen, dass dieser Prozess für uns zu einer Art "Silberkugel" geworden ist. Neue Leute, die zu dem Projekt kamen, konnten sich vom ersten Tag an sofort an der Arbeit beteiligen, da alle Prozesse beschrieben sind und die Dokumentation und Architektur in Form von Diagrammen sofort eine Vorstellung davon gab, was wir alle hier tun.
PS Ich möchte klarstellen, dass es keinen Projektmanager auf unserer Seite gibt. Es ist auf der Seite des Kunden. Überhaupt kein Technikfreak. Das Projekt ist europäisch. Die gesamte Kommunikation erfolgt nur in englischer Sprache.
Viel Glück an alle bei Projekten. Brennen Sie nicht aus und versuchen Sie, Ihre Prozesse zu verbessern.
Die Quelle ist auf meinem Blog .