Wszystkim tym, którzy mają cierpliwość czytać tego bloga - bez względu na to czy się ze mną zgadzają czy nie - życzę wszystkiego najlepszego, dużo radości, ciekawych prezentów i miłych chwil.
A na nadchodzący 2008 rok, pełnej dokumentacji :-), ciekawych defektów oraz przede wszystkim zdrowia.
Wszystkiego najlepszego.
niedziela, 23 grudnia 2007
piątek, 7 grudnia 2007
Procesowość procesu
Na rynku dostępne są całe lasy literatury poświęconej procesom. Można je sobie oglądać z punktu widzenia zapewniania jakości, zarządzania projektem, SCM, czy testów.
Nie chcę tutaj pochylać się nad oczywistościami. Z całą pewnością dobrze zdefiniowany proces ułatwia skupienie się na samym projekcie, minimalizując elementy niezaplanowane i nieoczekiwane. Z drugiej strony każdy proces jest pewną generalizacją dokonywaną na podstawie przypadków konkretnych i reprezentatywnych. Oznacza to, że rzeczywistość jest bardziej ciekawa niż to może się wydawać krojniczym takiego procesu. Zawsze!
Bardzo często, mechanizmami obronnymi takiego procesu jest rozrost administracji w skrajnych wypadkach prowadzący do jakiejś formy tego, co Max Weber nazwał "złotą klatką racjonalizmu". W skrajnych przypadkach dla małych projektów, większa część czasu jest przeznaczona na obsługę samego procesu a nie na obsługę projektu.
Nie wchodząc w szczegóły poczyniłem następujące spostrzeżenia:
Nie chcę tutaj pochylać się nad oczywistościami. Z całą pewnością dobrze zdefiniowany proces ułatwia skupienie się na samym projekcie, minimalizując elementy niezaplanowane i nieoczekiwane. Z drugiej strony każdy proces jest pewną generalizacją dokonywaną na podstawie przypadków konkretnych i reprezentatywnych. Oznacza to, że rzeczywistość jest bardziej ciekawa niż to może się wydawać krojniczym takiego procesu. Zawsze!
Bardzo często, mechanizmami obronnymi takiego procesu jest rozrost administracji w skrajnych wypadkach prowadzący do jakiejś formy tego, co Max Weber nazwał "złotą klatką racjonalizmu". W skrajnych przypadkach dla małych projektów, większa część czasu jest przeznaczona na obsługę samego procesu a nie na obsługę projektu.
Nie wchodząc w szczegóły poczyniłem następujące spostrzeżenia:
- Działanie procesu w dużej mierze nie zależy na konstrukcji samego procesu ale na procesie zarządzania nim (np. zmuszanie programistów do pisania dokumentacji).
- Każdy proces powinien być definiowany na potrzeby konkretnej organizacji. Kopiowanie na wprost w tym zakresie zawsze się zemści!
- Każdy proces opracowany na potrzeby konkretnej organizacji musi być skalowalny (mini dla małych projektów, midi dla średnich projektów i maxi dla dużych projektów
- każdy proces musi mieć określony cel i powinien być wykorzystywany tylko w kierunku realizacji tylko tego celu. Każde nadużycie tej zasady może prowadzić do zmiany działającego procesu. W myśl zasady "lepsze" jest wrogiem "dobrego" efekt wcale nie musi być zachwycający.
- Materiał wyjściowy i wejściowy z i do procesu powinien być generowany możliwie najczęściej automatycznie minimalizując nakład ręcznego przygotowywania dokumentów
- Potrzebny jest miernik na jakim poziomie projekt powinien być opisany. Dla projektów run-and-forget powinien być to minimalny opis natomiast dla projektów o szerokim horyzoncie utrzymaniowym taki opis powinien być możliwie szczegółowy
- Role powinny być odseparowane. Developer woli programować niż pisać a technical writter woli pisać niż programować
- Jeden wspólny język dla całego procesu
Subskrybuj:
Posty (Atom)