🥇 Organizacja pracy zespołowej w projekcie IT

Cześć, przyjaciele. Często, zwłaszcza w outsourcingu, widzę ten sam obrazek. Brak wyraźnego procesu roboczego w zespołach na różnych projektach.

Najważniejsze jest to, że programiści nie rozumieją, jak komunikować się z klientem i ze sobą nawzajem. Jak zbudować ciągły proces tworzenia wysokiej jakości produktu. Jak zaplanować swój dzień pracy i sprinty.

Wszystko to ostatecznie prowadzi do nietrzymania terminów, nadgodzin, ciągłych konfliktów o to, kto jest winny, oraz niezadowolenia klientów – dokąd i jak to wszystko idzie. Dosyć często prowadzi to do zmian wśród programistów, a nawet całych zespołów. Utraty klienta, pogorszenia reputacji i tym podobnych spraw.

Kiedyś natrafiłem na taki projekt, gdzie występowały wszystkie te niedogodności.

Nikt nie chciał wziąć odpowiedzialności za projekt (duża usługa marketplace), rotacja była straszna, klient po prostu wściekał się. CEO podszedł do mnie i powiedział, że masz odpowiednie doświadczenie, więc oto masz karty w ręce. Weź projekt dla siebie. Jeśli zawalisz, zamkniemy projekt i wszystkich wyrzucimy. Jeśli się uda, będzie świetnie, wtedy prowadź go i rozwijaj, jak uważasz za stosowne. W końcu zostałem liderem zespołu w tym projekcie i wszystko spadło na moje ramiona.

Pierwszą rzeczą, którą zrobiłem, było opracowanie procesu roboczego od podstaw, który odpowiadał mojemu widzeniu na tamten moment, i napisanie opisu stanowiska dla zespołu. Wdrażanie go nie było łatwe. Ale po około miesiącu wszystko się ustabilizowało, programiści i klient się przyzwyczaili, i wszystko zaczęło iść gładko i komfortowo. Aby pokazać zespołowi, że to nie jest tylko 'burza w szklance wody', ale realne rozwiązanie, wziąłem na siebie maksymalną ilość obowiązków, zdjęły dręczące rutyny z zespołu.

Minęło już półtora roku, a projekt rozwija się bez nadgodzin, bez 'wyścigów szczurów' i wszelkich stresów. Ktoś ze starego zespołu nie chciał tak pracować i odszedł, a dla innych było świetnie, że pojawiły się przejrzyste zasady. Ale ostatecznie wszyscy w zespole są bardzo zmotywowani i znają ogromny projekt w całości, zarówno frontend, jak i backend. Włącznie z bazą kodu i całą logiką biznesową. Doszło już do tego, że nie jesteśmy tylko 'wioślarzami', ale sami wymyślamy wiele procesów biznesowych i nowych funkcji, które przypadły do gustu biznesowi.

Dzięki takiemu podejściu z naszej strony, klient postanowił zamówić u naszej firmy jeszcze jeden marketplace, co bardzo cieszy.

Ponieważ w moim projekcie to działa, może komuś to również pomoże. Oto proces, który pomógł nam uratować projekt:

Proces pracy zespołu nad projektem 'Mój ulubiony projekt'

a) Wewnątrz proces zespołowy (między programistami)

Wszystkie zadania są tworzone w systemie Jira.
Każde zadanie powinno być maksymalnie opisane i wykonywać jedno konkretne działanie.
Każda funkcja, jeśli jest wystarczająco skomplikowana, dzieli się na wiele małych zadań.
Zespół pracuje nad funkcjami jako nad jedną całością. Na początku robimy wszystko razem w jednej funkcji, oddajemy ją do testów, a następnie bierzemy następną.
Każde zadanie jest oznaczane, czy jest to backend czy frontend.
Istnieją typy zadań i błędów. Należy je poprawnie oznaczać.
Po wykonaniu zadania, jest ono przenoszone do statusu przeglądu kodu (tworzony jest pull request do kolegi).
Osoba, która wykonała zadanie, natychmiast śledzi swój czas dla tego zadania.
Po sprawdzeniu kodu, PR jest zatwierdzany, a następnie osoba, która wykonała to zadanie, samodzielnie łączy je z gałęzią master, po czym zmienia status na gotowe do wdrożenia na dev. serwer.
Wszystkie zadania gotowe do wdrożenia na serwer dev są wdrażane przez lidera zespołu (to jego strefa odpowiedzialności), czasami przez członka zespołu, jeśli coś jest pilne. Po wdrożeniu wszystkie zadania gotowe do wdrożenia na dev przechodzą w status — gotowe do testów na dev.
Wszystkie zadania testuje klient.
Gdy klient przetestował zadanie na dev, przenosi je do statusu gotowe do wdrożenia na prod.
Do wdrożenia na prod mamy osobną gałąź, do której łączymy master tylko przed wdrożeniem.
Jeśli podczas testowania klient znajdzie błędy, zwraca zadanie do przeróbki, nadając mu status zwrócone do przeróbki. W ten sposób oddzielamy nowe zadania od tych, które nie przeszły testów.
W rezultacie wszystkie zadania przechodzą drogę od stworzenia do zakończenia: To Do → W Rozwoju → Przegląd Kodu → Gotowe do wdrożenia na dev → QA na dev → (Powrót do dev) → Gotowe do wdrożenia na prod → QA na prod → Zrobione.
Każdy programista testuje swój kod samodzielnie, także jako użytkownik strony. Nie jest dozwolone łączenie gałęzi z główną, jeśli nie wiadomo na pewno, że kod działa.
Każde zadanie ma swoje priorytety. Priorytety ustala zleceniodawca lub lider zespołu.
Programiści w pierwszej kolejności realizują priorytetowe zadania.
Programiści mogą przydzielać zadania sobie nawzajem, jeśli w systemie znalazły się różne błędy lub jedno zadanie składa się z pracy kilku specjalistów.
Wszystkie zadania, które tworzy zleceniodawca, trafiają do lidera zespołu, który je ocenia i albo prosi zleceniodawcę o poprawki, albo przydziela je jednemu z członków zespołu.
Wszystkie zadania, które są gotowe do wdrożenia na etapie dewelopmentu lub produkcji, również trafiają do lidera zespołu, który samodzielnie decyduje, kiedy i jak przeprowadzić wdrożenie. Po każdym wdrożeniu lider zespołu (lub członek zespołu) musi powiadomić zleceniodawcę o tym. Musi także zmienić statusy zadań na gotowe do testowania na etapie dewelopmentu/produkcji.
Każdego dnia o tej samej porze (u nas o 12:00) przeprowadzamy spotkanie z wszystkimi członkami zespołu.
Na spotkaniu każdy z uczestników, w tym lider zespołu, relacjonuje, co zrobił wczoraj, co planuje zrobić dzisiaj oraz co mu nie wychodzi i dlaczego. W ten sposób cały zespół jest na bieżąco z tym, kto czym się zajmuje i na jakim etapie znajduje się projekt. To daje nam możliwość prognozowania i korekty, jeśli to konieczne, naszych szacunków i terminów.
Na spotkaniu lider zespołu informuje także o wszelkich zmianach w projekcie oraz o poziomie bieżących błędów, które nie zostały zgłoszone przez zleceniodawcę. Wszystkie błędy są analizowane i przydzielane każdemu członkowi zespołu do rozwiązania.
Na spotkaniu lider zespołu przydziela zadania, biorąc pod uwagę bieżące obciążenie programistów, poziom ich umiejętności oraz bliskość danego zadania do tego, czym zajmuje się programista w danym momencie.
Na spotkaniu lider zespołu opracowuje ogólną strategię dotyczącą architektury i logiki biznesowej. Po tym cała drużyna dyskutuje o tym i podejmuje decyzję o wprowadzeniu poprawek lub przyjęciu danej strategii.
Każdy programista pisze kod i buduje algorytmy samodzielnie w ramach jednej architektury i logiki biznesowej. Każdy może wyrazić swoją wizję realizacji, ale nikt nie jest zmuszony do robienia tego w określony sposób. Każde rozwiązanie jest uzasadnione. Jeśli istnieje lepsze rozwiązanie, ale obecnie nie ma na nie czasu, tworzy się zadanie w JIRA na przyszły refactoring określonej części kodu.
Kiedy programista podejmuje się zadania, zmienia jego status na 'w trakcie rozwoju'. Cała komunikacja dotycząca wyjaśnienia zadania z klientem spoczywa na programiście. Pytania techniczne można zadawać liderowi zespołu lub kolegom.
Jeśli programiście nie jest jasne, na czym polega zadanie, a klient nie umiał go wyraźnie wyjaśnić, przechodzi do następnego zadania. Obecne zadanie przejmuje lider zespołu i sam omawia je z klientem.
Każdego dnia programista powinien na czacie klienta informować, nad jakimi zadaniami pracował wczoraj i nad jakimi zadaniami będzie pracować dziś.
Proces pracy odbywa się zgodnie z metodyką Scrum. Wszystko jest podzielone na sprinty. Każdy sprint trwa dwa tygodnie.
Sprinty tworzy, wypełnia i zamyka lider zespołu.
Jeśli projekt ma surowe terminy, staramy się mniej więcej oszacować wszystkie zadania. I zbieramy z nich sprint. Jeśli klient stara się dodać jeszcze zadania do sprintu, wówczas ustalamy priorytety i niektóre inne zadania przesuwamy na następny sprint.

b) Proces pracy z klientem

Każdy programista może i powinien komunikować się z klientem.
Nie można pozwolić klientowi narzucać swoich zasad działania. Należy w uprzejmy i przyjazny sposób dać klientowi do zrozumienia, że jesteśmy specjalistami w swojej dziedzinie i to my powinniśmy ustalać procesy pracy, angażując w nie klienta.
W idealnym przypadku, zanim przystąpimy do realizacji jakiejkolwiek funkcjonalności, należy stworzyć schemat blokowy całego procesu logicznego dla funkcji (workflow). I wysłać go do akceptacji klienta. Dotyczy to tylko skomplikowanej i nieoczywistej funkcjonalności, na przykład systemu płatności, systemu powiadomień itd. To pozwoli dokładniej zrozumieć, czego dokładnie potrzebuje klient, zachować dokumentację dla funkcji, a także zabezpieczyć się przed tym, że klient w przyszłości może powiedzieć, że zrobiliśmy coś innego niż to, co prosił.
Wszystkie diagramy/diagramy blokowe/logikę itp. zapisujemy w Confluence/Jira, gdzie prosimy klienta o potwierdzenie w komentarzach poprawności przyszłej realizacji.
Starajmy się nie obciążać klienta technicznymi szczegółami. Jeśli potrzebujemy zrozumieć, jak klient to sobie wyobraża, rysujemy prymitywne algorytmy w formie diagramu blokowego, który klient może zrozumieć i samodzielnie poprawić/dopracować.
Jeśli klient znajdzie błąd w projekcie, prosimy go o bardzo szczegółowe opisanie go w Jira. W jakich okolicznościach wystąpił, kiedy, jaką sekwencję działań wykonywał klient podczas testowania. Prosimy o dołączenie zrzutów ekranu.
Staramy się codziennie, maksymalnie co drugi dzień, wdrażać na serwer deweloperski. Wtedy klient zaczyna testować funkcjonalność i projekt nie stoi w miejscu. Daje to również klientowi znak, że projekt jest w pełnym rozwinięciu i nikt nie opowiada mu bajek.
Bardzo często bywa tak, że klient nie do końca rozumie, czego tak naprawdę potrzebuje. Z racji tego, że tworzy nowy biznes z jeszcze nieustalonymi procesami. Dlatego bardzo często zdarza się sytuacja, gdy wyrzucamy całe kawałki kodu do kosza i przekształcamy logikę aplikacji. Z tego wynika, że nie ma sensu pokrywać testami wszystkiego. Warto testować tylko krytycznie ważną funkcjonalność, i to z zastrzeżeniami.
Zdarzają się sytuacje, gdy zespół zdaje sobie sprawę, że nie mieszczą się w terminach. Wtedy przeprowadzamy szybką ocenę zadań i od razu informujemy o tym klienta. Jako wyjście z sytuacji proponujemy wdrażać na czas ważną i krytyczną funkcjonalność, a resztę zostawić na czas po wydaniu.
Jeśli klient zaczyna wymyślać różne zadania z głowy, zaczyna fantazjować i tłumaczyć na palcach, to prosimy go o dostarczenie nam projektu strony oraz flow z logiką, która powinna dokładnie opisać działanie całego projektu i jego elementów.
Przed rozpoczęciem jakiegokolwiek zadania musimy upewnić się, że ta funkcja była częścią warunków naszej umowy. Jeśli to nowa funkcja, która wychodzi poza nasze pierwotne ustalenia, musimy ją oszacować ((przybliżony czas realizacji + 30%) x 2) i poinformować klienta, że zajmie nam to tyle czasu, plus termin zostanie przesunięty o czas oszacowania pomnożony przez dwa. Jeśli uda nam się wykonać zadanie szybciej — świetnie, wszyscy na tym skorzystają. Jeśli nie, to mamy zabezpieczenie.

c) Co jest niedopuszczalne w zespole:

Niezobowiązujący stosunek, brak organizacji, zapominalstwo
Odkładanie zadań na później. Jeśli nie możesz wykonać zadania, nie wiesz jak, musisz natychmiast poinformować lidera zespołu, a nie czekać do ostatniej chwili.
Chwalenie się przez osobę, która jeszcze nie udowodniła swoimi działaniami swoich umiejętności i profesjonalizmu. Jeśli udowodniła, to można, w granicach przyzwoitości 🙂
Oszustwo w jakiejkolwiek formie. Jeśli zadanie nie zostało wykonane, nie należy zmieniać jego statusu na zrealizowane i pisać w czacie klienta, że jest gotowe. Wypadł komputer, padł system, pies pogryzł laptopa — to wszystko jest niedopuszczalne. Jeśli występuje faktyczny przypadek siły wyższej, lider zespołu powinien być niezwłocznie powiadomiony.
Gdy specjalista cały czas jest offline i trudno się do niego dostać w godzinach pracy.
Toksyczność w zespole jest niedopuszczalna! Jeśli ktoś z czymś się nie zgadza, wszyscy razem zbierają się na spotkanie, aby to omówić i rozwiązać.

I jeszcze szereg pytań/tez, które czasami zadaję swojemu klientowi, aby rozwiać wszelkie wątpliwości:

Jakie są Państwa kryteria jakości?
Jak określają Państwo, czy w projekcie są problemy, czy nie?
Łamiąc wszystkie nasze zalecenia i porady dotyczące zmiany/poprawy systemu, wszystkie ryzyka ponosicie Państwo.
Jakiekolwiek poważne zmiany w projekcie (na przykład różne przepływy zewnętrzne) będą prowadzić do potencjalnego pojawienia się błędów (które będziemy oczywiście naprawiać).
Nie można w ciągu kilku minut zrozumieć, co się stało w projekcie, a tym bardziej od razu to naprawić.
Pracujemy zgodnie z konkretnym przepływem produktu (Zadania w Jira — Rozwój — Testowanie — Wdrażanie). Oznacza to, że nie możemy reagować na cały strumień próśb i skarg na czacie.
Programiści są programistami, a nie profesjonalnymi testerami, i nie mogą zapewnić odpowiedniej jakości testowania projektu.
Odpowiedzialność za ostateczne testowanie i akceptację zadań na produkcji spoczywa w całości na was.
Jeżeli już wzięliśmy zadanie do realizacji, to nie możemy od razu przełączać się na inne, dopóki nie ukończymy bieżącego (w przeciwnym razie prowadzi to do jeszcze większej liczby błędów i wydłużenia czasu realizacji).
Liczba osób w zespole zmniejszyła się (z powodu urlopów lub chorób), a pracy przybyło i fizycznie nie jesteśmy w stanie zareagować na wszystko, czego chcecie.
Prośba z waszej strony o wdrożenie na produkcję bez przetestowanych zadań na devie to tylko wasze ryzyko, a nie programistów.
Kiedy stawiacie niejasne zadania, bez poprawnego przepływu, bez szablonów graficznych, wymaga to od nas znacznie większych wysiłków i wydłuża czas realizacji, gdyż zamiast was musimy wykonać dodatkową pracę.
Jakiekolwiek zadania dotyczące błędów, bez szczegółowego opisu ich wystąpienia i zrzutów ekranu, nie dają nam możliwości zrozumienia, co poszło nie tak i jak możemy odtworzyć ten błąd.
Projekt wymaga ciągłych poprawek i ulepszeń w celu zwiększenia wydajności i bezpieczeństwa. Dlatego zespół poświęca część swojego czasu na te poprawki.
Z powodu tego, że mamy nadgodziny (pilne poprawki), musimy je zrekompensować w inne dni.

Zazwyczaj klient od razu rozumie, że nie wszystko jest takie proste w rozwoju oprogramowania, i jedno pragnienie jest zdecydowanie niewystarczające.

To wszystko. Za kulisami pozostawiam wiele negocjacji i początkowe dostosowanie wszystkich procesów, ale w rezultacie wszystko się ustabilizowało. Mogę powiedzieć, że ten proces stał się dla nas swoistą 'srebrną kulą'. Nowe osoby, które przychodziły do projektu, mogły od razu z dnia na dzień zaangażować się w pracę, gdyż wszystkie procesy zostały opisane, a dokumentacja i architektura w formie diagramu od razu dały wyobrażenie o tym, czym się zajmujemy.

P. S. Chcę wyjaśnić, że po naszej stronie nie ma menedżera projektu. Jest on po stronie klienta. Zupełnie nie techniczny. Projekt jest europejski. Cała komunikacja odbywa się wyłącznie po angielsku.

Wszystkim życzę powodzenia w projektach. Nie wypalajcie się i postarajcie się udoskonalać swoje procesy.

Kod źródłowy w moim blogu.

Źródło: habr.com