Programiści mają łatwiej - polemika
Kolega Łukasz oczywiście spłyca, jak to profesjonalny analityk, wiadomo ;-) Przede wszystkim mam wrażenie, że popełnia błąd numer jeden wszystkich analityków systemowych wszechświata — nadużycie określenia „programiści”.
wygodna granica
Osobiście mam trochę inny obraz sytuacji. Oczywiście może on być naznaczony piętnem projektów, w których uczestniczyłem, i przez to niektórym może się wydać daleki od rzeczywistości. Niemniej w moim wszechświecie jest prawdziwy. Z obrazu tego wynika, że większość analityków stawia wyraźną granicę na poziomie „dokumentacji analitycznej” (obojętnie w jakiej postaci występuje ona w danym projekcie). Wszystko, co następuje po drugiej stronie, czyli po powstaniu tego dokumentu, to już są „aspekty czysto techniczne”, którymi zajmie się banda niedogolonych facetów o dziwnym poczuciu humoru, których z braku lepszej nazwy analitycy określają właśnie słowem „programiści”. To „programiści” wykonują to, co faktycznie użytkownik dostanie, czyli na nich spada splendor w przypadku sukcesu. Równocześnie nie potrafią zrozumieć prostego faktu, że jeżeli ktoś zmienia założenia, to klient a nie analityk i zawsze wykręcą tak, że winni za niepowodzenie projektu są wszyscy, tylko nie oni. Z punktu widzenia analityka „programiści” to banda niewdzięcznych i niewyrozumiałych palantów. I ok — ja potrafię taką postawę zrozumieć. A nawet domyślam się, że z tego właśnie powodu Łukasz powiedział mi niedawno, że „inżyniera oprogramowania to generalnie nuda” — faktycznie nuda jeśli się wrzuci wszystko do jednego worka i odpowiednio mocno uogólni...
wszyscy jedziemy na tym samym wózku
W praktyce jednak jest tak, że grupa określana jako „programiści” jest na tyle niejednorodna, że bez problemu wytwarzają się w niej kolejne granice i podziały. Zachowując koncepcję poprzedniej tabelki można (nadal trochę upraszczając) zaproponować np. takie rozwinięcie:
| Testerzy | Programiści | Projektanci | Analitycy |
|---|---|---|---|
| Działający produkcyjnie system. | Jakiś kod, o którym nie wiadomo nic — jak się ma do założeń, ile ma błędów. | Prototypy, pomysły i rysunki. | Prototypy, najczęściej nierealne. |
| Scenariusze testowe. Kto czyta scenariusze testowe??? | Brak zbędnej papierologii. | Dokumentacja projektowa. Kto czyta dokumentację projektową? | Dokumentacja analityczna. Kto czyta dokumentacją analityczną? |
| Kontakty z programistami, mniej lub bardziej konfliktogenne. | Brak konfliktogennych kontaktów z analitykiem. |
|
|
| Źle przetestowany system jest winą testerów. | Poprawnie działający system jest zasługą programistów. Wielokrotnie łatany i niekonserwowalny system jest ich winą. | Źle działający system jest winą projektantów. | Źle zrozumiane potrzeby klienta są winą analityków. |
Jak widać powyżej, sprawa nie jest taka prosta. Nie widzę tutaj możliwości postawienia jasnej diagnozy kto „ma lepiej” lub komu „łatwiej dostać premię”...
2005.03.04 | 5 komentarzy | 
tagi » uczestnicy dramatu
Komentarze
#1 | 2005.03.04 16:14 | Łukasz Grabuń
Oczywiście, było (jest) to pewnego rodzaju uproszczenie; poniekąd cieszę się, że zwróciłeś na to uwagę. Tyle tytułem wstepu.
Być może nie dałem tego w pełni odczuć - bo i nie do końca było to chyba moim zamiarem - ale chodziło mi o podkreślenie, że mimo krytycznego znaczenie analizy w projekcie, rola osób ją (tę analizę) przeprowadzających jest często marginalizowana, a cała chwała przypada osobom, które robią coś konkretnego (czytaj: programiści, koderzy, jak ich zwał, tak ich zwał). Gdy coś nie działa tak, jak powinno, pierwsze baty zbiera analityk (często pełniący rolę konsultanta), podczas gdy programista dostaje zbindowaną dokumentację, na podstawie której sam opracuje zapytania do bazy danych, nie doceniając faktu, że jej (tej dokumentacji) opracowanie kosztuje zarówno rzeczonego analityka, jak i użytkownika/klienta dużo wysiłku i nerwów (tak, to były bardzo długie zdania). Ot, można powiedzieć, że przypada nam rola rozpoznania walką, a mimo to ciężko jest powiedzieć, by analityk robił coś "konkretnego".
Niemniej, dziękuję bardzo za sprostowanie. I cieszę się, że mój wpis był powodem czyjejś reakcji. Zawsze miło wiedzieć, że to, co się pisze w jakiś sposób trafia do Czytelników.
Pozdrawiam serdecznie.
#2 | 2005.03.07 09:16 | MiMaS
rola osób ją (tę analizę) przeprowadzających jest często marginalizowana, a cała chwała przypada osobom, które robią coś konkretnego
Zapewniam Cię, że Twoje poczucie niedowartościowania jest zupełnie nieuzasadnione. We wszystkich rozmowach na temat obsady projektu (jako „lider zespołu” przeprowadzam takie rozmowy dosyć często) kwestia obsadzenia roli analityka jest kluczowa. Od zdolności tego człowieka zależy zrozumienie celów systemu przez zainteresowane strony, a więc ... wszystko co ważne.
programista dostaje zbindowaną dokumentację, na podstawie której sam opracuje
Wątpię. Po pierwsze, nie programista tylko projektant. A po drugie, nie sam tylko z pomocą analityka (niejednokrotnie intensywną). Dobra dokumentacja analityczna to najbardziej wartościowy produkt w projekcie informatycznym (i nie boję się tego powiedzieć, a co!). Niestety, szczerze mówiąc, często jest tak, że dokumentacja ta nie istnieje w postaci zjadliwej dla kogokolwiek poza samym analitykiem. W takiej sytuacji analityk ma szanse ujawnić swoje zdolności interpersonalne tłumacząc życzenia klienta „z polskiego na nasze”. I to nadal jest ok, bo najważniejsze jest zrozumienie, nie dokument sam w sobie. Najważniejsze, żeby umieć rozmawiać z klientem, a nikt oprócz analityka, tego robić nie umie. I przede wszystkim nie chce...
Podsumowując — ktoś, kto kreśli wyraźną granicę między analitykiem a resztą zespołu i doszukuje się bardziej niewdzięcznej roli, spłyca problem i wulgaryzuje interakcje w projekcie. Natomiast ten, kto niedocenia roli analityka nie powinien w ogóle zajmować się produkcją oprogramowania. I tyle.
#3 | 2005.03.07 09:22 | MiMaS
Zresztą o niebagatelnej roli analityka już kiedyś pisałem...
#4 | 2005.03.10 15:55 | Łukasz Grabuń
Michale, miło przeczytać takie słowa.
Niemniej, ręce opadają, gdy czyta się coś takiego.
#5 | 2005.03.11 14:03 | MiMaS
Od dawna uważam, że przemyślenia, w których występują pojęcia typu „agile”, lub które powołują się na techniki choćby zbliżone do XP, bardzo łatwo wprowadzają zamieszanie. Powodem jest najczęściej fakt, że ludzie nie czytają tego, co się do nich pisze i nie słuchają tego, co się do nich mówi, tylko zadowalają się własnymi wyobrażeniami. Błędnymi niemal zawsze. W ten sposób pomysły typu „code as design” są właściwie z założenia narażone na wularyzację i spłycenie w wypowiedziach ignorantów. Ciekawe też, że zadziwiająco często ludzie tacy nie uczestniczyli nigdy w żadnym projekcie wymagającym pracy więcej niż jednej osoby....
Zresztą jeśli czytam:
musiałbym coś poczytać i porobić, żeby się wypowiadać
to całość można zostawić bez komentarza.
Uwaga: Ze względu na bardzo intensywną działalność spambotów komentowanie zostało wyłączone po 60 dniach od opublikowania wpisu. Jeżeli faktycznie chcesz jeszcze skomentować skorzystaj ze strony kontaktowej.