Cześć przyjaciele. Dość często, zwłaszcza w outsourcingu, widzę ten sam obraz. Brak jasnego przepływu pracy w zespołach nad różnymi projektami.
Najważniejsze jest to, że programiści nie rozumieją, jak komunikować się z klientem i między sobą. Jak zbudować ciągły proces rozwoju produktu wysokiej jakości. Jak planować swój dzień pracy i sprinty.
A wszystko to ostatecznie skutkuje niedotrzymaniem terminów, nadgodzinami, ciągłymi sporami o to, kto jest winny i niezadowoleniem klientów - gdzie i jak wszystko się dzieje. Dość często wszystko to prowadzi do zmiany programistów, a nawet całych zespołów. Utrata klienta, pogorszenie reputacji i tak dalej.
Kiedyś właśnie wszedłem na taki projekt, w którym były te wszystkie pyszności.
Nikt nie chciał wziąć odpowiedzialności za projekt (duża giełda usług), obroty były fatalne, klient po prostu rwał i metal. Prezes w jakiś sposób podszedł do mnie i powiedział, że masz niezbędne doświadczenie, więc masz karty w swoich rękach. Weź projekt dla siebie. Jeśli schrzanisz, zamkniemy projekt i wszystkich wyrzucimy. Okaże się, że będzie spoko, to poprowadź to i rozwijaj według własnego uznania. W rezultacie zostałem liderem zespołu nad projektem i wszystko spadło na moje barki.
Pierwszą rzeczą, którą zrobiłem, było zaprojektowanie od podstaw przepływu pracy, który pasował do mojej ówczesnej wizji i napisanie opisu stanowiska dla zespołu. Wdrożenie go nie było łatwe. Ale gdzieś w ciągu miesiąca wszystko się uspokoiło, programiści i klient przyzwyczaili się do tego i wszystko poszło cicho i komfortowo. Aby pokazać zespołowi, że to nie tylko burza w szkle, ale realne wyjście z sytuacji, wziąłem na siebie maksymalną ilość obowiązków, usuwając z zespołu nieprzyjemną rutynę.
Minęło już półtora roku, a projekt rozwija się bez nadgodzin, bez „wyścigów szczurów” i wszelkiego rodzaju stresów. Ktoś w starym zespole nie chciał tak pracować i odszedł, wręcz przeciwnie, ktoś bardzo się w to wkręcił, że pojawiły się przejrzyste zasady. Ale w rezultacie wszyscy w zespole są bardzo zmotywowani i w pełni znają ten ogromny projekt, zarówno od strony front-end, jak i back-end. Obejmuje zarówno bazę kodu, jak i całą logikę biznesową. Doszło nawet do tego, że nie jesteśmy tylko „wioślarzami”, ale sami wymyślamy wiele procesów biznesowych i nowych funkcji, które biznes lubi.
Dzięki takiemu podejściu z naszej strony klient zdecydował się zamówić u nas kolejny marketplace, co jest dobrą wiadomością.
Ponieważ działa to w moim projekcie, może komuś też pomoże. A więc sam proces, który pomógł nam uratować projekt:
Proces pracy zespołowej nad projektem „Mój ulubiony projekt”
a) W ramach procesu zespołowego (między programistami)
- Wszystkie zadania tworzone są w systemie Jira
- Każde zadanie powinno być opisane jak najdokładniej i wykonać ściśle jedną czynność.
- Każda funkcja, jeśli jest wystarczająco złożona, jest podzielona na wiele małych zadań
- Zespół pracuje nad funkcjami jako pojedynczym zadaniem. Najpierw robimy wspólnie jedną cechę, oddajemy ją do testów, a potem bierzemy się za następną.
- Każde zadanie jest oznaczone jako backend lub frontend
- Istnieją rodzaje zadań i błędów. Musisz je poprawnie określić.
- Po wykonaniu zadania przechodzi ono do stanu code review (tworzony jest pull request dla jego współpracownika)
- Ten, kto wykonał zadanie, natychmiast śledzi swój czas na to zadanie
- Po sprawdzeniu kodu PR jest zatwierdzany, po czym osoba, która wykonała to zadanie samodzielnie scala go z gałęzią master, po czym zmienia swój status na gotowy do wdrożenia na dev server.
- Wszystkie zadania gotowe do wdrożenia na serwer dev są wdrażane przez lidera zespołu (jego obszar odpowiedzialności), czasami członka zespołu, jeśli coś jest pilne. Po wdrożeniu wszystkie zadania od gotowego do wdrożenia do dev są przenoszone do stanu - gotowe do testowania na dev
- Wszystkie zadania są testowane przez klienta
- Kiedy klient przetestował zadanie na deweloperze, przenosi je do stanu gotowego do wdrożenia na produkcję.
- Do wdrożenia na produkcję mamy oddzielny oddział, w którym łączymy master tuż przed wdrożeniem
- Jeśli podczas testowania klient znajdzie błędy, to zwraca zadanie do sprawdzenia, ustawiając jego status zwrócone do sprawdzenia. W ten sposób oddzielamy nowe zadania od tych, które nie zostały przetestowane.
- W rezultacie wszystkie zadania przechodzą od stworzenia do ukończenia: Do zrobienia → W trakcie opracowywania → Przegląd kodu → Gotowe wdrożenie do dewelopera → Kontrola jakości na deweloperze → (Powrót do dewelopera) → Gotowe wdrożenie do prod → Kontrola jakości na prod → Gotowe
- Każdy programista samodzielnie testuje swój kod, w tym jako użytkownik serwisu. Niedozwolone jest łączenie oddziału z głównym, chyba że wiadomo na pewno, że kod działa.
- Każde zadanie ma priorytety. Priorytety są ustalane przez klienta lub lidera zespołu.
- Deweloperzy najpierw wykonują zadania priorytetowe.
- Deweloperzy mogą przydzielać sobie zadania, jeśli w systemie zostały znalezione różne błędy lub jedno zadanie składa się z pracy kilku specjalistów.
- Wszystkie zadania, które tworzy klient, są wysyłane do lidera zespołu, który je ocenia i albo prosi klienta o ich sfinalizowanie, albo przypisuje je jednemu z członków zespołu.
- Wszystkie zadania, które są gotowe do wdrożenia do dev lub prod, trafiają również do lidera zespołu, który samodzielnie określa, kiedy i jak wdrożyć. Po każdym wdrożeniu lider zespołu (lub członek zespołu) musi o tym powiadomić klienta. A także zmień statusy zadań na gotowe do testowania na dev / prod.
- Codziennie o tej samej porze (u nas o 12.00) odbywa się wiec pomiędzy wszystkimi członkami zespołu
- Wszyscy na rajdzie relacjonują, łącznie z liderem zespołu, co robił wczoraj, co planuje zrobić dzisiaj. Co nie działa i dlaczego. Dzięki temu cały zespół wie, kto co robi i na jakim etapie jest projekt. Daje nam to możliwość przewidywania i korygowania w razie potrzeby naszych szacunków i terminów.
- Na spotkaniu lider zespołu informuje również o wszystkich zmianach w projekcie oraz poziomie aktualnych błędów, których klient nie znalazł. Wszystkie błędy są sortowane i przydzielane każdemu członkowi zespołu w celu ich rozwiązania.
- Na wiecu lider zespołu przydziela każdemu zadania, biorąc pod uwagę aktualne obciążenie programistów, poziom ich wyszkolenia zawodowego, a także biorąc pod uwagę bliskość danego zadania do tego, czym aktualnie zajmuje się programista.
- Na spotkaniu lider zespołu opracowuje ogólną strategię dotyczącą architektury i logiki biznesowej. Następnie cały zespół omawia to i decyduje, czy wprowadzić poprawki, czy przyjąć tę strategię.
- Każdy programista niezależnie pisze kod i buduje algorytmy w ramach jednej architektury i logiki biznesowej. Każdy może wyrazić swoją wizję realizacji, ale nikt nikogo nie zmusza do robienia tego w taki, a nie inny sposób. Każda decyzja jest uzasadniona. Jeśli istnieje lepsze rozwiązanie, ale teraz nie ma na to czasu, to w fat tworzy się zadanie do przyszłej refaktoryzacji określonej części kodu.
- Gdy programista podejmuje się zadania, przenosi je do stanu deweloperskiego. Cała komunikacja dotycząca wyjaśnienia zadania z klientem spada na barki dewelopera. Pytania techniczne można zadawać kierownikowi zespołu lub współpracownikom.
- Jeśli deweloper nie rozumie istoty zadania, a klient nie potrafił tego sensownie wytłumaczyć, to przechodzi do następnego zadania. A lider zespołu bierze aktualny i omawia go z klientem.
- Deweloper powinien codziennie pisać na czacie klienta, nad jakimi zadaniami pracował wczoraj i nad jakimi zadaniami będzie pracował dzisiaj
- Przepływ pracy oparty jest na Scrumie. Wszystko podzielone jest na sprinty. Każdy sprint trwa dwa tygodnie.
- Sprinty są tworzone, wypełniane i zamykane przez lidera zespołu.
- Jeśli projekt ma ściśle określone terminy, wtedy staramy się z grubsza oszacować wszystkie zadania. I zbieramy od nich sprint. Jeśli klient próbuje dodać więcej zadań do sprintu, ustalamy priorytety i przenosimy niektóre inne zadania do następnego sprintu.
b) Proces pracy z klientem
- Każdy programista może i powinien komunikować się z klientem
- Nie można pozwolić klientowi na narzucenie własnych reguł gry. Należy w grzeczny i przyjazny sposób wyjaśnić klientowi, że jesteśmy specjalistami w swojej dziedzinie i tylko my powinniśmy budować procesy pracy i angażować w nie klienta
- Najlepiej przed przystąpieniem do implementacji jakiejkolwiek funkcjonalności stworzyć schemat całego procesu logicznego dla danej cechy (workflow). I wyślij go do klienta w celu potwierdzenia. Dotyczy to tylko skomplikowanych i nieoczywistych funkcjonalności, na przykład systemu płatności, systemu powiadomień itp. Pozwoli to dokładniej zrozumieć, czego dokładnie potrzebuje klient, zapisać dokumentację dla danej funkcji, a także zabezpieczyć się przed tym, że klient może w przyszłości powiedzieć, że nie zrobiliśmy tego, o co prosił.
- Wszystkie diagramy/schematy blokowe/logika itp. zapisujemy w Confluence/Fat, gdzie prosimy klienta w komentarzach o potwierdzenie poprawności przyszłej implementacji.
- Staramy się nie obciążać klienta szczegółami technicznymi. Jeśli potrzebujemy zrozumienia, jak chce klient, wówczas rysujemy prymitywne algorytmy w postaci schematu blokowego, który klient może zrozumieć i sam wszystko naprawić/zmodyfikować.
- Jeśli klient znajdzie błąd w projekcie, prosimy o bardzo szczegółowe opisanie go w Fat. W jakich okolicznościach to nastąpiło, kiedy, jaką sekwencję działań wykonał klient podczas testowania. Proszę dołączyć zrzuty ekranu.
- Staramy się codziennie, maksymalnie co drugi dzień, wdrażać na serwerze dev. Następnie klient rozpoczyna testowanie funkcjonalności, a projekt nie stoi w miejscu. Jednocześnie jest to dla klienta wyznacznikiem, że projekt jest w fazie pełnego rozwoju i nikt mu bajek nie opowiada.
- Często zdarza się, że klient nie do końca rozumie, czego potrzebuje. Ponieważ tworzy dla siebie nowy biznes z procesami, które nie zostały jeszcze debugowane. Dlatego bardzo częstym przypadkiem jest wyrzucanie do kosza całych fragmentów kodu i przekształcanie logiki aplikacji. Wynika z tego, że nie trzeba absolutnie wszystkiego pokrywać testami. Sensowne jest objęcie testami tylko krytycznej funkcjonalności, a następnie zastrzeżeniami.
- Bywają sytuacje, kiedy zespół zdaje sobie sprawę, że nie dotrzymujemy terminów. Następnie przeprowadzamy szybki audyt zadań i od razu informujemy o tym klienta. Jako wyjście z sytuacji sugerujemy terminowe uruchamianie ważnych i krytycznych funkcjonalności, a resztę zostawiamy na później.
- Jeśli klient zaczyna wymyślać sobie różne zadania z głowy, zaczyna fantazjować i tłumaczyć na palcach, to prosimy go o dostarczenie układu strony i przepływu z logiką, która powinna w pełni opisywać zachowanie całego układu i jego elementy.
- Zanim podejmiemy się jakiegokolwiek zadania, musimy upewnić się, że taka funkcja została uwzględniona w warunkach naszej umowy/kontraktu. Jeśli jest to nowa cecha, która wykracza poza nasze wstępne ustalenia, to musimy zdecydowanie oszacować tę cechę ((przybliżony czas realizacji + 30%) x 2) i wskazać klientowi, że wykonanie jej zajmie nam tyle czasu, plus termin zostaje przesunięty o szacowany czas pomnożony przez dwa. Zróbmy zadanie szybciej - świetnie, wszyscy tylko na tym skorzystają. Jeśli nie, to jesteśmy ubezpieczeni.
c) Czego nie akceptujemy w zespole:
- Niekonsekwencja, niespójność, zapominalstwo
- „Karmienie na śniadanie”. Jeśli nie możesz wykonać zadania, nie wiesz jak, musisz natychmiast powiadomić o tym lidera zespołu, a nie czekać do końca.
- Brovadas i chwali się od człowieka, który jeszcze czynem nie udowodnił swoich umiejętności i profesjonalizmu. Jeśli udowodnione, to jest to możliwe, w granicach przyzwoitości 🙂
- Oszustwo we wszystkich jego przejawach. Jeśli zadanie nie jest ukończone, nie należy zmieniać jego statusu na zakończone i napisać na czacie klienta, że jest gotowe. Komputer się zawiesił, system się zawiesił, pies pogryzł laptopa – to wszystko jest niedopuszczalne. W przypadku wystąpienia rzeczywistej siły wyższej należy niezwłocznie powiadomić kierownika zespołu.
- Gdy specjalista jest cały czas offline i trudno się z nim skontaktować w godzinach pracy.
- Toksyczność w zespole jest niedozwolona! Jeśli ktoś się z czymś nie zgadza, to wszyscy zbierają się na wiecu, dyskutują i decydują.
I szereg pytań/tez, które czasami zadaję mojemu klientowi, aby usunąć wszelkie nieporozumienia:
- Jakie są twoje kryteria jakości?
- Jak określić, czy projekt ma problemy, czy nie?
- Łamiąc wszystkie nasze zalecenia i porady dotyczące zmiany/ulepszenia systemu, wszelkie ryzyko ponosisz tylko Ty
- Wszelkie większe zmiany w projekcie (na przykład wszelkiego rodzaju dodatkowe przepływy) doprowadzą do możliwego pojawienia się błędów (które oczywiście naprawimy)
- Nie można zrozumieć w ciągu kilku minut, jaki problem wystąpił w projekcie, a tym bardziej naprawić go od razu
- Pracujemy nad określonym przepływem produktów (Zadania w Zhira - Rozwój - Testowanie - Wdrażanie). Oznacza to, że nie możemy odpowiedzieć na cały strumień próśb i skarg na czacie.
- Programiści są tylko programistami, a nie profesjonalnymi testerami i nie mogą zapewnić odpowiedniej jakości testowania projektu
- Odpowiedzialność za końcowe testy i odbiór zadań na sprzedaż spoczywa wyłącznie na Tobie
- Jeśli już podjęliśmy się zadania, to nie możemy od razu przejść do innych, 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 rozwoju)
- W zespole jest mniej osób (ze względu na urlopy lub choroby), a pracy jest więcej i fizycznie nie będziemy mieli czasu, aby odpowiedzieć na wszystko, co chcesz
- Prośba o wdrożenie do produkcji bez przetestowanych zadań na dev to tylko twoje ryzyko, a nie programista
- Kiedy ustawiasz zadania rozmyte, bez poprawnego przepływu, bez układów projektowych, wymaga to od nas znacznie więcej wysiłku i czasu realizacji, ponieważ musimy wykonać dodatkową pracę za Ciebie
- Wszelkie 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 ten błąd wyemitować
- Projekt wymaga ciągłego doskonalenia i ulepszeń w celu poprawy wydajności i bezpieczeństwa. Dlatego zespół poświęca trochę czasu na te ulepszenia.
- W związku z tym, że mamy godziny nadliczbowe (naprawy pilne), musimy je zrekompensować w inne dni
Z reguły klient od razu rozumie, że w tworzeniu oprogramowania wszystko nie jest takie proste, a samo pragnienie najwyraźniej nie wystarczy.
Ogólnie rzecz biorąc, to wszystko. Za kulisami zostawiam wiele negocjacji i wstępne debugowanie wszystkich procesów, ale w rezultacie wszystko się udało. Mogę powiedzieć, że ten proces stał się dla nas swego rodzaju „srebrną kulą”. Nowe osoby, które przyszły do projektu, mogły już od pierwszego dnia zaprzęgnąć się do pracy, ponieważ wszystkie procesy są opisane, a dokumentacja i architektura w postaci diagramów od razu dały wyobrażenie o tym, czym wszyscy się zajmujemy Tutaj.
PS Chcę wyjaśnić, że po naszej stronie nie ma kierownika projektu. Jest po stronie klienta. Wcale nie technikum. projekt europejski. Cała komunikacja odbywa się wyłącznie w języku angielskim.
Powodzenia wszystkim w twoich projektach. Nie wypalaj się i staraj się usprawniać swoje procesy.
źródło w moim .
Źródło: www.habr.com