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
7 komentarzy:
...Dodał bym:
- proces pomaga lepiej (efektywniej) pracować dobrym inżynierowm, ale nawet najlepszy proces nie pomoże gdy brak kompetencji merytorycznych...
- proces powinien być ciągle doskonalony przez jego "użytkowników" bo ważne aby gonić króliczka...ciągle, albo przynajmniej iteracyjnie :)
- w procesie konieczna jest świadomość dlaczego coś robię, jaki jest cel konkretnej praktyki. jesli tego brakuje (z różnych względów) praktyka (nawet najbardziej oczywista) jest ignorowana
- na zly proces, z którym się zespół nie utworzsamia zawsze znajdzie obejście - taki "bypass"
- w implementacji procesu istotna jest edukacja i komunikacja. Brak tych elementów utrudnia identyfikowanie się uczestników z procesem
- wdrożenie procesu powinno zagwarantowac poparcie sponsora. Brak wsparcia decydentów to częsta przyczyna niepowodzeń.
Podoba mi się zdanie o koniecznosci wspólnego języka. Ostatnimi czasy podoba mi się Eclipse Process Framework Composer (EPF) jako zgrabna platfroma wykorzystywania gromadzonej wiedzy w przyszłych projektach.
Czy można przez to rozumieć, że autor jest przeciwnikiem procesów?
Może lepiej mówić o praktykach niż jednym wielkim, "cieżkim" procesie?
Wydaje mi się że z faktu, że każda strona (pukt widzenia) patrzy na ten proces trochę inaczej, no i że nie ma wspólnego języka wynikają problemy i niezrozumienie.
Chciałbym poznać zdanie autora na temat pytania kto powinen być "krojniczym" takiego procesu?
"proces pomaga lepiej (efektywniej) pracować dobrym inżynierowm, ale nawet najlepszy proces nie pomoże gdy brak kompetencji merytorycznych..."
Moim zdaniem proces powinien uwzględniać potrzeby zarówno jednych jak i drugich. W minimalistycznej wersji nie powinien ograniczać ludzi mierzących wyżej i ułatwiać zdobywanie kompetencji tym, którzy zostają w tyle. Ale to tylko jeden z aspektów procesu i to wcale nie najważniejszy. Jest to o tyle trudne, że w większości przypadków tych bardziej kompetentnych obciąża się obowiązkiem douczania tych mniej kompetentnych. Ale szczerze mówiąc nie ma chyba innego rozwiązanie, które byłoby praktyczne. Problem polega na przekonaniu tych pierwszych, że dla nich też jest to rodzaj doświadczenia. Taki układ nie jest zły do momentu kiedy nie obciąża ani jednych ani drugich. Nie ma przedsiębiorstw wymagających pracy samych ekspertów - w prawdziwym sensie tego słowa. Jest wiele zadań, wymagających przeciętnych umiejętności, które z natury odrzucane są przez ambitnych a z powodzeniem mogą być wykonywane przez tych, których kompetencje i umiejętności są wystarczające do tych celów.
Scenariusz maxi to taki proces, który wspiera najlepszych oraz eliminuje różnice kompetencyjne w sposób ciągły.
Zaznaczyć tutaj jednak muszę, że taki kształt procesu to bardzo wyrafinowany i dojrzały proces. Nie wiele firm potrafi dotrzeć do tego etapu.
"proces powinien być ciągle doskonalony przez jego "użytkowników" bo ważne aby gonić króliczka...ciągle, albo przynajmniej iteracyjnie :)"
Chyba nie istnieje proces, który się nie rozwija!? I to chyba jest przyczyna, dlaczego implementacja procesu jest tak trudna. Czasami przypomina to żywy organizm.
Problem polega tylko na świadomości tego faktu. Jeśli kierownictwo firmy nie jest świadome tej cechy, to w takich okolicznościach proces bardzo szybko się degeneruje i odchodzi od zamierzonych celów. Każdy konsultant, czy każda firma próbująca wdrożyć proces utworzony w przysłowiowym "gabinecie" powinna być szybko zwolniona. Warunkiem udanej implementacji o kontrolowanego rozwoju procesu jest uwzględnienie doświadczeń jego użytkowników.
Iteracyjność jest jednym ze sposobów wdrażania procesów, która wedle mojej opinii jest najbardziej efektywna kiedy iteracje nie są zbyt obszerne. W przypadku długich i skomplikowanych iteracji, zauważam tendencję do powstawania poditeracji lub co gorsza "krojenia" procesu w locie.
"w procesie konieczna jest świadomość dlaczego coś robię, jaki jest cel konkretnej praktyki. jesli tego brakuje (z różnych względów) praktyka (nawet najbardziej oczywista) jest ignorowana"
Każdy proces na poziomie organizacji ma zazwyczaj cele złożone, które są mapowane na cele podrzędne definiowane na poziomie i w kształcie zrozumiałym dla danego działu. I wyjaśnienie, upewnienie się, że cel został właściwie zrozumiały oraz kontrolowanie kursu realizacji tego celu, należy do podstawowych obowiązków każdej osoby odpowiedzialnej za realizację zadań.
"na zly proces, z którym się zespół nie utworzsamia zawsze znajdzie obejście - taki "bypass""
Nie wiem czy zły proces ma szansę w ogóle zafunkcjonować!? Owszem, może on być źle zaprojektowany, w oparciu o zbyt wyidealizowany ogląd organizacji ale takie ułomności da sie usunąć w fazie analizy projektu. Jeżeli proces źle działa to po prostu znaczy, że jest źle zarządzany i wtedy rzeczywiście degeneruje bardzo szybko.
"w implementacji procesu istotna jest edukacja i komunikacja. Brak tych elementów utrudnia identyfikowanie się uczestników z procesem"
Dodałbym tutaj jeszcze 'sprzedanie procesu', czyli przekonanie potencjalnych uczestników, że warto. Bez tych trzech czynników, architekcie procesu skazują swoje przedsięwzięcie jeśli nie na klęskę to na wielkie trudności.
"wdrożenie procesu powinno zagwarantowac poparcie sponsora. Brak wsparcia decydentów to częsta przyczyna niepowodzeń."
To także są uczestnicy procesu i od nich należy zaczynać przekonywanie oraz przejrzyste określenie ich ról. Sponsor musi byś świadomy swojej roli jako współkreatora implementacji procesu.
"Czy można przez to rozumieć, że autor jest przeciwnikiem procesów?"
Absolutnie nie! Proces istnieje tak czy inaczej, bez względu na to czy istnieją przeciwnicy czy zwolennicy. Jest to po prostu kwestia wpływu na kształt i cele procesu. Niekontrolowany proces ma cele rozmyte i często dryfuje od punktu do punktu. Natomiast dobrze zanalizowany proces zastany, uregulowany i ukierunkowany, pozwala osiągać cele i przede wszystkim wymaga definicji tych celów na poziomie trochę mniej ogólnym.
"Może lepiej mówić o praktykach niż jednym wielkim, "cieżkim" procesie?
Wydaje mi się że z faktu, że każda strona (pukt widzenia) patrzy na ten proces trochę inaczej, no i że nie ma wspólnego języka wynikają problemy i niezrozumienie."
Ja jestem zwolennikiem raczej ujęcia tego w kontekście poziomów. Coś w rodzaju baby w babie. Duży proces składa się z kilku średnich. Średni proces z kilku mniejszych. A mniejszy proces z jednego lub kilu mini procesów. Ale to wymaga trochę więcej pracy. Każdy z takich procesów podlega iteracjom no i każdy z nich zawiera warstwę META, która dla małych procesów powinna być możliwie mini. Mając takie koła zębate można dobierać liczbę i wielkość i zakres w zależności od realizowanego projektu.
"Chciałbym poznać zdanie autora na temat pytania kto powinen być "krojniczym" takiego procesu?"
Nie jestem zwolennikiem tworzenia procesu z góry na dół! Uważam, że każda zainteresowana strona najlepiej opisze sposób w jaki pracuje i zidentyfikuje problemy z którymi się boryka. Problem polega na połączeniu poszczególnych podprocesów w jeden duży, tak aby spełniał on swoją rolę także na poziomie całej organizacji a nie tylko na poziomie pojedynczej komórki. Proces budowany oddolnie w sposób moderowany pozwala osiągnąć taki efekt i jednocześnie pozwala na identyfikację, tych obszarów które wymagają kompromisu lub wręcz ustępstw jednej grupy zainteresowanych na rzecz innych. I znowu, na poziomie technicznym sprawa jest prosta, natomiast na poziomie zarządzania, pojmowania interesów przez poszczególne działy, zespoły... to jest wyzwanie dla koordynatora implementacji takiego procesu.
Podoba mi się stwierdzenie "...w sposób moderowany...", który oddaje trudności budowy kompletnej metodyki projektu i jej póżniejszej optymalizacji. Wydaje się, że problemem jest brak wśród liderów poszczególych kawałków szerokiego spektrum wiedzy na temat wszystkich podprocesów jakie powinny być zorganizowane w projekcie. Ludzie czesto nie chcą wygladać poza swój horyzont oczekujac, że ktos zrobi to za nich. Poszczególne role dobrze znają swoją dziedzinę, są w stanie zorganizować a także doskonalić zasady pracy we właściwym dla swojej roli obszarze. Gorzej jest z integracją i pogodzeniem różnic interesów poszczegołnych ról\podprocesów. Potrzebny jest w tym przypadku autorytet (np kierownika projektu) pozwalajacy rozstrzygnąć i narzucić optymalny dla projektu sposób działania także szerokie spektrum wiedzy na temat poszczególnych obszarów, praktyk, zalezności między nimi. Nie bez znaczenia jest wiedza z zakresu SPI, monitorowania i mierzenia procesów
Poruszyłeś tutaj dwie, bardzo istotne kwestie: autorytet kierownika i coś co nazwałbym "świadomością jakości" na tak zwanych wyższych szczeblach.
W dzisiejszym świecie kierownictwo zdaje się bardzo nieśmiało korzystać ze swojego autorytetu w dziedzinie jakości. Wdrożenie procesów wspierających jakość - tak jak każda zmiana w organizacji - wymaga wsparcia tego autorytetu. Kierownictwo jednak udziela go chyba nazbyt skąpo - przypuszczam, że dla tego, iż nie bardzo rozumie do czego to służy. Prawdopodobnie po części wynika to z tego, że informatyka sama w sobie jest rzemiosłem bylejakości... znaczy się, łatwo jest osiągnąć cokolwiek w byle jaki sposób.
I tutaj przechodzimy to "świadomości jakości". Symptomatyczne jest to, że mamy CFO, CTO, CXO a nie ma czegoś takiego jak CQO... ale to jest rola wszystkich tych, którzy na co dzień są odpowiedzialni za jakość aby uzmysławiać wagę tego problemu. Pracując z szefem, który rzeczywiście postrzega jakość jako istotny element krajobrazu biznesowego jest dużą przyjemnością... ale z drugiej strony dużą sztuką jest przekonać go do tego... i bynajmniej rzadko skutkują argumenty typu pomniejszenie kosztów utrzymania. Bo cóż znaczą nagrody w przyszłości kiedy teraz chwieje się cały projekt.
Bardzo ciekawy. Myślę, że fajne są też szkolenia ISTQB poziom podstawowy :)
Prześlij komentarz