Jak nie robić projektów

Jak to zwykle w opowieściach bywa… Kolega (bo to jest nasz główny bohater) od kilku miesięcy współpracuje z pewną, międzynarodową firmą IT. Która, to podjęła się nie lada wyzwanie stworzenia systemu call center dla jeszcze większej firmy - tym razem z branży telekomunikacyjnej.

Scenariusz jest dosyć standardowy dla projektów IT. Każdy zakasał rękawy, wziął się do roboty, lecz po kilku miesiącach okazało się, że prace idą za wolno, deadline’y zostają przekroczone, a ludzie nie są zadowoleni z tego jak się mają sprawy. Dlatego chciałbym przedstawić kilka podstawowych powodów dla których tak się stało oraz jak się przed nimi uchronić.

Przedstawienie firmy

Tak jak wspominałem jest to firma o wielkości 100-150 osób, mieszcząca się w 5 piętrowym budynku, w stosunkowo małym mieście ok. 36 tys. osób.

Firma X (bo tak ją możemy nazwać), prowadzi nie tylko wymieniony projekt, ale także projekty poboczne. Co ciekawe projekt ten nie jest ich głównym projektem. Tak naprawdę wywodzą się z trochę innej branży, ale na potrzeby tego artykułu nie jest to najważniejsze.

Zespół składa się z:

• ok. 30-stu deweloperów (w tym adminów)
• kilkunastu PM’ów
• kilku testerów
• jednego CTO
• oraz kilku managerów i ludzi biznesu

W tym momencie firma nie polega tylko i wyłącznie na swoich zasobach ludzkich, ale także na kilku innych firmach wspomagających cały proces.

Są to firmy z kilku krajów:

• Holandia - główna firma oraz druga firma z adminami
• Niemcy - klient firmy holenderskiej, mający swój zespół testowo-wdrożeniowy
• Rumunia - firma zajmująca się tworzeniem projektu od strony frontendowo-backendowej
• Polska - dwie firmy IT wspomagające główny zespół holenderski, frontend, backend i admini

Jak widać przy takiej ilości osób, z tylu narodowości pierwsze, co się nasuwa to problemy z…

Bolączki projektu

Komunikacja - Język, który jest używany w projekcie, to oczywiście język angielski, lecz każdy kraj ma swój specyficzny dialekt, przez co nie zawsze można zrozumieć, co dana osoba miała na myśli (co chciała przekazać). Dlatego ważne jest, aby w takim zespole porozumiewać się bardzo prostym językiem.

Załatwianie spraw - Brak wydzielonej osoby do komunikacji ze stroną holenderską. Lecz tylko w przypadkach, gdy trzeba np. załatwić dostępy do kolejnych części infrastruktury, albo w przypadku wprowadzenia do projektu. Ponieważ teraz skacze się “od okienka do okienka” dowiadując się, kto co może załatwić. Gdyby wydelegować tego typu zadania dedykowanej osobie, która to wie do kogo pójść z daną sprawą (najprawdopodobniej PM od strony holenderskiej) praca stała by się o wiele przyjemniejsza.

Powolne załatwianie spraw - Na niektóre sprawy czeka się nawet tygodniami. Niekiedy sprawy te zostają pominięte tak jak np. dostęp do citrixa, który to zgłoszony był kilka tygodni temu, a że w między czasie ktoś użyczył swojego konta, i już nikt nie pamięta, aby sprawę tą posunąć dalej.

Częste zmiany dotyczące projektu - Pomimo dość dobrych mockup’ów tudzież grafik, często funkcjonalności lub też elementy wizualne projektu zostają zmienione. Co prowadzi do frustracji programistów i oczywiście wielkiego marnowania czasu, a tym samym pieniędzy.

Zrzucanie wszystkiego na jedną osobę (CTO) - No może nie wszystkiego, ale jednak znaczniej części. Przez tego typu działania osoba ta nie ma życia, a o wakacjach może zapomnieć. A gdyby tak stworzyć dwie-trzy kopie tej osoby, które miały by podobne uprawnienia oraz podobną wiedzę na temat projektu. Jak mi ktoś kiedyś powiedział - “zawsze twórz cień danej osoby, tak aby ich wiedza się przeplatała”, w innym przypadku jeżeli osoba ta nie będzie dysponowana (przecież różnie może być), będzie ktoś, kto będzie mógł przejąć obowiązki pierwszej osoby.

Podział na zespoły/microservices’y - Wiem, że jest to buzzword, który często jest nadużywany w projektach, ale w odpowiednim projekcie, przy odpowiednich zasobach warto przemyśleć wdrożenie takiej architektury. Nie tylko będziemy mieli podział technologiczny na mniejsze struktury, ale także każdy zespół byłby odpowiedzialny za swoją część projektu, co zniwelowało by niektóre z powyższych bolączek (chociażby przeładowanie jednej osoby zadaniami). Trzeba mieć tylko na uwadze, aby zachować bardzo dobrą komunikacje pomiędzy zespołami, a tym samym serwisami, nad którymi pracują.

Brak walki pomiędzy IT, a biznesem - Nie wszystko da się wyperswadować klientowi (w tym przypadku niemieckiej firmie telekomunikacyjnej), ale każdy deweloper uważający się za profesjonalistę powinien wiedzieć kiedy powiedzieć NIE. Po prostu nie powinien zgadzać się na wszystkie zachcianki biznesu. Bo to od dewelopera powinno zależeć jakie technologie powinny zostać użyte, dlaczego powinniśmy wdrożyć daną funkcjonalność oraz dlaczego nie powinniśmy jej wdrażać. Czyli istny brak rozmów pomiędzy IT, a biznesem.

Błędne podejście do ustalania deadline’ów - Tak naprawdę zespół deweloperski nie ma pojęcia, kto i co ważniejsze na jakiej podstawie wymyślił deadline’y!? Najprawdopodobniej zrobił, to kiedyś jakiś zespół projektowy lub zespół analityków, lecz nie na tym polega podejście scrum’owe, którym to chwali się nie jedna firma - z firmą X łącznie. To deweloperzy powinni podawać estymaty, najlepiej poprzedzone POC, o ile nie mają dość dogłębnej wiedzy w danym temacie.

Pośpiech - Ulubione słowo każdego dewelopera: ASAP. Zamiast zastanowić się nad danym problemem i przedyskutować go w swoim zespole, każdy PM oczekuje, że będzie to wykonane jak najszybciej przez dewelopera. Co w rzeczywistości nie oznacza, że zadanie będzie zrobione najszybciej jak się da - bo przecież inny programista mógł wymyślić lepsze, szybsze rozwiązanie.

Dług technologiczny - Wyżej wymieniony przykład doprowadził do przeogromnego długu technologicznego jeszcze w takcie tworzenia projektu. Wyobraźcie sobie, że robicie remont w domu, dzwonicie po najlepszych specjalistów w mieście, czekacie kilka/kilkanaście dni na zakończenie prac i na samym końcu wasz dom, wygląda jeszcze gorzej niż przed remontem. Nikt więcej nie zaufałby takiej ekipie remontowej. Tak samo wygląda z tym projektem. Jeżeli w trakcie tworzenia systemu, wygląda on nieciekawie (od strony technicznej), to co będzie przy jego ostatecznym wydaniu!? Ja osobiście przewiduję dużą klapę i wielkie buraki na twarzy managerów.

Niestabilne środowisko deweloperskie - Tutaj posłużę się przykładem. Jedna z osób, która także pracowała nad tym projektem stawiała 2 tygodnie swoje środowisko deweloperskie, 2 tygodnie!!! A gdy komukolwiek środowisko padło, (a działo się to tak średnio kilka razy w miesiącu, a nawet w tygodniu), jedyne co można było usłyszeć to “skasuj środowisko i postaw je na nowo”. Spoko, gdyby nie to że każde postawienie środowiska to min. 30 min. Kolejny przykład na idealne tracenie czasu.

Niedopasowane technologie - Oraz przestarzałe, które skutecznie spowalniają pracę każdego dnia. Pamiętajcie nigdy nie używajcie Citrixa, czy też niestandardowego VPN’a (SonicWALL Global VPN)

Timeshit - Na szczęście poprawili tą kwestię, ale przed długi czas używali systemu, z którego można było korzystać tylko na windowsie. A że większość programistów używa linuksa, nie pozostawało nic innego jak wgranie wirtualnej maszyny, aby tylko zaraportować swoje godziny. Była też wersja online, lecz bardziej zbugowana niż sam windows ’95, dwadzieścia lat temu.

Zbyt duża ilość bezsensownych call’y - Przypadek wspomnianego kolegi. Kiedy, to system doznał błędu i trzeba było oczywiście naprawić go ASAP. Pierwsza rozmowa telefoniczna nastąpiła po około godzinie. Nie było by w tym nic dziwnego, gdyby, nie to, że potrzeba było do tej rozmowy ok. 5 osób. Jedyne, co mogli wtedy usłyszeć, to “I still working on it”. Wypowiedzenie tego zdania trwało 10 sekund, a zebranie wszystkich osób “potrzebnych” do rozmowy 10 minut. Po około dwóch godzinach nastąpił kolejny call, wyglądający podobnie. I pod koniec dnia ostatni z hasłem “fixed”. Tak naprawdę wystarczyło powiadomić tylko PM’a, który mógł przekazać informację dalej, czy to na slacku, czy w postaci maila.

Nadgodziny - Rozumiem, że czasami trzeba zrobić jakąś nadgodzinę, czy dwie, aby pomóc w ciężkich chwilach. Lecz kiedy dochodzą wszystkie wyżej wymienione aspekty, które wpływają na jakość pracy, to człowiek, staje się bardzo zirytowany. Bo przecież ma świadomość, że gdyby tylko ułożyć w sensowny sposób zadania, można by było uniknąć w większej mierze niepotrzebnych nadgodzin. Tym samym pracodawca, miałby mniejszy koszt utrzymania swojej firmy.

Dodatkowo warto wspomnieć o:

• Braku PSR
• Braku testów jednostkowych
• Braku refaktoryzacji kodu
• Różnych ustawień środowisk deweloperskich/testowych/produkcyjnych
• Deploy w piątek

Pomimo niezliczonych minusów jakie niesie za sobą ten projekt ma on także…

Plusy projektu

Jedno środowisko z narzędziami - Wykorzystanie systemów z rodziny Atlassian (system ticketowy, system git, bug tracker, system dokumentacji, system CI). Jest to całkiem dobre podejście bo dzięki temu stosunkowo łatwo zachować spójny flow zarządzania błędami, informacjami wewnątrz firmowymi, czy też deploymentem.

Tworzenie Pull Requestów - Dobra praktyka, zamiast pozwalać deweloperom na wrzucanie commitów jak leci, każdy commit jest zatwierdzany przez grupę (z reguły) doświadczonych programistów. Dzięki czemu możemy częściowo uniknąć błędów oraz braku spójności wdrażanych rozwiązaniach.

Zamiana systemu timeshit - Pomimo dość kłopotliwego procesu (w pewnym momencie trzeba było wypełniać godziny w 5 miejscach) udało się w końcu przejść ze starego systemu TS na wbudowany TS w Jirze.

Testy wydajnościowe - Wprowadzenie nie tylko testów manualnych, ale także testowanie aplikacji pod względem wydajnościowym. Mało kiedy można spotkać tego typu testy w projektach.

Duża infrastruktura - Przy odpowiedniej skali projektu i zasobów, ma to swoje plusy, bo nie ograniczamy się stricte tylko do dwóch-trzech maszyn. Jeżeli potrzebujemy dołożyć kolejną maszynę, nie ma z tym problemu.

Prężne szukanie kolejnych zasobów ludzkich - Jak w każdym projekcie ludzie przychodzą i odchodzą. Jak widać po narodowościach, które zaangażowane są w projekt, firmie dość dobrze idzie szukanie kolejnych programistów. Aczkolwiek jakość niektórych zespołów pozostawia wiele do życzenia.

Podszkolenie języka - Zaangażowanie zespołów z różnych krajów ma też swoje plusy. Mianowicie można podszkolić język. W końcu każdego dnia trzeba rozmawiać/pisać z innymi narodami.

Mokupy, grafiki - W momencie kiedy uda się wyciągnąć od nich mockupy/grafiki trzeba przyznać, że są dość dobrze zrobione i opisane.

Poczucie humoru CTO - Pomimo wielu spraw na głowie potrafi w dość wyluzowany sposób odpowiadać na wiadomości.

CTO: If you need me to scalete something and Zend let me know we bought like 300k licenses two new Nissan GT-R’s in support ;) I except them to fix siht if its broken!

CTO: Lisa needs your help Shee needs you ;)

CTO: Mr. D. how’s life?

D: Pretty good and your?

CTO: Shitty as always You don’t wanna know ;)

D: Now I get it, but that is ugly hack

CTO: Welcome to my life. One big ugly hack since conception It’s my middle name”

CTO: Yes, really? If that it, I will come and kiss you

CTO: I will take my girlfriends best lipstick and we will build a statue of you

CTO: searching for my lipstick…

JV: Indeed, you need

JS: Ok then I will do it with G.

JS: Ok then I will do it with G.

Można dogadać się z ludźmi - Po tak długiej współpracy człowiek dochodzi do wspólnego języka i pomimo wielu nieporozumień jest w stanie skutecznie rozwiązywać problemy.

Podsumowanie

Jak nie trudno zauważyć przeważająca ilość punktów dotyczyła negatywnych aspektów. Niestety projekt ten nie jest najlepiej zarządzany przez, co duża ilość osób czuje frustracje podczas jego tworzenia. I bezsensownych decyzji jakie zostały podjęte. To co ja bym radził, to w końcu się zatrzymać, przeanalizować sytuacje i odbić się na inny kurs.

Kurs w którym, to przoduję dewiza “Jakość, a nie jakoś”. Gdyby tylko zacząć wdrażać dobre praktyki i tworzyć soft od samego początku z minimalną ilością błędów, można by było skupić się na produkowaniu nowych feature’ów, a nie poprawianiu tych samych bug’ów- wiem byłem tam.

Przeżyłem dwa różne podejścia jednego systemu, w jednym przodowało hasło “jakoś”, w drugim “jakość”. Ta druga sprawdziła się o niebo lepiej, ale to już opowieść na osobny artykuł.