Niedawno pisałem o tym, że projekt, który mieliśmy rozpocząć nie był gotowy na ten start. Jednak mimo to trzeba było wszystko ruszyć z miejsca. Dlatego na pierwszy ogień poszło przygotowanie fundamentów projektu od strony technicznej. Jeżeli ktokolwiek miał okazję widzieć jak rozdziela się taką pracę na cały zespół ten już zapewne wie o czym będę tutaj mówił.

Samemu to każdy potrafi

Start projektu wiąże się z tym, że musimy założyć repozytorium, utworzyć projekt w IDE, dodać najważniejsze biblioteki i ewentualnie skonfigurować proces continuous integration. Większość z tych rzeczy to praca na kilka godzin. Siadasz rano i przez 17:00 masz już gotowy projekt. Jeżeli wybrałeś jakąś bardziej złożoną architekturę (tylko nie przesadź! Dlaczego? O tym mówię w TYM filmie) to ewentualnie praca rozciągnie się na 2-3 dni. Po tym 2 dniach możemy ruszyć z zadaniami typowo biznesowymi, prawda? Prawda. Pod warunkiem, że pracujemy sami.

Gorzej jeżeli od początku zespół składa się z kilku osób, a dostępność wymagań na najbliższą przyszłość jest taka sobie. Wtedy trzeba jakoś zagospodarować wszystkich w projekcie. Mi się trafiło takie zadanie w ostatnim czasie.

Każdy po kawałku

Nie można powiedzieć klientowi, że jedna osoba pracuje, a 3 pozostałe siedzą i czekają. To nie wygląda profesjonalnie! Nie za to nam płacą. Dlatego czekając na więcej biznesowych konkretów każdy i tak powinien mieć zajęcie. Z resztą wynika to też z tego, że jak programista nie ma zadań to zaczyna narzekać. A jak programista narzeka to za chwilę nie ma programisty.

W takim wypadku nie pozostało mi nic innego niż sztuczne podzielenie pracy. I w ten sposób jedna osoba jest odpowiedzialna za utworzenie solucji z projektami w Visual Studio. Druga ma za zadanie dodać potrzebne biblioteki, a jeszcze inna skonfigurować CI albo Dockera (którego używamy). Tylko tutaj powstaje problem. Bo skoro nie ma projektu w repozytorium to nie można dodać bibliotek. A jak konfiguracja Dockera nie jest gotowa to ciężko dodać np. lokalny serwer do logów, który ma być uruchamiany przez docker-compose. I w ten prosty sposób jednodniowa praca dla jednej osoby zajmuje czterem osobom co najmniej tydzień. I klient jest zadowolony bo mimo, że zawalił z wymaganiami to praca wre.

Konflikt interesów

Tak jak już wspomniałem, przy takim sztucznym podziale pracy dochodzi do sytuacji kiedy ciągle ktoś na kogoś czeka. I zazwyczaj łańcuch zależności jest dłuższy niż jedna osoba zależna od drugiej. W takiej sytuacji dochodzimy do kuriozalnego momentu kiedy większość osób na coś czeka i prawie nikt nic nie robi. Nie dziwi mnie nawet moment kiedy w konsekwencji zadanie, które jednej osobie zajęło by moment zaczyna przedłużać się na tyle, że przekracza zaplanowany na nie czas.

Każdy w zespole wie, że sam zrobił by to wszystko szybciej i równie dobrze albo i lepiej. Jednak nawet jeżeli klient nie będzie miał nic przeciwko temu, że jeden robi, a reszta patrzy to jak wybrać tą jedną osobę? Czy ma być to tech leader? Wtedy inne osoby nigdy się nie nauczą jak zakładać projekt. A może ktoś nowy żeby mógł się wykazać? W takim wypadku albo może nie mieć jeszcze wiedzy o wszystkim albo uznać, że wykorzystujemy go bo jest nowy. Nie ma dobrej odpowiedzi.

„Góra” nie ma z tym problemu

Wszyscy przywykli do tego, że projekty w korporacjach trwają długo. Widocznie tak musi być i nikt się tym nie interesuje za mocno. Poza osobami, które pracują najniżej. One zazwyczaj opowiadają przy kawie albo na spotkaniu ze znajomymi, że to wszystko to jest okropnie zarządzane i jak tak można.

A tak można, że firma woli rozciągnąć projekt w czasie niż doprowadzić do sytuacji kiedy tylko jedna osoba ma wiedzę o projekcie. A taka sytuacja by wystąpiła jeżeli to jedna osoba zakładałaby projekt. Bo wtedy wszyscy pozostali znaliby sytuację tylko z drugiej ręki – robiąc code review albo po prostu przeglądając repozytorium. Dodatkowo jeżeli projekt jest robiony dla zewnętrznego klienta to od razu podpisuje się umowę na konkretną ilość pracowników (jeżeli mówimy o wynajmowaniu zespołu). Więc jeżeli powiedzielibyśmy, że w sumie to przez cały sprint, czyli zwykle ok. 2 tygodnie, niepotrzebnie klient płacił za więcej niż 1 osobę bo reszta siedzi i czeka to wizerunkowo wyglądałoby to kiepsko. A prowadzenie firmy i realizacja kontraktów to gra i polityka – najważniejszy jest pozytywny wizerunek.

A dla Nas jako programistów takie sytuacje mają jedną zaletę. Możemy dobrze przemyśleć nasz kawałek rozwiązania i naprawdę mocno zagłębić się w temat albo jakaś bibliotekę czy framework. Korzystajmy.