środa, 18 kwietnia 2007

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ę.

poniedziałek, 16 kwietnia 2007

Dlaczego dobrzy mangerownie nienawidzą innowacji

Prezentację pod takim intrygującym tytułem znalazłem nie tak dawno w sieci. A że zostałem przywołany do głosu na blogu Alexa to podzielę się swoimi spostrzeżeniami wcześniej niż miałem zaplanowane i trochę na szybko.

Prezentację znalazłem na stronach Charles'a Leadbeater'a. Bezpośredni link do prezentacji tutaj. Powody dla których dobrzy managerowie nienawidzą innowacji:
  • Innowatorzy wspierają przyszłość, podczas gdy skuteczne firmy lubią wzmacniać stare sukcesy
  • Innowacje wymagają wolnych mocy przerobowych, podczas gdy managerowie chcą by organizacje były produktywne, żadnego marnowania
  • Trzeba się oduczyć, żeby stworzyć miejsce na coś nowego, podczas gdy tożsamość managerów pochodzi z przeszłości
  • Innowacja to twórczość i wolne wyzwania, podczas gdy bycie managerem oznacza branie odpowiedzialności
  • Innowacja zaczyna się od przyznania się do niewiedzy, podczas gdy bycie managerem oznacza znanie odpowiedzi
  • Innowacja oznacza zapożyczanie i pokorę, podczas gdy managerowie nienawidzą przyznawać się, że ktoś jest lepszy
  • Innowacja rodzi się na styku środowisk, podczas gdy managerowie pozostają w swoich biurach
  • Innowatorzy mają historie do opowiedzenia, podczas gdy managerowie mają plany, liczby i udziały w rynkach
Prezentację i powody te powinien znać każdy, kto w jakiejkolwiek organizacji chce zabrać się za proponowanie lub wdrażanie innowacji. Bardzo często zdarza się, że wprowadzanie jakiejkolwiek zmiany w firmie a w szczególności zmiany innowacyjnej to "droga przez mękę". Najczęściej pierwsze na co człowiek trafia to mur czegoś, co zwykle uważa się za niechęć czy wręcz awersję. Nieumiejętne podejście do tego może zostawić wrażenie, że organizacja składa się z postępowych innowatorów i nic nie rozumiejących managerów. Tymczasem jest inaczej.

Mimo treści, która może być odebrana jako agresywna powyższe tezy warte są uwagi i spokojnego przemyślenia. Największą zaletą wynikającą z przemyślenia tych tez może być zrozumienie różnicy w światopoglądzie (angielskie mind-set, nie wiem jak to lepiej przetłumaczyć) innowatora i managera "organizacji funkcyjnej", do którego taki innowator zwykle musi zwrócić się o akceptację pomysłu i/lub przyznanie środków na jego realizację.

Kiedyś pewien mądry człowiek przekonywał mnie, że każdy człowiek ma rację... ze swojego punktu widzenia. Zawarte powyżej tezy dobrze naświetlają punkt widzenia managera organizacji. Znajomość tego punktu widzenia i jasne porównanie go do "innowacyjnego" punktu odniesienia pomoże znaleźć argumenty, które przekonają drugą stronę do naszych pomysłów. Poznanie potrzeb i światopoglądu pozwoli w prostszy sposób dojść do sytuacji typu wygrana-wygrana, w której szanowane i zaspokajane będą potrzeby obu stron. To znów lepiej na przyszłość ułoży stosunki między obiema stronami i znacznie zwiększy szanse powodzenia projektu.

Wszystkim zaś managerom liniowym/funkcyjnym w organizacjach bardzo polecam zapoznanie się z całością prezentacji a zwłaszcza z radami, które tam występują. O ile oczywiście zależy Wam na tym, aby Wasza organizacja była innowacyjna. I na tym, aby lepiej zrozumieć tych dziwnych ludzi, którzy przychodzą do Was i coś chcą zmieniać.

Kierownik projektu a zmiany

Czytam właśnie znaną i uznaną książkę na temat zarządzania projektami. Polecana przez dużą część znanych mi kierowników projektów. Wszystko z tą książką było dobrze do czasu aż nie doszedłem to rozdziału pt. "Zarządzanie zmianą w projekcie". Zaczął się całkiem interesująco, ale gdzieś tak w czwartym-piątym akapicie natrafiłem na takie zdanie i to jeszcze wytłuszczone:

"Zadaniem kierownika projektu jest unikanie zmian."

Przeczytałem raz, drugi, trzeci. Zdanie nie znikło. Więcej jego parafrazy pojawiały się odtąd regularnie w całym rozdziale. Ciekawe spojrzenie na rolę kierownika projektu. Zdecydowanie odległe od mojego.

Umówmy się: dzisiejszy świat zwariował. A wydatnie pomogły w tym techniki komunikacyjne. W tym świecie dzieje się za dużo, żeby ktokolwiek mógł to opanować i co więcej o wszystkim tym jesteśmy informowani czy tego chcemy czy nie. W związku z tym nie ma praktycznie możliwości, aby jakikolwiek plan odpowiadał rzeczywistości. Proces tworzenia planu musi się bowiem opierać o pewne dane, które trzeba "zamrozić" na czas tworzenia planu, co często trwa dość spory kawałek czasu. W tym samym czasie zmienia się rzeczywistość i założenia na podstawie których plan został stworzony. Dlatego każdy plan jest przestarzały w chwili kiedy skończymy go opracowywać. To w sposób oczywisty wcześniej lub później prowadzi do sytuacji, kiedy zauważamy, że to co robimy w sposób nieoptymalny odpowiada rzeczywistości. Kluczowe pytanie polega na tym jak w takiej sytuacji zareagować?

Są dwa podejścia: trzymamy sie planu ("zadaniem jest unikanie zmian") albo odpowiadamy na zmianę. Które podejście jest lepsze? Zapytam inaczej: jako ostateczny użytkownik/klient produktu wytwarzanego w ramach projektu jak byście chcieli żeby zachował się kierownik projektu?

Żeby się przekonać zobaczmy to na przykładach. Z dziedziny jak najbardziej odległej od bliskiego mi wytwarzania oprogramowania. Zwykle mówi się, że w software to wszystko jest proste, bo koszty zmian są niewielkie. Za to na przykład w takim budownictwie, to już wszystko musi być na pewno w zgodzie z planem, bo tam koszty zmian i w ogóle się nie da. No to posłuchajcie.

Wrocław, pewna duża działka w bezpośrednim sąsiedztwie Obwodnicy Śródmiejskiej, bardzo ładnie położona blisko parku z rewelacyjnym dojazdem, niecałe 4 km od ścisłego centrum. Kupiła ją firma inwestycyjna i zaplanowała postawienie tam parterowego supermarketu z potężnym parkingiem. Uzyskanie pozwoleń, projektu itp. zajęło im (na ich szczęście jak się później okazało) około 3-4 lat. W tym czasie średnia cena metra kwadratowego mieszkania skoczyła we Wrocławiu z około 2000 PLN do około 8000 PLN. Działka blisko centrum, w pobliżu parku, zielono, spokojnie... Obecnie trwa tam budowa zespołu kilkupiętrowych apartamentowców z cenami niektórych mieszkań sięgającymi 10000 PLN za metr kwadratowy. Ile kosztowałoby firmę (w sensie utraconych korzyści) gdyby kierownik i sponsor projektu potraktowali na poważnie zasadę unikania zmian?

Drugi przypadek jeszcze bardziej ekstremalny. Budowa drogi w okolicach Wrocławia, rok zdaje się 1999. Budowa już trwała ale jednemu z bardziej doświadczonych ludzi w ekipie coś przestało pasować. Przyjrzano się powtórnie dokumentacji i okazało się, że projekt techniczny został sporządzony na podstawie planów geodezyjnych sprzed 1997 czyli sprzed powodzi. Tymczasem powódź coś tam pozmieniała w glebie (co dokładnie nie wiem, nie jestem geologiem, ale zdaje się gęstość gleby). Sytuacja była taka, że drogę, a zwłaszcza występujący w jej ciągu wiadukt, dało się co prawda zbudować według oryginalnego planu, ale takie wykonanie nie gwarantowało, że droga przetrwa pierwszy rok eskploatacji - zapadłaby się. Czy w takiej sytuacji zadaniem kierownika projektu też miało być unikanie zmian? Z tego co się orientuję po dość długich negocjacjach z inwestorem projekt został zmieniony, droga spełnia wszelkie normy i służy do dzisiaj.

Naprawdę nie czułbym się komfortowo jako klient firmy, która pozostaje głucha na zmiany.

Podsumowując, po mojemu będzie więc tak:

"Zadaniem kierownika projektu jest odpowiadanie na zmiany."

wtorek, 10 kwietnia 2007

Pierwszy post

Zobaczymy czy i jak zadziała!!!

Ten blog jest skutkiem innowacyjności w czystym wydaniu:

Miałem własny serwer, nie miałem chęci ani ochoty konfigurowania sobie samemu Wordpress'a. Jak widać nie byłem jedyny. Więcej osób chciało publikować blogi bez konieczności bawienia się w konfigurację serwerów. Powstała potrzeba... i została zaspokojona. W tym konkretnym wypadku zaspokoił ją Google z (już) swoim Bloggerem - możliwość pisania na blogger.com a publikowania na dowolny inny serwer. To takie proste. A jednocześnie tak trudno było na to wpaść.