🥇Organisation des Arbeitsablaufs im Team bei einem IT-Projekt

Hallo Freunde. Sehr oft, insbesondere im Outsourcing, sehe ich das gleiche Bild. Das Fehlen eines klaren Arbeitsablaufs in Teams bei verschiedenen Projekten.

Das Wichtigste ist, dass Programmierer es nicht verstehen, mit dem Kunden und untereinander zu kommunizieren. Wie man einen kontinuierlichen Prozess zur Entwicklung eines Qualitätsprodukts aufbaut. So planen Sie Ihren Arbeitstag und Ihre Sprints.

Und all dies führt schließlich zu Terminüberschreitungen, Überstunden, ständigen Machtkämpfen darüber, wer die Schuld trägt, und zur Unzufriedenheit der Kunden – wo und wie sich alles bewegt. All dies führt häufig zu einem Wechsel von Programmierern und sogar ganzen Teams. Verlust eines Kunden, Verschlechterung des Rufs usw.

Irgendwann war ich gerade bei einem solchen Projekt, bei dem es all diese Freuden gab.

Niemand wollte die Verantwortung für das Projekt übernehmen (ein großer Dienstleistungsmarktplatz), die Fluktuation war schrecklich, der Kunde hat einfach nur gerissen und geworfen. Der CEO ist irgendwie auf mich zugekommen und hat gesagt, dass Sie über die nötige Erfahrung verfügen, also die Karten in Ihren Händen halten. Nehmen Sie das Projekt für sich. Wenn Sie es vermasseln, schließen wir das Projekt und werfen alle raus. Es wird sich herausstellen, es wird cool sein, dann führen Sie es und entwickeln Sie es, wie Sie es für richtig halten. Dadurch wurde ich zum Teamleiter des Projekts und alles lag auf meinen Schultern.

Als erstes habe ich einen Arbeitsablauf von Grund auf entworfen, der meiner damaligen Vision entsprach, und eine Stellenbeschreibung für das Team verfasst. Die Umsetzung war nicht einfach. Aber irgendwann innerhalb eines Monats beruhigte sich alles, die Entwickler und der Kunde gewöhnten sich daran und alles verlief ruhig und angenehm. Um dem Team zu zeigen, dass dies nicht nur ein Sturm im Glas ist, sondern ein echter Ausweg aus der Situation, habe ich ein Höchstmaß an Verantwortung übernommen und dem Team die unangenehme Routine genommen.

Eineinhalb Jahre sind bereits vergangen und das Projekt entwickelt sich ohne Überstunden, ohne „Rattenrennen“ und allerlei Stress. Jemand im alten Team wollte nicht so arbeiten und ist gegangen, im Gegenteil, jemand hat sich wirklich darauf eingelassen, dass transparente Regeln entstanden sind. Aber dadurch sind alle im Team sehr motiviert und kennen das riesige Projekt vollständig, sowohl im Frontend als auch im Backend. Einschließlich sowohl der Codebasis als auch 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 dem Unternehmen gefallen.

Dank dieser Vorgehensweise unsererseits hat sich der Kunde entschieden, einen weiteren Marktplatz bei unserem Unternehmen zu bestellen, was eine gute Nachricht ist.

Da dies bei meinem Projekt funktioniert, hilft es vielleicht auch jemandem. Also der Prozess selbst, der uns geholfen hat, das Projekt zu retten:

Der Prozess der Teamarbeit am Projekt „Mein Lieblingsprojekt“

a) Innerhalb eines Teamprozesses (zwischen Entwicklern)

Alle Aufgaben werden im Jira-System erstellt
Jede Aufgabe sollte so genau wie möglich beschrieben werden und genau eine Aktion ausführen.
Jede Funktion ist, wenn sie komplex genug ist, in viele kleine Aufgaben unterteilt
Das Team arbeitet als einzelne Aufgabe an Features. Zuerst machen wir gemeinsam eine Funktion, geben sie zum Testen und nehmen dann die nächste.
Jede Aufgabe ist als Backend oder Frontend gekennzeichnet
Es gibt Arten von Aufgaben und Fehlern. Sie müssen sie korrekt angeben.
Nachdem die Aufgabe abgeschlossen ist, wird sie in den Code-Review-Status überführt (ein Pull-Request wird für ihren Kollegen erstellt).
Derjenige, der die Aufgabe erledigt hat, erfasst sofort seine Zeit für diese Aufgabe
Nach der Überprüfung des Codes wird der PR genehmigt und danach führt derjenige, der diese Aufgabe ausgeführt hat, ihn selbstständig in den Hauptzweig ein, woraufhin er seinen Status in „Bereit für die Bereitstellung auf dem Entwicklungsserver“ ändert.
Alle Aufgaben, die zur Bereitstellung auf dem Entwicklungsserver bereitstehen, werden vom Teamleiter (seinem Verantwortungsbereich) bereitgestellt, manchmal auch von einem Teammitglied, wenn etwas dringend ist. Nach der Bereitstellung werden alle Aufgaben von „Bereit zur Bereitstellung“ bis „Entwickler“ in den Status „Bereit zum Testen auf dem Entwickler“ übertragen
Alle Aufgaben werden vom Kunden getestet
Wenn der Kunde die Aufgabe auf dem Entwickler getestet hat, überführt er sie in den Status „Bereit für die Bereitstellung in der Produktion“.
Für die Bereitstellung in der Produktion haben wir einen separaten Zweig, in dem wir den Master direkt vor der Bereitstellung zusammenführen
Wenn der Kunde beim Testen Fehler findet, sendet er die Aufgabe zur Überarbeitung zurück und setzt den Status „Zur Überarbeitung zurückgegeben“. So trennen wir neue Aufgaben von noch nicht getesteten.
Infolgedessen durchlaufen alle Aufgaben von der Erstellung bis zum Abschluss: Zu erledigen → In der Entwicklung → Codeüberprüfung → Bereitstellen für die Entwicklung → QA für die Entwicklung → (Zurück zur Entwicklung) → Bereit für die Bereitstellung für die Produktion → QA für die Entwicklung → Fertig
Jeder Entwickler testet seinen Code unabhängig, auch als Benutzer der Website. Es ist nicht erlaubt, einen Zweig mit dem Hauptzweig zusammenzuführen, es sei denn, es ist sicher bekannt, dass der Code funktioniert.
Jede Aufgabe hat Prioritäten. Die Prioritäten werden entweder vom Kunden oder vom Teamleiter festgelegt.
Entwickler erledigen zuerst vorrangige Aufgaben.
Entwickler können einander Aufgaben zuweisen, wenn unterschiedliche Fehler im System gefunden wurden oder eine Aufgabe aus der Arbeit mehrerer Spezialisten besteht.
Alle Aufgaben, die der Kunde erstellt, werden an den Teamleiter gesendet, der sie bewertet und entweder den Kunden bittet, sie fertigzustellen, oder sie einem der Teammitglieder zuweist.
Alle Aufgaben, die bereit sind, für die Entwicklung oder Produktion bereitgestellt zu werden, gelangen auch an den Teamleiter, der unabhängig bestimmt, wann und wie sie bereitgestellt werden. Nach jedem Einsatz muss der Teamleiter (bzw. Teammitglied) den Kunden hierüber informieren. Und ändern Sie auch den Status für Aufgaben in „Bereit zum Testen auf Entwickler/Produkt“.
Jeden Tag zur gleichen Zeit (wir haben es um 12.00 Uhr) veranstalten wir eine Kundgebung zwischen allen Teammitgliedern
Jeder bei der Rallye berichtet, auch der Teamleiter, was er gestern gemacht hat, was er heute vorhat. Was funktioniert nicht und warum. So weiß das gesamte Team, wer was macht und in welchem Stadium sich das Projekt befindet. Dies gibt uns die Möglichkeit, unsere Schätzungen und Fristen vorherzusagen und bei Bedarf anzupassen.
Bei der Besprechung gibt der Teamleiter auch alle Änderungen im Projekt und den Grad der aktuellen Fehler bekannt, die vom Kunden nicht gefunden wurden. Alle Fehler werden aussortiert und jedem Teammitglied zugewiesen, um sie zu beheben.
Bei der Rallye weist der Teamleiter jedem die Aufgaben zu, wobei er die aktuelle Arbeitsbelastung der Entwickler, ihren Ausbildungsstand und auch die Nähe einer bestimmten Aufgabe zu dem, was der Entwickler gerade macht, berücksichtigt.
Bei dem Treffen entwickelt der Teamleiter eine allgemeine Strategie für Architektur und Geschäftslogik. Anschließend bespricht das gesamte Team dies und entscheidet, ob Anpassungen vorgenommen oder diese Strategie übernommen werden sollen.
Jeder Entwickler schreibt unabhängig voneinander Code und erstellt Algorithmen innerhalb einer einzigen Architektur und Geschäftslogik. Jeder kann seine Vision der Umsetzung äußern, aber niemand zwingt jemanden dazu, es so und nicht anders zu machen. Jede Entscheidung ist berechtigt. Wenn es eine bessere Lösung gibt, aber jetzt keine Zeit dafür ist, wird in Fat eine Aufgabe für die zukünftige Umgestaltung eines bestimmten Teils des Codes erstellt.
Wenn ein Entwickler eine Aufgabe übernimmt, versetzt er sie in den Entwicklungsstatus. Die gesamte Kommunikation zur Klärung der Aufgabenstellung mit dem Kunden liegt auf den Schultern des Entwicklers. Technische Fragen können an den Teamleiter oder Kollegen gestellt werden.
Wenn der Entwickler den Kern der Aufgabe nicht versteht und der Kunde sie nicht sinnvoll erklären konnte, geht er zur nächsten Aufgabe über. Und der Teamleiter nimmt das aktuelle und bespricht es mit dem Kunden.
Jeden Tag sollte der Entwickler im Chat des Kunden 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 unterteilt. Jeder Sprint dauert zwei Wochen.
Sprints werden vom Teamleiter erstellt, gefüllt und abgeschlossen.
Wenn das Projekt strenge Fristen hat, versuchen wir, alle Aufgaben grob abzuschätzen. Und wir sammeln von ihnen einen Sprint. 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 soll mit dem Kunden kommunizieren
Sie können nicht zulassen, dass der Kunde seine eigenen Spielregeln durchsetzt. Es ist notwendig, dem Kunden auf höfliche und freundliche Weise klar zu machen, dass wir Spezialisten auf unserem Gebiet sind und nur wir Arbeitsprozesse aufbauen und den Kunden in diese einbeziehen sollen
Idealerweise ist es notwendig, vor der Implementierung einer Funktionalität ein Flussdiagramm des gesamten logischen Prozesses für ein Feature (Workflow) zu erstellen. Und senden Sie es zur Bestätigung an den Kunden. Dies gilt nur für komplexe und nicht offensichtliche Funktionen, beispielsweise ein Zahlungssystem, ein Benachrichtigungssystem usw. Auf diese Weise können Sie genauer verstehen, was genau der Kunde benötigt, die Dokumentation für die Funktion speichern und sich außerdem davor schützen, dass der Kunde in Zukunft sagen könnte, dass wir nicht getan haben, was er verlangt hat.
Alle Diagramme/Flussdiagramme/Logik usw. Wir speichern in Confluence/Fat, wo wir den Kunden in den Kommentaren bitten, die Richtigkeit der zukünftigen Implementierung zu bestätigen.
Wir versuchen, den Kunden nicht mit technischen Details zu belasten. Wenn wir verstehen müssen, was der Kunde will, dann zeichnen wir primitive Algorithmen in Form eines Flussdiagramms, die der Kunde verstehen und alles selbst reparieren/modifizieren kann.
Wenn der Kunde einen Fehler im Projekt findet, bitten wir Sie, diesen in Fat ausführlich zu beschreiben. Unter welchen Umständen ist es wann aufgetreten, welche Handlungsabfolge wurde vom Kunden während des Tests durchgeführt. Bitte fügen Sie Screenshots bei.
Wir versuchen jeden Tag, maximal jeden zweiten Tag, die Bereitstellung auf dem Entwicklungsserver. Anschließend beginnt der Kunde mit dem Testen der Funktionalität und das Projekt steht nicht still. Gleichzeitig ist dies für den Kunden ein Zeichen dafür, dass das Projekt in voller Entwicklung ist und ihm niemand Märchen erzählt.
Es kommt oft vor, dass der Kunde überhaupt nicht vollständig versteht, was er braucht. Da er sich ein neues Unternehmen gründet, mit noch nicht debuggten Prozessen. Daher kommt es sehr häufig vor, dass wir ganze Codeteile in den Papierkorb werfen und die Anwendungslogik umgestalten. Daraus folgt, dass es nicht notwendig ist, absolut alles mit Tests abzudecken. Es ist sinnvoll, nur kritische Funktionen mit Tests und dann mit Vorbehalten abzudecken.
Es gibt Situationen, in denen das Team merkt, dass wir die Fristen nicht einhalten. Anschließend führen wir eine schnelle Prüfung der Aufgaben durch und informieren den Kunden umgehend darüber. Als Ausweg aus dieser Situation schlagen wir vor, wichtige und kritische Funktionen rechtzeitig einzuführen und den Rest für die Zeit nach der Veröffentlichung aufzubewahren.
Wenn der Kunde anfängt, sich in seinem Kopf verschiedene Aufgaben auszudenken, zu phantasieren und mit den Fingern zu erklären, dann bitten wir ihn, uns ein Seitenlayout und einen Ablauf mit Logik zur Verfügung zu stellen, die das Verhalten des gesamten Layouts und seiner Elemente vollständig beschreiben sollten Elemente.
Bevor wir eine Aufgabe übernehmen, müssen wir sicherstellen, dass diese Funktion in den Bedingungen unserer Vereinbarung / unseres Vertrags enthalten ist. Wenn es sich um eine neue Funktion handelt, die über unsere ursprünglichen Vereinbarungen hinausgeht, müssen wir diese Funktion auf jeden Fall schätzen ((ungefähre Vorlaufzeit + 30 %) x 2) und dem Kunden mitteilen, dass wir für die Fertigstellung so viel Zeit in Anspruch nehmen werden die Frist verschiebt sich um die geschätzte Zeit multipliziert mit zwei. Machen wir die Aufgabe schneller – großartig, davon werden alle nur profitieren. Wenn nicht, sind wir versichert.

c) Was wir im Team nicht akzeptieren:

Inkonsistenz, Inkohärenz, Vergesslichkeit
„Frühstücksfütterung“. Wenn Sie die Aufgabe nicht erledigen können und nicht wissen, wie, müssen Sie den Teamleiter sofort darüber informieren und nicht bis zum letzten warten.
Brovadas und Prahlereien eines Mannes, der seine Fähigkeiten und seine Professionalität noch nicht durch Taten unter Beweis gestellt hat. Wenn es bewiesen ist, dann ist es im Rahmen des Anstands möglich 🙂
Betrug in all seinen Erscheinungsformen. Wenn die Aufgabe nicht abgeschlossen ist, sollten Sie ihren Status nicht auf „erledigt“ ändern und im Chat des Kunden schreiben, dass sie fertig ist. Der Computer ist abgestürzt, das System ist abgestürzt, der Hund hat auf dem Laptop gekaut – das alles ist inakzeptabel. Tritt ein tatsächlicher Fall höherer Gewalt ein, ist der Teamleiter unverzüglich zu benachrichtigen.
Wenn ein Spezialist ständig offline ist und es während der Arbeitszeit schwierig ist, ihn zu erreichen.
Toxizität im Team ist nicht erlaubt! Wenn jemand mit etwas nicht einverstanden ist, dann kommen alle zu einer Kundgebung zusammen und diskutieren und entscheiden.

Und eine Reihe von Fragen/Thesen, die ich meinem Kunden manchmal stelle, um alle Missverständnisse auszuräumen:

Was sind Ihre Qualitätskriterien?
Wie stellen Sie fest, ob ein Projekt Probleme hat oder nicht?
Bei Verstößen gegen alle unsere Empfehlungen und Ratschläge zur Änderung/Verbesserung des Systems tragen nur Sie das gesamte Risiko
Alle größeren Projektänderungen (z. B. alle Arten von Extra-Flows) führen möglicherweise zum Auftreten von Fehlern (die wir selbstverständlich beheben werden).
Es ist unmöglich, innerhalb weniger Minuten zu verstehen, was für ein Problem bei dem Projekt aufgetreten ist, und noch mehr, es direkt an Ort und Stelle zu beheben
Wir arbeiten an einem bestimmten Produktfluss (Aufgaben in Zhira – Entwicklung – Testen – Bereitstellen). Dies bedeutet, dass wir nicht auf den gesamten Fluss an Anfragen und Beschwerden im Chat reagieren können.
Programmierer sind nur Programmierer, keine professionellen Tester und können die ordnungsgemäße Qualität der Projekttests nicht gewährleisten
Die Verantwortung für die Endprüfung und Abnahme der Verkaufsaufgaben liegt vollständig bei Ihnen
Wenn wir eine Aufgabe bereits übernommen haben, können wir nicht sofort zu anderen wechseln, bis wir die aktuelle Aufgabe abgeschlossen haben (sonst führt dies zu noch mehr Fehlern und einer Verlängerung der Entwicklungszeit).
Es gibt weniger Leute im Team (aufgrund von Urlaub oder Krankheit), es gibt mehr Arbeit und wir werden physisch keine Zeit haben, auf alles zu reagieren, was Sie wollen
Es liegt nur auf Ihrem Risiko, Sie zu bitten, die Bereitstellung ohne getestete Aufgaben auf dem Entwickler in der Produktion durchzuführen, nicht das des Entwicklers
Wenn Sie Fuzzy-Aufgaben, ohne korrekten Ablauf, ohne Design-Layouts festlegen, erfordert dies von uns viel mehr Aufwand und Implementierungszeit, da wir anstelle von Ihnen einen zusätzlichen Arbeitsaufwand leisten müssen
Alle Aufgaben zu Fehlern ohne detaillierte Beschreibung ihres Auftretens und ohne Screenshots geben uns keine Möglichkeit zu verstehen, was schief gelaufen ist und wie wir diesen Fehler beheben können
Das Projekt erfordert ständige Weiterentwicklung und Verbesserungen, um Leistung und Sicherheit zu verbessern. Daher investiert das Team einen Teil seiner Zeit in diese Verbesserungen.
Aufgrund der Tatsache, dass wir Überstunden haben (dringende Korrekturen), müssen wir diese an anderen Tagen kompensieren

In der Regel versteht der Kunde sofort, dass in der Softwareentwicklung nicht alles so einfach ist und der Wunsch allein eindeutig nicht ausreicht.

Im Allgemeinen ist das alles. Hinter den Kulissen hinterlasse ich viele Verhandlungen und das anfängliche Debuggen aller Prozesse, aber am Ende hat alles geklappt. Ich kann sagen, dass dieser Prozess für uns zu einer Art „Silver Bullet“ geworden ist. Neue Leute, die zum Projekt kamen, konnten sich bereits vom ersten Tag an sofort an die Arbeit machen, da alle Prozesse beschrieben sind und die Dokumentation und Architektur in Form von Diagrammen sofort einen Eindruck davon vermittelten, was wir alle tun Hier.

PS: Ich möchte klarstellen, dass es auf unserer Seite keinen Projektmanager gibt. Es liegt auf der Seite des Kunden. Überhaupt kein Technikfreak. Europäisches Projekt. Die gesamte Kommunikation erfolgt ausschließlich auf Englisch.

Viel Glück an alle bei Ihren Projekten. Lassen Sie sich nicht ausbrennen und versuchen Sie, Ihre Prozesse zu verbessern.

Quelle in meinem блоге.

Source: habr.com

Organisation des Arbeitsablaufs im Team an einem IT-Projekt