Nie stawiaj na prędkość

Jestem wciąż młodym deweloperem. Można nawet powiedzieć, że żółtodziobem. Jednak podczas mojej 4-letniej pracy w obecnej firmie, widziałem już wiele, jeśli chodzi o rozwój i zarządzanie projektami.

Opowiem Ci, jak wyobrażałem sobie projekty, gdy zaczynałem studia.

Chciałem się nauczyć programowania od 14 roku życia. I faktycznie wtedy zacząłem, ale nie robiłem tego tak jak trzeba, ponieważ nie miałem do dyspozycji dobrego środowiska, ale też musiałem się skupić na swoim stypendium.

Mimo to, zacząłem uczyć się z Open Classroom, dawniej Le Site du Zéro, i byłem w stanie stworzyć kilka (brzydkich) stron internetowych z PHP, HTML i CSS.

Po ukończeniu szkoły średniej udałem się do Uniwersyteckiego Instytutu Technologii w paryskim Descartes, gotowy jak zawsze, by wreszcie nauczyć się tego, co najbardziej mi się podobało - programowania. Uczyłem się z pasją: najpierw algorytmy, potem C i C++, Java, JavaScript (szło mi topornie), a także wiele innych dziedzin, takich jak systemy operacyjne i sieci.

Ale co z innymi umiejętnościami? A co z zarządzaniem projektami? A co z odrobiną ekonomii? I co ważniejsze: co z tym, co dzieje się każdego dnia w każdej firmie? A co z faktem, że w 2019 r. projekty informatyczne nadal zawodzą? I z tym, że prawdopodobnie nadal będą zawodzić, jeśli będziemy nadal postępować tak, jak postępujemy?

W zakresie zarządzania projektami, ekonomii, ekspresji oratorskiej i innych nietechnicznych umiejętności. miałem zajęcia z naprawdę dobrymi nauczycielami.

Ale jeśli chodzi o ostatnie dwa punkty, nigdy nie byłem przygotowany na to, co miałem zobaczyć w prawdziwym życiu. Nawet w mojej szkole inżynierskiej nigdy nie przygotowywali nas do tego - bo przecież jak mieliby to zrobić? Podczas odbywania praktyki również byłem naprawdę daleki od rzeczywistości.

Kiedy zacząłem uczyć się programowania, myślałem, że chodzi o to, by robić co się chce i być dobrym technicznie.

Byłem taki głupi.

Umiejętności technicznie nie są tak ważne

[Spoiler alert] To nie umiejętności techniczne są problemem.

Serio, nie jestem ekspertem, ale nigdy nie miałem żadnego problemu z nauką czegoś technicznego, jeżeli mi się to podobało.

Podczas moich praktyk nie byłem programistą: Byłem konsultantem ds. wydajności i nienawidziłem tej pracy. Chciałem być deweloperem, więc na 3 miesiące przed zakończeniem mojego stażu zacząłem uczyć się JavaScriptu z Udacity. W pierwszych latach studiów byłem naprawdę słaby z JS. Kurs był trochę chaotyczny - było za dużo rzeczy do przyswojenia, a nauczyciel nie był zbyt dobrze zorganizowany. Ponadto, jak każdy, kto zaczyna uczyć się JavaScript, nie zrozumiałem dobrze tego języka.

Kiedy zacząłem się uczyć ponownie (mam na myśli naprawdę się uczyć), byłem pozytywnie zaskoczony, widząc, że rozumiem to całkiem dobrze.

Po tym zostałem zatrudniony w naprawdę dobrej firmie, gdzie mogłem pracować zarówno z Javą jak i JavaScriptem. Zacząłem od projektu w AngularJS 1.6 i TypeScript. Byłem zupełnie nowy i musiałem rozwijać od zera tę zupełnie nową aplikację. Z biegiem czasu ludzie dołączyli do zespołu projektowego, a my znaleźliśmy się w zespole SCRUM. Projekt trwał 18 miesięcy, zanim go opuściłem, wraz z innymi deweloperami.

To było w 2016 roku. Dzisiaj, kiedy piszę ten artykuł, projekt nadal trwa. Chcesz wiedzieć, co się stało? Zmęczyliśmy się, ponieważ poproszono nas o przerobienie każdego ekranu z jednego sprintu na drugi, ponieważ projekt ciągle się zmieniał i nie było nikogo, kto by to wyraźnie zatwierdził.

Projekt rozpoczął się we wrześniu 2015 roku. W ciągu jednego roku złapał 18 milionów euro deficytu. Jeśli nie potrafisz zgadnąć, co do tego doprowadziło, to może potrafisz zgadnąć, co nie było powodem: technologia i umiejętności techniczne.

Umiejętności techniczne nigdy nie były problemem

3 miesiące po naszym odejściu, zdecydowano całkowicie przerobić projekt w Qt. Nic to nie pomogło. Oczywiście, Qt był wyraźnie bardziej dostosowany do kontekstu (dlaczego miałbyś używać JavaScript w aplikacji wbudowanej?), ale opóźnienia w dostarczaniu projektu tylko się zwiększały.

Myślę, żę wiesz już, dokąd zmierzam. Kontynuujmy z innym przykładem.

Po tych porażkach przeszedłem do nowego, zupełnie innego projektu. Był bardzo atrakcyjny: Angular 2+, TypeScript, Docker, ElasticSearch, mikrousługi, Spring Boot. Wyglądało to jak mój wymarzony projekt.

Miałem być fullstack developerem i miałem zamiar nauczyć się wszystkiego! Perspektywa rozwijania zarówno frontendu jak i backendu była ekscytująca.

Pracowałem nad tym projektem przez rok i jeden miesiąc. Mógłbym zostać dłużej, ale prawda jest taka, że zmęczył mnie jeden konkretny aspekt - zarządzanie projektem.

Nasi klienci, nasi użytkownicy - wszyscy doświadczają strachu. Obawiają się rotacji, opóźnień, złej jakości, niezadowalającego produktu. Ale przede wszystkim obawiają się utraty pieniędzy. I ten jeden strach wypiera każdy inny rodzaj strachu.

Z powodu strachu przed utratą pieniędzy, nasi klienci podejmują złe decyzje. Mają też tendencję do utraty zaufania do nas (programistów, projektantów, scrum masterów, PO, itp.) oraz do zmiany decyzji, które podjęli w celu zmniejszenia opóźnień, złej jakości i rotacji.

Zła wiadomość jest taka, że nasi klienci są ludźmi i nie możemy ich winić za doświadczanie strachu. Dobra wiadomościa jest taka, że nasi klienci są ludźmi, tak jak my, i możemy uczyć się wspólnie. Szczególnie, gdy chodzi o główną zmorę w każdym projekcie, czyli zarządzanie projektem.

Metodologia, którą wybieramy do zarządzania projektami, to jedno. Sposób, w jaki stosujemy tę metodologię, to drugie.

W tym projekcie nasz klient chciał zastosować metodykę zwinną, ale chciał też, aby wszystko zostało zrobione dokładnie w ciągu jednego roku. Te dwa warunki były sprzeczne.

W związku z tym - klient zaplanował wszystko na sztywno - każdy zespół w projekcie zaczął odczuwać napięcia w kontaktach z innymi zespołami; programiści, niezależnie od tego, czy pracowali w backendzie, frontendzie czy z SAP-em, byli wyczerpani. Tak samo było z każdym designerem czy PO.

Projekt męczył też naszego klienta, ponieważ było wiele osób od podejmowania decyzji, które rzadko się ze sobą zgadzały.

Poza tym zwinna metodologia szybko przeszła ze SCRUM do PAIN (skrót od Prodigiously Absurd, Inefficient and Nasty): decyzje były absurdalne (przestańmy robić testy i wyślijmy scrum masterów do domu), ludzie zaczęli być nieefektywni, a kod był najgorszy, jaki kiedykolwiek widziałem (dzięki NgRx).

Im więcej czasu mijało, tym bardziej się spieszyliśmy. A nie możesz dostarczyć dobrego produktu, gdy się spieszysz. Właściwie, ledwo możesz dostarczyć cokolwiek, gdy się spieszysz.

Powinniśmy byli Was posłuchać

Widziałem się z jedną z osób podejmujących decyzje w sprawie projektu miesiąc temu. Spotkałem się po pracy z kilkoma byłymi kolegami z tego projektu. Była ekipa zebrała się, aby wymienić się doświadczeniami i miło spędzić czas, kiedy to nasz były klient wszedł do pubu, w którym siedzieliśmy.

Zamieniliśmy z nim parę słów i oto, co nam powiedział:

Powinniśmy byli was posłuchać.

Po dwóch latach takie wystawił projektowi post-mortem.

Czasami klienci nie będą nas słuchać. Naszym obowiązkiem jest to zaakceptować. Pamiętaj, klienci się boją. A strach jest zabójcą umysłu. Kiedy się boisz, niezwykle trudno jest się skupić i podejmować dobre decyzje.

Z drugiej strony, nasi klienci również mają obowiązki: jest to słuchanie ekspertów, których zatrudniają.

Błędy klientów

Za bardzo skupiają się na prędkości

Jeśli funkcje są dostarczane w odpowiednim czasie, to jest w porządku. Jeśli funkcje nie zostaną dostarczone w odpowiednim czasie, trzeba ponownie przemyśleć estymaty. Nikt nie umrze, jeśli funkcje nie zostaną dostarczone na czas. To znaczy, że odpowiedni czas nie był wcale odpowiednim.

Narzucają techniczne aspekty projektu

Czy w projekcie jest Karma czy Jest, Protractor czy Cypress, czy wybieramy NgRx czy nie, sposób w jaki deweloper będzie kodować, powinien być dla klienta niemal bez znaczenia. Powinien się obawiać, jedynie o to, czy jego aplikacja będzie możliwa do utrzymania w przyszłości, czy też nie.

Wymuszają na zespole stosowanie nieadekwatnej wizji metodologii

Kiedyś pracowałem dla klienta, który dosłownie wziął metodologię SCRUM i przekształcił ją w jakieś bzdury (3-godzinne plany sprintu w celu oszacowania dwóch historii? Naprawdę?). Bez względu na metodologię, którą zamierza się stosować, należy przynajmniej dobrze z niej skorzystać lub wziąć odpowiedzialność za każdą wykonaną personalizację.

Myślą, że jeżeli to, co robimy jest wirtualne, to można to stworzyć szybciej niż jakikolwiek inny produkt.

Ten pomysł jest po prostu błędny. Dostarczany produkt pozwala wykonywać niektóre zadania szybciej niż przy innych produktach, ale budowanie tak złożonych aplikacji mimo wszystko wymaga czasu.

Moim zdaniem lepiej jest dać więcej czasu mniejszej liczbie programistów, niż zatrudniać coraz więcej programistów, aby dotrzymać terminu. 

Wymagają szybkiego działania

Próba bycia szybkim prawdopodobnie Cię spowolni.

Podsumowanie

Zakończę te wywody jednym, ostatnim przykładem.

W 2019 roku pracowałem dla klienta, który tworzył kompleksową aplikację internetową. Projekt miał naprawdę piękny stos i kilka fajnych wyzwań: Angular 7 na frontendzie, NestJS na backendzie, cztery zespoły i piękne zautomatyzowane środowisko integracyjne. Poza tym, pracowaliśmy zgodnie z metodologią zwinną i najwyraźniej robiliśmy to dobrze. Więc co mogło pójść nie tak?

Migrowaliśmy z poprzedniego stosu do nowego. A w czasie migracji, wdrażaliśmy również nowe funkcje.

Robiąc w ten sposób, czuliśmy tak dużą presję, że nie mieliśmy czasu, aby nawet coś zjeść w porze lunchu. Niektórzy z nas pozostawali na nogach do późna i pracowali również w weekend. Nieustannie się spieszyliśmy, a ja bardzo się starałem znaleźć odpowiednie komponenty, by możliwie szybko coś dostarczyć i przy okazji niczego nie zepsuć - i oczywiście wszystko zepsułem.

Zostawiłem ten projekt z gorzkim smakiem w ustach. Bardzo chciałem wykonać dobrą robotę. Widziałem cały zespół, pędzący każdego dnia. Fakt, że ten projekt był bałaganem, nie wynikał z żadnych problemów technicznych. Wynikało to z kontekstu i zarządzania. Staraliśmy się działać szybko i sprawnie na SCRUM-ie. Naprawdę nas to spowolniło.

Teraz pracuję nad innym projektem. Bierzemy odpowiedzialność za sposób, w jaki stosujemy naszą zwinną metodologię. Każde wydanie jest sukcesem. Nie staramy się dotrzymywać niemożliwych terminów. Klienci są zadowoleni z naszej pracy. Nasz zespół, licząc stażystów, jest dość mały. Czas jest uprzywilejowany w stosunku do ilości osób. To pomogło mi uświadomić sobie coś naprawdę ważnego:

Nie powinniśmy próbować działać szybko. Powinniśmy próbować działać wydajnie.


Oryginał tekstu w języku angielskim przeczytasz tutaj.