O długu technologicznym ciąg dalszy. Tym razem będzie o managemencie czyli o wszelkich kierownikach, dyrektorach, leadach, dev leadach, pm-ach, project i product managerach i wszystkich innych, którzy mają pozycję decyzyjną. Przez to rozumiem wszystkie te osoby, które, między innymi, powinny wiedzieć, kiedy będzie nowa wersja i co w jej zakres wchodzi.
Wydawało Ci się, że to tylko lenistwo programistów wpędza zespoły w długi? Otóż nie. Nie mały wkład w to ma management (zarząd w j. polskim ma trochę inne znaczenie a nic innego nie przychodzi mi do głowy).
Podstawowym grzechem jest bezsensowne naciskanie na programistów:
M(anager): Funkcjonalność X musi być dostarczona za 2 dni (bo jest prezentacja dla klienta)*
P(rogramista): Potrzebujemy na to 5 dni (w domyśle 2 tygodnie to minimum)
M: 2 dni i koniec!!! (w domyśle co te sieroty chcą pisać przez 5 dni)
P: Nie da się
M: Zróbcie ile się da (w domyśle zróbcie wszystko, super dokładnie i super elegancko)
P: Postaramy się (w domyśle nie ma bata żeby to zrobić, powiem postaram się to się odwali, jak nie napiszę testów, jak oleję to i tamto i zrobię tylko happy path i posiedzę do 20-stej kosztem życia prywatnego to będzie to jako tako działo)
M: OK (w domyśle OK bo M(anager) usłyszał że zostanie to zrobione)
I w tym momencie zaczyna się jazda. Czyli wszelkie dobre zasady odstawia się na bok i napierdala po klawiaturze jak Bruce Willis w jakiejś szklanej pułapce – aby tylko uratować świat. Po 2 dniach Żona Cię nienawidzi (i nie to że ma jakiś uraz – przecież jest przyzwyczajona, chodzi o to ze rzeczywiście Cię nie widziała od 2 dni), Twój organizm Cię nienawidzi (chciałby wreszcie spać i ma dość tej ohydnej korpokawy), testerzy Cię nienawidzą (bo szczerze powiedziawszy napisałeś gówno) ale myślisz jestem super hero, zrobiłem, zdążyłem, jestem bogiem/lordem/czy czym tam chcesz.
Rzeczywistość jest bardziej smutna.
Generalnie wyjścia są dwa:
albo prezentacja się nie odbyła i Twoje poświęcenie delikatnie mówiąc było gówno warte
albo prezentacja się odbyła ale ponieważ było to odwalone ja było to coś tam się wyspało, coś tam nie zadziałało i generalnie klapa.
Hola Hola, jest też trzecie wyjście. Prezentacja się odbyła, wszyscy są zadowoleni a my w swojej wspaniałości (przecież uratowaliśmy świat) zapominamy jak poszyty kod napisaliśmy (przecież działa) i lecimy znowu ratować świat.
Trzecie wyjście to chyba najgorsze z najgorszych bo ten kiepsko-marny kod zostaje bez zmiany. W tym momencie przydało by się go mocno zrefaktoryzować i doprowadzić do ładu. Jeśli tego nie zrobimy to dług który zaciągnęliśmy na potrzeby prezentacji zaczyna generować odsetki (zazwyczaj bardzo szybko) w postaci błędów.
Powyżej przedstawioną sytuację pomimo, że lekko podkolorowaną to miałem okazję przeżyć…. nie raz. Jeśli jednak myślisz, że piszę takie tam na potrzeby bloga to sięgnij do książki Clean Coder Roberta C. Martina – pisze on o podobnych sytuacjach a ma trochę większą renomę i więcej doświadczenia niż ja – może Cię przekona.
*) potrzeby prezentacji/wdrożenia/termin u klienta/przetarg/demo/cośtam cośtam, niepotrzebne skreślić
