TheTarPit

programista, a może projektant?

Teoria książkowa aka sformalizowany świat idealny przedstawia taki łańcuch rozbieżnych kompetencji — klient, analityk, projektant, programista, tester. W łańcuchu tym wymagania i uwagi klienta co do funkcjonalności systemu są pieczołowicie zbierane przez analityka i przekazywane projektantowi, który tworzy szczegółowy projekt tego co ma być wykonane. Następnie projekt ten trafia do programisty w celu jego urzeczywistnienia i na końcu do testera dla konfrontacji efektu z założeniami. Taki schemat zakłada separację ról, czyli jest praktycznie wzorowany na kaskadowym modelu cyklu życia projektu informatycznego. I jest równie absurdalny jak sam model kaskadowy.

W opozycji do takiego podejścia stoi idea XP i podobne, gdzie występują właściwie wyłącznie programiści, którzy ... po prostu piszą, aż uzyskają efekt akceptowalny przez klienta; bez formalnego projektu.

A rzeczywistość jak zwykle trafia gdzieś po środku. Nawet odrzucając małe zespoły (gdzie z konieczności, z braku ludzi i środków programista musi być wszystkim) sztywny podział ról jest po prostu niepraktyczny i nieprawdziwy. Owszem istnieją takie role, np. analityk, których zakres zupełnie nie pokrywa się z umiejętnościami projektanta i programisty — to kwestia przejścia z poziomu koncepcji biznesowych do poziomu technicznej implementacji systemu. Jednak już w ramach poziomu technicznego założenie rozbieżności czynności projektowania i programowania jest po prostu złe i nie bez powodu krytykowane od co najmniej dziesięciu lat^[1]. W rzeczywistym projekcie informatycznym każdy programista jest i musi być po części projektantem. I to nie tylko w zakresie drobnych szczegółów implementacyjnych, ale generalnie w zakresie stworzenia dobrego rozwiązania problemu. W praktyce wygląda to tak, że programista samodzielnie wypełnia luki w projekcie. Luki świadomie tam pozostawione przez projektanta.

Z mojej praktyki projektanta wynika, że pozostawienie "dużej" roboty dla programisty daje niejednokrotnie bardzo dobre efekty. Tym bardziej w sytuacji gdy praca nad projektem niemal z założenia odbywa się w dużym niedoczasie. Formalny projekt dowolnego systemu informatycznego jest niemal zawsze traktowany po macoszemu we wszelkich harmonogramach po prostu dlatego, że szefostwo nie rozumie lub nie widzi produktów tej fazy. Znajomość możliwości zespołu produkcyjnego i indywidualnych cech programistów ma w takim przypadku kolosalne znaczenie. Wiedząc, że dany moduł czy fragment systemu będzie implementowany przez programistę, który ma dobrą intuicję, wystarczające zdolności i któremu po prostu mogę zaufać, pozwalam sobie na więcej swobody i niedomówienia. Poprzestaję wtedy na zarysowaniu problemu, wskazaniu sposobu rozwiązania, powiązań z resztą systemu i ewentualnych analogii. W innym przypadku, kiedy wiem, że programista przyjdzie do mnie z setką pytań niezależnie od zawartości projektu, pozwalam sobie na jeszcze mniejszą precyzję — i tak wszystko będziemy dyskutować ustnie. A w zespole z dobrym i odpowiedzialnym analitykiem mogę wszelkie generalne wątpliwości programisty kierować bezpośrednio do analityka (w naszym aktualnym projekcie brzmi to ładnie: "Zapytaj Anię" :-)) i tym samym świadomie wyłączam rolę projektanta. Można mieć obawy, że taki sposób pracy za bardzo zbliża projekt do teoretycznie kontrolowanego chaosu lub jakiejś odmiany ekstremalnej, jednak ... to po prostu działa. Programiści są projektantami (w lokalnym zakresie) i często bardzo dobrze sobie z tym radzą.

Oczywiście w sytuacji kryzysowej potrafię bezpardonowo przeforsować swoją koncepcję rozwiązania. Jednak odwoływanie się do formalnego przypisania ról w projekcie to plan awaryjny, który dobrze mieć, ale niekoniecznie trzeba korzystać...

Komentarze

Brak komentarzy do tego wpisu.