🥇Organisation des Arbeitsprozesses im Team für ein IT-Projekt

Hallo Freunde. Immer wieder, besonders im Outsourcing, sehe ich dasselbe Bild. Das Fehlen eines klaren Arbeitsprozesses in Teams bei verschiedenen Projekten.

Das Wichtigste ist, dass die Programmierer nicht verstehen, wie man mit dem Kunden und untereinander kommuniziert. Wie man einen kontinuierlichen Prozess zur Entwicklung eines qualitativ hochwertigen Produkts aufbaut. Wie man seinen Arbeitstag und die Sprints plant.

Und das alles führt letztendlich zu verpassten Deadlines, Überstunden, ständigen Streitigkeiten darüber, wer schuld ist, und Unzufriedenheit bei den Kunden – wohin und wie alles vorankommt. Häufig führt das zu einem Wechsel der Programmierer oder sogar ganzer Teams. Zu einem Verlust des Kunden, einer Verschlechterung des Rufs und so weiter.

Ich war einmal in einem solchen Projekt, wo all diese Vorzüge vorhanden waren.

Niemand wollte die Verantwortung für das Projekt (eine große Service-Marktplatz-Applikation) übernehmen, die Fluktuation war schrecklich, der Kunde war einfach aufgebracht. Der CEO kam eines Tages zu mir und sagte, dass ich die nötige Erfahrung habe, also sollte ich das Projekt übernehmen. Mach einen Fehler, und wir schließen das Projekt und feuern alle. Wenn es klappt, wäre es großartig, dann leite und entwickle es, wie du es für richtig hältst. Letztendlich wurde ich Teamleiter des Projekts und alles lag auf meinen Schultern.

Das Erste, was ich tat, war, einen Arbeitsprozess von Grund auf neu zu entwickeln, der zu meinem damaligen Verständnis passte, und eine Stellenbeschreibung für das Team zu schreiben. Es war nicht einfach, ihn einzuführen. Aber nach etwa einem Monat hatte sich alles stabilisiert, die Entwickler und der Kunde hatten sich daran gewöhnt, und alles lief schon ruhig und komfortabel. Um dem Team zu zeigen, dass dies nicht nur ein "Sturm im Wasserglas" ist, sondern eine echte Lösung, habe ich mir den größten Teil der Aufgaben aufgeladen und die unangenehme Routine vom Team genommen.

Es ist jetzt anderthalb Jahre her, und das Projekt entwickelt sich ohne Überstunden, ohne "Rattenrennen" und all die verschiedenen Stresssituationen. Einige in der alten Mannschaft wollten so nicht arbeiten und sind gegangen, andere hingegen waren froh über die transparenten Regeln. Aber am Ende sind alle, die im Team sind, sehr motiviert und kennen das große Projekt in vollem Umfang, sowohl das Frontend als auch das Backend. Inklusive des Codes und aller Geschäftslogik. Es ist sogar so weit gekommen, dass wir nicht nur "Ruderer" sind, sondern viele Geschäftsprozesse und neue Funktionen selbst entwickeln, die dem Unternehmen gefallen.

Dank dieses Ansatzes von unserer Seite hat der Kunde beschlossen, ein weiteres Marktplatzprojekt bei unserer Firma zu beauftragen, was uns natürlich sehr freut.

Da es bei meinem Projekt funktioniert, könnte es vielleicht auch jemand anderem helfen. Also, hier ist der Prozess, der uns geholfen hat, das Projekt zu retten:

Der Arbeitsprozess des Teams im Projekt „Mein Lieblingsprojekt“

a) Interner Teamprozess (zwischen den Entwicklern)

Alle Aufgaben werden im Jira-System erstellt.
Jede Aufgabe muss so detailliert wie möglich beschrieben werden und genau eine Aktion ausführen.
Jede Funktion, wenn sie komplex genug ist, wird in viele kleine Aufgaben aufgeteilt.
Das Team arbeitet an Funktionen als an einer einzigen Aufgabe. Zunächst arbeiten wir gemeinsam an einer Funktion, geben sie zur Tests frei und nehmen dann die nächste an.
Jede Aufgabe wird gekennzeichnet, ob sie für Backend oder Frontend ist.
Es gibt Arten von Aufgaben und Bugs. Diese müssen korrekt angegeben werden.
Nach Abschluss der Aufgabe wird diese in den Status Code Review überführt (ein Pull Request an den Kollegen wird erstellt).
Derjenige, der die Aufgabe erledigt hat, trackt sofort seine Zeit für diese Aufgabe.
Nach der Überprüfung des Codes wird der PR genehmigt und anschließend merge derjenige, der die Aufgabe erledigt hat, diese selbst in den Master-Branch und ändert ihren Status in bereit für Deployment auf Dev. Server.
Alle Aufgaben, die bereit für den Deployment auf den Dev-Server sind, werden vom Teamleiter deployed (seine Verantwortung). Manchmal auch von einem Teammitglied, wenn etwas Dringendes ansteht. Nach dem Deployment werden alle Aufgaben mit dem Status bereit für den Deployment auf Dev in den Status bereit für die Tests auf Dev überführt.
Alle Aufgaben werden vom Kunden getestet.
Wenn der Kunde die Aufgabe auf Dev getestet hat, überführt er sie in den Status bereit für den Deployment auf Prod.
Für das Deployment auf Prod haben wir einen separaten Branch, in den wir Master nur kurz vor dem Deployment zusammenführen.
Wenn der Kunde während der Tests Bugs findet, gibt er die Aufgabe zur Überarbeitung zurück und setzt ihren Status auf zurück zur Überarbeitung. So trennen wir neue Aufgaben von denen, die die Tests nicht bestanden haben.
Letztendlich durchlaufen alle Aufgaben den Weg von der Erstellung bis zum Abschluss: To Do → In Entwicklung → Code Review → Bereit zum Deployment auf Dev → QA auf Dev → (Zurück zu Dev) → Bereit zum Deployment auf Prod → QA auf Prod → Fertig.
Jeder Entwickler testet seinen Code selbstständig, einschließlich als Benutzer der Website. Das Zusammenführen des Branches mit dem Haupt-Branch ist nicht erlaubt, es sei denn, es ist sicher bekannt, dass der Code funktioniert.
Jede Aufgabe hat Prioritäten. Die Prioritäten werden entweder vom Auftraggeber oder vom Teamleiter festgelegt.
Die Entwickler bearbeiten in erster Linie die priorisierten Aufgaben.
Die Entwickler können Aufgaben gegenseitig zuweisen, wenn verschiedene Fehler im System gefunden wurden oder eine Aufgabe aus der Arbeit mehrerer Spezialisten besteht.
Alle Aufgaben, die der Auftraggeber erstellt, gelangen zum Teamleiter, der sie bewertet und entweder den Auftraggeber um Nachbesserung bittet oder sie einem der Teammitglieder zuweist.
Alle Aufgaben, die bereit für das Deployment auf der Dev- oder Prod-Umgebung sind, gelangen ebenfalls zum Teamleiter, der eigenständig entscheidet, wann und wie das Deployment durchgeführt wird. Nach jedem Deployment muss der Teamleiter (oder ein Teammitglied) den Auftraggeber darüber informieren und die Status für die Aufgaben auf "bereit für Tests" auf Dev/Prod ändern.
Jeden Tag zur gleichen Zeit (bei uns um 12:00 Uhr) führen wir ein Meeting mit allen Teammitgliedern durch.
Jeder berichtet im Meeting, einschließlich des Teamleiters, was er gestern gemacht hat, was er heute plant und welche Probleme er hat und warum. So ist das gesamte Team darüber informiert, wer was macht und in welcher Phase sich das Projekt befindet. Dies gibt uns die Möglichkeit, unsere Schätzungen und Fristen zu prognostizieren und gegebenenfalls zu korrigieren.
Im Meeting gibt der Teamleiter außerdem alle Änderungen im Projekt und den aktuellen Stand der Fehler bekannt, die nicht vom Auftraggeber gefunden wurden. Alle Fehler werden besprochen und jedem Teammitglied zur Lösung zugewiesen.
Im Meeting weist der Teamleiter jedem Aufgaben zu, wobei die aktuelle Auslastung der Entwickler, deren berufliches Niveau sowie die Nähe der jeweiligen Aufgabe zu dem, mit dem sich der Entwickler gerade beschäftigt, berücksichtigt werden.
Im Meeting entwickelt der Teamleiter eine allgemeine Strategie für die Architektur und Geschäftslogik. Anschließend diskutiert das gesamte Team dies und trifft die Entscheidung, ob Änderungen vorgenommen oder diese Strategie akzeptiert werden.
Jeder Entwickler schreibt Code und baut Algorithmen selbstständig im Rahmen einer einheitlichen Architektur und Geschäftslogik. Jeder kann seine eigene Vision der Implementierung ausdrücken, aber niemand wird gezwungen, es auf eine bestimmte Weise zu tun. Jede Entscheidung wird argumentiert. Wenn es eine bessere Lösung gibt, aber im Moment keine Zeit dafür ist, wird eine Aufgabe in JIRA erstellt, um künftig einen bestimmten Teil des Codes zu refaktorisieren.
Wenn der Entwickler eine Aufgabe in Arbeit nimmt, ändert er deren Status auf Entwicklung. Die gesamte Kommunikation bezüglich der Klärung der Aufgabe beim Auftraggeber liegt in der Verantwortung des Entwicklers. Technische Fragen können an den Teamleiter oder Kollegen gerichtet werden.
Wenn der Entwickler die Essenz der Aufgabe nicht versteht und der Auftraggeber sie nicht klar erklären konnte, geht er zur nächsten Aufgabe über. Die aktuelle Aufgabe wird vom Teamleiter übernommen, der sie selbst mit dem Auftraggeber bespricht.
Jeden Tag muss der Entwickler im Kunden-Chat schreiben, an welchen Aufgaben er gestern gearbeitet hat und an welchen Aufgaben er heute arbeiten wird.
Der Arbeitsprozess erfolgt nach Scrum. Alles ist in Sprints aufgeteilt. Jeder Sprint dauert zwei Wochen.
Die Sprints werden vom Teamleiter erstellt, gefüllt und abgeschlossen.
Wenn das Projekt strenge Fristen hat, versuchen wir, alle Aufgaben grob zu schätzen. Und wir stellen einen Sprint aus ihnen zusammen. Wenn der Auftraggeber versucht, dem Sprint weitere Aufgaben hinzuzufügen, setzen wir Prioritäten und verschieben einige andere Aufgaben in den nächsten Sprint.

b) Der Prozess der Zusammenarbeit mit dem Auftraggeber

Jeder Entwickler kann und sollte mit dem Auftraggeber kommunizieren.
Dem Auftraggeber darf man nicht erlauben, seine Regeln aufzuzwingen. Man muss höflich und freundlich dem Auftraggeber klarmachen, dass wir Spezialisten auf unserem Gebiet sind und nur wir die Arbeitsprozesse gestalten und den Auftraggeber dabei einbeziehen sollten.
Idealerweise sollte man, bevor man mit der Implementierung einer Funktion beginnt, ein Flussdiagramm des gesamten logischen Prozesses für das Feature (Workflow) erstellen und es dem Auftraggeber zur Bestätigung zusenden. Dies betrifft nur komplexe und nicht offensichtliche Funktionen, beispielsweise Zahlungssysteme, Benachrichtigungssysteme usw. Dies wird helfen, genauer zu verstehen, was der Auftraggeber tatsächlich benötigt, die Dokumentation zum Feature zu bewahren und sich abzusichern, dass der Auftraggeber in Zukunft nicht sagen kann, dass wir nicht das gemacht haben, was er angefordert hat.
Alle Diagramme/-flüsse/-logiken usw. speichern wir in Confluence/Jira, wo wir den Kunden bitten, in den Kommentaren die Richtigkeit der zukünftigen Umsetzung zu bestätigen.
Wir versuchen, den Kunden nicht mit technischen Details zu belasten. Wenn wir ein Verständnis dafür brauchen, was der Kunde möchte, zeichnen wir primitive Algorithmen in Form von Flussdiagrammen, die der Kunde verstehen und selbst anpassen/korrigieren kann.
Wenn der Kunde einen Fehler im Projekt findet, bitten wir ihn, diesen ausführlich in Jira zu beschreiben. Unter welchen Umständen ist der Fehler aufgetreten, wann und welche Abfolge von Aktionen hat der Kunde beim Testen durchgeführt. Wir bitten darum, Screenshots beizufügen.
Wir versuchen, jeden Tag, höchstens alle zwei Tage ein Deployment auf den Development-Server zu machen. Der Kunde kann dann die Funktionalität testen und das Projekt ruht nicht. Dies ist zudem ein Marker für den Kunden, dass das Projekt in vollem Gange ist und ihm niemand Märchen erzählt.
Es kommt häufig vor, dass der Kunde nicht ganz versteht, was er eigentlich benötigt. Da er ein neues Geschäft mit noch nicht eingespielten Prozessen gründet. Daher ist es oft der Fall, dass wir ganze Codeabschnitte in den Papierkorb werfen und die Logik der Anwendung umgestalten. Daraus ergibt sich, dass nicht alles unbedingt abgedeckt werden muss. Es macht Sinn, nur kritisch wichtige Funktionalitäten mit Tests zu versehen und das auch mit Vorbehalten.
Es gibt Situationen, in denen das Team erkennt, dass wir die Deadlines nicht einhalten können. Dann führen wir einen schnellen Audit der Aufgaben durch und informieren sofort den Kunden darüber. Als Lösung schlagen wir vor, die wichtigen und kritischen Funktionalitäten rechtzeitig zu starten und den Rest auf nach der Veröffentlichung zu verschieben.
Wenn der Kunde beginnt, verschiedene Aufgaben aus dem Stegreif zu erfinden, anfängt zu fantasieren und alles mit Gesten zu erklären, bitten wir ihn, uns ein Layout der Seite und den Fluss mit der Logik bereitzustellen, die das Verhalten des gesamten Layouts und seiner Elemente vollständig beschreiben sollte.
Bevor wir eine Aufgabe in Angriff nehmen, müssen wir sicherstellen, dass dieses Feature Bestandteil unseres Vertrags ist. Wenn es sich um ein neues Feature handelt, das über unsere ursprünglichen Vereinbarungen hinausgeht, müssen wir es unbedingt schätzen ((geschätzte Ausführungszeit + 30%) x 2) und dem Kunden mitteilen, dass wir dafür eine bestimmte Zeit benötigen, plus der Termin verschiebt sich auf die geschätzte Zeit multipliziert mit zwei. Wenn wir die Aufgabe schneller erledigen können, umso besser, alle profitieren davon. Wenn nicht, haben wir uns abgesichert.

v) Was wir im Team nicht akzeptieren:

Unzuverlässigkeit, Unordnung, Vergesslichkeit
„Kann nicht“ oder „weiß nicht wie“. Wenn du eine Aufgabe nicht erledigen kannst oder nicht weißt, wie, musst du sofort den Teamleiter informieren, anstatt bis zur letzten Minute zu warten.
Prahlerei und Angeberei von jemandem, der seine Fähigkeiten und Professionalität noch nicht bewiesen hat. Wenn er bewiesen hat, ist es in Ordnung, im Rahmen des Anstands 🙂
Betrug in jeglicher Form. Wenn eine Aufgabe nicht erledigt ist, sollte ihr Status nicht auf erledigt geändert und im Kundensupport-Chat nicht behauptet werden, dass sie fertig ist. Der Computer ist abgestürzt, das System ist ausgefallen, der Hund hat das Laptop angeknabbert – all das ist inakzeptabel. Wenn ein echter Notfall eintritt, muss der Teamleiter sofort informiert werden.
Wenn ein Specialist ständig offline ist und ihn während der Arbeitszeit schwer zu erreichen ist.
Toxizität im Team ist nicht akzeptabel! Wenn jemand mit etwas nicht einverstanden ist, treffen sich alle gemeinsam zu einem Meeting, um dies zu besprechen und zu entscheiden.

Und noch einige Fragen/Thesen, die ich manchmal meinem Kunden stelle, um Missverständnisse auszuräumen:

Welche Qualitätskriterien haben Sie?
Wie erkennen Sie, ob es im Projekt Probleme gibt oder nicht?
Indem Sie all unsere Empfehlungen und Ratschläge zur Änderung/Verbesserung des Systems missachten, tragen Sie alle Risiken allein.
Jede wesentliche Änderung am Projekt (z. B. verschiedene Extraflüsse) kann zu möglichen Fehlern führen (die wir natürlich beheben werden).
Es ist unmöglich, in wenigen Minuten zu erkennen, welches Problem im Projekt aufgetreten ist, geschweige denn, es sofort zu beheben.
Wir arbeiten gemäß einem spezifischen Produktfluss (Tasks in Jira – Entwicklung – Testing – Deployment). Das bedeutet, dass wir nicht auf den gesamten Strom an Anfragen und Beschwerden im Chat reagieren können.
Programmierer sind Programmierer und keine professionellen Tester und können daher nicht die erforderliche Testqualität des Projekts gewährleisten.
Die Verantwortung für das endgültige Testen und die Annahme von Aufgaben im Produktionsumfeld liegt vollständig bei Ihnen.
Wenn wir bereits an einer Aufgabe arbeiten, können wir uns nicht sofort auf andere umschalten, bis die aktuelle abgeschlossen ist (sonst führt das zu noch mehr Bugs und verlängert die Entwicklungszeit).
Die Anzahl der Personen im Team ist geringer geworden (wegen Urlaub oder Krankheit), während die Arbeit zunimmt, und wir können physisch nicht auf alles reagieren, was Sie möchten.
Ihre Bitte, ein Deployment in die Produktion ohne getestete Aufgaben in der Entwicklungsumgebung durchzuführen, bedeutet nur Ihr Risiko und nicht das der Entwickler.
Wenn Sie unklare Aufgaben ohne richtigen Workflow und ohne Designlayouts stellen, erfordert das von uns viel mehr Aufwand und längerfristige Umsetzung, da wir stattdessen zusätzlichen Arbeitsaufwand leisten müssen.
Jede Aufgabe zu Bugs, die ohne detaillierte Beschreibung ihres Auftretens und ohne Screenshots eingereicht wird, gibt uns keine Möglichkeit zu verstehen, was schiefgegangen ist und wie wir diesen Bug reproduzieren können.
Das Projekt erfordert ständige Überarbeitung und Verbesserungen zur Steigerung der Leistung und Sicherheit. Daher investiert das Team einen Teil seiner Zeit in diese Verbesserungen.
Aufgrund von Überstunden (dringende Fixes) müssen wir diese an anderen Tagen ausgleichen.

In der Regel versteht der Kunde sofort, dass die Softwareentwicklung nicht so einfach ist und ein bloßer Wunsch nicht ausreicht.

Das ist alles. Hinter den Kulissen lasse ich zahlreiche Verhandlungen und das erste Debugging aller Prozesse, aber letztlich hat sich alles eingespielt. Ich kann sagen, dass dieser Prozess für uns eine Art 'Silbergeschosse' geworden ist. Neue Leute, die ins Projekt kamen, konnten sofort am ersten Tag mit der Arbeit beginnen, da alle Prozesse dokumentiert sind und die Dokumentation sowie die Architektur in Form von Diagrammen sofort ein Bild davon gab, womit wir uns alle beschäftigen.

P.S. Ich möchte klarstellen, dass es auf unserer Seite keinen Projektmanager gibt. Er befindet sich auf der Seite des Kunden. Ganz und gar kein Techniker. Das Projekt ist europäisch. Die gesamte Kommunikation erfolgt nur auf Englisch.

Ich wünsche allen viel Erfolg bei ihren Projekten. Brennt nicht aus und versucht, eure Prozesse zu verbessern.

Der Originalcode ist in meinem Blog.

Quelle: habr.com

Organisation des Arbeitsprozesses im Team für IT-Projekte