Nie ulegaj presji czasu, jakość jest ważna!

Kojarzysz film “Marsjanin”? Historia opowiada o tym, że jeden z bohaterów filmu został uwięziony na Marsie po nieudanej misji kosmicznej. Wtedy zaczyna się akcja – NASA chce zrealizować misję ratunkową. Podczas całej historii toczy się ciekawy epizod obrazujący jak negatywny wpływ na efekt projektu może mieć presja czasu wywierana na procownikach: szef departamentu pyta ile potrzeba czasu na zorganizowanie akcji ratunkowej, w odpowiedzi słyszy, że 9 miesięcy, po czym ustala termin na 3 miesiące…

… jak można się spodziewać ta misja miała prawo zakończyć się niepowodzeniem 😉

Sytuacja przypomina częsty sposób prowadzenia projektów informatycznych. Działy biznesowe często wymuszają na programistach aby wykonali swoją pracę szybciej niż jest to możliwe w normalnych warunkach. W tej sytuacji zespół deweloperski przyparty do muru nie jest w stanie wiele zrobić, dlatego realizowane są postawione im zadania, a dobre praktyki wytwarzania oprogramowania porzucone (przecież pisanie testów tylko wydłuża czas rozwoju projektu), co w rezultacie prowadzi do klęski.

W tym artykule podzielę się swoimi doświadczeniami i wnioskami po przeżyciu podobnych sytuacji – chciałbym przedstawić jak programista można poradzić sobie z presją i krótkimi terminami realizując swoje zobowiązania bez negatywnego wpływu na jakość projektu.

Geneza

Zacznijmy od tego, że wyróżniamy dwa podstawowe typy kontraktowania projektów: Fix Price oraz Time & Material. Pierwszy z nich polega na tym, że zakres prac, obowiązków i cena za cały projekt jest ustalana z góry. Z kolei drugi typ sprawdza się wtedy gdy trudno założyć kształt projektu, a klient płaci za faktycznie wykonywaną pracę. Pozwala szybko reagować na potrzeby w czasie rozwoju aplikacji i łatwo zwiększać zakres.

Z mojej perspektywy często dużo trudniejsze w realizacji są projekty typu Fixed Price. I to nie ze względu na to, że wymaga to precyzyjnego oszacowania czasu potrzebnego na jego realizację. Największym problemem w projektach typu Fixed Price jest to, że są one często traktowane jak Time & Material. Oczywiście czas na realizację się nie zmienia, ale zakres obowiązków jak najbardziej. Co więcej, bardzo często zamiast „oddać projekt i zapomnieć” trzeba przejść w etap utrzymania i rozwoju.

Przeważnie podczas implementowania oprogramowania wychodzą rzeczy których wcześniej nikt nie przewidział, klient zaczyna dostrzegać nowe aspekty, chciałby jednak coś zmienić albo “przypomina sobie o czymś” o czym wcześniej nie powiedział, albo co gorsza – założył, że powinniśmy o tym wiedzieć.

Jeśli na poziomie biznesowym wszystko działa jak należy to każda zmiana zakresu odpowiednio wydłuża czas na zrealizowanie wszystkich zadań. Niestety, z tym bywa różnie. Często zdarza się, że osoby odpowiedzialne za negocjacje z klientem nie chcą nadszarpywać ich relacji i zamiast poinformować go o tym jak pewne zmiany wpływają na czas wykonania projektu wolą wymuszać na zespole “przyspieszenia prac”…

“Jakoś to będzie…”

Największą wiedzę o stanie projektu oraz o ewentualnych zagrożeniach posiada zespół projektowy, ale często jednak nie ma on bezpośredniego kontaktu z klientem. Kontakt odbywa się więc z działami biznesowymi i innymi jednostkami, które wiedzą co należy wykonać i jaki jest na to przeznaczony czas. Problem pojawia się kiedy te osoby “wiedzą lepiej” co i w jakim czasie da się coś wykonać. To właśnie wtedy zaczynają powstawać ASAPy, dedlajny i inne podobne smutne hasła…

Nawet jeśli członkowie zespołu programistycznego komunikują swoim przełożonym odpowiednio szybko jakich rzeczy nie da się wykonać w wyznaczonym czasie to ostatecznie jeżeli nawet “przyjmują to do wiadomości”, to nic z tym dalej nie robią…

W takiej sytuacji jest przed faktem dokonanym. Albo decydują się na to, że nie dowiozą niektórych funkcjonalności w terminie na rzecz działających, albo starają się zaimplementować całość, ale wtedy trzeba to zrobić na pełnych obrotach lub kosztem jakości oprogramowania… No i najczęściej robią. “Jakoś to będzie…”, “To już ostatni weekend w pracy”. I tak przez kolejne tygodnie.

Dług techniczny

Podczas tworzenia oprogramowania “na szybko”, kiedy dedlajn się zbliża najbardziej cierpi projekt i jakość kodu Panuje złudne wrażenie, że nie ma czasu na testy, przemyślenie architektury ani tego jaki wpływ może mieć kolejny komponent na całość projektu. Przecież trzeba zrobić to na wczoraj, inaczej będa kary.

Powiedzmy sobie szczerze, że można zaciągnąć świadomie dług techniczny aby to poprawić jak już się skończy ta presja czasu. Zrobisz to jutro? Spoko. Ale jutro w takich projektach często nie nadchodzi. Jutro pojawi się kolejny dedlajn, wrzutka albo hotfixy…

Powstaje kod coraz trudniejszy w utrzymaniu, pojawiają się kolejne szybkie poprawki. Brak tworzenia testów, który na początku pozwolił zaoszczędzić sporo czasu już dawno przerodził się w duży problem i tracone jest teraz znacznie więcej czasu na ciągłe analizowanie tych samych newralgicznych miejsc. Wcześniej gdy pojawiał się bug to dało się to naprawić w kilkanaście minut, a teraz zajmuje to już godzinę, dzień, tydzień i końca nie widać.

Utrzymywanie takiego stanu rzeczy prowadzi do nieuchronnej klęski – albo w porę ktoś powstrzyma to błędne koło i wywalczy możliwość na uratowanie tego projektu, albo zespół postanowi tkwić w takim stanie rzeczy dolewając paliwa do rozpędzonej lokomotywy zmierzającej ku przepaści…

Kto ponosi odpowiedzialność za fiasko projektu?

Jeśli w projekcie nie zmienia się nic na lepsze to można zakładać, że zakończy się on dużym niepowodzeniem. Znając życie zacznie się wtedy przerzucanie winy między kolejnymi osobami. Ostatecznie z pewnością odbije się to na zespole programistycznym.

Było to zgłaszane wcześniej? A komu? Przecież ta osoba nic nie pamięta. Szczerze mówiąc – czym większa korporacja tym większa biurokracja i jeśli czegoś nie ma na mailu lub innej pisemnej podkładce to trudno cokolwiek udowodnić z “niższego” szczebla całej firmowej hierarchii.

Ale… Większość winy tej porażki spoczywa właśnie na programistach. Praca w zawodzie programisty to nie tylko klepanie kodu i dostarczanie rozwiązań w jak najszybszym czasie. Będąc profesjonalistą trzeba potrafić powiedzieć “NIE” kiedy wiesz, że stworzenie czegoś w narzuconym Ci czasie jest prawdziwym samobójstwem. Będąc ekspertem nie pozwolisz na rezygnację z jakości i dobrych praktyk jeśli wiesz, że będzie to miało negatywny wpływ na przyszłość projektu. Oczywiście trzeba w tym samym czasie zaproponować inne pomysły na rozwiązanie problemu.

Co robić? Jak żyć?

Kiedyś na jednej z grup programistycznych przeczytałem ciekawą wymianę zdań pomiędzy dwoma osobami, jakości ich projektów. Konkretnych wypowiedzi nie pamiętam, ale kontekst wyglądał mniej więcej tak:

– mam wrażenie, że dobre praktyki wytwarzania oprogramowania panują tylko w naszych aplikacjach rozwijanych po godzinach, a w komercyjnych projektach nie ma na to czasu…

– eee… moim zdaniem to tylko wymówka, tylko od nas samych zależy w jakich warunkach pracujemy i jakiej jakości tworzymy soft

Ta krótka konwersacja świetnie ukazuje problem i przedstawia dwa typy programistów – pierwszy z nich bezkrytycznie realizuje zadania, które są mu narzucone mimo wiedzy, że to co robi jest niskiej jakości. Z kolei drugi z nich jest świadomy tego, że porzucanie dobrych praktyk wytwarzania oprogramowania to krótkowzroczność i zaoszczędzony czas podczas implementacji szybko się odbije rykoszetem.

Menedżerowie, osoby z biznesu czy klienci oczekują od Ciebie wykonania dla nich odpowiedniego produktu i Twoim obowiązkiem jest aby zadbać o to, że dostarczasz działający projekt, a efekt Twojej pracy jest wysokiej jakości. Nawet jeśli często usłyszysz, że trzeba zrobić coś na JUŻ, że jest dedlajn itp. – nie porzucaj dobrych praktyk na rzecz zrobienia czegoś szybciej. Przedyskutuj, przedstaw swój punkt widzenia i staraj się wyjaśnić jaki negatywny wpływ na całość będzie miała praca na szybko. Jesteś ekspertem, Twoją rolą jest nie tylko tworzenie, ale również dzielenie się swoją wiedzą i wskazywaniem zagrożeń odpowiednio szybko. W większości przypadków jeśli Twoje argumenty są racjonalne uda Ci się zmienić albo zakres prac do wykonania albo same terminy na realizację.

Co jednak robić jeśli ani terminy, ani zakres prac nie mogą ulec zmianie? To zależy. Warto organizować warsztaty z klientem gdzie stosując odpowiednie techniki (MoSCoW, Cut Your Project Times in Half, Priority Poker) można wybrać najważniejsze funkcjonalności aplikacji, które powinny być zaimplementowane w pierwszej kolejności, ale to raczej rola managementu.

Po stronie programisty i zespołu deweloperskiego głównym zadaniem jest jasne precyzowanie najszybciej jak to możliwe co się da wykonać w danym czasie i dostarczyć to bez rezygnowania z dobrej jakości. Najlepszym sposobem jest dobranie takiego zakresu prac, który na pewno zostanie zrealizowany (niestety trzeba będzie niektóre zadania odrzucić i pozostawić na dalszy etap rozwoju aplikacji). Asertywność przy tym jest bardzo ważna.

Uzgadniając z przełożonym co zespół jest w stanie zaimplementować w odpowiednim czasie trzeba mu zaufać, że jest osobą kompetentną i eskaluje to w odpowiedni sposób. Jeśli tego nie robi przez dłuższy czas, to można próbować dotrzeć ”wyżej”, ale nie zawsze jest to proste. Nie raz trzeba zadziałać w sposób bardzo korporacyjny i wszelkie złożone deklaracje trzymać na swojej skrzynce mailowej. Najważniejsze aby powierzone zadania realizować najlepiej jak się potrafi i należy pamiętać, że lepiej dostarczyć mniejszą ilość funkcjonalności niż wszystkie, z których połowa nie działa.

Podsumowanie

Jeśli chcesz być traktowany jak specjalista musisz się tak zachowywać i tworzyć oprogramowanie, z którego będziesz dumny. Nie chodzi o stosowanie samych zasad dla zasad czy tworzenia pięknego kodu dla zaspokojenia własnego ego. Będziesz dumny z projektu, który ma wartość biznesową, przyniósł zyski firmie, ale jednocześnie jest utrzymywalny i da się go wciąż rozwijać. Jest to możliwe tylko wtedy kiedy podczas jego tworzenia nie zrezygnujesz z własnych zasad i dobrych praktyk na rzecz zbliżającego się dedlajnu. To tylko wymówka, nie rezygnuj z jakości!

Zawsze staraj się dyskutować z przełożonym o zakresie obowiązków i informuj najszybciej jak to możliwe jeśli czegoś nie da się wykonać w wyznaczonym czasie, a po tych rozmowach najlepiej sporządzaj podsumowania i wysyłaj je mailowo. Lepiej zrobić mniej, a dobrze, niż próbować zaimplementować wszystkie funkcjonalności w gorszej jakości. Pracując w nadgodzinach lub porzucając dobre praktyki pokazujesz, że da się tak realizować projekty. Przyzwyczajasz tym osoby, które zlecają Ci zadania i będą oczekiwać tego samego w przyszłości, a problem będzie się pogłębiał.