🥇Effiziente Teamarbeit bei IT-Projekten

Hallo zusammen. Immer wieder, besonders im Outsourcing, sehe ich dasselbe Bild. Es fehlt an klaren Arbeitsabläufen in den Teams bei verschiedenen Projekten.

Das Wichtigste ist, dass Programmierer nicht verstehen, wie sie mit dem Auftraggeber und untereinander kommunizieren sollten. Wie man einen kontinuierlichen Entwicklungsprozess für qualitativ hochwertige Produkte aufbaut. Wie man seinen Arbeitstag und die Sprints plant.

Und das alles führt letztendlich zu verfehlten Fristen, Überstunden, ständigen Streitigkeiten darüber, wer schuld ist, und Unzufriedenheit der Auftraggeber — wohin und wie es weitergeht. Dies führt oft dazu, dass Programmierer, manchmal sogar ganze Teams, gewechselt werden. Es geht dabei um den Verlust von Kunden, die Verschlechterung der Reputation und so weiter.

Ich habe damals ein solches Projekt mit all diesen Herausforderungen kennengelernt.

Niemand wollte die Verantwortung für das Projekt (eine große Service-Marktplatz) übernehmen. Die Fluktuation war erschreckend und der Kunde war sehr unzufrieden. Irgendwann kam der CEO zu mir und sagte, dass ich die nötige Erfahrung habe. Also, hier hast du die Karten in die Hand. Nimm das Projekt an. Wenn du scheiterst, schließen wir es und alle werden entlassen. Wenn es klappt, wird es großartig, dann führ es weiter 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 meinem damaligen Verständnis entsprach, und eine Stellenbeschreibung für das Team zu erstellen. Die Umsetzung war nicht einfach. Aber nach etwa einem Monat war alles geregelt, die Entwickler und der Kunde gewöhnten sich daran, und alles lief ruhig und angenehm. Um dem Team zu zeigen, dass es sich nicht nur um „einen Sturm im Wasserglas“ handelt, sondern um eine echte Lösung der Situation, übernahm ich den Großteil der Verantwortung und befreite das Team von unangenehmen Routineaufgaben.

Bereits sind anderthalb Jahre vergangen, und das Projekt entwickelt sich ohne Überstunden, ohne "Rattenrennen" und jeglichen Stress. Einige aus dem alten Team wollten nicht so arbeiten und haben das Team verlassen, während andere sehr erfreut darüber sind, dass es transparente Regeln gibt. Am Ende sind alle, die im Team sind, sehr motiviert und kennen das gesamte große Projekt, sowohl das Frontend als auch das Backend. Das umfasst sowohl den Code als auch die gesamte Geschäftlogik. Es ist sogar so weit gekommen, dass wir nicht nur "Paddler" sind, sondern selber viele Geschäftsprozesse und neue Funktionen entwickeln, die dem Unternehmen gefallen haben.

Dank dieses Ansatzes von unserer Seite hat der Kunde beschlossen, bei uns ein weiteres Marktplatzprojekt zu beauftragen, worüber wir uns sehr freuen.

Da es in 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 Entwicklern)

Alle Aufgaben werden im Jira-System erstellt.
Jede Aufgabe muss maximal beschrieben sein 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 eine gemeinsame Aufgabe. Zuerst entwickeln wir zusammen eine Funktion, geben sie zur Tests und nehmen dann die nächste in Angriff.
Jede Aufgabe wird markiert, entweder für das Backend oder das Frontend.
Es gibt verschiedene Arten von Aufgaben und Bugs. Diese müssen korrekt angegeben werden.
Nach Abschluss der Aufgabe wird sie in den Code-Review-Status versetzt (dabei wird ein Pull-Request für einen Kollegen erstellt).
Derjenige, der die Aufgabe erledigt hat, verfolgt sofort seine Zeit für diese Aufgabe.
Nach der Überprüfung des Codes wird der Pull-Request genehmigt und anschließend führt der Bearbeiter dieser Aufgabe das Mergen in den Master-Zweig selbstständig durch und ändert dann dessen Status auf bereit für das Deployment auf dem Dev-Server. der Server.
Alle Aufgaben, die bereit für das Deployment auf dem Dev-Server sind, werden vom Teamleiter (seine Verantwortung) deployed, manchmal auch von einem Teammitglied, wenn es dringend ist. Nach dem Deployment werden alle Aufgaben, die bereit für das Deployment auf dem Dev sind, in den Status — bereit für Tests auf dem Dev geändert.
Alle Aufgaben werden vom Auftraggeber getestet.
Wenn der Auftraggeber die Aufgabe auf dem Dev getestet hat, wird sie in den Status bereit für das Deployment auf dem Prod versetzt.
Für das Deployment auf dem Prod haben wir einen separaten Branch, in den wir den Master kurz vor dem Deployment mergen.
Wenn der Auftraggeber während der Testphase Fehler findet, returniert er die Aufgabe zur Überarbeitung und setzt den Status auf "Zurück zur Überarbeitung". So trennen wir neue Aufgaben von solchen, die die Tests nicht bestanden haben.
Alle Aufgaben durchlaufen letztendlich den Weg von der Erstellung bis zum Abschluss: To Do → In Entwicklung → Code-Überprüfung → Bereit zum Deployment auf Dev → QA in Dev → (Zurück zu Dev) → Bereit zum Deployment auf Prod → QA in Prod → Fertig.
Jeder Entwickler testet seinen Code selbstständig, einschließlich der Benutzererfahrung auf der Website. Es ist nicht erlaubt, den Branch mit dem Hauptbranch zu verschmelzen, es sei denn, es ist sicher, dass der Code funktioniert.
Jede Aufgabe hat Prioritäten. Diese werden entweder vom Auftraggeber oder vom Teamleiter festgelegt.
Entwickler bearbeiten in erster Linie die priorisierten Aufgaben.
Entwickler können Aufgaben gegenseitig zuweisen, wenn unterschiedliche Fehler im System gefunden wurden oder eine Aufgabe die Arbeit mehrerer Spezialisten umfasst.
Alle Aufgaben, die der Auftraggeber erstellt, gelangen zum Teamleiter, der sie bewertet und entweder den Auftraggeber zur Überarbeitung auffordert oder sie einem der Teammitglieder zuweist.
Alle Aufgaben, die für das Deployment in Dev oder Prod bereit sind, werden auch an den Teamleiter übermittelt, 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. Außerdem müssen die Status der Aufgaben auf 'bereit für Tests' in Dev/Prod geändert werden.
Jeden Tag zur gleichen Zeit (bei uns ist das um 12:00 Uhr) halten wir ein Meeting mit allen Teammitgliedern ab.
Jeder im Meeting berichtet, einschließlich des Teamleiters, was er gestern gemacht hat, was er heute plant und was möglicherweise nicht funktioniert und warum. So ist das gesamte Team informiert, wer woran arbeitet und wo sich das Projekt befindet. Dies ermöglicht es uns, unsere Schätzungen und Termine gegebenenfalls zu prognostizieren und anzupassen.
Im Meeting informiert der Teamleiter auch über alle Änderungen im Projekt und den aktuellen Stand der Bugs, die nicht vom Auftraggeber gefunden wurden. Alle Bugs werden besprochen und jedem Teammitglied zur Behebung zugewiesen.
In der Besprechung weist der Teamleiter jedem Entwickler Aufgaben zu, wobei die aktuelle Auslastung, das Fachwissen der Entwickler und die Nähe der jeweiligen Aufgabe zum aktuellen Tätigkeitsfeld des Entwicklers berücksichtigt werden.
Im Meeting entwickelt der Teamleiter eine gemeinsame Strategie für Architektur und Geschäftslogik. Anschließend wird diese von dem gesamten Team diskutiert, um Entscheidungen über eventuelle Anpassungen oder die Annahme der Strategie zu treffen.
Jeder Entwickler schreibt den Code und erstellt die Algorithmen selbstständig innerhalb einer einheitlichen Architektur und Geschäftslogik. Jeder kann seine Ideen zur Implementierung einbringen, jedoch wird niemand gezwungen, es auf eine bestimmte Weise zu tun. Jede Entscheidung wird begründet. Wenn es eine bessere Lösung gibt, aber derzeit keine Zeit dafür ist, wird eine Aufgabe in JIRA für zukünftige Refactorings eines bestimmten Codeabschnitts erstellt.
Wenn ein Entwickler eine Aufgabe übernimmt, verändert er deren Status auf "In Entwicklung". Alle Kommunikationen zur Klärung der Aufgaben beim Auftraggeber fallen in den Verantwortungsbereich des Entwicklers. Technische Fragen können an den Teamleiter oder Kollegen gerichtet werden.
Wenn der Entwickler die Aufgabe nicht versteht und der Kunde sie nicht klar erklären kann, geht er zur nächsten Aufgabe über. Der Teamleiter übernimmt die aktuelle Aufgabe und bespricht sie selbst mit dem Kunden.
Jeden Tag sollte der Entwickler im Chat des Kunden berichten, an welchen Aufgaben er gestern gearbeitet hat und welche Aufgaben er heute bearbeitet.
Der Arbeitsprozess erfolgt nach Scrum. Alles ist in Sprints unterteilt. 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 daraus einen Sprint zu erstellen. Wenn der Kunde versucht, zusätzliche Aufgaben in den Sprint einzufügen, setzen wir Prioritäten und schieben 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 darf nicht erlaubt werden, seine Spielregeln aufzuzwingen. Es ist wichtig, ihm in höflicher und freundlicher Weise zu verdeutlichen, dass wir die Spezialisten auf unserem Gebiet sind und nur wir die Arbeitsprozesse gestalten und den Kunden dabei einbeziehen sollten.
Im Idealfall sollten Sie, bevor Sie mit der Implementierung einer Funktion beginnen, ein Flussdiagramm für den gesamten logischen Prozess der Funktion (Workflow) erstellen und es zur Genehmigung an den Kunden senden. Dies gilt insbesondere für komplexe und nicht offensichtliche Funktionen, wie zum Beispiel Zahlungssysteme, Benachrichtigungssysteme usw. Dadurch können wir klarer verstehen, was der Kunde benötigt, die Dokumentation der Funktion aufbewahren und uns absichern, dass der Kunde in Zukunft nicht sagen kann, dass wir etwas anderes gemacht haben, als er angefragt hat.
Alle Diagramme / Flussdiagramme / Logik usw. speichern wir in Confluence / Jira, wo wir den Kunden bitten, in den Kommentaren die Richtigkeit der zukünftigen Umsetzung zu bestätigen.
Wir bemühen uns, den Kunden nicht mit technischen Details zu überladen. Wenn wir ein Verständnis dafür brauchen, wie der Kunde es sich wünscht, zeichnen wir einfache Algorithmen in Form von Flussdiagrammen, die der Kunde verstehen kann und selbst Änderungen vornehmen oder Ergänzungen hinzufügen kann.
Wenn der Kunde einen Fehler im Projekt findet, bitten wir ihn, diesen sehr detailliert in Jira zu beschreiben. Unter welchen Umständen ist er aufgetreten, wann, welche Schritte der Kunde während der Tests durchgeführt hat. Wir bitten um das Hinzufügen von Screenshots.
Wir bemühen uns, jeden Tag oder spätestens alle zwei Tage ein Deployment auf den Entwicklungsserver durchzuführen. So kann der Kunde mit dem Testen der Funktionalitäten beginnen und das Projekt steht nicht still. Dies signalisiert dem Kunden, dass sich das Projekt in voller Entwicklung befindet und keine unrealistischen Versprechungen gemacht werden.
Es kommt häufig vor, dass der Kunde nicht genau versteht, was er überhaupt benötigt. Da er ein neues Geschäft aufbaut, sind die Prozesse noch nicht eingespielt. Daher kommt es oft vor, dass wir ganze Codeabschnitte entsorgen und die Logik der Anwendung neu gestalten müssen. Daraus ergibt sich, dass es nicht sinnvoll ist, alles abzudecken. Tests sollten sich nur auf kritisch wichtige Funktionalitäten konzentrieren und das auch mit Einschränkungen.
Es gibt Situationen, in denen das Team erkennt, dass wir die Fristen nicht einhalten können. Daher führen wir eine schnelle Überprüfung der Aufgaben durch und informieren sofort den Kunden darüber. Um die Situation zu verbessern, schlagen wir vor, die wichtigen und kritischen Funktionen rechtzeitig zu starten und den Rest auf nach dem Release zu verschieben.
Wenn der Kunde beginnt, verschiedene Aufgaben aus dem Stegreif zu erfinden, zu fantasieren und diese mit Händen und Füßen zu erklären, bitten wir ihn, uns ein Layout der Seite und einen Flow mit der Logik zur Verfügung zu stellen, die das Verhalten des gesamten Layouts und seiner Elemente vollständig beschreibt.
Bevor wir mit einer Aufgabe beginnen, müssen wir sicherstellen, dass dieses Feature in den Bedingungen unseres Vertrags enthalten war. Wenn es sich um ein neues Feature handelt, das über unsere ursprünglichen Vereinbarungen hinausgeht, müssen wir dieses Feature unbedingt schätzen ((geschätzte Zeit + 30 %) x 2) und dem Kunden mitteilen, dass wir dafür so viel Zeit benötigen, plus der ursprüngliche Frist verlängert sich um die geschätzte Zeit multipliziert mit zwei. Wenn wir die Aufgabe schneller erledigen können, ist das großartig, alle profitieren davon. Wenn nicht, sind wir abgesichert.

c) Was wir im Team nicht akzeptieren:

Unverbindlichkeit, Unorganisiertheit, Vergesslichkeit
„Aufschieberitis“. Wenn Sie eine Aufgabe nicht erfüllen können oder nicht wissen, wie, sollten Sie umgehend den Teamleiter informieren und nicht bis zur letzten Minute warten.
Angeben und Prahlen von jemandem, der seine Fähigkeiten und Professionalität noch nicht unter Beweis gestellt hat. Wenn er es bewiesen hat, ist es im Rahmen des Anstands in Ordnung 🙂
Betrug in jeglicher Form. Wenn eine Aufgabe nicht abgeschlossen ist, sollte der Status nicht auf „erledigt“ geändert werden und im Chat des Kunden sollte nicht stehen, dass sie bereit ist. Der Computer ist abgestürzt, das System hat versagt, der Hund hat den Laptop zerbissen – all das ist inakzeptabel. Wenn ein wirklicher Notfall eintritt, muss der Teamleiter sofort informiert werden.
Wenn der Spezialist ständig offline ist und während der Arbeitszeit schwer zu erreichen ist.
Toxizität im Team ist nicht akzeptabel! Wenn jemand mit etwas nicht einverstanden ist, sollten alle zusammen ein Meeting einberufen, um das zu diskutieren und zu lösen.

Und noch einige weitere Fragen/Thesen, die ich ab und zu meinem Kunden stelle, um Missverständnisse auszuräumen:

Welche Qualitätskriterien haben Sie?
Wie erkennen Sie, ob es im Projekt Probleme gibt oder nicht?
Wenn Sie gegen all unsere Empfehlungen und Ratschläge zur Verbesserung des Systems verstoßen, tragen Sie alle Risiken selbst.
Jede wesentliche Veränderung des Projekts (z. B. verschiedene Extaflows) kann zu Bugs führen, die wir selbstverständlich beheben werden.
Es ist nicht möglich, innerhalb weniger Minuten zu verstehen, was für ein Problem im Projekt aufgetreten ist, geschweige denn, es sofort zu beheben.
Wir arbeiten nach einem festgelegten Produktfluss (Tasks in Jira – Entwicklung – Testing – Deployment). Das bedeutet, dass wir nicht auf den gesamten Strom von Anfragen und Beschwerden im Chat reagieren können.
Die Programmierer sind Programmierer und keine professionellen Tester und können daher keine angemessene Qualität bei der Testung des Projekts gewährleisten.
Die Verantwortung für die endgültige Testung und Abnahme der Aufgaben in der Produktion liegt vollständig bei Ihnen.
Wenn wir eine Aufgabe bereits in Bearbeitung haben, können wir nicht sofort auf andere umschalten, bis die aktuelle abgeschlossen ist (ansonsten führt das zu noch mehr Bugs und einer Verlängerung der Entwicklungszeit).
Die Anzahl der Personen im Team ist gesunken (aufgrund von Urlauben oder Krankheiten), während die Arbeit zugenommen hat, sodass wir physisch nicht auf alles reagieren können, was Sie wünschen.
Die Bitte, ein Deployment auf die Produktionsumgebung ohne getestete Aufgaben in der Entwicklungsumgebung durchzuführen, birgt ausschließlich Ihre Risiken und nicht die der Entwickler.
Wenn Sie unklare Aufgaben ohne einen korrekten Ablauf und ohne Designmockups festlegen, erfordert das von uns erheblich mehr Aufwand und längere Umsetzungszeiten, da wir anstelle von Ihnen zusätzlichen Arbeitsaufwand leisten müssen.
Jegliche Aufgaben zu Bugs ohne detaillierte Beschreibungen ihrer Entstehung und Screenshots ermöglichen es uns nicht, zu verstehen, was schiefgelaufen ist und wie wir diesen Bug reproduzieren können.
Das Projekt erfordert ständige Verbesserungen und Anpassungen zur Steigerung der Leistungsfähigkeit und Sicherheit. Daher investiert das Team einen Teil seiner Zeit in diese Optimierungen.
Da wir manchmal Überstunden für dringende Fixes haben, müssen wir diese an anderen Tagen ausgleichen.

In der Regel erkennt der Auftraggeber sofort, dass die Softwareentwicklung nicht so einfach ist und dass der bloße Wille nicht ausreicht.

Im Grunde ist das alles. Hinter den Kulissen lasse ich viele Gespräche und die anfängliche Feinabstimmung aller Prozesse außen vor, aber letztendlich hat sich alles eingependelt. Ich kann sagen, dass dieser Prozess für uns eine Art „Silberne Kugel“ geworden ist. Neue Mitarbeiter, die zum Projekt kommen, können sofort ab dem ersten Tag durchstarten, da alle Prozesse dokumentiert sind und die Architektur in Form von Diagrammen eine klare Vorstellung davon vermittelt, woran wir hier alle arbeiten.

P.S. Ich möchte klarstellen, dass wir keinen Projektmanager auf unserer Seite haben. Er ist auf der Seite des Kunden. Völlig kein Techniker. Das Projekt ist europäisch. Alle Kommunikation läuft ausschließlich auf Englisch.

Viel Erfolg bei euren Projekten. Lasst euch nicht ausbrennen und versucht, eure Prozesse zu verbessern.

Der Quellcode ist in meinem Blog.

Quelle: habr.com

Organisation des Arbeitsablaufs im Team bei IT-Projekten