niedziela, 13 września 2009

Księga procedur a 15 minut

Dzisiaj będzie stricte o projektach IT. Kiedyś dawno temu przeczytałem, że programista pracując nad nowym kodem średnio co 15 minut podejmuje ważną decyzję technologiczną. Fakt ten przypomniał mi się w zeszłym tygodniu, kiedy zaangażowałem się w ciekawą dyskusję nad procedurami w firmie.

Ogólnie pytanie brzmi: jak dokładnie można opisać procedury, które powinien stosować pracownik. Istnieje pewna grupa przekonań, według których procedury mogą i powinny opisywać każdą istotną czynność wykonywaną przez pracownika. Założenie stojące za takimi stwierdzeniami jest takie, że można przewidzieć i opisać każdą jedną sytuację wobec której stanie pracownik. A jak już będzie to opisane to pracownikowi będzie łatwiej pracować, bo zamiast myśleć (?!) sięgnie tylko do odpowiedniej procedury. Hmm, ciekawe, ale na pewno nie w projektach IT. Być może w budownictwie, którego tradycje sięgają kilku tysięcy lat można skatalogować i opisać każdy jeden przypadek. Ale w programowaniu? Gdzie każdą rzecz można wykonać na przynajmniej kilka sposobów? Gdzie decyzje technologiczne podejmuje się co 15 minut? Nawet gdyby teoretycznie było to możliwe księga wzorców projektowych musiałaby liczyć tysiące stron. A gdzie procedury decydowania, który wzorzec użyć? Po pierwsze nikt nie byłby w stanie tego opisać, a jeżeli nawet to potem nikt nie byłby się w stanie tego nauczyć :-)

Co więc zamiast ścisłych procedur? Po pierwsze określone ramy postępowania, czyli np. pracownicy wiedzą co jest ważne w danym rozwiązaniu: elastyczność czy wydajność. Po drugie właściwi pracownicy, którzy potrafią użyć swojej inteligencji do wybrania spośród znanych im rozwiązań tego najlepszego akurat w zadanych ramach. Co 15 minut :-) Tu problem jest większy, ale cóż za to w końcu firma płaci programiście albo innemu administratorowi, żeby to ON się znał na rzeczy. Jeżeli firma uważa, że ON się nie zna, to czemu go jeszcze zatrudnia? Pracownik musi być na tyle inteligentny i proaktywny, żeby potrafić zastosować w danym momencie rozwiązanie najlepiej realizujące cel postawiony dla danego oprogramowania. Jeżeli firmie uda się zbudować taki zespół i ustalić wspierającą go strukturę zarządzania to będzie ona na pewno bardziej "agile" (zwinna) niż firmy starające się opisać każdą decyzję pracownika w opasłym tomie procedur.

2 komentarze:

Anonimowy pisze...

Masz absolutną rację. Jednak procedury na pewnym poziomie ogólności są potrzebne. Moim zdaniem procedura jest niezbędna w sytuacji gdy decyzja wykracza poza kompetencje danego pracownika i/lub gdy swoją decyzję musi z kimś skonsultować. Ostatnio procedury coraz częściej służą kontroli pracy danego specjalisty aby czuł, że jest kontrolowany i korzystał z ogólnodostępnej w firmie bazy wiedzy, oszczędzając tym samym czas.

Patryk P. pisze...

Hm, fajny wpis pokdreślający tak na prawdę rolę każdego pracownika w innowacyjności firmy - używanie własnej kreatywności :) Procedury, jeśli już, powinny być na tyle elastyczne aby nie blokowały cennego czasu programisty i najlepiej jeśli sam będzie mógł zdecydować o tym co będzie lepsze. Tak jak napisałeś, jeśli nie potrafi - to dlaczego to właśnie on miałby programować ? Moim zdaniem warto również zorganizować priorytetowość decyzji, powiedzmy, trzypoziomowo - stopień pierwszy i drugi byłby otwarty dla pracownika z problemem. Dopiero trzeci wymagałby zorganizowania jakiegoś spotkania (i tutaj znów ukłon w stronę metodyk Agile, szczególnie Scruma). Często procedury zabijają pomysły pracowników które potrafią być na prawdę dobre acz niedostrzegane przez choćby managera :) Ps: rozwiązania które wprowadził google (pomijając już całą ich płaskość) w tej sprawie wydaje się bardzo fajne - podzielił programistów na małe zespoły i wpakował(ali się) w małe projekty - flow pracy oraz możliwość "dogadania" się (przy czym szybkiego rozwiązania danego problemu) stoi na bardzo wysokim poziomie :)

Pozdrawiam,
Patryk.