wtorek, 30 grudnia 2008

Kosmiczne agilowe innowacje

W pierwszy dzień Świąt na TVN24 wyemitowano bardzo ciekawy reportaż dotyczący oryginalnego konceptu i historii przyznania X Prize. Dla niezorientowanych: nagrodę XPrize w wysokości USD 10 mln ufundował wówczas nieznany biznesmen a miała ona być przyznana pierwszej drużynie, której uda się skonstruować komercyjny statek kosmiczny, który w ciągu 2 tygodni dwukrotnie wyniesie na niską orbitę (100 km) dwie osoby. Miało to otworzyć drogę do kosmicznej turystyki. Nagrodę zdobył w 2004 roku zespół pod kierownictwem konstruktora Burta Rutana. Reportaż cały był arcyciekway, ja zwrócę uwagę na dwie rzeczy.

Jednym z zespołów startujących do XPrize, któremu nie udało się wtedy wygrać, był Armadillo Aerospace. Jego kierownik opowiadał o tym jak przygotowywali się do stworzenia pojazdu. Po pierwsze zespół składał się z ludzi o różnych zainteresowaniach i umiejętnościach, ale wspólnie stanowili całość, która była w stanie zaprojektować i zbudować pojazd. Po drugie pracowali i pracują głównie społecznie, bez znaczącego wsparcia finansowego, więc musieli wymyśleć jak najbardziej efektywny sposób pracy. Sposób ten polegał na tym, że co tydzień budowali prototyp, przeprowadzali próbę oraz następnie zbierali dane i wyciągali wnioski. W następnym tygodniu od nowa. Coś Wam to przypomina? I neich mi ktoś jeszcze raz powie, że agile to tylko software a i to nie każdy. Pewnym wytłumaczeniem skąd metody agile w projektowaniu pojazdów kosmicznych niech będzie fakt, że szefem firmy jest niejaki John Carmack- współtwórca Id Software (Wolfenstein, Doom, Quake, ...). Co ciekawe metody się sprawdzają. Zespół co prawda nie wygrał oryginalnej XPrize, ale za to dwa miesiące temu skasował nagrodę za tzw. poziom pierwszy Northrop Grumman Lunar Lander Challenge. I jako jedyny podszedł to poziomu drugiego, na razie niestety bez rezultatu (szczegóły w wideo na podanej stronie).

Moja druga obserwacja z całego tego reportażu jest natomiast zupełnie inna. Reportaż otworzył mi oczy na to jakie gospodarcze znaczenie miała X Prize. Powstało kilkadziesiąt firm, setki ludzi podjeło wyzwanie i stanęło do walki o nagrodę. Ilość wytworzonej w ten sposób wiedzy, innowacji i produktów naprawdę wysokiej technologii jest nie do przecenienia. Oczywiście były i sukcesy jak i porażki - parę firm zbankrutowało, parę innych bardzo słabo sobie radzi. Jednak patrząc się na całość nie mogę odeprzeć wrażenia, że skutki były więcej niż pozytywne. To wszystko zostało spowodowane przez sumę 10 mln dolarów amerykańskich, czyli mniej więcej 30 mln PLN. To tyle, ile mniej więcej kosztuje wyremontowanie 1 km ulicy w mieście. I znowu pojawia się u mnie to pytanie: dlaczego u nas tak nie można??? Czy nas naprawdę nie stać na te 30 mln, czy też chodzi o co innego? Za wskazówkę niech świadczy fakt, że w Google Lunar X Prize starują obok drużyn z USA taże Włosi, Niemcy, Duńczycy, Szwajcarowie, ale także... Malezyjczycy i ..... Rumuni. Polacy nie :-(


niedziela, 21 grudnia 2008

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

piątek, 19 grudnia 2008

Innowacyjność po polsku...

Niestety tym razem chodzi tylko o to, że przetłumaczona na język polski. Jakiś czas temu napisałem tu wpis "Dlaczego nie u nas?" na temat tworzenia w USA wysoce innowacyjnych projektów z budżetem ~50 USD.

Ostatnio dostałem od Radka informację (dziękuję), że opisana tam sesja z TED jest już dostępna z polskim tłumaczeniem. Razem z informacjami o innych ciekawych projektach umieszczona jest na mindblowing.pl: http://mindblowing.pl/?p=81

piątek, 12 grudnia 2008

Innowacje organizacyjne

Na początek trochę teorii i rozważań "podstawowych".

Świat jest przez nas opisywany za pomocą pewnych reguł. Stałych i niezmiennych. Te reguły określają to w jaki sposób działa świat (np. masy się przyciągają). Na podstawie reguł, które naszym zdaniem opisują świat, tworzymy pewnego typu metody i procedury, które są niczym innym jak zastosowaniem tychże reguł do konkretnego środowiska (np. szklankę stawiamy na stole a nie obok stołu - bo spadnie, co wynika wprost ze wspomnianej wcześniej reguły).

Przy takim spojrzeniu na organizacje działające w świecie rzeczywistym możemy założyć, że są dwie metody wprowadzania innowacji w organizacji. Pierwszy to zmiana metod i procedur. Po prostu jak chcemy wprowadzić coś nowego to zaczynamy od tego, że zmieniamy sposób działania ze starego na nowy. Następnie sprawdzamy czy nowy sposób działa lepiej czy gorzej, oczywiście względem pewnego konkretnego wskaźnika, który powinniśmy wyznaczyć zanim cokolwiek zaczniemy zmieniać. Ten sposób nazywa się często z angielska learning-by-doing.

Jest też drugi sposób wprowadzania innowacji, który o ile dobrze kojarzę nazywa się learning-by-understanding. Ten sposób zakłada, że zanim zaczniemy zmieniać cokolwiek w metodach i procedurach powinniśmy przeanalizować reguły, które rządzą danym kawałkiem rzeczywistości. W tym zwłaszcza upewnić się, czy to co wydaje się nam regułą opisującą daną rzeczywistość na pewno nią jest. Można tu zastosować metodę naukową. Dopiero jak mamy wystarczająco dobre reguły, to na ich podstawie konstruujemy metody i procedury. Tak aby wypełniały te zidentyfikowane reguły w konkretnym środowisku.

Powyższe uwagi są uwagami ogólnymi, ale jak najbardziej stosują się do agile a tak konkretnie do wdrażania metod zwinnych w organizacjach. Wielkim błędem jest wdrażanie metod "bo tak wszyscy robią", czy z innych tego typu powodów. A tak niestety często się dzieje. Niestety. To jest typowe podejście zmiany procedur i metod oraz później modlenia się o rezultaty. Stosując nielubiane przez mnie porównania wojskowe jest to podobne do radzieckiego "rozpoznania bojem". Ze względu na historycznie przetestowany poziom strat własnych podejście jest bardzo niezalecane. Zalecane jest za to sprawdzenie jakie reguły obowiązują w danym wycinku rzeczywistości, w którym porusza się dana organizacja. Dopiero na tej podstawie można skonstruować zestaw metod i procedur, które wdrożone przyniosą dokładnie taki efekt jak spodziewany.

To, co opisałem powyżej jest jedną z przyczyn dla której nie słyszałem o udanym wdrożeniu metod zwinnych, które było przeprowadzone ściśle według książki. Po prostu książki opisują pewną wiedzę ogólną a każda z organizacji działa w trochę innym otoczeniu, więc zestaw praktyk i metod musi być inny (choć reguły mogą, ale nie muszą, być takie same). I stąd właśnie do wdrożenia metod zwinnych często firmy potrzebują pomocy z zewnątrz - aby ktoś bezstronny "obejrzał" daną organizację i pomógł zdefiniować właściwe działania.

poniedziałek, 17 listopada 2008

User Acceptance Tests

Ostatnio prowadziłem szkolenie z agile, podczas którego padło bardzo logiczne pytanie: „a co z User Acceptance Tests (UAT – testy akceptacyjne)? kiedy je się wykonuje i jak zapewnia się, że podczas ich trwania ma się dostęp do grupy wykonawczej, aby ewentualnie naprawić zgłoszone przez użytkowników błędy?”. Pytanie jak najbardziej logiczne, dobre i odpowiedź powinna gdzieś być do znalezienia. Niestety po przeszukaniu dostępnej w mojej biblioteczce literatury okazało się, że odpowiedzi na to pytanie nie ma w posiadanej przeze mnie literaturze agile. Dlatego napiszę co ja na ten temat sądzę i jak ta sprawa była rozwiązywana w firmach, w których widziałem duże wdrożenia metod zwinnych. I przy okazji: jak ktoś gdzieś ma opis w literaturze takiego lub podobnego rozwiązania to bardzo proszę o podanie mi źródła.

„Problem” z User Acceptance Tests wynika z faktu, że według procesów agile grupa wykonawcza, pracująca nad projektem powinna cały czas w ramach iteracji dostarczać kolejne działające inkarnacje produktu. Tymczasem w tzw. świecie realnym, w którymś momencie przychodzi moment, kiedy taki działający produkt należy pokazać klientowi, który to klient powinien się zdecydować czy produkt spełnia jego wymagania czy nie. Ta właśnie procedura nazywa się testami akceptacyjnymi (UAT) i zwykle trwa jakiś czas- na pewno nie jeden czy nawet dwa dni. Co więcej z punktu widzenia firmy produkującej oprogramowanie jest to czas, który jest krytyczny. W trakcie testów akceptacyjnych musi być stały dostęp do zespołu, który wytworzył dany produkt aby bardzo szybko reagować na ewentualne błędy (pamiętajmy, że testuje to już klient – użytkownik ostateczny). Jak to więc zrobić, aby mieć dostęp do grupy wykonawczej w środowisku agile?

Ano bardzo prosto. Tylko trzeba się wznieść na „poziom wyżej”. Tak jak już kiedyś pisałem poziom iteracji i poziom wersji rządzi się trochę innymi prawami jeżeli chodzi o planowanie. Przypomnę tylko, że w ramach jednej wersji może być kilka iteracji. Wersja natomiast oznacza wersję produkcyjną, która zostaje zainstalowana u klienta ostatecznego w jego środowisku produkcyjnym. W ramach danej wersji następujące po sobie iteracje stanowią pewną całość i odbywają się jedna po drugiej, bez przerw. Nikt jednak nie powiedział, że tak samo musi być z wersjami. Często jest to w ten sposób rysowane w różnej literaturze (prace nad kolejną wersją rozpoczynają sie natychmiast po zakończeniu prac nad poprzednią), ale praktyka często weryfikuje takie podejście. W praktyce jest tak, że po zakończeniu pracy nad jedną wersja produkcyjną danego produktu następuje jej wypuszczenie i wdrożenie (deployment) w środowisku klienta. Natomiast prace nad kolejną wersją tego samego produktu zaczynają się zwykle z pewnym opóźnieniem (na przykład 2-4 tygodnie). W trakcie tego „opóźnienia” odbywają się dwie rzeczy. Po pierwsze klient przeprowadza UAT wersji, którą dostał. Jako, że w tym czasie nie ma prac rozwojowych nad wersją kolejną to w przypadku jakiejkolwiek awarii zespół wykonawczy jest w stanie bardzo szybko zareagować na ewentualne problemy. Jednak zespół wykonawczy nie przeznacza tego czasu tylko na bycie w gotowości. Oprócz tego, ten czas przeznaczany jest na przygotowanie do rozpoczęcia prac nad kolejną wersją. Zwykle oznacza to w praktyce przejrzenie z kierownikami produktu wszystkich funkcjonalności mających wejść w skład następnej wersji, nadanie im priorytetów oraz przeprowadzenie wstępnej estymacji. I nie jest to wbrew zasadom agile – wręcz przeciwnie, powtórzę po raz kolejny, że agile to nie chaos i kierownicy produktu powinni na początku prac nad wersją wiedzieć co chcą w jej ramach dostać. Zwłaszcza jeżeli chodzi o funkcjonalności o wysokich priorytetach, które wejdą do produkcji w pierwszych iteracjach pracy nad nową wersją.

Na koniec podsumowując w jednym zdaniu: praktyka wskazuje, że User Acceptance Tests w projektach agile przeprowadza się w „przerwie” pomiędzy pracą nad kolejnymi wersjami produktu.

sobota, 1 listopada 2008

Metoda Uwe K.

Jakiś czas temu pracowałem dla naszych sąsiadów zza Odry i Nysy Łużyckiej a moim szefem był niejaki Uwe K. Miał on bardzo ciekawą metodę zarządzania zadaniami. Otóż dzwonił codziennie o godzinie 16.15 do mnie, jako do swojego pracownika i przekazywał ustnie zadania do wykonania. Następnego dnia często dzwonił o godzinie 8.00 z pytaniem gdzie może obejrzeć rezultaty mojej pracy. Najwięcej zadań oczywiście było przekazywane w piątek o 16.15, tylko po to, aby oczekiwać, że będą zrealizowane do poniedziałku do 8.00. Bardzo ciekawa metoda zarządzania to była. Szczególnie w kontekście tego, że życie nie składa sie jedynie z pracy. Jak się zapewne domyślacie dość szybko zacząłem aktywnie działać w kierunku zwolnienia Uwe K. z funkcji mojego szefa...

Historia powyższa przypomniała mi się gdy rozmawiałem w zeszłym tygodniu z pewną osobą, której nie udało się wdrożenie zwinnych metod zarządzania w średniej wielkości polskiej firmie informatycznej. Teoretycznie firma była idealna do wdrożenia. Produkty cechujące się dużą niepewnością funkcjonalności, bardzo duża możliwość testowania niepełnego produktu przez klientów ostatecznych, projekty na tyle małe, że można je robić jednym zespołem, więc odpadają wszelkie typowe problemy ze skalowaniem metod zwinnych. Niestety wdrożenie zostało wyłożone. Co się stało? Zacznijmy od tego, że wdrożenie agile project management zostało umotywowany tym, że "firma zbyt wolno reaguje na potrzeby klienta". Celem było więc stworzenie systemu, który pozwoli szybko reagować na zgłaszaną przez klienta informację zwrotną o produktach firmy. O ile osoby zajmujące się programowaniem dość szybko zrozumiały o co chodzi w nowym systemie pracy, to zrozumienie metod zwinnych po stronie osób zarządzających produktem (product managerów) było cokolwiek powierzchowne. Doprowadzono do sytuacji, w której dano product managerom pełną dowolność zmian funkcjonalności produktu bez liczenia się z opinią kierowników projektów realizacyjnych. Bardzo szybko spowodowało to pojawienie się syndromu opisanego powyżej. Objawiało się to wpisywaniem przez menedżerów produktu na listę funkcjonalności niezdefiniowanych rzeczy podczas spotkań planujących iterację. Realizatorzy prosili o uszczegółowienie takich wymagań, co następowało zwykle na trzy dni przed końcem iteracji. Na innym poziomie było wrzucanie do ostatniej iteracji przed wypuszczeniem wersji zmian fundamentalnych, wymagających zmian w architekturze - oczywiście tłumaczone nagłą potrzebą klienta. A także inne kwiatki, których nie mogę opublikować. Jak się domyślacie oczekiwanie było, że na koniec każdej iteracji będzie dostępny działający produkt. A już wersja to koniecznie musiała być, bo przecież obiecana klientowi. Jakiekolwiek tłumaczenie od strony realizatorów, że taka praca jest nieoptymalna menedżerowie produktów kwitowali krótko: "no jak to, czy to znaczy, że nie jesteście wystarczająco agile?". Dość szybko ludzie z zespołów realizacyjnych zaczęli myśleć dokładnie to, co ja myślałem o moim szefie.

Nauka z tego taka, że zwinność zwinnością, ale i tak zawsze trzeba pamiętać, że istnieje gdzieś niepisana cienka linia, której przekroczenie spowoduje zabicie metody. Najpierw na poziomie elementarnego poziomu i trzymania się zasad. Chwilę potem na poziomie ludzkich relacji i chęci dalszej współpracy. Napiszę jeszcze raz to, co już tu wielokrotnie wprowadzałem: agile to wprowadzanie porządku w chaos. Agile to nie jest zarządzanie bez reguł.

I na koniec taka refleksja. Nie wiem dlaczego, ale zaczyna u mnie dominować przekonanie, że wdrożenia metod agile są najbardziej zagrożone nie od strony realizacji, ale od strony zarządzania produktem. Właśnie ze względu na błędne zrozumienie, że agile oznacza "wszystko nam wolno". A co ciekawe firmy praktycznie nigdy nie chcą aby im szkolić menedżerów produktów...

wtorek, 21 października 2008

Zarządzanie innowacją - skąd się biorą pomysły?

Dzisiaj krótko, ale na temat bardzo interesujący. Wszyscy wokoło chcą teraz nagle zarządzać innowacjami. I fajnie. Niech się gospodarka rozwija nie tylko w oparciu o doskonałość operacyjną, ale także o nowe rozwiązania. Problem jaki widzę jest taki, że podejście do innowacji nawet w poważnych firmach jest dość mało poważne. Najlepiej widać to na przykładzie procesu zbierania pomysłów na nowe innowacje. Zwykle sprowadza się to do powołania jakiegoś "oficera innowacji", którego zadaniem jest zbieranie pomysłów od pracowników. Ta sama osoba odpowiedzialna jest za zorganizowanie mniej lub bardziej formalnej oceny przysyłanych pomysłów oraz późniejsze wdrażanie w życie tych, które ocenę przeszły pozytywnie. Czy to działa? Tak, i nawet są jakieś efekty - zwykle w postaci dziesiątek, jeżeli nie setek pomysłów od pracowników, które nigdy nie zostały wdrożone.

Przedstawione podejście, poza oczywistą taką zaletą, że działa, ma jeszcze dwie poważne wady. Po pierwsze nie ukierunkowuje pracowników na szukanie rozwiązań konkretnych problemów. Zgłaszane pomysły zwykle proponują usprawnianie wszystkiego po kolei zamiast tych rzeczy, które najbardziej bolą i uniemożliwiają rozwój. A takich rzeczy jest relatywnie mało. Według Teorii Ograniczeń zresztą tylko jedno. Ukierunkowanie całej kreatywności pracowników w jedno tylko miejsce będzie miało zdecydowanie lepszy rezultat niż zbieranie, czy jeszcze gorzej realizowanie, pomysłów na ślepo. Wyzwanie jakie tu się kryje to konieczność przeprowadzenia wnikliwej analizy przedsiębiorstwa przed wytyczeniem tematyki, w której miałyby nastąpić innowacje. A to jest trudne. Dużo trudniejsze od wyznaczenia "oficera innowacji".

Druga wada jest z zupełnie innego poziomu. Otóż chodzi w skrócie o to, że zbieranie pomysłów jest dużo bardziej efektywne nie na zasadzie "pomysły luzem", ale na zasadzie reakcji na konkretne wydarzenia. Na przykład takim wydarzeniem jest... nieoczekiwany sukces. Jeżeli organizacja odniosła sukces, który nie był spodziewany to należy się jak najszybciej zainteresować powodami, dla których ten sukces został osiągnięty. Ostatnio leci taka reklama z pralkami: firma sprzedaje dużo pralek w Indiach i pracownik jedzie na miejsce zobaczyć dlaczego, okazuje się, że Hindusi w tych pralkach mieszają soki. Teraz można oczywiście obśmiać Hindusów, jacy oni głupi, ale można też lekko zmienić projekt urządzenia i wprowadzić mieszarkę do soków. A następnie zarobić krocie. Cała sztuka polega na tym, żeby to było odpowiednio zapisane w procesach firmy. tak, aby tego rodzaju innowacje nie stanowiły szczęśliwego trafu, ale były efektem skodyfikowanego, powtarzalnego procesu.

wtorek, 14 października 2008

Dokumentacja wdrożeniowa i administracyjna

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.

poniedziałek, 22 września 2008

Dzielenie funkcjonalności raz jeszcze

Prawie dokładnie dwa lata temu napisałem post nt. wielkości funkcjonalności. Post był krótki i treściwy, ale po dwóch latach w sposób równie krótki i równie treściwy muszę dokonać pewnej modyfikacji tego, co w nim napisałem.

Otóż jak najbardziej prawdą jest, że w ramach iteracji powinniśmy realizować funkcjonalności, których wielkość jest nie większa niż jedna iteracja. Doświadczenie dwóch lat nauczyło mnie jednak, że nie jest optymalne mówienie, iż każda z tych funkcjonalności musi dostarczać wartość dodaną dla klienta. Powinno się mówić o tym, że każda z funkcjonalności (w tym takie po podziale) powinny dostarczać wartość dodaną dla właściciela produktu (Product Managera). Czy to robi różnicę? Subtelną, ale jednak robi. Różnica ta polega na tym, że właściciel produktu nie koniecznie jest klientem (aczkolwiek może nim być). Zdarzyło mi się w mojej praktyce spotkać się z przypadkami, kiedy klient końcowy jako wartość dodaną dla siebie widział tylko i wyłącznie coś, co jest efektem końcowym całego projektu. Po prostu z punktu widzenia klienta końcowego żaden z elementów pośrednich, będących efektami poszczególnych iteracji nie powoduje, że biznes klienta zacznie lepiej działać i przynosić lepsze efekty. Dlatego czasami trudno tu jest mówić o wartości dodanej poszczególnych iteracji. Z punktu widzenia klienta takowych po prostu nie ma.

Natomiast wartość dodana z punktu widzenia właściciela produktu może być trochę inną wartością dodaną niż z punktu widzenia klienta. Na przykład posiadanie części rozwiązania może być dla właściciela produktu wartością, bo wie, że jest bliżej całości rozwiązania. Natomiast z punktu widzenia klienta to nie ma żadnego znaczenia, bo jemu wartość przynosi tylko i wyłącznie rozwiązanie w całości.

Nauka z tego taka, że w planowaniu zwinnym jeżeli istnieje ktoś taki jak właściciel produktu to planowanie odbywa się z oparciu o jego definicję wartości i on odpowiada za definiowanie funkcjonalności. I to właściciel produktu odpowiedzialny jest za to, aby koniec końców produkt dostarczał wartość dla klienta ostatecznego.

Uwaga!!! Klient i właściciel produktu w niektórych przypadkach to może być jedna i ta sama osoba, wtedy oczywiście cały ten post i tłumaczenie ma mały sens.

I na koniec jeszcze jedno spostrzeżenie. Gdyby nie praktyczna próba zastosowania agile nigdy nie spotkałbym się z taką sytuacją i nigdy nie przypuszczałbym, że wartość dodana dla klienta może w pewnych wypadkach być tak trudna do zastosowania. Ale od czego jesteśmy zwinni (agile). W sposób agilowy dostosowaliśmy się do panujących warunków. Zastanawiam się tylko jak by się w takiej sytuacji zachowali reprezentanci nurtu "agile ortodoksyjny"?

poniedziałek, 15 września 2008

Zarządzanie innowacjami – podstawy

Dzisiaj kilka słów na temat, który nie był do tej pory często poruszany na tym blogu, a w przyszłości mam zamiar pisać o nim więcej. Dotyczy zarządzania innowacjami, czyli jakby nie patrzyć tytułowego problemu tego bloga.

Na początek trochę o podstawach. Wiele osób twierdzi, że zarządzanie innowacjami w ogóle nie jest możliwe. Jako powód podawane jest zwykle to, że innowacje są czymś tak nowym i kreatywnym, że w przypadku organizacji nie jest możliwe stworzenie systemów i narzędzi, które umożliwiłyby zarządzanie innowacją. Taki punkt widzenia oznacza traktowanie innowacyjności jako tego, co przytrafiło się Archimedesowi: czyli siedzenia w wannie i krzyczenia w odpowiednim momencie „eureka”. Na szczęście w przepadku przedsiębiorstw i firm dochodzenie do innowacyjnym rozwiązań odbywa się w zupełnie inny sposób, nie mający nic wspólnego z przedstawionym pojmowaniem innowacji.

Zarządzanie innowacjami w przedsiębiorstwach to wbrew pozorom ściśle zdefiniowany proces (tak, proces) mający swoje cele i mierniki. A tak dokładnie każda firma chcąca zarządzać innowacjami prędzej czy później będzie zmuszona do stworzenia systemowych rozwiązań pozwalających na dokonywanie trzech głównych grup działań:

  • Identyfikacja pomysłów
  • Ocena pomysłów
  • Wdrażanie rozwiązań

W organizacjach naprawdę skutecznych pod względem innowacji te trzy grupy działań są świadomie zidentyfikowane i opisane za pomocą procesów. Na czym polegają te grupy działań?

Identyfikacja pomysłów to wszelkie działania prowadzące do spisania pomysłów i koncepcji możliwych do wprowadzenia w organizacji. Mogą to być wszelkiego typu pomysły od tego jak usprawnić pracę na jakimś stanowisku po pomysły na nowe produkty. Co jest ważne, to zbieranie pomysłów musi być dokonywane w pewien standardowy sposób. Wbrew pozorom to da się zrobić i jest to w miarę proste. System powinien być skonstruowany tak, aby wręcz wymuszał myślenie o możliwościach innowacji w konkretnych punktach działania firmy, tam gdzie potencjał zauważenia możliwości innowacji jest największy.

Ocena pomysłów to działanie polegające na wyborze spośród zidentyfikowanych możliwości tych, które są najlepsze z punktu widzenia firmy. Tutaj najważniejsze jest, aby wiedzieć jakie są kryteria wyboru oraz jaki jest proces oceny. Chodzi o to, aby zapewnić sobie możliwość wskazania akurat tych, które naprawdę są najkorzystniejsze w taki sposób, aby mieć przejrzystość procesu. Brak przejrzystości prędzej czy później spowoduje spadek liczby generowanych pomysłów.

Trzecia grupa działań to wdrażanie rozwiązań. To nic innego jak projekty wprowadzania innowacji. I tutaj mała, ale bardzo ważna uwaga. Projekt wprowadzania innowacji nie powinny być realizowane w taki sam sposób w jaki realizujemy „zwykłe” projekty w firmie. Projekty innowacyjne mają zupełnie innych charakter i dlatego procesy według których są realizowane również powinny być inne.

Jak widać wszystkie trzy grupy działań są logiczne i mogą być w prosty sposób opisane procesowo. Do tychże procesów należy następnie przypisać odpowiednie miary i osoby odpowiedzialne za realizację. Później wystarczy je „tylko” wdrożyć i kontrolować. Wtedy będzie można powiedzieć, że dana firma faktycznie zarządza innowacjami. I nie ma to nic wspólnego z czekaniem na „eureka” dobiegające z wanny…

P.S. Po ponownym przeczytaniu tego, co powyżej zdałem sobie sprawę, że stopień prawdziwości zawartych wyżej stwierdzeń bardzo zależy od tego, w jaki sposób zdefiniujemy innowacje. Teraz już nie ma na to czasu, ale będzie to tematem któregoś z następnych wpisów.

poniedziałek, 8 września 2008

Jak upowszechnić ideę, czyli dlaczego zostanie tylko SCRUM

Witam po dłuższej przerwie wakacyjnej. W każdym razie żyję i teraz już postaram się wrócić do zwykłej częstotliwości pisania.

Na początek temat tylko z pozoru odległy od głównej tematyki tego bloga. W trakcie wakacji kilkukrotnie powróciło do mnie zagadnie czynienia nowej idei popularną. Chodzi o sytuację, kiedy mamy nową (innowacyjną) ideę i chcemy ją upowszechnić. Niektórzy puryści powiedzą w tym momencie, że to nic trudnego, po prostu trzeba tą ideę sprzedać używając „zwykłych” metod marketingu i sprzedaży, postępując podobnie jak z każdym innym produktem. Być może mają rację. A nawet mają ja na pewno. Ale ja się zacząłem zastanawiać nad czymś innym. Jaka powinna być konstrukcja systemu, w którym krąży rzeczona idea, aby tenże system był w stanie w sposób najbardziej skuteczny upowszechnić tą właśnie ideę wśród firm (uwaga to ważne: mówimy o upowszechnieniu wśród organizacji komercyjnych).

Czyli sytuacja wyjściowa jest następująca: mamy nową, dobrą ideę, czyli na przykład agile project management i chcemy, żeby koncepcja ta przedostała się do świata firm i była tam używana. Jaki system zbudować, aby to było możliwe?

Jeden z modeli takowego systemu, który służy upowszechnianiu idei został mi zasugerowany przez Marka Kowalczyka. Po drobnych zmianach system ten, nazwany przeze mnie „modelem guru”, wygląda mniej więcej tak:


W centrum tego modelu stoi „guru” – osoba, która jest niekwestionowanym autorytetem jeżeli chodzi o daną koncepcję, czy też ideę, najczęściej jej twórca. Osoba ta najczęściej przekazuje swoje idee poprzez książkę swojego autorstwa, która zawiera jedynie właściwą wykładnię tego, co jest treścią idei. Książka najczęściej nie jest jedna, tylko robi się z tego cykl, każda następna prezentująca kolejną odsłonę idei. Książka jest głównym nośnikiem marketingowym, pozwalając dotrzeć do masowego odbiorcy za bardzo sensowne pieniądze (dla odbiorcy). Te osoby, które po przeczytaniu książki zainteresuje idea są następnie zachęcane do odbywania spotkań z „guru” lub osobami przez niego wskazanymi, na których to spotkaniach można zgłębić kolejne tajniki wiedzy. Całą tą machinę aktywnie wspiera sieć społeczna zbudowana wokół idei. Sieć taka zwykle opiera się o jakąś formę portalu webowego lub sieć stowarzyszeń/klubów w których spotykają się osoby zainteresowane tą właśnie ideą. Sieć ta ma zwykle jakiś sposób na wyróżnienie swoich członków spośród innych ludzi. Takim sposobem są na przykład wszystkiego typu gadżety reprezentujące idee: teczki, koszulki, kubki, zakładki do książek, etc. Zwykle sprzedawane po cenach absurdalnie wysokich.

Model powyższy został w praktyce zaimplementowany i sprawdza się znakomicie w pewnych przypadkach. Przykładami „guru” i stojących za nimi idei rozpowszechnianych w takim modelu są między innymi: Stephen Covey (7 nawyków skutecznego działania), Robert Kiyosaki (Bogaty Ojciec), Anthony Robbins (The Power Within) czy w końcu David Allen (GTD). Wymienione przykłady dowodzą, że model ten działa i w oparciu o niego można skonstruować sprawnie działający mechanizm szerzenia idei i (przy okazji) zarabiania pieniędzy.

Wymieniony model ma jednak dość znaczącą wadę. Otóż nigdzie nie ma dowodów na to, że pozwala on w sposób efektywny sprzedawać idee do firm. Wszystkie wymienione koncepcje są nakierowane na sprzedaż dla jednostek a nie dla organizacji. Mimo, że może nawet wystąpić sytuacja kiedy to firma płaci za seminarium GTD czy dowolne inne to nadal cały czas ta idea jest sprzedawana poszczególnym osobom w ramach organizacji. Czy ktoś kiedyś słyszał, żeby firma działała według 7 nawyków, aby według GTD albo czegoś podobnego? Nie. Firmy działają według Lean, CMMI, SixSigma, ISO, PMI czy Prince2 . W tym momencie mnie tknęło. Następnym logicznym pytaniem jest bowiem: czy te wszystkie koncepcje też mają wspólny model wokół którego się obracają? Analiza wykazała: mają.

„Model standardu” jest drugim modelem upowszechniania idei, który sporządziłem próbując dokonać reverse engineeringu na koncepcjach odnoszących największe sukcesy w firmach. Takich, które zostały już wielokrotnie wdrożone i które są znane większości osób zaangażowanych w daną działkę przemysłu. „Model standardu” prezentuje się w sposób następujący:

Zgodnie z nazwą w centrum modelu jest standard. Koniecznie spisany, dostępny albo za darmo, albo (częściej) w postaci płatnego wydawnictwa. Standard ten jest oficjalnie opracowany i utrzymywany przez pewną organizację, która jest zwykle pomysłodawcą idei. Ta sama organizacja zajmuje się certyfikacją, która jest kolejnym elementem modelu. Organizacja, która wymyśliła ideę rości sobie prawo do oceniania i certyfikowania z zakresu propagowanej idei. Odbywa się to zwykle dwutorowo. Po pierwsze organizacja może przetestować i certyfikować poszczególne osoby/organizacje pod kąte tego jak dobrze znają one dany standard. W ten sposób powstają wszystkie dyplomy, certyfikaty, stopnie dojrzałości itp. Drugi zakres działania organizacji certyfikującej jest jeszcze ciekawszy: dotyczy certyfikacji organizacji, które mogą propagować standard dalej. Czy organizacja, która wymyśliła pierwotną ideę, daje swoistą licencję innym organizacjom na propagowanie tej właśnie idei. Zauważyłem zresztą, że bardzo rzadko ta organizacja, która wymyśliła ideę sama dostarcza np. wiedzę z jej zakresu. Ona wynajmuje do tego „niezależnych”, certyfikowanych dostawców. Cudzysłów jest dlatego, że ci dostawcy są w 100% zależni od organizacji certyfikującej, gdyż brak ich uznania, cofnięcie certyfikatu w większości wypadków skutkowałby natychmiastowym wypadnięciem z rynku. Na koniec jako element propagowania idei jest jeszcze coś takiego jak sieć kontrahentów. Chodzi tu o to, że organizacje certyfikujące poprzez swoich „niezależnych” dostawców często wymuszają na przedsiębiorstwach, że w momencie implementacji standardu będą „namawiać” swoich partnerów do przyjęcia tego samego standardu. „Właśnie wdrożyliśmy ISO i aby utrzymać wymaganą jakość oczekujemy, że za 6 miesięcy wszyscy nasi dostawcy też wdrożą ISO”. Działa rewelacyjnie, zwłaszcza jak pierwszym podmiotem, który tak mówi jest organizacja rządowa udzielająca zleceń (przypadek PMI, Prince2 czy CMMI).

Jaki jest powód tego, że „model standard” jest znacznie skuteczniejszy w sprzedawaniu idei do firm niż „model guru”? Według mnie klucz leży w modelu potrzeb Maslowa a konkretnie w drugiej kluczowej potrzebie każdego człowieka, czyli potrzebie bezpieczeństwa. W tym wypadku bezpieczeństwa zawodowego menedżera, który podejmuje decyzje o wdrożeniu danej idei. W przypadku „modelu guru” idea taka nie jest dla niego bezpieczna, gdyż opiera się o konkretnego, jednego człowieka. Czy jakikolwiek wysoki szczeblem menedżer pozwoli, żeby jego firma opierała się o idee jednej jednostki, jednego człowieka? Nie. Zupełnie inaczej natomiast wygląda sytuacja, kiedy mamy wdrożyć znany na rynku standard wspierany przez „niezależną” instytucję certyfikującą i „niezależnych” dostawców wiedzy. Zresztą tych dostawców jest wielu w odróżnieniu od „modelu guru”, gdzie zwykle dostawca jest jeden (firma założona przez twórcę idei).

I tak na koniec. Dlaczego piszę o tym na tym właśnie blogu? Otóż próbowałem przeanalizować sobie w jaki sposób próbuje się upowszechniać koncepcje agile project management. Wydaje mi się, że do tej pory wszystkie koncepcje agile były upowszechniane w sposób przypominający „model guru”. Dwa najbardziej jaskrawe przypadki to Alistair Cockburn z jego metodami Crystal oraz Ken Schwaber i SCRUM. Upowszechnianie idei w ten sposób jakoś szło. Ken Schwaber, Mike Cohn oraz Esther Derby, jako jedyni spośród „guru” agilowych, zdecydowali się jednak powołać Scrum Alliance. „Niezależną” organizację trzymającą pieczę nad standardem oraz certyfikującą „niezależnych” dostawców. Jeżeli moje rozważania są poprawne oznacza to, że prędzej czy później, ale raczej prędzej SCRUM upowszechni się jako jedyna słuszna metoda zwinnego zarządzania projektami.

niedziela, 15 czerwca 2008

Zespoły - na co zwrócić uwagę

Projekty realizowane metodami agile/zwinnymi wymagają zupełnie innych zespołów niż takie realizowane metodami tradycyjnymi. Jak wiadomo zespół powinien być maksymalnie 10-12 osobowy, idealnie przebywać w jednym miejscu fizycznym, sam się zarządzać + parę innych cech, bardzo często wymienianych w literaturze. Ja natomiast dzisiaj napiszę o tych czynnikach, które mogą być potencjalnym zagrożeniem dla sprawnego działania zespołu realizującego projekt przy użyciu metod zwinnych. Na te czynniki powinno się zwrócić szczególną uwagę podejmując decyzję o realizowaniu projektu metodami zwinnymi.

Po pierwsze należy to jasno powiedzieć, choć może nie jest to twierdzenie politycznie poprawne: skuteczność zespołu pracującego metodami zwinnymi zależy w dużym stopniu od kultury miejsca pracy. Chodzi tu zarówno o kulturę organizacyjną jak i kulturę państwa/narodu, którego przedstawicielami są osoby uczestniczące w projekcie. Kultura musi wspierać prace grupowe i jednocześnie deprymować lansowanie się jednostek kosztem grupy. Praca metodami zwinnymi jest pracą grupową i na to poradzić nic nie można. I tak jak z innymi zajęciami grupowymi (na przykład sport) często zdecydowanie lepszy jest zespół składający się z osób o przeciętnych zdolnościach, ale zdolnych do współpracy od zespołu składającego się z geniuszy, którzy nie potrafią ze sobą porozmawiać, bo każdy chce tylko udowodnić swoją wyższość. To jaki charakter pracy jest uprawiany w danej organizacji zależy właśnie od kultury organizacji. I niestety zmiana tego jest bardzo trudna.

Po drugie zespoły pracujące metodami zwinnymi powinny w czasie trwania projektu móc pracować tylko i wyłącznie nad tym projektem. To niestety jest bardzo trudne do zrobienia w przypadku organizacji posiadających silną strukturę macierzową. Taka struktura zakłada bowiem, że w każdy członek zespołu projektowego ma jeszcze swojego przełożonego "liniowego", który w znaczącej większości przypadków decyduje o takich rzeczach jak awanse czy podwyżki. To oznacza, że praktycznie w każdej sytuacji niejasnej pracownicy będą słuchać swojego przełożonego liniowego a nie osób z projektu. W tradycyjnie zarządzanych projektach powoduje to duże problemy i jest m.in. jedną z przyczyn notorycznych opóźnień. W projektach zarządzanych metodami zwinnymi takie podejście jest całkowicie destrukcyjne i projekty praktycznie nie mogą się toczyć. Projekt zwinny bardzo podobny jest do wspomnianego już kiedyś przypadku operacji w szpitalu. Na czas operacji cały zespół ma być tylko i wyłącznie na sali operacyjnej. Przecież nikt nie wyobraża sobie, że nagle anestezjolog wyjdzie z sali i zajmie się sporządzaniem raportu, którego akurat bardzo potrzebuje jego przełożony "liniowy". Ciekawe, że w projektach, takie zachowanie jest uważane za coś normalnego.

Po trzecie i ostatnie (na dzisiaj) należy sobie zdawać sprawę, że zupełnie inna jest rola kierownika projektu w projekcie zarządzanym metodami tradycyjnymi a zupełnie inna jest ta rola w projektach zarządzanych metodami zwinnymi. Do tego stopnia, że niektórzy puryści zajmujący sie agile twierdzą wręcz, że w tych metodach stanowisko kierownika projektu istnieć nie powinno i nazywają je inaczej (np. SCRUM Master). Tak naprawdę nie ważne jak się ono nazwa, ważne jest, że osoba wyznaczona do kierowania powinna mieć zupełnie inne umiejętności i na co innego zwracać uwagę niż w projektach tradycyjnych. Typowym przykładem jest kwestia rozdziału zadań i podejmowania decyzji. W metodach tradycyjnych zwyczajowo to kierownik projektu podejmuje wszystkie decyzje sam, podobnie on rozdziela zadania do wykonania. Takie podejście jest zaprzeczeniem metod zwinnych. Tutaj zadaniem kierownika jest tak pokierować (przewodzić) pracy zespołu, aby decyzje były podjęte wspólnie a zadania rozdzielone na zasadzie swobodnego wyboru przez członków zespołu. To oznacza również, że kierownik stosujący zwinne metody zarządzania musi być ekspertem w dziedzinie, której dotyczy projekt. W odróżnieniu od tradycyjnego podejścia, gdzie parafrazując pewną bardzo znaną książkę "nawet pielęgniarka może poprowadzić projekt budowlany, byleby miała dobrze zdefiniowany system zarządzania projektami". W metodach zwinnych takie podejście gwarantuje porażkę.

niedziela, 8 czerwca 2008

Kiedy nie stosować metod zwinnych

Na Controlling Chaos pojawił się przydługi wywiad z Jerrym Manasem. Trwa półtorej godziny i gdzieś w środku pojawił się jeden wątek, który z oczywistych względów mnie zainteresował. Otóż rozważane było czy stosować podejście procesowe czy elastyczne (org. flexible). Zeszło na Agile Project Management i po chwili padły tam trzy kryteria/sytuacje, których zaistnienie wyklucza użycie metod zwinnych (agile) do zarządzania projektem:
  1. Bezpieczeństwo
  2. Wymaganie dokładności
  3. Standardy prawne
Moje komentarze do tych sytuacji:

Ad.1. Chodzi o sytuację kiedy mamy projekt od którego będzie zależało życie ludzkie: oprogramowanie nawigacyjne samolotu, projekty wojskowe czy np. oprogramowanie tomografu komputerowego. Sytuacja wyjątkowa. Takimi projektami zarządza się zupełnie inaczej niż czymkolwiek innym.
Ad. 2. Ta sytuacja zachodzi wtedy, kiedy z góry wiemy, że są ściśle zdefiniowane parametry produktu końcowego, które chcemy uzyskać. W wywiadzie był podany przykład budownictwa: tam jest wszystko opisane jak co powinno wyglądać (w projekcie) i nie ma miejsce na zwinność. Po prostu trzeba zrobić. To jest bardzo logiczne. Jeżeli parametry wyrobu są podane wcześniej i wymagane jest dokładne spełnienie tychże kryteriów to logiczniejszym wyjściem jest zaplanowanie całości w celu uzyskania tychże kryteriów niż dochodzenie do nich w sposób iteracyjny. Z drugiej strony problem może się pojawić jak nie mamy pojęcia w jaki sposób osiągnąć wymagane parametry. Wtedy rozważyłbym, czy jednak metody zwinne nie byłyby przydatne.
Ad. 3. Projekt dotyczy wdrożenia standardów prawnych (org. regulatory standards). Sytuacja jest prosta: standard istnieje i mamy go wdrożyć. Standard ze swojej definicji jest dokładnie określony i nie ma tam miejsca na zwinność. I jedna tylko drobna uwaga. Chodzi tylko i wyłącznie o standardy prawne. Jeżeli projekt dotyczy standardów innego typu, np. wewnątrzfirmowych to już rozważenie metod zwinnych jest jak najbardziej wskazane. Jak to było wspomniane w wywiadzie należy pamiętać, że standardy wewnątrzfirmowe są narzędziem a nie celem samym w sobie. Ich interpretacja jest jak najbardziej uzasadniona jeżeli gwarantuje osiągnięcie celów, dla których zostały stworzone.

Moja opinia:
Zgadzam się w całości z tym, co usłyszałem w wywiadzie. Oznacza to, że dla bardzo znaczącej większości projektów użycie metod zwinnych nie jest wykluczone.

sobota, 31 maja 2008

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.

niedziela, 25 maja 2008

Sztuka odmawiania

Innovation is not about saying yes to everytnig. It's about saying NO to all but crucial features.

Innowacja nie polega na akceptowaniu wszystkiego. Polega na odrzucaniu wszystkich oprócz absolutnie niezbędnych funkcjonalności

Kto to powiedział? Steve Jobs. Kto jak kto, ale on akurat wie co to innowacyjność. Przeczytałem to zdanie w doskonałej zresztą książce "Getting Real". I mnie olśniło. To jest aż tak proste a jednocześnie aż tak skomplikowane do zastosowania. Innowacja jest czymś, co w absolutnie nowy sposób rozwiązuje istniejący, konkretny problem świata rzeczywistego. Dlatego nie jest sztuką wymyślać tysiące nowych funkcjonalności naszego produktu, które kiedyś, być może zostaną użyte przez pół promila użytkowników. Sztuką jest tak wymyślić kilka podstawowych rzeczy tak, aby wnosiły one istotne zmiany w życie naszych klientów. Parafrazując to, co kiedyś pisał na swoim blogu Alex Barszczewski chodzi o to, aby za pomocą 4% rzeczy osiągnąć 64% rezultatów (podwójna zasada Pareto). Teraz prawdziwa trudność polega na tym, że nie tylko trzeba potrafić wytworzyć te 4% co spowoduje 64% oczekiwanej wartości dodanej, ale także, a w zasadzie przede wszystkim, należy te właśnie 4% wprowadzić do produktu jako pierwsze. Jeszcze więcej: w zasadzie powinno się wprowadzić tylko te 4% i nie martwić się o resztę. Pomyślcie, jeżeli 4% naszej funkcjonalności generuje 64% wartości dodanej dla klienta ostatecznego to jak bardzo uzasadnione ekonomicznie jest tworzenie pozostałych 96%???

Jeżeli takie podejście jest słuszne (brzmi logicznie), to oznaczałoby, że posiadanie skutecznego sposobu ustalania co jest a co nie jest ważne z punktu widzenia klienta ostatecznego naszego produktu jest dla firmy kluczem do tego, czy jest ona innowacyjna czy nie. Innymi słowy nawet ponadprzeciętna zdolność do wytarzania produktów będzie mało przydatna i/lub nieefektywna ekonomicznie, jeżeli nie będziemy wiedzieli co wytworzyć oraz gdzie zatrzymać się w naszym tworzeniu. Znów są to pytania warte miliony. Krótka analiza i przeszperanie pamięci wykazało, że metody zwinne mają mechanizm wyboru funkcjonalności zaimplementowany same w sobie. Opisywałem go tutaj. Czy jest wystarczający? Kiedyś myślałem, że tak. Teraz jak już jasno widać jak bardzo kluczowy jest to proces zaczynam mieć wątpliwości, czy nie mógłby on być zastąpiony czymś skuteczniejszym. Mimo wszystko, sam fakt że istnieje on, choćby w szczątkowej formie, oznacza , metody zwinne wspierają innowacyjność. W odróżnieniu od metod, które na wartość biznesową uwagi nie zwracają żadnej.

Zadanie domowe do przemyślenia: jaki jest w Twojej organizacji system (tak, system – to jest zbyt ważne, aby opierać się tylko na przeczuciu jednej czy drugiej osoby) określania tego, co wnosi jak dużą wartość dla Waszych klientów?

sobota, 17 maja 2008

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.

niedziela, 11 maja 2008

Kontrakty na projekty zwinne

Ostatnie kilka tygodni spędziłem bardzo pracowicie spotykając się z wieloma bardzo interesującymi ludźmi. Stąd dłuższy brak postów na blogu. Z drugiej strony spotkania te były niezwykle interesujące i dostarczyły bardzo ciekawych spostrzeżeń.

Przykład, który mnie najbardziej zadziwił to omawiany już tu kiedyś (tutaj) „problem” kontraktów na projekty zwinne. Generalnie podczas każdej prezentacji, szkolenia czy nawet rozmowy na temat zwinnych metod zarządzania projektami prędzej czy później któryś z obecnych kierowników projektów podnosi „problem” kontraktów. Najczęściej przybiera to formę pytania „a co ja mam powiedzieć mojemu klientowi jak on zapyta ile będzie kosztował cały system”. Zwykle w takich przypadkach tłumaczę, że kontrakty na projekty realizowane zwinnie powinny być płacone inkrementalnie za wykonaną pracę, tak jak jest dostarczana funkcjonalność. Odpowiedź kierowników jest zwykle jedna: „moi klienci się na to nigdy nie zgodzą, oni chcą wiedzieć ile będzie kosztowała całość”. Dyskusja trwa długo.

Otóż tak się składa, że rozmawiałem ostatnio z kilkoma osobami, na co dzień kupującymi oprogramowanie, w tym oprogramowanie tworzone na zamówienie. Jako, że metody zwinne moim konikiem są, prędzej czy później schodziło na tą tematykę. Z wielkim zdziwieniem stwierdzałem, że idea zwinnego rozwoju oprogramowania, w tym płacenia inkrementalnego... bardzo im się (wszystkim) podobała. Jako, że byli to ludzie odpowiedzialni za pieniądze natychmiast (wszyscy) reagowali tak samo: to jest idealny sposób ograniczania ryzyka. Jeden z nich wprost od razu zapytał gdzie może znaleźć firmę, która zgodzi się na rozwój oprogramowania w taki właśnie sposób: płacenia za krótkie, ściśle zdefiniowane iteracje. Czy przeszkadza im to, że nie wiedzą ile będzie kosztowała całość? W zasadzie nie. Ewentualne kontrowersje natychmiast znikały gdy dowiadywali się, że będą mogli zmieniać definicję „całości” w dowolnym momencie, ze skutkiem z końcem kolejnej iteracji. To jest racjonalne, bo przecież zwykle oprogramowanie kupuje się nie po to, aby było „całością”, tylko po to, aby realizowało potrzeby biznesowe. Co ciekawe ludzie, którzy zlecają tworzenie oprogramowania rewelacyjnie to rozumieją. Dla nich rachunek jest prosty: kwota jaką zapłaciłem za oprogramowanie musi być (zdecydowanie) mniejsza niż korzyść wyrażona finansowo, którą ono (szybko) wygeneruje. Dlatego możliwość dynamicznego dostosowywania się do zmieniających się potrzeb i w ten sposób możliwość szybszego generowania większej korzyści jest bardzo, ale to bardzo dużą realną wartością. Więc ja się pytam o jakim „problemie” kontraktów na projekty zwinne mówią kierownicy projektów? Zadanie domowe dla nich: przy następnej rozmowie z klientem zapytajcie się czy nie zgodziliby się na kontrakt oparty o metody zwinne zarządzania projektami.

Na koniec jedna uwaga: klienci z którymi rozmawiałem są osobami wydającymi pieniądze, że które ponoszą pełną odpowiedzialność (w części są to ich własne pieniądze). Podkreślam to, bo w korporacjach, gdzie wydaje się pieniądze „budżetowe” sprawa może wyglądać zdecydowanie inaczej.

niedziela, 4 maja 2008

Dlaczego nie u nas?

Witam po miesięcznej przerwie. Co było powodem może wyjaśnię kiedy indziej. Dzisiaj coś na temat innowacyjności. Zobaczyłem i od paru dni nie mogę wyjść ze zdziwienia. Chodzi o ten filmik zaprezentowany w ramach TED Talks:
http://www.ted.com/index.php/talks/view/id/245

Dla tych którym nie chce się oglądać streszczenie: Johnny Lee pokazuje jak za pomocą bezprzewodowego kontrolera Wii (USD 40) oraz diod podczerwonych (USD 10) skonstruował interaktywny whiteboard oraz technikę trójwymiarowej prezentacji obrazu. Zwłaszcza to drugie robi niesamowite wrażenie (więcej i dokładniej tutaj).

A teraz coś co nie daje mi spokoju od kilku dni. Jaka jest przyczyna tego, że takie innowacje powstały w USA na Carnegie Mellon University a nie gdziekolwiek w Polsce? Zwykle w takich wypadkach mówi się o pieniądzach i niedoinwestowaniu nauki. Niestety, w tym wypadku ta wymówka odpada: cały sprzęt kosztował USD 50, reszta to zwykły PC & czas na napisanie software. Odpada argument finansowy, bo nie wierzę, że naszej nauki nie stać na wydatki rzędu 200 PLN. Chyba brakuje nam więc czego innego. Pamiętam jak dzisiaj, że ładnych kilka lat temu jak chciałem robić doktorat usłyszałem na mojej uczelni "ale wie Pan, doktorat to nie jest od tego, żeby rozwiązywać jakieś problemy techniczne, tylko od tego aby poszerzać dziedzinę nauki". Cóż, Johnny Lee nic nie poszerzył za to od momentu powstania prototypu w jego laboratorium do momentu komercyjnego wdrożenia minęło... 5 miesięcy (o czym niżej). Mam dziwne wrażenie, że u nas trzeba zmienić system, bo jeżeli nie potrafimy poradzić sobie z innowacją za 200 PLN to na pewno nie będziemy potrafili poradzić sobie z innowacją za 200 000 000 PLN. Czuję się wściekły i bezsilny. Jeszcze raz: jaka jest przyczyna, że to nie powstało u nas?

Ciekawe jest też w jaki sposób rzeczony Johnny Lee poinformował świat o swojej innowacji i doprowadził do jej komercjalizacji. Otóż film z doświadczenia opublikował na... Youtube (tutaj konkretnie). Koszt: USD 0 (zero). Film obejrzał człowiek z Electronic Arts. Muszę tłumaczyć do było dalej??? 5 miesięcy.

Co sprawia, że u nas tak nie można?

Odpowiedź jest warta miliardy i przyszłość naszego kraju.

piątek, 11 kwietnia 2008

Co to jest to Agile Project Management?

Jak w największym skrócie wytłumaczyć czym jest zwinne zarządzanie projektami (Agile Project Management)? Odpowiedź w szczegółach będzie inna w zależności od tego do kogo ma być skierowana. W jednym zdaniu powiedziałbym tak:

Dla organizacji, działających w warunkach, w których istnieje niepewność dotycząca technologii bądź wymagań klienta, Agile Project Management jest klasą metod zarządzania projektami pozwalającą,w odróżnieniu od innych, na natychmiastowe rozpoczęcie, uporządkowane poprowadzenie i zakończenie z sukcesem projektów kierując sie cały czas przepływem wartości dodanej dla odbiorcy produktów projektu.*

Miejscem, gdzie metody zwinne znajdują najlepsze zastosowanie są te środowiska, w których występuje niepewność. Na przykład wszelkiego typu projekty innowacyjne lub projekty dla bardzo szybko zmieniających się rynków (internet, „nowe media”). W takich wypadkach nie ma możliwości dokładnego zaplanowania całości projektu w sensownym czasie. Mamy więc klasyczny dylemat: albo planujemy dokładnie (bo tak jest bezpiecznej) i odkładamy start projektu w nieskończoność albo zaczynamy działać szybko (bo tak wymaga rynek) w oparciu o niepełne plany. Metody zwinne rozwiązują ten potencjalny konflikt dając zestaw narzędzi pozwalający na rozpoczęcie projektów w nie będąc pewnym całego planu osiągnięcia celów projektu. Co więcej dają możliwość usystematyzowania prac nad takim projektem w sposób, który gwarantuje, że zespół mimo braku posiadania pełnego planu pozostanie na właściwej drodze i będzie wykonywał właściwe zadania.

Metody zwinnego zarządzania projektami są tak skonstruowane, że mimo braku pewności co do dróg osiągnięcia celów projektu jeden parametr jest cały czas w punkcie skupienia zarówno kierownictwa projektu jak i każdego członka zespołu. Tym parametrem jest przepływ dodanej wartości biznesowej dla odbiorcy produktów projektu (klienta). Ta jedna cecha stanowi, że w połączeniu z elastycznością tego rozwiązania projekty realizowane metodami zwinnymi mają zdecydowanie większe szanse zakończyć się sukcesem. Klient jest zaangażowany w cały proces decyzyjny w projekcie zwinnym. Zespół projektowy realizując projekt ściśle odpowiada na potrzeby klienta dostarczając mu dokładnie te elementy, które stanowią realną wartość dodaną dla klienta. Takie podejście powoduje, że z jednej strony zespół projektowy uczy się co ma a co nie ma wartości w danym projekcie, z drugiej odbiorca produktu (klient) doskonale wie, że będzie dostawał dokładnie to, co dla niego jest wartościowe a nie to co wartościowe jest dla zespołu projektowego.

Na koniec rzecz wcale nie najmniej ważna, którą zawsze lubię podkreślać. Zarządzanie zwinne projektami, poprawnie zaimplementowane, oprócz opisanych wcześniej realnych zalet biznesowych ma jedną niepowtarzalną zaletę ludzką: zespoły projektowe po prostu lubią pracować tą metodą. Jakie są tego powody tłumaczyłem tutaj. A możliwe implikacje biznesowe przedstawiałem nie swoimi słowami tutaj.


*Dodatkowy warunek konieczny: produkty projektu można dostarczać w postaci inkrementacyjnej. To oznacza, że funkcjonalność, którą spodziewamy się dostać w ramach całego projektu powinna być możliwa do podzielenia na tak małe części, aby każdą z nich dało się wykonać w ramach jednej, dość krótkiej (2-6 tygodni), iteracji.

czwartek, 3 kwietnia 2008

Metody zwinne w organizacji "stabilnej" cz. 4

Dzisiaj po raz ostatni napiszę o tym dlaczego stabilne organizacje przechodzą na zwinne zarządzanie projektami. Powód, który zostawiłem na koniec jest dość kontrowersyjny, choć jednocześnie jest dość często wymieniany przez managerów z firm, które wdrożyły zarządzanie zwinne projektami.

Powodem, dla którego przechodzi się na zarządzanie zwinne jest często chęć przestawienia organizacji z nastawienia czysto technicznego na nastawienie biznesowe. Tradycyjny paradygmat zarządzania przyłożony do organizacji produkujących bardzo zaawansowane technicznie produkty takie jak na przykład oprogramowanie powoduje bowiem, że wewnątrz organizacja zaczyna skupiać się na technice podczas gdy na zewnątrz powinna skupiać się na zaspokajaniu biznesowych potrzeb klienta. Inżynierowie pracujący w organizacjach zarządzanych tradycyjnie przez większość swojego czasu zastanawiają się jak rozwiązać problem techniczny a nie problem biznesowy klienta. Wbrew pozorom to nie to samo. W niektórych firmach powstają wręcz specjalne działy analityków, których jedynym zajęciem jest przekładanie wymagań biznesowych na wymagania techniczne. Założenia za tym stojące są takie, że inżynierowie nie mogą zrozumieć wymagań biznesowych a z drugiej strony, że klient nie jest w stanie pojąć techniki. O ile to drugie być może jest prawdziwe to zarządzanie zwinne projektami całkowicie odrzuca założenie pierwsze.

Całe proces zarządzania zwinnego został tak stworzony by na każdym etapie dbać o klienta. Inżynier pracujący nad projektem głównie rozwiązuje problemy klienta i spełnia jego wymagania. Każde działanie zespołu projektowego jest podporządkowane wypełnieniu wymagania funkcjonalnego klienta. Wymagania funkcjonalne zaś są reprezentacją wartości dodanej dla klienta, czyli tego, za co firma realizująca projekt dostaje pieniądze. Takie podejście pomaga inżynierom skupić się na rozwiązywaniu realnych problemów klientów a nie problemów technicznych, które często są ciekawe i interesujące ale w żadnym razie nie przyczyniają się do znacznej poprawy funkcjonalności produktu.

Kolejną cechą pomagającą zespołowi projektowemu nastawić się na rozwiązywanie potrzeb klienta jest sposób zapisywania wymagań i idący za tym stały kontakt z klientem. W projektach zwinnych zakłada się, że wymagania pierwotnie spisywane są na dość dużym poziomie ogólności. Następnie są one uszczegółowiane podczas bieżących kontaktów z przedstawicielami klienta. Jak już kiedyś wspominałem rozwiązuje to problem kodowania i dekodowania informacji – osoby implementujące wymagania na bieżąco i bezpośrednio od klienta dostają informację o tym jak będzie wykorzystywana zlecona funkcjonalność. Otrzymywanie tych informacji bezpośrednio od klienta z pominięciem zespołu analityków oznacza lepszy kontakt z rzeczywistym światem klienta i zdecydowanie lepszą komunikację. Doświadczenie projektów prowadzonych metodami zwinnymi wskazuje, że ilość niepoprawnie (z punktu widzenia klienta) działających funkcji produktu jest nieistotnie mała. Oczywiście wszystko to pod warunkiem, że klient zgodzi się poświęcić swój czas na intensywną komunikację z zespołem projektowym – zwykle nie ma z tym jednak problemu, gdyż w zamian uzyskuje zdecydowaną korzyść w postaci lepiej przemyślanego produktu.

Dużą rolę w skupieniu na kliencie odgrywają przeprowadzane po każdej iteracji prezentacje działającego produktu. Podczas tych prezentacji klient może i powinien sam używać produktu wytworzonego do tej pory w projekcie. Najłatwiej jest to zrobić w przypadku oprogramowania komputerowego, gdzie po prostu klient dostaje do ręki klawiaturę i myszkę. Może w pełni korzystać ze wszystkich funkcji, które miały być wyprodukowane we właśnie zakończonej iteracji. NA tym samym spotkaniu obecni są także członkowie zespołu projektowego, którzy na żywo widzą, w jaki sposób klient używa ich produktu. Takie spotkania bardo pomagają ustawić właściwą perspektywę biznesową wśród zespołu. Szczególnie, że odbywają się relatywnie często. Zdarzało się wielokrotnie, że zespół widząc jak ich klient używa produktu proponował rewolucyjne zmiany w produkcie wielokrotnie upraszczające sposób użycia i w efekcie pozwalające klientowi pracować dużo bardziej efektywnie.

Na koniec mała uwaga: w żaden sposób nie chcę tutaj dowieść, że tradycyjnie zarządzane projekty nie są nastawione pro-kliencko. Twierdzę jedynie, że metody zwinne wydatnie pomagają skupić się na rozwiązywaniu faktycznych problemów klienta, komunikacji z klientem oraz na sposobie, w jaki faktycznie będzie wykorzystywany produkt końcowy.

środa, 19 marca 2008

Przejrzystość – przykład

W nawiązaniu do posta o przejrzystości.

Znany mi jest przypadek projektu, w którym kierownik wyższego szczebla miał zwyczaj idąc po kawę wchodzić do pokoju projektowego, patrzyć się na ścianę na której były te wszystkie informacje po czym bez słowa wychodzić z pokoju. Takie „nawiedzenia” zdarzały się mniej więcej co dwa dni. Co z tego? Otóż jednocześnie ten sam kierownik (który był jednocześnie sponsorem – płacił za projekt) nigdy nie pytał kierownika projektu o status. Nauczył się sam go odczytywać i te dwie minuty raz na dwa dni mu starczały. Z kierownikiem projektu spotykali się tylko podczas demonstracji na koniec iteracji. Obaj: kierownik projektu i sponsor byli z tego bardzo zadowoleni. Pierwszy miał święty spokój a drugi czuł się najlepiej poinformowanym sponsorem w firmie. Wniosek: radiatory informacji się sprawdzają.

wtorek, 11 marca 2008

Iteracje synchronizujące

Kiedyś pisałem o tym, że nie każda iteracja musi być „zwykłą” iteracją. Wtedy podawałem przykład tzw. iteracji 0, których cechą jest dostarczanie wartości dodanej dla zespołu projektowego nie dla klienta. Osobom wyznającym „agile ortodoksyjny” na pewno się to nie spodoba, ale ja dopuszczam poza iteracją 0 także inne „specjalne” iteracje. Ważne tylko jest, aby każda z tych iteracji dostarczała realną wartość dodaną dla klienta. Nie dopuszczam sytuacji, kiedy iteracja inna niż 0 nie wytwarza rzeczywistej wartości dodanej.

Szczególnym przykładem takiej specjalnej iteracji jest coś, co popularnie nazywa się iteracjami synchronizującymi. Takie iteracje występują w sytuacji, kiedy na jeden produkt składa się więcej niż jeden element wytwarzany metodami zwinnymi w jednym czasie. Wówczas w którymś momencie musi nastąpić połączenie poszczególnych elementów w jeden produkt, czyli integracja komponentów. „Agile ortodoksyjne” zakłada, że takie komponenty są integrowane cały czas wykorzystując mechanizmy ciągłej integracji. W praktyce często zdarza się jednak, że z różnych powodów nie jest możliwe przeprowadzanie ciągłej integracji. Wówczas dość często stosuje się tak zwane iteracje synchronizujące. Polega to na tym, że dana wersja produktu jest rozwijana w ramach poszczególnych komponentów (czyli normalnie). Ostatnia iteracja w rozwoju danej wersji przeznaczona jest na poskładanie w całość wszystkich komponentów. Z punktu widzenia przepływu wartość dla klienta wygląda to tak, że do przedostatnie iteracji klient dostaje komponenty o zwiększonej funkcjonalności, natomiast zwiększoną wartością ostatniej iteracji jest działanie systemu (zamiast sumy komponentów). Takie działania integracyjne w ramach ściśle określonej iteracji dają w większości przypadków bardzo pozytywne efekty. Należy jedynie pamiętać, aby tą akurat iterację zaplanować od strony czasowej bardzo konserwatywnie. Powód jest bardzo prosty. Bez włączonych mechanizmów ciągłej integracji okazuje się, że sama integracja wykazuje wiele błędów w poszczególnych komponentach. Dlatego dodatkowy czas musi być przeznaczony na ewentualne poprawki znalezionych błędów. Cóż: coś za coś – brak „problemów” ciągłej integracji skutkuje zwiększonymi kosztami poprawiania błędów.

Na koniec dwie uwagi do powyższego tematu. Po pierwsze mimo braku zaimplementowanych mechanizmów ciągłej integracji pod żadnym pozorem nie wolno doprowadzić do rozjechania się interfejsów poszczególnych komponentów. Zadanie zsynchronizowania poszczególnych części jest w takiej konfiguracji szczególnie ważne i powinno zostać powierzone osobie odpowiedzialnej za całość przedsięwzięcia (uwaga, to też nie jest zgodne z „agile ortodoksyjnym”).

Druga uwaga, to dość oczywisty, ale często zapominany fakt, że problemy z integracją komponentów w największym stopniu można ograniczyć poprzez inteligentny i przemyślany podział na całości systemu na części. Do takich przemyśleń można wykorzystać na przykład czas iteracji 0. Jak konkretnie to zrobić to byłby już temat na osobny post.

poniedziałek, 3 marca 2008

Metody zwinne w organizacji "stabilnej" cz. 3

Dzisiaj kolejny powód, dla którego organizacje stabilne wdrażają zwinne metody zarządzania projektami. Powodem tym jest przejrzystość prac, którą zapewniają metody zwinne.

Przejrzystość prac jest widoczna na dwóch ogólnych poziomach. Po pierwsze przejrzyste jest to co kto robi i jaki jest stopień zaawansowania prac. Podczas codziennych spotkań zespołu uczestnicy projektu opowiadają nad czym pracowali wczoraj i co będą robić dzisiaj, co skutkuje bardzo szybkim rozpowszechnianiem się informacji. Prowadzi to do jasnej sytuacji na temat tego, jakie jest aktualne zajęcie wszystkich członków zespołu. Innym, jeszcze ciekawszym narzędziem są wszelkiego typu „radiatory informacji” wykorzystywane przez zespoły do graficznej prezentacji zaawansowania prac. To temat na osobny post, ale w skrócie narzędzia te są „analogowe” (np. tablica z żółtymi karteczkami) a nie elektroniczne i mogą zawierać najważniejsze informacje zarządcze dotyczące projektu: co zostało zrobione, co jest robione, co będzie robione, a także informacje o tym jak aktualny status ma się do planu. Wszystko to jest przedstawione wizualnie. To narzędzie jest genialne w swojej prostocie a jednocześnie przekazuje zadziwiająco dużo informacji.

Drugim poziomem przejrzystości jest przejrzystość w stosunku do klienta. W tradycyjnych metodach zarządzania projektami często jest tak, że klient nie ma najmniejszej wiedzy, co się dzieje w projekcie, za który przecież płaci, aż do dnia ostatecznego odbioru produktu. Techniki zwinne zakładają inne podejście. Po pierwsze klient musi być zaangażowany cały czas. W każdej chwili zespół pracujący nad projektem ma prawo zapytać się klienta o uszczegółowienie wymagań lub potwierdzić, że wymagania zostały zaimplementowane poprawnie. Takie zaangażowanie samo w sobie daje klientowi wgląd w to, nad czym aktualnie pracuje zespół projektowy i wystarcza, aby klient nie miał pretensji, co do stopnia informowania go o stanie projektu. Jednak techniki zwinne mają jeszcze jedno potężne narzędzie: krótkie iteracje zakańczane działającą wersją produktu. Po każdej z iteracji klient może wypróbować nowe funkcjonalność stworzone podczas tej iteracji. W związku z tym klient ma cały czas poczucie, że wie, za co płaci. Wie też, kiedy pojawią się kolejne funkcjonalności do przetestowania (na koniec aktualnej iteracji). To z punktu widzenia klienta zapewnia pełną przejrzystość i pozwala na utrzymanie bardzo dobrych relacji z dostawcą. Uwaga!!! Trzeba być jednak świadomym, że taka sytuacja nie powstanie od razu i jej wypracowanie będzie wymagało włożenia odpowiednio dużej ilości czasu w ustalanie zasad współpracy z klientem.

Inną stroną przejrzystości prac jest to, o czym wspomniał jakiś czas temu w komentarzach Marcin (tutaj). Przejrzystość może być bowiem bardzo niewygodna dla tych, którzy mówiąc delikatnie „nie lubią” pracować. Częste sprawdzanie postępu prac i konieczność wyraźnego informowania o tym co się zrobiło powoduje, że nie ma mowy o ukrywaniu się przez kilka dni nic nie robiąc. Poza ewidentnym pokazaniem szefom, że taki pracownik jest zbędny w środowiskach pracujących według metod zwinnych pojawia się bardzo silna presja ze strony grupy. Podczas wspomnianych codziennych spotkań wszyscy współpracownicy słyszą i widzą kto pracuje mało. Doświadczenie wskazuje też, że da się wyczuć kto po prostu się obija a kto rzeczywiście tworzy mało bo ma jakieś problemy. Osoby ewidentnie się obijające są pod bardzo dużą presją grupy aby zabrać się do pracy.

I w ten sposób ujawnia się jeszcze jedna duża zaleta metod zwinnych: znacząco wzrasta wydajność zespołów pracujących przy użyciu tych metod w porównaniu do zespołów stosujących metody tradycyjne. Rzecz nie do przecenienia w biznesowym świecie nastawionym na efektywność prac. Co więcej wzrost tej efektywności nie ma żadnego negatywnego wpływu na atmosferę prac. Wręcz przeciwnie ma wpływ pozytywny.

niedziela, 24 lutego 2008

Miary

Z miarami jest tak jak w popularnym powiedzeniu. W języku polskim mówi się „proście a będzie wam dane”, po angielsku jest „proście a otrzymacie”. To drugie ma w tym przypadku jeszcze większy sens. Już znany chyba wszystkim W. Edwards Deming kilkadziesiąt lat temu wskazywał, że wszelkiego typu systemy miar stosowane w przedsiębiorstwach i firmach determinują sposób, w jaki pracują pracownicy. „Pokaż mi, co mierzysz a powiem Ci jak pracujesz”. To normalne dla natury ludzkiej, że ucieka od sytuacji kiedy boli a dąży do sytuacji w której jest przyjemnie. Systemy miar stosowane w firmach najczęściej powiązane są z jakimiś reperkusjami, na przykład z wypłatą premii czy choćby łaskawszym (bądź nie) spojrzeniem szefa. Dlatego tak skutecznie determinują sposób w jaki się pracuje. Ludzie nie są głupi i będą próbowali pracować tak, aby dzięki stosowanym miarom mieć jak najwięcej przyjemności.

Po co to piszę? Bo każdy, nawet najlepszy system zarządzania, nawet najlepiej zdefiniowane i wdrożone metody zwinne zarządzania projektami można wypaczyć stosując nieadekwatny i źle dostosowany system miar. Najczęściej zdarza się to, kiedy „dojrzała” organizacja dojdzie do wniosku, że trzeba wdrożyć metody zwinne. Dość szybko okazuje się, że problemem jest to, że dość dużo osób ma problemy z odnalezieniem się w nowej sytuacji. Wszystkie te osoby są z kategorii zawodowej zajmującej się w głównej mierze przeglądaniem różnego typu raportów, papierków, tworzeniem sprawozdań, koordynowaniem działań, zapewnianiem spójności, politykami wewnętrznymi itp. W skrócie: żadna z nich nie przyczynia się bezpośrednio do osiągania wartości dodanej dla klienta. Poprawne wdrożenie metod zwinnych w organizacji oznacza przestawienie wszystkich tych osób na zadania bezpośrednio związane z generowaniem wartości dodanej. Niestety często w przypadku niezbyt udanych wdrożeń zdarza się, że o tych osobach się „zapomina”. Problem zamieciony pod dywan wraca jednak dość szybko. Zaczyna się usilne udowadnianie jak kto bardzo jest potrzebny. W ramach tego udowadniania najprościej jest zażądać tego, co było wcześniej, czyli raportów i sprawozdań. Najczęściej pod szczytnym hasłem potrzeby sprawdzania, czy wszystko jest: zgodne z planem, zgodne z polityką jakości, zgodne z procesami, itp. Z raportów wyciągane są miary. Miary służą potem do oceny pracowników. Pracownicy zaczynają pracować dla zaspokojenia miar. Normalne i zdrowe ludzkie zachowanie. Tyle tylko, że nie ma nic wspólnego z tym, co powinni robić. Przypominam: pracownicy powinni pracować dla zaspokojenia potrzeb klienta.

Przykład z życia wzięty. Pewna firma produkująca oprogramowanie komputerowe wdrożyła zarządzanie zwinne projektami. Zapomniano jednak zaangażować w prace projektowe dział zarządzania jakością firmy i zostawiono go poza strukturą projektów. Szybko okazało się, że dział ten zaczął zgłaszać potrzebę upewnienia się, że w projektach tworzy się tylko i wyłącznie oprogramowanie „wysokiej jakości”. Zdefiniowano więc miary: ilość unikalnych przypadków testowych w projekcie oraz stopień automatyzacji przypadków testowych. Jeden i drugi wskaźnik ustalano na podstawie historii wcześniejszych projektów. Miało to zagwarantować wysoką jakość oprogramowania gdyż: im więcej przypadków testowych tym lepiej przetestowany produkt oraz im więcej z nich jest automatycznych tym mniejsze prawdopodobieństwo popełnienia błędów. Na ten drugi wskaźnik zwracano szczególną uwagę, gdyż zapewniał on także znaczące oszczędności: testy odbywały się automatycznie, więc były „tańsze” niż takie, przy których pracować musieli ludzie. Brzmi logicznie? Powiedzmy. Co się stało? Oczywiście oba wskaźniki były osiągane w każdym projekcie. Przynajmniej na pierwszy rzut oka wszystko było ok. A w szczegółach? Zacznijmy od automatyzacji. Konieczność automatyzacji testów powodowała, że po prostu nie definiowano przypadków testowych, których nie dało się zautomatyzować. Proste? Ano tak. Po drugie ilość testów. Jak najprościej osiągnąć dużą liczbę przypadków testowych? Ano napisać wiele wersji tego samego. Szybko i bezboleśnie można wygenerować dowolnie dużą ilość przypadków. W tym konkretnym przypadku po analizie okazało się, że zdefiniowane przypadki testowe pokrywały (wielokrotnie) średnio niecałe 70% kodu stworzonego oprogramowania. Nietrudno się domyślić, że pozostałe 30% było tymi fragmentami, gdzie trudno było napisać testy automatyczne. Zgadnijcie, gdzie najczęściej ujawniały się błędy w oprogramowaniu tworzonym przez tą firmę? Proście a otrzymacie…

poniedziałek, 4 lutego 2008

Przerwa

Ze względu na nawał pracy ze smutkiem ogłaszam przerwę w pisaniu na blogu. Orientacyjny czas powrotu do regularnego pisania: ostatni tydzień lutego 2008.

Zapraszam serdecznie!!!

niedziela, 20 stycznia 2008

Wdrażanie metod zwinnych

Metody zwinne jak wielokrotnie wskazywałem na tym blogu i w każdych innych źródłach są niezwykle proste. Pełen proces zarządzania projektem zwinnym przy odrobinie szczęścia można zapisać na kilku kartkach A4. To prowadzi do przekonania, że wdrożenie metod zwinnych w firmie jest równie proste. Ostrzegam. Wcale tak nie jest.

Główny problem polega na tym, że aby poprawnie zarządzać projektami nie zmienić i wystarczy wdrożyć samych procesów zarządczych. W większości wypadków natomiast zmiana sposobu realizacji projektów polega mniej więcej na tym, że pewnego pięknego dnia szef daje pracownikom książkę lub zbiór instrukcji i mówi „od dziś tak będziemy pracować”. Niestety tak się nie da. Być może w ten sposób można zmienić metodę zarządzania projektami z PMI na Prince2 lub odwrotnie. Natomiast jest to zdecydowanie za mało, aby przestawić firmę na zarządzanie zwinne.

Wdrożenie zarządzania zwinnego musi być skupione nie na zmianie samych procesów, ale na zmianie przynajmniej trzech elementów w firmie:

  1. Procesu – tak, to jest ważne, aby wszyscy zainteresowani wiedzieli, według jakiego procesu pracują i co jest od nich wymagane. Ten element jest najprostszy – jest to czysta wiedza, którą trzeba sobie po prostu przyswoić. Są do tego książki, są szkolenia, nie ma problemu.
  2. Umiejętności ludzi – zarządzanie zwinne niesie za sobą konieczność używania zupełnie innego zestawu umiejętności, zwłaszcza w obszarze międzyludzkim, niż tradycyjne zarządzanie projektami. Ze względu na bardzo duże znaczenie komunikacji międzyludzkiej i odstąpienie od dokumentowania najmniejszych szczegółów uzyskuje się z jednej strony dramatyczny wzrost wydajności, z drugiej zaś duże pole do psucia stosunków między ludźmi. Tylko osoby posiadające odpowiednie umiejętności będą mogły z sukcesem prowadzić projekty zwinne. Nabycie tych umiejętności nie jest już takie proste jak zmiana procesu. Umiejętności z definicji oznaczają, że coś się umie zrobić – to już jest praktyka a nie teoria.
  3. Kultura pracy (tzw. kultura organizacyjna) – rzecz ostania, ale bardzo ważna, aby zarządzanie zwinne pokazało wszystkie swoje zalety i zapewniło oczekiwany wzrost efektywności. Kultura pracy, czyli zestaw postaw prezentowanych przez wszystkich pracowników organizacji. Tutaj musi nastąpić wielka zmiana. Choćby dlatego, aby "szefostwo" nie wymagało na początku dokładnego planu całego przedsięwzięcia a z drugiej strony sprzedaż nie próbowała usilnie sprzedać klientowi efektu końcowego drugiej iteracji (w momencie kiedy wersja produktu miała pojawić się po iteracji ósmej). Kulturę pracy zmienić najtrudniej. Nie można tego zrobić oddolnie, zawsze musi to przyjść od strony wyższej kadry kierowniczej. Podkreślam to, gdyż jest to jasna wskazówka, że bez zaangażowania i przekonania wyższego kierownictwa wdrożenie metod zwinnych nigdy nie zakończy się pełnym sukcesem a metody te nie pokażą swojego pełnego potencjału.

Podsumowując wypada mi tylko powtórzyć, że jeżeli ktoś twierdzi, że można „wdrożyć agile” poprzez danie do przeczytania książki programistom i kierownikom projektów to się bardzo grubo myli. Przeprowadzenie wdrożenia metod zwinnych tylko na jednej płaszczyźnie zamiast na wszystkich w pesymistycznym przypadku może spowodować w organizacji więcej szkody niż pożytku.

niedziela, 13 stycznia 2008

Metody zwinne w organizacji "stabilnej" cz. 2

Wracamy do tematu wdrażania metod zwinnych w organizacji stabilnej. Jak już pisałem wcześniej (tutaj) jest to obecnie pewna moda, ale są też realne powody dla których taka decyzja może być podjęta. Dzisiaj o aspekcie biznesowo-technicznym a mianowicie o uzyskiwaniu informacji zwrotnej od klienta.

Metody zwinne prowadzenia projektów zakładają podejście iteracyjne do tworzenia produktu. Każda z krótkich iteracji zakończona jest przedstawieniem klientowi działającej wersji produktu, która jest wzbogacona o konkretną wartość biznesową w porównaniu z wersją dostępną na początku iteracji. Klient uczestniczy w prezentacji funkcjonalności stworzonej podczas iteracji i/lub dostaje niewykończony produkt do testów. To, że klient widzi działający produkt powoduje natychmiastową reakcję klienta i dostarczenie zespołowi informacji zwrotnej (feedback) na temat produktu. Najważniejsze w tym opisie jest to, że w odróżnieniu od innych metod zarządzania w metodach zwinnych obowiązkowo informacje zwrotną klient przekazuje po każdej iteracji, czyli bardzo często. Dla każdej organizacji nastawionej na dostarczanie wartości dodanej dla klienta częsta informacja zwrotna jest kluczowym czynnikiem sukcesu. Pozwala ona bardzo często dokonywać sprawdzenia, czy rozwijany produkt faktycznie spełnia oczekiwania klienta, będzie mu przydatny i ogólnie czy będzie sukcesem (z punktu widzenia stopnia zadowolenia klienta). Dla tych graczy na rynku, którzy faktycznie żywią się sukcesem swoich klientów jest to zaleta nie do przecenienia.

Dla tych samych graczy kluczowy jest także drugi aspekt zbierania informacji zwrotnej od klientów w projektach zarządzanych zwinnie. Otóż informacja ta jest w 100% zbierana na podstawie stworzonej i działającej wersji produktu ostatecznego. W innych metodach bardzo często zdarza się, że informacja zwrotna zbierana jest na podstawie analizy dokumentów. Problem w tym jest taki, że każdy dokument ma pewien stopień swobody interpretacyjnej. Co więcej im mniej jest tej swobody tym dokument droższy do stworzenia. Zwykle następuje więc kompromis pomiędzy stopniem swobody a kosztami wytworzenia dokumentacji. Efekt jest taki, że choć obie strony przeczytają dokument i według nich będzie on dobry, obie zrozumieją go inaczej i klient dostanie nie to, co sobie zinterpretował z dokumentu. Porażka i negocjacje dotyczące trybu wprowadzenia poprawek są w takiej sytuacji gwarantowane. Metody zwinne pozwalają zbierać informację zwrotną już na podstawie stworzonego produktu. Klient namacalnie może stwierdzić, czy to jest zgodne z jego oczekiwaniami. Nie ma tu już możliwości interpretacji, bo ogląda działający produkt. W ten sposób przekazywana informacja zwrotna jest nie tylko częsta i szybka, ale także dokładna. Dla firm „upolitycznionych” żyjących z tego jak dobrych mają prawników może to być duża wada, ale dla większości firm, które dostają faktury za spełnienie oczekiwań swoich klientów może być to kluczowa element budowania dobrej marki.


Warto wspomnieć o dwóch biznesowych skutkach częstego zbierania dokładnej informacji zwrotnej. Po pierwsze dramatycznie zmniejszają się koszty poprawek. Choć na początku projektu klient może zgłaszać ich dużo to po praktyka wskazuje, że po pewnym okresie (kilka iteracji) jest ich już znacząco mniej, bo zespół uczy się na czym zależy klientowi. Taka sytuacja powoduje, że jest możliwe wprowadzenie kluczowych poprawek w momencie, kiedy produkt jest jeszcze stosunkowo mały (1-3 iteracja). Jest to zdecydowanie tańsze niż wprowadzanie tej samej poprawki w momencie, kiedy produkt już się rozrósł. Po drugie zbieranie szybkiej informacji zwrotnej od klienta pozwala bardzo szybko zlikwidować nieudane projekty. W każdej organizacji zdarza się tak, że czasami któryś projekt nie jest udany i nie ma szans na sukces. Problem, który się zwykle pojawia, to że okazuje się to kiedy organizacja zainwestowała już w projekt bardzo dużo środków. Wówczas podjęcie decyzji o zamknięciu takiego projektu jest bardzo trudne, bo ciężko jest się przyznać do tak dużego błędu. Metody zwinne pozwalają oceniać projekt po każdej iteracji przez tych, którzy będą go używać. Z tego względu jeżeli projekt jest nietrafione często da się to wykryć już po drugiej/trzeciej iteracji i zlikwidować go przy dużo niższych kosztach niż w tradycyjnych metodach. Jest to kluczowe zwłaszcza dla firm działających w sferze wysoce innowacyjnej lub przy bardzo szybko zmieniającym się rynku.

sobota, 5 stycznia 2008

Zarządzanie innowacjami jest łatwe!!!

A konkretnie: zarządzanie projektami innowacyjnymi nie jest trudniejsze od projektów nie-innowacyjnych. Taki długi tytuł nie zmieściłby się na stronie. Przechodząc do konkretów:
Zupełnie nie rozumiem, dlaczego przyjęło się, że zarządzanie projektem wysoce innowacyjnym jest dużo trudniejsze niż zarządzanie projektem „standardowym”. Fakty przeczą takiemu twierdzeniu i jedyne, co można powiedzieć to, że zarządzanie jest „inne”, ale na pewno nie „trudniejsze”.


W zarządzaniu projektami innowacyjnymi główną „innością” jest występująca duża niepewność, co do podejmowanych działań. Z jednej strony tradycyjna metodyka zarządzania projektem zwykle wymaga, żebyśmy już na początku wiedzieli, co dokładnie mamy zrobić, w jakiej kolejności i ile to potrwa. Z drugiej strony samo pojęcie innowacyjności sugeruje coś dokładnie odwrotnego: nie wiemy co dokładnie mamy zrobić, nie wiemy dokładnie jaki będzie rezultat, ani tym bardziej nie wiemy ile dokładnie przeznaczymy na to czasu. Z takich dwóch stanowisk rodzi się konflikt, którego rozwiązanie nie wydaje się być proste. Wtłoczeni w ten konflikt kierownicy projektów rozrywani między dwie strony twierdzą później, że zarządzanie projektami innowacyjnymi to koszmar.

Tymczasem ten konflikt można rozwiązać w dość prosty sposób: zmieniając założenia dotyczące zarządzania projektami. Metody tradycyjne, wymagające bardzo dokładnego planowania po prostu są tutaj złym narzędziem. To tak, jakby ktoś próbował użyć siekiery do obierania ziemniaków i narzekał, że to frustrujące. Wystarczy natomiast zmienić narzędzie (na nóż) i natychmiast przestaniemy się frustrować.

Ogólnie można wyróżnić dwa „trudne” przypadki w zarządzaniu projektami innowacyjnymi: albo wiemy co mamy zrobić (poszczególne zadania) ale nie wiemy ile będą trwały, bo są one innowacyjne, albo wiemy tylko co chcemy osiągnąć, ale nie mamy sprecyzowanej drogi dojścia do celu.

W drugim wypadku, gdy znamy tylko cel a nie znamy metody dojścia do celu ani nie możemy jej zaplanować w ekonomicznie uzasadnionym czasie pozostaje użycie narzędzia stworzonego do takich przypadków: zwinnego zarządzania projektami. Jak już wielokrotnie tu było pisane metody zwinne pozwalają na dokładne planowanie tylko krótkich iteracji zbliżających cały projekt do wcześniej określonego celu (wizji). Jednocześnie częste interakcje z klientem pozwalają na weryfikację czy nasza innowacja stanowi wartość dodaną dla klienta. W ten sposób możemy bardzo szybko wycofać się z chybionych inwestycji. Czy zarządzanie projektem innowacyjnym w oparciu o takie procesy to koszmar? Nie, to czysta przyjemność. Pod warunkiem oczywiście, że procesy będą wspierane przez wszystkich w organizacji a nie tylko przez kierownika projektów.

Innym przypadkiem jest pierwszy z przypadków opisanych wcześniej. Czyli sytuacja, kiedy wiemy, jakie zadania należy wykonać w projekcie, ale innowacyjność przedsięwzięcia uniemożliwia stworzenie poprawnych oszacowań czasu trwania poszczególnych zadań. Jest to interesujące, bo problem ten dotyczy także innych projektów, niekoniecznie innowacyjnych – często z wielu przyczyn nie możemy określić dokładnie czasu trwania poszczególnych zadań lub ten czas trwania z założenia jest określony z dość małym stopniem prawdopodobieństwa. Znów użycie tradycyjnych metod zarządzania projektami w takim przypadku bardzo szybko prowadzi do frustracji kierownika projektu i całego zespołu. Należy bowiem zdać sobie sprawę, że np. szeroko stosowana metoda ścieżki krytycznej zakłada, że czasy trwania poszczególnych zadań są oszacowany poprawnie. Jeżeli pojawią się różnice w realnym czasie wykonania zadań w stosunku do planu wówczas ścieżka krytyczna może się zmieniać praktycznie codziennie doprowadzając osobę próbującą nią zarządzać na stan załamania nerwowego. Czy tak musi być? Nie. Istnieją odpowiednie metody zarządzania projektami, które skonstruowane zostały właśnie po to, aby radzić sobie z niedokładnością oszacowań. Taką metodą jest metoda łańcucha krytycznego (łańcuch a ścieżka to dwa różne pojęcia). W metodzie łańcucha krytycznego zakłada się skonstruowanie modelu projektu w taki sposób, aby ochronić datę zakończenia projektu przed zmianami. Jednocześnie jednym z założeń tej metody jest niedokładność oszacowań czasu trwania poszczególnych zadań. Niemożliwe? A jednak. Możliwe i wykorzystywane.


Znów dochodzimy do tego, od czego ten post się zaczął. Zarządzanie projektami innowacyjnymi jest łatwe. Pod warunkiem, że użyje się odpowiedniego narzędzia. Niestety część osób próbuje używać tego samego zestawu narzędzi do zarządzania stabilnym projektem budowy domku jednorodzinnego jak i do zarządzania wysoce innowacyjnym projektem z dziedziny IT. Oczywiście można próbować, tylko jaki będzie efekt? Etyka zawodowa kierownika projektów powinna nakazywać poznanie więcej niż jednej metody zarządzania projektami. Każdy kierownik powinien posiadać wiedzę o wielu narzędziach i wykorzystywać je w zależności od potrzeb. Jeżeli będzie próbował zawsze i wszędzie stosować jedno i to samo narzędzie to niestety skutki będą znane: frustracje, porażki i tłumaczenia, że to jest „trudne i skomplikowane”. Fakt, obieranie ziemniaka przy użyciu siekiery jest trudne i skomplikowane.