Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

The Big Bang Theory – filmowa historia transformacji

X-Men Geneza: Wolverine

Dawno, dawno temu była sobie firma produkująca oprogramowanie. Firma była mała, z młodym zarządem, młodymi programistami. Młodości dodawało niewielkie doświadczenie zarówno założycieli jak i zatrudnianych osób. Wiek dziecięcy firmy skutkował łączeniem ról, wszyscy pisali kod, rozmawiali z klientami, dokonywali analizy funkcjonalnej. Firma nie posiadała również jasnej ścieżki kariery, nic dziwnego więc, że każdy robił to co czuł, że powinno być robione. Nie było jawnego podziału odpowiedzialności.

Z klientami rozmawiano przez telefon, także osobiście, gdyż często przyjeżdżali by zobaczyć efekt końcowy produktów z jakimi zmagali się pracownicy firmy.

X2 (Matrix Rewolucje)

W pewnym momencie ktoś postanowił: Takie podejście nie jest profesjonalne!. Powinniśmy usprawnić nasze procesy, powinniśmy je najpierw stworzyć.

Zebrało się grono decyzyjnych osób i przedstawiło swoje postulaty.
  • Nie może tak być, że każdy robi co chce – stwórzmy opisy stanowisk z przypisanymi odpowiedzialnościami.
I stało sie: Stworzono stanowiska kierowników, dyrektorów, oraz podział technicznych stanowisk na kilka stopni...
  • Nie może tak być, że analizą wymagań zajmuje się szary programista, a kierowaniem projektem kierownik zespołu.
I stało się: Stworzono stanowiska odpowiedzialne za analizę wymagań i kierowanie projektem...
  • Nie może tak być, ze nikt nie kontroluje jakości oprogramowania.
I stało się: Stworzono dział QA...

X-Men (Matrix Reaktywacja)

Fantastycznie! Teraz każdy wie co ma robić. Firma dorosła, stała się bardzo profesjonalna. - krzyczano na lewo i prawo.

Czy aby na pewno?

Otóż proces tworzenia oprogramowania w skrócie zaczął wyglądać następująco: Analiza -> Projektowanie -> Implementacja -> Testowanie
A nad nim czuwa kierownik projektu…

Klient nie zadzwoni już do programisty aby zapytać o postępy, umówi się raczej na formalne spotkanie, gdzie kierownik projektu lub tez osoba odpowiedzialna za sprzedaż przedstawi mu piękną prezentację.
Oczywiście sporadycznie pojawiły się głosy: Dodajmy do tego procesu pętlę (iteracje), dostosujmy go na potrzeby code review, ale powyższa forma mocno się zakorzeniła.

Nie będę się rozwodzić nad tym czy i dlaczego waterfall nie działa, lub jak ważny w trakcie trwania projektu jest udział klienta. Chodzi o sam fakt, iż mała samoorganizujaca się firma realizująca właściwie wspaniały agile’owy proces cofnęła się o epokę (mówię o epokach umownych dotyczących procesu tworzenia oprogramowania) nawet tego nie zauważając. I to w imię rozwoju, jakości i profesjonalizmu.

Wszelakie wypowiedzi agile’owych ewangelistów przekonują, iż proces transformacji podejścia do prowadzenia projektów odbywa się wg schematu: formal -> agile. Niemniej jednak nie jest sytuacją rzadką odwrotny jej kierunek (dlatego tytuły filmów występują w tym odwróconym kierunku). W końcu profesjonalizm kojarzy się z procesami – miękkie aspekty takie się nie wydają. Często niedoceniane są sprawy załatwiane nieoficjalnie, czy też rozluźnienia procesów kojarzone z samym agile’m.

X-Men: Ostatni Bastion

Problemem stają sie w takiej sytuacji m. in. ścieżki kariery. Co jeśli będąc programistą (wg stanowiska) jestem dodatkowo (praktycznie) testerem, albo analitykiem? Czy powinnam robić to wolontarialnie, jeśli nikt mi za to nie płaci? Pewnie dostanę pełno głosów, że tak, ale uwaga – to pytanie jest retoryczne. Chodzi mi o sam fakt występowania takich dylematów.

Właściwie zgadzam się ze stwierdzeniem, że to developerzy powinni zajmować się strona biznesową tworzonych aplikacji. Nie uważam też za dobry pomysł wydzielanie specjalnych działów analityków, kierowników projektów, testerów – stoi to w sprzeczności z zasada samoorganizacji agile’owych zespołów, ale przede wszystkim doprowadza do sytuacji, gdy konkretne osoby stoją przed wyborem lojalności wobec własnej ścieżki kariery i szefa swojego działu oraz projektu, w jakim uczestniczą. Takie osoby nie są częścią zespołu, albo ten pobyt jest mocno utrudniony.

Dodatkowo jeśli firma posiada takie specjalizowane działy, skazuje się na konkretną metodykę. Zamykamy jej (lub znów bardzo utrudniamy) zastosowanie np. scruma, gdzie rola kierownika projektu nie istnieje.
Co jeśli nagle przyjdzie moda/ochota na jeszcze inną metodykę? Zaczniemy zmieniać strukturę firmy od nowa?

Oczywiście uważam, że firma wręcz powinna się powiększać i rozwijać, a przez to również zmieniać. Również procesy nie są złe same w sobie. Muszą jakieś istnieć, bo inaczej zrobi się straszny bałagan i nikt nie będzie w stanie pracować. Ale standaryzacja wszystkiego łącznie z tym jak powinny być prowadzone projekty nie jest dobrym pomysłem. Co więcej, procesy w większej firmie są potrzebne, gdyż o ile mała świetnie radzi sobie z samoorganizacja - w większej nie jest to wcale proste.
Ostatnimi czasy pojawiło się wiele głosów mówiących o tym, ze nowoczesny management musi być bardziej nastawiony na to, by stworzyć takie środowisko pracy. Powinno się raczej pozwalać ludziom pracować na ich własnych warunkach (servant leadership) niż kierować tym co i w jaki sposób robią. Zmiany powinny więc dotyczyć podejścia do nowoczesnego managementu niż zmuszania deweloperów do pracy przy ustalonych przez "wyższe władze" zasadach.

Opublikowane 12 maja 2010 14:34 przez fusion

Komentarze:

Brak komentarzy
Komentarze anonimowe wyłączone