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.

Założenia to przekleństwo

Czasami warto jest się przyjrzeć głębiej powodom, dla których podejmowane są działania uważane przez wszystkich za oczywiste. Dla przykładu pierwsza z brzegu rzecz czyli planowanie. Wszyscy wiemy, że to jest ważne, jest podstawą pracy itd. Projekty z definicji są działaniami, które są innowacyjne, które zawierają w sobie pewien element niepewności. Dlatego też musimy je planować a nie działać automatycznie jak to się robi w przypadku procesów. Plan jest następnie realizowany, po czym, w dużej części przypadków, następuje brutalne zderzenie z rzeczywistością, które dla planu okazuje się być nie do przeżycia. Zwykle w wyniku nieprzewidzianych zdarzeń muszą nastąpić poważne zmiany w planie jak i w samych produktach projektu.

Interesujące jest co dzieje się dalej. W większości środowisk, z którymi miałem do czynienia podejmuje się natychmiastowe działania naprawcze skupiające się wokół generalnego twierdzenia "musimy lepiej planować". Przez "lepiej" w tym wypadku określa się zwykle dogłębniej, dokładniej i bardziej szczegółowo. Generalnie bardziej kosztownie. I tu pojawia się pytanie następujące. Jakie założenie stoi za twierdzeniem, że więcej zasobów poświęconych na planowanie automatycznie przekłada się na lepszą realizacje tychże planów w przyszłości?

Jak dla mnie założenia za tym twierdzeniem są następujące "planując dłużej uzyskujemy większą kontrolę nad przyszłością" oraz "dłuższe planowanie powoduje zmniejszenie liczby zmian w przyszłości". Czy te założenia są prawdziwe? Wątpię. Czy to oznacza, że planowanie jest zbędne. Oczywiście nie. Oznacza tylko, że nigdy nie możemy oczekiwać, że maksymalne wydłużenie analizy i planowania spowoduje automatyczny sukces naszego projektu. Tak się nie dzieje. Od pewnego momentu mimo przeznaczania coraz większych nakładów na planowanie "uzysk" dokładności jest minimalny. A im działanie jest bardziej innowacyjne tym to "wypłaszczenie" następuje szybciej.

Co z tym zrobić? Może zamiast brnąć w taki system oparty na błędnym założeniu skonstruować system, który dostosowuje się do rzeczywistości. Czyli zadać sobie pytanie "jak powinien wyglądać mój system realizacji projektów jeżeli założę, że zmiany na pewno nastąpią". Jeżeli uda się taki system zbudować i wprowadzić w życie to zamiast walczyć z rzeczywistością otrzymamy organizację potrafiącą w danej rzeczywistości idealnie zarządzać.

P.S. Oczywiście powyższe wywody nie dotyczą pewnej klasy systemów, np. takich gdzie gra idzie o życie ludzkie (projektowania samolotów).

Innowacja zarządcza

Wśród wszystkich innowacji, które może wprowadzić firma jest jeden typ, który zajmuje miejsce szczególne. Tym typem są tak zwane innowacje zarządcze (mangement innovation).

Mianem innowacji zarządczej określa się innowację polegającą na odejściu od tradycyjnych paradygmatów zarządzania w danej branży lub danym rynku. W wyniku takiej innowacji powstają nowe procesy, praktyki czy też struktury zarządzania pozwalające firmie działać w sposób odmienny od całej konkurencji. Celem takiej innowacji jest to, aby firma po przekształceniach miała znaczącą przewagę konkurencyjną nad innymi uczestnikami rynku.

Przykłady? Każda firma pracująca w systemie projektowym jak ognia unika kar umownych za opóźnienie końca projektu. A co by się stało, gdyby pojawiła się firma, która sama dobrowolnie będzie chciała wpisywać takie kary do umów i to w kwocie znacznie przekraczającej to co do tej pory chciał zamawiający? Większość firm produkcyjnych produkuje pod prognozy sprzedaży, zwykle w perspektywie 6-12 miesięcy. Co by się stało, gdyby dostawca nie wymagał od sklepu prognoz sprzedaży, a i tak zawsze zapewniał mu dostępność towaru? “Wszyscy wiedzą”, że aby zacząć prace nad systemem informatycznym trzeba wcześniej dokładnie zdefiniować wymagania. A co by się stało, gdyby stworzyć proces, który tego nie wymaga? Jaką siłę na rynku miałyby takie firmy? Jak na ich oferty reagowaliby klienci?

Piękno innowacji zarządczej polega na tym, że zbudowana na jej podstawie przewaga konkurencyjna jest niezwykle trudna do skopiowania przez innych uczestników rynku. Z zewnątrz wszystko wygląda bowiem prosto i logicznie, tym niemniej dzięki temu, że jest to odejście od paradygmatu konkurencja nie może skopiować innowacji tylko poprzez skopiowanie praktyk czy procesów. Konkurencja musiałaby również zmienić swój paradygmat zarządzania. A to jest bardzo trudne. I wielu się nie udaje. Najlepszym przykładem są tutaj amerykańskie i zachodnioeuropejskie firmy produkcyjne, które próbują skopiować TPS (Toyota Production System). Niestety, mimo że TPS jest dość dokładnie opisany jego skopiowanie, rozumiane jako uzyskanie takich samych efektów biznesowych, idzie bardzo opornie i nawet jeżeli teraz możemy już mówić o jakichś sukcesach to zajęło to jakby nie patrzeć kilkanaście lat.

Tak więc innowacja zarządcza pozwala zbudować relatywnie trwałą przewagę konkurencyjną. Na tyle trwałą, aby można było bez pośpiechu przygotować kolejną innowację. Niestety ceną za taki komfort jest fakt, że innowacja zarządcza jest niesamowicie trudna do opracowania a jeszcze trudniejsza do wdrożenia. Dokładnie z tych samych powodów dla których tak trudno skopiować ją konkurencji. No ale cóż, tylko odważni i wytrwali zdobędą szczyty...

Jeżeli to kogoś zainteresowało to jedynym znanym mi systematycznym procesem pozwalającym na szukanie i weryfikację pomysłów na innowacje zarządcze są narzędzia myślowe oparte o TOC. Zaś implementacje takich innowacji można znaleźć opisane w Strategy & Tactic Trees opublikowanych przez Goldratt Institute Inc.

Przyczyna źródłowa

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

Dług technologiczny

Koncepcja długu technologicznego jest stara jak agile a ostatnio natknąłem się na nią przy okazji robienia czegoś zupełnie innego. Co to jest dług technologiczny? Oto jak kiedyś mi to wytłumaczono: cokolwiek co czyni Twój produkt trudnym do zmiany w przyszłości jest długiem technologicznym - możesz albo zapłacić pełną cenę technologiczną teraz (zrobić od razu rozwiązanie elastyczne) albo zaciągnąć dług i spłacić go później (zrobić rozwiązanie szybkie ale nieelastyczne a przy pierwszej konieczności zmiany mieć trudność z brakiem elastyczności). Dług ma to do siebie, że generuje odsetki. To znaczy, że jeżeli dzisiaj nie poświęcimy dwóch dni na uczynienie naszego produktu elastycznym, to w przyszłości jeżeli będziemy chcieli przeprowadzić zmiany nie będzie kosztowało to dwa dni, tylko dwa dni plus odsetki. Odsetki te niestety przyrastają zdecydowanie szybciej niż w popularnych bankach. Efektem skrajnym jest kiedy produkt staje się tak niepodatny na zmiany, że prościej jest takowy produkt zrobić od nowa niż zmienić stary (sam byłem w takiej sytuacji).

W szczególności dług technologiczny dotyczy kodu oprogramowania. Tam jest bardzo łatwo zrobić rozwiązanie, które jest mało elastyczne ale bardzo szybkie we wdrożeniu (np. użycie nieudokumentowanych funkcji - kto z nas tego nie robił ;-)). Zdecydowanie trudniej jest napisać kod, który jest elastyczny. Co więcej często wprowadzenie zmiany sprawia, że kod staje się mniej elastyczny. Wówczas, aby nie zaciągać długu należy przeprowadzić refaktoryzację i zmienić kod tak, aby elastycznym był. Pominięcie refaktoryzacji spowoduje pogłębianie się długu, produkt będzie coraz trudniejszy do zmian. Prędzej czy później trzeba będzie za to zapłacić. Z tego punktu widzenia czas poświęcony na refaktoryzację to nie jest koszt. Jest to raczej inwestycja. Dzisiaj inwestujemy dwa dni pracy po to, aby w przyszłości nie musieć inwestować 5 dni w przeprowadzenie prostej zmiany.

Agile w sposób naturalny wspiera eliminację długu technologicznego. Poprzez iteracyjność oraz fakt, że nikt w zasadzie nie wie nad jakim kawałkiem produktu będzie pracował w przyszłej iteracji wspiera się aktywnie tworzenie rozwiązania bardzo elastycznego. W zespołach bardzo często tworzenie rozwiązań elastycznych jest przyjmowane jako jedna z głównych zasad pracy. Niestety nawet w przypadku takim jak ten, kiedy metodyka wspiera takie działania można cały ten efekt zepsuć. Najprościej dzięki mało kompetentnym kierownikom projektów, którzy nie pozwalają własnym zespołom na pracę dobrą a wymagają tylko pracy szybkiej. Jeżeli jesteście w takiej sytuacji to wytłumaczcie proszę zarządzającym koncepcję długu technologicznego i odsetek od niego. Moje ostatnie doświadczenia wskazują, że takie podejście skutkuje.

Wdrożenia nowych metod - zadanie domowe

W środowisku osób zajmujących się wdrożeniami systemów zarządzania projektami (chodzi tu o systemy rozumiane jako zestawy procesów a nie oprogramowanie) do rangi anegdoty kultowej urosło podobno prawdziwe zdanie, wypowiedziane przez jednego z konsultantów pod koniec długiego i kosztownego projektu wdrażania nowej metody zarządzania projektami w pewnej firmie (XXX - nazwa metody zarządzania projektami):

“Jak na dziś to wszyscy już rzygają tym naszym XXX, w związku z czym wdrożenie uważam za w pełni zakończone sukcesem!!!”

Hmm. Przypadek wręcz kliniczny, który przypomniał mi się w ramach kolejnej rundy rozważań nad pewnym nieudanym wdrożeniem metod agile. Pytanie brzmi następująco. Jeżeli wdrażamy coś (cokolwiek) nowego w organizacji i jako efekt dostajemy aktywne niezaangażowanie osób do których adresowane było wdrożenie tego czegoś, to o czym to świadczy? Hipoteza jest taka, że po prostu nie odrobiliśmy pracy domowej i wdrożyliśmy rzecz, która jest absolutnie niepotrzebna z punktu widzenia osób zaangażowanych lub mimo, że rzecz jest potrzebna, to sposób jej wdrożenia jest nieadekwatny. Przez rzecz niepotrzebna rozumiem nie pozwalająca jednostkom na osiąganie lepszych rezultatów. Rezultatów mierzonych w sposób taki w jaki się je mierzy dla każdego konkretnego człowieka w tej konkretnej organizacji. Innymi słowy, mówiąc kolokwialnie z wprowadzonej przez nas zmiany człowiek “nic nie będzie miał”.

Oczywiste pytanie to czy każdy musi z tego wdrażanego rozwiązania coś mieć. Jasne, że tak! Bo skoro organizacja jako całość ma na danej nowości zyskać, to dlaczego nie mieliby zyskać poszczególni uczestnicy tej organizacji? Wszyscy uczestnicy. Z jakiego powodu tak często zakładamy, że wdrożenie czegoś nowego musi być robione przeciw ludziom a nie z ludźmi? Czy naprawdę jeżeli wdrażamy coś nowego to musi być tak, że ktoś będzie "rzygał" tym rozwiązaniem? Moja hipoteza jest taka, że absolutnie nie. Jeżeli rozwiązanie jest dobre dla całości organizacji, to musi być sposób, aby skonstruować je tak, aby było dobre dla wszystkich osób w nią zaangażowanych (odwrotnie nie działa). Powtarzam wszystkich. Tylko trzeba ten sposób znaleźć, dokładnie analizując sytuację.

Przed wdrożeniem trzeba odrobić pracę domową i zobaczyć jak zmiany proponowane przez agile mogą pomóc wszystkim innym interesariuszom projektów w organizacji. Ta pomoc musi zwłaszcza być sprawdzona w odniesieniu do miar, którymi mierzona jest efektywność pracy poszczególnych kierowników. Chodzi o to, aby tak skonstruować system zarządzania, że wprowadzenie nowych reguł spowoduje z punktu widzenia poszczególnych jednostek zmiany pozytywne. Bo na przykład będzie łatwiej osiągać właściwe cele lub choćby prezentować wyniki. Jeżeli nie zadbamy o to, aby wszystkim ważnym interesariuszom było łatwiej to osiągniemy efekt podobny do wyrażonego w przytoczonym cytacie. I osoby aktywnie niezaangażowane we wdrożenie, powodujące realne zagrożenie jego powodzenia.

Stąd, jak już kiedyś pisałem, jednym z większych błędów jakie można zrobić przy wdrażaniu agile jest wdrożenie samych tylko procedur. Trzeba zmienić jeszcze także inne elementy organizacji. A to jak je zmienić i na jakie, tak aby spowodować z jednej strony akceptację, a z drugiej zakładany efekt biznesowy to już jest zadanie domowe dla tych, którzy agile wdrażać będą. I gwarantuję dwie rzeczy:

1. nie jest to proste
2. nie ma gotowych rozwiązań (porównaj).

Wieloprojektowość

Wyobraźcie sobie szpital, w którym operuje się chorych. Teraz kierownictwo tego szpitala, jako że chce skutecznie i szybko leczyć swoich pacjentów nakazuje aby natychmiast jak tylko pojawi się pacjent kierować go na potrzebną mu operację. Pomyślcie co się zaczyna dziać na salach operacyjnych. Jak jest jeden czy dwóch pacjentów to jest jeszcze dobrze, potem zaczyna być ich coraz więcej (kierowani są na operacje od razu jak tylko się pojawią). W końcu jest ich więcej niż zespołów lekarzy chirurgów i sal operacyjnych. Co w tym momencie robi kierownictwo szpitala? Nakazuje, żeby jeden zespół lekarzy wykorzystujący jedną salę operacyjną jednocześnie robił kilka operacji. Przecież Ci lekarze to świetni specjaliści, na pewno jakoś dadzą radę. Tak więc zaczyna się dzielenie czasu. Nad jednym pacjentem godzina, potem godzina dla drugiego. W miarę jak rośnie ich liczba zaczyna się problem z dostępnością sal operacyjnych. Anestezjologów zresztą też brakuje. W związku z tym tworzymy listy dostępności sali wraz ze ścisłym harmonogramem, który chirurg kiedy operuje którego pacjenta a który anestezjolog gdzie asystuje. Sale są dokładnie na godziny, więc nie można się spóźniać. Problem w tym co chirurdzy mają robić w czasie, gdy nie mogą operować swojego pacjenta, bo sala jest zajęta. Najchętniej by poczekali, ale szefostwo szpitala nie chce marnować drogocennego czasu chirurgów. Przecież to są świetni specjaliści i nie mogą w pracy spędzać "nieproduktywnych" godzin. W związku z tym szefostwo nakazuje chirurgom robić obchody w czasie jak ich (już "rozpoczęty") pacjent czeka na wolną salę. Skutek jest taki, że przestają zdążać na swój czas w harmonogramie dostępności sali, bo nie mogą się oderwać od obchodów. A jak już przyjdą i zaczną operować to jak tylko się dobrze "wdrożą" w danego pacjenta okazuje się, ze muszą go zostawić, bo w harmonogramie skończył się czas dostępności dla nich sali operacyjnej. Anestezjolodzy mają podobny problem.

Jesteście oburzeni takim podejściem? Kto by się chciał tam leczyć?

Teraz proszę podstawicie sobie w powyższym przykładzie zamiast "pacjent" to "projekt", zamiast "chirurg" to "programista" a zamiast "sala operacyjna" to "serwerownia" (czy dowolny inny zasób, który jest wystarczający rzadki w Waszym środowisku). Brzmi znajomo? Nikt nie zadaje pytania "kto by kupił projekt od takiej organizacji"?

Ciekawe jest, że branża medyczna, jakkolwiek niedoskonała, już od dawna potrafi sobie radzić z taką sytuacją. W prosty sposób: dedykowane zespoły, priorytetyzacja wykorzystania kluczowych zasobów (najpierw ten co ma życie zagrożone a potem ten co operacja plastyczna), kolejkowanie pacjentów zamiast współbieżności. Śmiem twierdzić, że nawet w Polsce statystyki sukcesów są dużo lepsze dla operacji medycznych niż dla projektów, w tym zwłaszcza projektów innowacyjnych. Znaczy, że takie rozwiązania działają. Teraz wypadałoby podpatrzyć czy u nas nei da się tak samo. I tutaj niespodzianka. Zarządzanie zwinne bardzo podobnie podchodzi do portfolio projektów jak szpital do operacji. To znaczy: zespół jest dedykowany do jednego projektu (nie wolno pożyczać ludzi), projekty robi się jeden po drugim a nie współbieżnie, a priorytety zapewnia właściciel produktu. Czyli podobnie. Ciekawe, dlaczego skoro w branży medycznej te zasady uznajemy za taką oczywistość w projektach już nie.

Zwinne zarządzanie zmianą w organizacji

Parę tygodni temu obyłem inspirującą rozmowę z pewnym ciekawym człowiekiem. Rozmawialiśmy na temat projektu wprowadzenia zmian organizacyjnych w bardzo dużej firmie. Zmiany miały być na wielką skalę. Na tyle wielką, że projekt musiał być realizowany w etapach. Na sam koniec rozmowy poprzez tematykę etapów zeszło na metody skutecznego zarządzania takim projektem. Jedną z rozważanych hipotez stało się użycie metod zwinnych do zarządzania tymże projektem.

Na pierwszy rzut oka pomysł wydaje się być totalnie pozbawiony sensu. Podstawowym założeniem wszystkich metod zwinnych (wszystkiego co nazywa się agile) jest iteracyjne dostarczanie działającego produktu. Działającego produktu. A my mówimy o projekcie wprowadzenia zmian organizacyjnych. Więc nie spełniamy podstawowego założenia. Drugim założeniem bardzo ważnym dla metod zwinnych jest koncentracja na przepływie wartości dodanej dla klienta, której emanacją są definicje funkcjonalności. Dlatego w projektach zwinnych nie definiuje się struktury podziału pracy tylko strukturę podziału funkcjonalności produktu końcowego. Bo to ukończona funkcjonalność niesie wartość dodaną a nie praca wykonana. Znowu więc na pierwszy rzut oka nijak ma się to do wprowadzania zmian organizacyjnych w firmach. A na drugi rzut oka?

Załóżmy przez chwilę, że organizację jako całość traktujemy jako produkt. Klientem na ten produkt jest właściciel organizacji lub jego przedstawiciel (zarząd). Tenże produkt przynosi właścicielowi korzyści biznesowe (zwykle wyrażone dość konkretnie w pieniądzach). Aby te korzyści przynosić tenże produkt posiada zestaw funkcjonalności, pewnych działań realizowanych przez organizację, które to działania, każde z nich, ma pewną wartość dla klienta. Jeżeli by tej wartości nie miało to klient (właściciel) już dawno wyrzuciłby to działanie ze swojego produktu (organizacji).

Przy takim spojrzeniu nie ma przeszkód, aby zarządzać projektem zmian organizacyjnych przy użyciu metod zwinnych. Klient (właściciel) definiuje jakie nowe funkcjonalności powinien mieć produkt (organizacja). Na przykład organizacja powinna mieć dedykowany dział wsparcia klienta albo organizacja powinna zarządzać projektami według metod zwinnych. To jest funkcjonalność, której brakuje a która z punktu widzenia właściciela przyniosłaby realny wzrost wartości całej organizacji. Teraz taką funkcjonalność można potraktować tak jak w projektach zwinnych: rozbić na mniejsze, nadać priorytety i wspólnie z klientem zastanowić się co wdrażamy najpierw. A następnie powołany zespół projektowy ds. zmian organizacyjnych zacząłby takie zmiany wdrażać. Produktem dostawy po każdej iteracji byłaby cała organizacja, która wykazywałaby działające kolejne elementy zdefiniowanej funkcjonalności.

Takie podejście do tematu zmian organizacyjnych po krótkim zastanowieniu wydaje się być obiecujące. Nie dość, że wydaje się być możliwe do wdrożenia to ma jeszcze dwie ważne cechy. Po pierwsze traktując organizację jako produkt z określonymi funkcjonalnościami spowodujemy, że definiując co trzeba zmienić będziemy się patrzeć na funkcjonalności właśnie a nie działania, które mamy przeprowadzić. Podobnie jak w przypadku zwinnych projektów przestajemy rozmawiać o działaniach a zaczynamy się skupiać na efektach, które te działania mają przynieść. Dzieje się tak, gdyż właściciel podobnie jak klient chce efektów a nie działań. Druga ważna sprawa wynika wprost z poprzedniej. Skupienie się na efektach oznacza, że będziemy musieli rozważać wartość biznesową każdego z nich. (każdej nowej funkcjonalności, którą będzie miała mieć organizacja). A analiza wartości biznesowej wprowadzanych zmian jest czymś, co w przypadku tradycyjnie zarządzanych projektów zmian organizacyjnych rzadko się zdarza. Potencjalnie uzyskujemy bardzo dużo.

Powyższe to czysta spekulacja, ale czy to zadziała? Zgodnie z duchem zasad projektów zwinnych teoretyczna negacja jest zabroniona. Trzeba by przeprowadzić eksperyment. Szukam chętnych. Adres email w informacji o mnie po prawej stronie.

Metody zwinne a struktura organizacyjna

Czy struktura organizacji może mieć wpływ na zdolność do działania z wykorzystaniem metod zwinnych? Mogłoby się wydawać, że nie bo co ma struktura organizacji do metod wykorzystywanych w konkretnym projekcie. A jednak...

Dla uproszczenia przyjmijmy, ze mamy cztery podstawowe struktury organizacyjne:

• Liniowa - organizacja dzieli się na działy, które realizują poszczególne elementy projektu. Każdy dział dostaje do realizacji ten kawałek projektu który odpowiada jego specjalizacji. Cała władza skupia się w rękach kierowników liniowych.
  
• Macierzowa słaba - do organizacji liniowej wprowadza się koordynatorów projektów, którzy koordynują pracę osób w poszczególnych działach. Ich zadaniem jest jednak jedynie koordynacja prac, bez możliwości realnego wpływania na pracowników. Bezpośrednimi przełożonymi pracowników są kierownicy liniowi.
  
• Macierzowa silna - różni się od macierzowej słabej tym, że pojawia się pełnowartościowy kierownik projektu, który ma odpowiedzialność za projekt ale również uprawnienia do władzy na członkami zespołu projektowego. Kierownicy liniowy pełnią funkcje pomocnicze dbając o zapewnienie personelu, bieżące zarządzanie kompetencjami, sprawy formalne itp.
  
• Projektowa - organizacja całkowicie projektowa nie posiada struktur liniowych a tylko pulę pracowników, z których wybiera się członków zespołów projektowych. Kierownik projektu ma pełną odpowiedzialność i uprawnienia do zwierzchnictwa nad członkami zespołu projektowego.
  

Którą należałoby wybrać dla realizacji projektów metodami zwinnymi? Zanim się na to pytanie odpowie najpierw kilka słów o tym czym powinien charakteryzować się zespół pracujący nad projektem metodami zwinnymi. Poniżej tylko cechy właściwe dla tej dyskusji:

1. Zespół jest interdyscyplinarny - skupia ludzi o różnych umiejętnościach ale jednocześnie każdy członek zespołu może wchodzić w różne role
   
2. Zespół ponosi pełną odpowiedzialność za wykonywaną pracę
3. Zespół ma wszelkie uprawnienia potrzebne do wykonywania zadanej pracy
4. Kluczowy członkowie zespołu pracują tylko i wyłącznie nad jednym projektem
   

W przypadku organizacji o strukturze liniowej żadna z tych cech nie mogłaby być spełniona. Nie ma interdyscyplinarności - w ramach jednego zespołu linowego osoby posiadają prawie identyczne umiejętności. Zespół nie może ponosić pełnej odpowiedzialności za całość prac, bo z definicji wykonuje tylko ten jej kawałek za który odpowiada komórka organizacyjna w której pracuje. Zespół nie ma uprawnień do wykonywania całej pracy a jedynie tego kawałka, który dotyczy ich części organizacji. Ponieważ organizacja jest liniowa a nie projektowa najczęściej pracuje "nad zagadnieniem", które jest w wielu projektach. Cecha czwarta też nie jest spełniona. W takich warunkach nie można prowadzić projektu metodami zwinnymi!!!

W przypadku organizacji macierzowej słabej cecha pierwsza ma się trochę lepiej. Zespół pochodzi z różnych działów, więc jest interdyscyplinarny. Cecha druga jednak nie jest już spełniona, gdyż nadal zespół nie posiada odpowiedzialności - posiadają ją kierownicy liniowi. Podobnie z uprawnieniami - mimo iż jest zespół projektowy to nie ma on możliwości podejmowania decyzji, która leży w gestii kierowników liniowych. Co do cechy czwartej to w tej strukturze organizacyjnej często jest możliwe osiągnięcie stanu kiedy członkowie zespołu projektowego pracują nad jednym i tylko jednym projektem.

Wszystkie cechy zespołu zwinnego są możliwe do osiągnięcia tylko w organizacjach projektowych i macierzowych silnych. Macierzowe silne muszą być na tyle silne, aby rola kierowników liniowych faktycznie ograniczała się tylko do spraw administracyjnych. Trzeba mieć możliwość traktować ich jako wsparcie administracyjno-logistyczne. Jeżeli w rękach kierowników liniowych pozostanie możliwość podejmowania (blokowania) decyzji to okaże się, że zespół zwinny nie będzie miał ani uprawnień ani odpowiedzialności za projekt.

Co z tego wszystkiego wynika? Otóż jeżeli jakaś organizacja będzie chciała wdrożyć zwinne zarządzanie projektami to musi się też zastanowić nad tym, czy jednocześnie nie należy zmienić struktury organizacyjnej. Bardzo często może to powodować spięcia. Przejście z organizacji liniowych czy macierzowych słabych do bardziej zorientowanych projektowo oznacza bowiem, że kierownicy liniowi tracą część swojej władzy. To zaś zawsze jest dla ludzi trudne...

Przerwanie iteracji

Kilka osób pytało się jakie jest moje zdanie na temat przerywania iteracji w projekcie zarządzanym metodami zwinnymi. Zgodnie z pierwsza zasadą konsultanta prawidłowa odpowiedź powinna brzmieć "to zależy". I tak jest w rzeczywistości. Podjęcie decyzji o przerwaniu iteracji jest wynikiem działania czynników środowiska w którym przebiega dany projekt i trudno dać tu odpowiedź zawsze prawdziwą. Tym niemniej mogę podzielić się paroma wskazówkami.

Podjęcie decyzji o przerwaniu iteracji powinno być działaniem ostatecznym podejmowanym tylko wtedy jeżeli żadna inna technika zarządcza nie przyniesie lepszych biznesowo skutków. Podejście iteracyjne jest jedną z podstawowych zasad zarządzania zwinnego i jako taka nie może być w dowolny sposób łamana. Złamanie tej zasady musi mieć mocną podstawę biznesową i za każdym razem powinno być zatwierdzane przez najwyższe władze danego projektu (sponsora lub komitet sterujący). W interesie kierownika projektu jest jednak, aby takie decyzje nie były podejmowane. Podjęcie ich i złamanie tym samym umowy zawartej na początku iteracji może bowiem bardzo szybko doprowadzić do chaosu w projekcie. Jeżeli bowiem raz zapadnie zgoda na przerwanie iteracji to później powołując się na ten precedens bardzo łatwo będzie podjąć tego typu decyzje po raz kolejny. Dlatego kierownikowi projektu dla jego własnego przyszłego spokoju powinno zależeć na dotrzymaniu umów i nie przerywaniu iteracji.

Prześledźmy w jakich przypadkach najczęściej pojawia się pokusa przerwania iteracji i jakie są opcje w tych przypadkach.

Przypadek pierwszy i najczęstszy to sytuacja, kiedy w czasie trwania iteracji nagle okazuje się, że klient już nie chce produkowanej przez nas aktualnie funkcjonalności. W takim przypadku przerwanie iteracji nie powinno nastąpić. Iteracje w projektach zwinnych są dość krótkie (maksimum 8 tygodni), więc sytuacja kiedy w czasie trwania iteracji klient nagle przekonuje się, że pewna funkcjonalność na którą sam się zgodził kilka tygodni temu nie jest mu potrzebna nie powinna się wydarzyć. Jeżeli się zaś wydarzy to, choć to trudne, umów trzeba dotrzymywać. Na początku iteracji wszystkie strony zgadzają sie co do zakresu danej iteracji i podobnie jak klient oczekuje od zespołu, że nie wycofa się z podjętego zobowiązania tak samo zespół ma prawo oczekiwać, że nie wycofa się klient. Dodatkowo przerwanie iteracji z taką motywacją spowodowałoby, że w produkcie pozostałyby pewne ślady już wykonanej a nie dokończonej pracy. To mogłoby mieć negatywny wpływ na przyszłą stabilność i jakość produktu. Dlatego prace należy dokończyć. Sporne funkcjonalności mają być wykonane z pełną jakością a w produkcie końcowym mogą być na przykład zakomentowane czy w inny sposób ukryte. Ewentualne nowe funkcjonalności trzeba zrealizować zgodnie z procesem w następnej iteracji. Przed następną iteracją należy się tylko zastanowić, czy w związku z nagłymi zmianami zakresu nie należałoby zmodyfikować (skrócić) czasu trwania iteracji. Taka decyzja musi być podjęta w gronie kierownictwa projektu i nie może być pochopna.

Inny klasyczny przypadek to sytuacja kiedy w trakcie pracy nad funkcjonalnością w ramach iteracji zespół zorientował się, że nie ma możliwości technicznego stworzenia zakładanej funkcjonalności. Przypadek dużo trudniejszy od poprzedniego. Przede wszystkim jeżeli taka sytuacja nastąpiła należy rozważyć możliwość wykonania zakładanej funkcjonalności w technicznie inny sposób niż to było planowane na początku. Drugą opcją jest modyfikacja funkcjonalności w taki sposób, aby była ona wykonalna. Obie te decyzje muszą być skonsultowane ze wszystkimi zainteresowanymi w tym przede wszystkim z klientem / właścicielem produktu. To do niego bowiem należą wszystkie decyzje produktowe w projekcie i będzie on miał ostatnie zdanie w kwestii rozwiązania takiego problemu. Jeżeli nie ma możliwości wykonania danej funkcjonalności w inny technicznie sposób ani klient nie jest chętny zmienić funkcjonalności tak aby była wykonalna to są znowu dwie opcje. Albo zakańczamy iterację i przygotowujemy nową, albo w ramach danej iteracji zespół zobowiązuje się wykonać inną funkcjonalność. Zależy to od wielu czynników (z których najważniejszym jest czas jaki pozostał do końca danej iteracji), lecz w celu zapewnienia spójności zarządzania projektem w większości znanych przypadków lepiej zastosować podejście drugie.

Jedyny znany mi przypadek kiedy bez żadnych obiekcji należy wygasić (ale nie raptownie zakończyć) iterację to sytuacja kiedy znikło uzasadnienie biznesowe dla realizowanego projektu. Projekty są realizowane po to aby organizacje osiągnęły mierzalne rezultaty. Jeżeli nie ma możliwości osiągnięcia tychże rezultatów to kontynuowanie prac nad projektem i dalsze generowanie kosztów przestaje mieć sens. Jeżeli taka sytuacja zaistnieje to projekt należy poprawnie zamknąć, czyli dokończyć rozpoczęte prace, udokumentować wykonane prace, zarchiwizować dane, stworzyć "lessons learned" z projektu itp. Pod żadnym pozorem nie może to być rzucenie wszystkiego i odejście od biurek. Sygnał do podjęcia takich działań musi wyjść od sponsora projektu i być potwierdzona przez właściciela produktu/klienta.

Podsumowując: zwinne zarządzanie projektami rządzi się relatywnie małą ilością zasad. Zasady te powinny być jednak rygorystycznie przestrzegane, bo bardzo łatwo jest znaleźć się po drugiej stronie cienkiej linii, gdzie już rządzi czysty chaos. Iteracyjność jest jedną z tych podstawowych zasad i nie wolno jej łamać bez posiadania twardych, biznesowych dowodów na słuszność takiej decyzji.

Zwinne zmiany

Nawiązując jeszcze do wspomnianego już tematu zmian w projektach chcę obalić jeden mit związany ze zmianami, tym razem w projektach zarządzanych technikami zwinnymi. Ale od początku.

Oprócz tzw. "standardowych" czy też "tradycyjnych" metod zarządzania projektami istnieje też bardzo bliska mi klasa metod zarządzania projektami określana wspólnym mianem "Agile Project Management" czy też po naszemu zwinnym zarządzaniem projektami. Nadaje się rewelacyjnie do zarządzania projektami o wysokiej niepewności, czyli projektami zwinnymi. Jedną z fundamentalnych wartości zwinnego zarządzania projektami jest:

Responding to change over following the plan.

Czy odpowiadanie na zmianę jest bardziej wartościowe od trzymania się planu. Trzymanie się planu oczywiście też jest wartościowe, odpowiadanie na zmianę jest jednak bardziej wartościowe. O innych wartościach (są 4) zwinnego zarządzania projektami możecie przeczytać tutaj.

Teraz uwaga! Wiele osób błędnie interpretuje wspomniane zwinne podejście jako zachętę do wprowadzania dowolnych zmian, w dowolnych chwilach i generalnie wyrzucenia planu (i planowania) do kosza. To mit i duże nieporozumienie. Zwinne nie znaczy chaotyczne. Odrzucenie planowania i niekontrolowane zmiany prowadziłoby w prosty sposób do chaosu. A zwinne zarządzanie projektami rządzi się ścisłymi zasadami, których łamać nie można. Podobnie jak nie można ich łamać w tradycyjnym zarządzaniu. Łamanie zasad zawsze prowadzi do chaosu, niezależnie od techniki zarządzania.

Aby wyjaśnić temat zmian w zwinnym zarządzaniu należy jednak zacząć od czegoś bardziej fundamentalnego. Projekty zarządzane technikami zwinnymi zawsze realizowane są w iteracjach. Każda z iteracji dostarcza w pełni kompletny, ściśle określony podzbiór ostatecznej funkcjonalności produktu końcowego. Mówiąc prościej: każda iteracja dostarcza wartość dla klienta w postaci działającej wersji produktu. W związku z tym w dowolnym punkcie projektu funkcjonalności produktu końcowego można podzielić na trzy grupy: te, które zostały już zrealizowane, te które są realizowane w bieżącej iteracji oraz te które są do zrealizowania w przyszłych iteracjach. Jedną z najważniejszych zasad zwinnego zarządzania projektami jest: nie wolno wprowadzać zmian do funkcjonalności realizowanej w bieżącej iteracji. Funkcjonalności, które już zostały zrealizowane wolno zmieniać, trafiają one wtedy na listę do realizacji. Funkcjonalności z listy do zrobienia można oczywiście modyfikować bez żadnych warunków. Jeżeli istnieje dobrze uzasadniona potrzeba zmiany funkcjonalności realizowanej w ramach bieżącej iteracji to taką funkcjonalność wprowadza się jako nową na listę funkcjonalności do zrealizowania w przyszłości.

Jaki jest tego skutek? Otóż zespół projektowy w dowolnym momencie trwania projektu zarządzanego technikami zwinnymi pracuje nad niezmiennym zestawem funkcjonalności. Do czasu zakończenia danej iteracji ten zestaw wymagań nie może ulec zmianie. Ewentualnie zmiany pojawią się jako nowe funkcjonalności do zrealizowania w następnej iteracji. W ramach bieżącej zestaw wymagań zawsze jest stały i zawsze ma być ukończony na koniec iteracji. Zwinne oznacza stabilne. Zespół projektowy w każdej chwili zna minimalny zakres czasowy stabilności wymagań: do końca danej iteracji. Odpowiadanie na zmiany jest wyrażane w przyszłych działaniach a nie w natychmiastowej zmianie zakresu pracy dla grupy realizującej projekt. Złamanie tej zasady prowadzi do chaosu. Jest to zupełnie inna sytuacja niż w przypadku projektów zarządzanych tradycyjnie, gdzie zmiana może nastąpić w dowolnej chwili, jak tylko odpowiednie ciało zarządzające zmianami je zatwierdzi.

Wbrew pozorom doświadczenie wskazuje, że członkowie projektów (programiści - z tej branży mam doświadczenia) wolą pracować w stabilnym środowisku zwinnym niż w tradycyjnym projekcie, w którym zmiany spadają nie wiadomo w której chwili i to zwykle z klauzulą "do zrobienia jak najszybciej". Również wbrew temu co mogłoby się wydawać zmiany dotyczące już dostarczonej funkcjonalności po pewnym czasie zaczynają występować bardzo rzadko i projekt zwinny uzyskuje dużą stabilność. Dzieje się tak ze względu na mechanizm wyboru funkcjonalności do realizacji i jego wpływ na decyzje klienta. Ale to już temat na inną historię.