Własność funkcjonalności

W projektach informatycznych zdarza się bardzo często sytuacja kiedy projekty jest na tyle duży, że do poprawnego zdefiniowania wymagań potrzeba więcej niż jednej osoby. Po prostu wiedza dziedzinowa dotycząca projektu nie jest możliwa do zgromadzenia przez jedną osobę. W takim wypadku szczególnej uwagi nabiera kwestia tego, kto jest "właścicielem" poszczególnych funkcjonalności.

Przez właściciela funkcjonalności rozumie się osobę, która jest w pełni odpowiedzialna za zdefiniowanie danej funkcjonalności i zwykle będzie osobą używającą jej w przyszłości (odbiorcą korzyści biznesowej dostarczanej przez daną funkcjonalność). Zdefiniowanie takiej osoby jest niezmiernie ważne w kontekście mogących się pojawić wątpliwości dotyczących tego jak ma działać zdefiniowana funkcjonalność. Musi być ktoś, kto ma ostateczny głos w sprawie zdefiniowania pożądanego sposobu zachowania się systemu. W mniejszych systemach tą osobą jest właściciel produktu, w większych często właściciel produktu nie ma wystarczającej wiedzy aby decydować o każdej funkcjonalności i dlatego warto wyznaczać właścicieli poszczególnych funkcjonalności. Najlepiej właściciela po prostu zapisać na karcie funkcjonalności.

Powyższy system działa dobrze, do czasu kiedy nie zajdzie sytuacja w której dwie funkcjonalności zdefiniowane przez różne osoby stoją w konflikcie ze sobą. Wbrew pozorom często tak jest. Na przykład w systemach kompleksowo obsługujących przedsiębiorstwa proces sprzedaży zakłada zwykle udział działów sprzedaży, magazynu, księgowości a często także produkcji. Każdy z tych działów może mieć różną koncepcję tego jak proces sprzedaży wyglądać powinien. W takich sytuacjach osobą rozstrzygającą powinien być właściciel produktu. Niezależnie bowiem od właścicieli poszczególnych funkcjonalności musi istnieć ktoś, kto jest odpowiedzialny za całość definiowania wymagań i w związku z tym za ostateczny kształt projektowanego systemu. Tą osobą jest właśnie właściciel produktu. W przypadku dużych systemów, gdzie występuje wielu właścicieli funkcjonalności brak właściciela produktu jest bardzo często spotykanym błędem.

I na koniec: w takich sytuacjach jak opisana bardzo ważne jest, aby właściciel produktu był mocno "umocowany" w strukturze organizacji. Jest to konieczne, gdyż prędzej czy później będzie musiał on godzić wymagania różnych działów i forsować rozwiązania korzystne dla całości przedsiębiorstwa a nie dla poszczególnych kierowników. Osoba nisko stojąca w hierarchii, bez odpowiedniego autorytetu formalnego i nieformalnego nie ma szans w starciu z kierownikami "silosów". Wyznaczenie mało znaczącego właściciela produktu jest drugim bardzo często popełnianym błędem w opisywanych sytuacjach.

Księga procedur a 15 minut

Dzisiaj będzie stricte o projektach IT. Kiedyś dawno temu przeczytałem, że programista pracując nad nowym kodem średnio co 15 minut podejmuje ważną decyzję technologiczną. Fakt ten przypomniał mi się w zeszłym tygodniu, kiedy zaangażowałem się w ciekawą dyskusję nad procedurami w firmie.

Ogólnie pytanie brzmi: jak dokładnie można opisać procedury, które powinien stosować pracownik. Istnieje pewna grupa przekonań, według których procedury mogą i powinny opisywać każdą istotną czynność wykonywaną przez pracownika. Założenie stojące za takimi stwierdzeniami jest takie, że można przewidzieć i opisać każdą jedną sytuację wobec której stanie pracownik. A jak już będzie to opisane to pracownikowi będzie łatwiej pracować, bo zamiast myśleć (?!) sięgnie tylko do odpowiedniej procedury. Hmm, ciekawe, ale na pewno nie w projektach IT. Być może w budownictwie, którego tradycje sięgają kilku tysięcy lat można skatalogować i opisać każdy jeden przypadek. Ale w programowaniu? Gdzie każdą rzecz można wykonać na przynajmniej kilka sposobów? Gdzie decyzje technologiczne podejmuje się co 15 minut? Nawet gdyby teoretycznie było to możliwe księga wzorców projektowych musiałaby liczyć tysiące stron. A gdzie procedury decydowania, który wzorzec użyć? Po pierwsze nikt nie byłby w stanie tego opisać, a jeżeli nawet to potem nikt nie byłby się w stanie tego nauczyć :-)

Co więc zamiast ścisłych procedur? Po pierwsze określone ramy postępowania, czyli np. pracownicy wiedzą co jest ważne w danym rozwiązaniu: elastyczność czy wydajność. Po drugie właściwi pracownicy, którzy potrafią użyć swojej inteligencji do wybrania spośród znanych im rozwiązań tego najlepszego akurat w zadanych ramach. Co 15 minut :-) Tu problem jest większy, ale cóż za to w końcu firma płaci programiście albo innemu administratorowi, żeby to ON się znał na rzeczy. Jeżeli firma uważa, że ON się nie zna, to czemu go jeszcze zatrudnia? Pracownik musi być na tyle inteligentny i proaktywny, żeby potrafić zastosować w danym momencie rozwiązanie najlepiej realizujące cel postawiony dla danego oprogramowania. Jeżeli firmie uda się zbudować taki zespół i ustalić wspierającą go strukturę zarządzania to będzie ona na pewno bardziej "agile" (zwinna) niż firmy starające się opisać każdą decyzję pracownika w opasłym tomie procedur.

Założenia to przekleństwo

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

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

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

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

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

Metody realizacji projektów

Poniżej moje autorskie, przygotowane w konkretnym celu i dla konkretnej okazji, o której tutaj nie będę pisał, porównanie metod realizacji projektów. Można używać do woli, pod warunkiem podania źródła.

Metoda ścieżki krytycznej + EVM
Motywacja historyczna:
W dużych projektach rządowych chciano wiedzieć, na którym ciągu zadań powinien skupiać się kierownik, aby zapewnić realizację projektu w czasie.

Typowe rezultaty wdrożenia metody:

• Projekt zobrazowany jako lista prac do wykonania na osi czasu
  
• Ustalona odpowiedzialność za zadania
• Zmniejszone ryzyko opóźnienia projektu
• Możliwość formalizacji planowania i zarządzania projektami
• Iluzja pełnej kontroli (daty rozpoczęcia i zakończenia każdego zadania)
  
• Realna możliwość oceny efektywności prac zakończonych (EVM)
  

Typowe przeszkody we wdrożeniu

• Metoda tak stara, że teoretycznie nie powinno być, ale:
• Wymusza dużą formalizację projektów
• Nie daje szybkich wygranych
• Generowane są dane a nie informacje
• Łatwo skupić się na przerzucaniu formularzy zamiast zarządzaniu projektem
  

Łańcuch krytyczny (CCPM)
Motywacja historyczna:
Dla przedsiębiorstw komercyjnych kluczowe stało się realizowanie projektów w pierwotnie planowanym terminie przy ograniczonej liczbie zasobów


Typowe rezultaty wdrożenia metody:

• Projekt zobrazowany jako sieć połączonych zadań
• Ustalona odpowiedzialność za zadania
• Minimalne choć bardzo intensywny proces nadzorowania projektów
  
• Brak przeciążenia zasobów
• Maksymalizacja prawdopodobieństwa oddania projektu na czas (do 95%)
  
• Możliwość proaktywnego nadzorowania realizacji

Typowe przeszkody we wdrożeniu

• Brak jest jasnego uzasadnienia biznesowego wdrożenia
• Wymaga zmiany kultury pracy i mierników
• Pełne wdrożenie wymaga zgody wszystkich szczebli i działów
• Metoda na tyle skomplikowana, że wymaga wdrożenia zintegrowanego systemu IT
  
• Postrzeganie jako wdrożenia tylko systemu IT
• Metoda nieodporna na zmiany sieci projektu w trakcie trwania

Metody zwinne (agile)
Motywacja historyczna:
Branża informatyczna zauważyła, że konieczność planowana całości projektu przed jego rozpoczęciem nie sprawdza się w środowisku, gdzie zmiany bardzo łatwo się wprowadza – zastosowano podejście radykalnie różne od dotychczasowych


Typowe rezultaty wdrożenia metody:

• Projekt rozpisany jako lista funkcjonalności produktu
• Szybkie dostarczanie najbardziej wartościowych funkcji
• Nowe wersje dostarczane regularnie
• Łatwe dostosowywanie produktu do zmian
• Można pracować mimo braku pełnego planu
• Zdrowe relacje w zespołach
  
  

Typowe przeszkody we wdrożeniu

• Zbyt proste – wszyscy myślą, że zrozumieli
• „Cieńka czerwona linia” między chaosem a agile
• Wyższe szczeble zarządzania chcą „ciężkich” procesów
• Kierownicy produktu nie trzymają się założeń
• Wymaga zmiany kultury pracy i mierników

Na koniec drobna uwaga:

Odpowiedzialnością każdego specjalisty, w tym kierownika projektów, jest znać jak najwięcej różnych narzędzi i stosować te, które najlepiej spełnią cele postawione w danej sytuacji. Jak to kiedyś ujął mój kolega "chroń mnie Panie przed człowiekiem, który przeczytał tylko jedną książkę".

mBank antyinnowacyjny

Dzisiaj jak nigdy będzie osobiście, aczkolwiek nawiązanie do tematyki bloga na koniec się pojawi. Szerszy kontekst opisanej niżej sytuacji pochłaniał mnie przez ostatnich kilka tygodni. Mimo to nie napisałbym tego posta, gdyby nie fakt, że instytucja, o której mowa naśmiewa się w reklamach z konkurencji przedstawiając ją jako “bankozaury” i jawnie sugerując, że to ona właśnie jest ta nowa i innowacyjna. Więc chyba normalnym jest oczekiwanie, że będzie miała innowacyjny na rynku sposób podejścia do klienta. Spróbowałem.

Historia zaczęła się od tego, że potrzebowałem kredyt. Nie jakiś super bardzo duży, ale jak sobie policzyłem i tak dla banku będzie to zysk w wysokości ładnych kilku średnich krajowych. Ze względu na to, że jestem stałym klientem mBanku (między innymi dlatego, że mam alergię na przebywanie w oddziałach bankowych i stanie w kolejkach) pierwsza próba to oczywiście mBank. Prośba o kontakt wysłana przez stronę www, konsultantka oddzwania wtedy, kiedy powinna. Super. Mina zrzedła mi po 2 minutach rozmowy. Okazało się, że mBank nie przyjmie mojego wniosku kredytowego. Dlaczego? Bo za krótko prowadzę działalność gospodarczą. Za krótko o 7 dni, żeby być dokładnym. Za tydzień wniosek mógłbym złożyć, teraz nie. I to był koniec rozmowy. Nieważna była kwota, przeznaczenie, dochody, nic. “Pan zadzwoni za 7 dni to będziemy z Panem rozmawiać, teraz nie.” Ręce mi opadły. Rozumiem, jakby bank przyjął wniosek, rozpatrzył i przysłał mi odpowiedź w stylu przepraszamy, ale ten kredyt jest obarczony zbyt dużym ryzykiem/nie ma Pan zdolności czy cokolwiek innego. Ale odmówić przyjęcia wniosku?

Absurd całej sytuacji polega przede wszystkim na tym, że mBank nie chciał rozmawiać ani sprawdzić jaki to kredyt ani jak on się ma do aktywów czy dochodów. Czyli odmawiając nie mieli pojęcia o jakim zysku dla nich przy jakim ryzyku rozmawiamy. Poza tym, tak naprawdę na TERAZ to ja potrzebowałem decyzję kredytową, pieniądze mogliby mi wypłacić nawet nie 7 a 21 dni później. Tylko o to oczywiście też nikt się nie spytał, lepiej i prościej było powiedzieć, że wniosku ode mnie nie przyjmą "bo taka jest procedura". Dodatkowo zostałem postraszony, żebym nie próbował nawet złożyć wniosku samodzielnie przez internet bo jak to zrobię to złamię jakieśtam regulaminy i mBank na 3 miesiące odmówi mi jakichkolwiek usług kredytowych (czy coś podobnego). W tym momencie zupełnie już odechciało mi się z nimi rozmawiać.

Ok, super-innowacyjny bank ewidentnie nie chce, więc idziemy do “bankozaura”. Druga próba to Santander Consumer. Oni zaczęli bardziej logicznie, czyli od pytania na co kredyt i w jakiej kwocie. Wstępne wyliczenie rat kredytu dostałem od ich konsultanta mailem jakieś 4 godziny od wyrażenia zainteresowania. Nie byłoby w tym może nawet nic dziwnego, gdyby nie fakt że ten mail został wysłany o godzinie 21:46 - trochę mi szkoda p. Krzysztofa, który musiał pracować po godzinach, ale poczułem się doceniony. Wniosek o kredyt - jedna kartka A4, wypełnienie jej przy pomocy konsultanta zajęło jakieś 15 minut. Konsultant popatrzył się na parametry kredytu i po porównaniu wartości “inwestycji”, kwoty kredytu i dochodu netto od razu zaproponował procedurę uproszczoną - sprowadza się do złożenia jednego podpisu. Decyzję kredytową miałem 3 godziny później - otrzymałem ją telefonicznie. Całość trwała niecałe 24 godziny a podejrzewam, że gdyby nie fakt, że w międzyczasie zajmowałem się również innymi rzeczami, można ten czas jeszcze skrócić. Rewelacja.

Morały z tej historii są trzy:

1. Nie wierz reklamom
2. Reklamuj tylko to, co masz w rzeczywistości a nie to jakim chciałbyś być. Bo potem będziesz wyprzedzany przez dinozaury z własnej reklamy. I ktoś to jeszcze na blogu opisze ;-)
   
3. Głębsza refleksja: podczas seminarium SPMP, o którym pisałem wcześniej, panowała zgoda, że innowacje to głównie innowacje przez “małe i”. W tym konkretnym wypadku na przykład innowacje dotyczące procesu i instrukcji obsługi wniosków kredytowych. To, że Santander wykazał się innowacyjnością (czy też w zasadzie zdrowym podejściem) oznacza, że to on właśnie zarobił. Drugi stracił. Przez tak dziwną bzdurę jak ewidentnie błędnie skonstruowany proces obsługi wniosków kredytowych. Takie drobne, małe innowacje w procesach operacyjnych jak widać mogą stanowić o traceniu lub przyciąganiu klientów.

PMO w sposób zwinny

Rok temu opublikowałem tutaj posta na temat wprowadzania zmian w organizacjach metodami zwinnymi:
http://www.wlochowicz.com/blog/2008/05/zwinne-zarzdzanie-zmian-w-organizacji.html

Natomiast parę dni temu znalazłem na PM Hut posta na temat... wprowadzania PMO w organizacji własnie dzięki metodom agile. Cytat:

If you’re building a PMO and have a 3 year plan – drop it now! [...] As you’ve guessed by the article title I am going to suggest that we steal a technique from the software development industry. While I am not an agile expert by any means, there are some very successful practices that you can employ while building and growing your PMO.

Czyli da się. Jest to możliwe nawet do wprowadzania zmian tak rozległych jak PMO w organizacji.

Całość do przeczytania na PM Hut:
http://www.pmhut.com/the-agile-project-management-office-pmo

Narzędzia efektywnego zarządzania mniejszymi projektami

Tytuł tego postu to jednocześnie tytuł mojego wystąpienia na seminarium PMI we Wrocławiu 24 marca. Poniższą treść można traktować jako handout tej krótkiej prezentacji.

Na początek zdefiniujmy sobie co to jest ten “mniejszy projekt”. Metodą Alberta Einsteina mniejszy projekt to dla mnie projekt, dla zarządzania którym użycie MS Project jest zbyt skomplikowane / powoduje zbyt duży narzut zarządczy. W organizacjach takich jak je znam jest realizowanych wiele, bardzo wiele projektów, z których znacząca część to projekty małe. Ot choćby zmiana jednej czy drugiej procedury obsługi klienta, zorganizowanie spotkania dla klientów czy też wydanie nowej wersji katalogu firmowego. Tego typu aktywności często charakteryzują się wszystkimi cechami projektu, z tą właściwością, że ich złożoność jest o kilka rzędów wielkości mniejsza od złożoności projektu budowy nowego biurowca czy stworzenia systemu informatycznego. W związku z tym narzędzia informatyczne konstruowane z myślą o zarządzaniu projektami wielkości budowy biurowca nie mogą być wykorzystywane w sposób efektywny do tych mniejszych projektów. Głównie ze względu na swoje skomplikowanie, które powoduje, że narzut czynności zarządczych, które trzeba wykonać jest nieproporcjonalny do wielkości projektu.

Dla takich mniejszych projektów efektywne narzędzia wspierające zarządzanie nimi powinny być też mniejsze i zdecydowanie inaczej konstruowane. Na czym powinny się skupiać? Według PMI, i jest to niewątpliwie prawda, znacząca większość czasu pracy kierownika projektu jest poświęcona na komunikowanie się. W tym w szczególności na komunikowanie się z zespołem projektowym na temat poszczególnych zadań, ich statusów oraz postępu prac. W związku z tym jeżeli mówimy o efektywnym zarządzaniu projektami to podstawową funkcją, którą muszą wspierać narzędzia jest komunikacja.

Takimi właśnie narzędziami są pojawiające się ostatnimi czasy platformy internetowe oparte o technologi szumnie nazywane Web 2.0. Wiele z tych narzędzi było wręcz pisane jako nie-MS Project z nastawieniem na obsługę projektów mniejszych. Co ciekawe znacząca większość tych narzędzi kładzie nacisk właśnie na aspekty komunikacji w zespole i stara się rozwiązać ten problem poprzez udostępnienie wspólnej dla wszystkich interesariuszy platformy komunikacyjnej. Narzędzia te mają ze sobą wiele wspólnego. Do wspólnych cech zaliczyć należy przede wszystkim (oprócz dostępu przez internet z dowolnego miejsca na świecie a często także z dowolnego urządzenia mobilnego) nastawienie na maksymalne uproszczenie funkcjonalności i uczynienie doświadczenia użytkownika z pracy z narzędziem jak najbardziej pozytywnym. Poza tym, twórcy tych narzędzi garściami czerpią ze Steva Jobsa i zazwyczaj umieszczają w nich tylko i wyłącznie niezbędne funkcje, co czyni te narzędzia prostymi i efektywnymi w użyciu. Przykładowymi, choć istnieje o wiele więcej, narzędziami tego typu są BaseCamp i ActiveCollab.

Narzędzia te zbudowane są wokół koncepcji realizacji projektu poprzez osiąganie kolejnych kamieniu milowych, które to znowu są osiągane poprzez realizację zestawów zadań. Choć różni się to w szczegółach pomiędzy narzędziami to większość z nich pozwala na zdefiniowanie dla projektu dat osiągnięcia kamieni milowych. Następnie dla danych kamieni tworzy się listy zadań, przypisując odpowiedzialności do członków zespołów. Realizacja zadań jest wspomagana poprzez udostępnienie miejsca na dyskusje (coś w rodzaju forów internetowych), przechowywanie plików oraz inne dodatki zależne od konkretnego narzędzia. Śledzenie postępu przez kierownika odbywa się poprzez skondensowane dashboard’y prezentujące na jednym ekranie przeglądarki stan tego co dzieje się w projekcie. Jest to zwykle bardzo ciekawie zorganizowane, bo pokazuje stan komunikacji (co, kto, kiedy powiedział/wysłał/zaraportował) a nie jakiś wyimaginowany procentowy stan zaawansowania pracy. Takie podejście powoduje umieszczenie w jednym miejscu wszystkich informacji z realizacji projektu a także bardzo dobry pogląd na to, co się z tym projektem od strony wymiany tejże informacji dzieje.

Narzędzia te oczywiście mają także wady. Zaliczyć należy do nich głównie fakt, że czasami, zwłaszcza w sytuacjach kiedy bardzo zależy nam na czasie, mimo wszystkich uproszczeń ich użycie jest zbyt skomplikowane. Głownie dlatego, że mimo najnowszej technologii powiedzenie czegoś w bezpośredniej rozmowie jest nadal najbardziej efektywną formą komunikacji i nigdy chyba nie dorobimy się innej równie efektywnej. Drugą dużą wadą jest dla mnie to, że mimo wprowadzenia centralnego miejsca przechowywania informacji większość z tych narzędzi nie zapewnia kontroli wersji notatek, które tam się znajdują. To znaczy, że jeżeli ktoś wprowadzi jakąś informację to później można ją edytować i nie pozostawia to żadnego śladu. Takie zachowanie może wprowadzić szybko chaos komunikacyjny, zwłaszcza jeżeli osoby nie pracują w tej samej lokacji fizycznej. Kolejną wadą, czy też w tym przypadku raczej cechą, jest to że trzeba być bardzo świadomym wybierając to a nie inne narzędzie. Nie do każdego projektu one się nadają i realizacja nie każdego może być aż tak uproszczona. Ze względu na brak możliwości wymuszania sekwencji wykonywania zadań bardzo duża część projektów nie będzie mogła być efektywnie zarządzana.

Na koniec wypada tylko dodać, że jest to kolejna klasa narzędzi, którą warto znać. I używać wtedy i tylko wtedy kiedy ma to sens i jest właściwe dla danej sytuacji. Zdrowy rozsądek musi w pracy kierownika projektów odgrywać rolę pierwszoplanową.

Innowacja zarządcza

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

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

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

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

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

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

Co się działo?

Witam serdecznie po dłuższej niż zwykle przerwie. W jej czasie zdarzyły się dwa ciekawe wydarzenia. 19 marca prowadziłem dyskusje panelową nt. innowacji w ramach spotkania organizowanego przez SPMP we Wrocławiu. Natomiast 24 marca prowadziłem wykład na seminarium PMI dotyczący narzędzi internetowych wspomagających zarządzanie "mniejszymi" projektami.

Dla mnie szczególnie ciekawe było seminarium SPMP nt. innowacji i z tego miejsca jeszcze raz dziękuję p. Bogumiłowi za zaproszenie do dyskusji. Ciekawie było usłyszeć ekspertów prowadzących wykłady, jeszcze ciekawiej posłuchać dyskusji panelowej, której przebieg był zaskoczeniem dla wszystkich, łącznie z prowadzącym :-) Stało się tak głównie ze względu na bardzo aktywny udział publiczności. Najważniejsze dla mnie rzeczy, które pojawiły się w dyskusji zebrałem poniżej.

Po pierwsze, praktycznie każdy z prelegentów zauważył jedną bardzo ciekawą rzecz. Mianowicie w języku polskim traktujemy innowację jako coś, co musi być "duże". Innowacją jest na przykład wprowadzenie na rynek nowego produktu czy też opracowanie nowego materiału. W rzeczywistości natomiast tego typu innowacje stanowią zdecydowaną mniejszość. Większość stanowią innowacje "przez male i" czli drobne usprawnienia, które jednak wdrożone od pomysłu do wersji rynkowej powodują stopniowe zwiększanie się konkurencyjności konkretnych organizacji. Co więcej takie małe innowacje są dużo prostsze do przeprowadzenia, więc być może to właśnie na nich powinniśmy się skupiać zamiast na ciągłym myśleniu i planowaniu jednej, wielkiej, przełomowej innowacji, która kiedyś nadciągnie.

Po drugie po bardzo ciekawej dyskusji wśród publiczności nastąpił konsensus na temat tego, że z obserwacji wynika, że w Polsce nie ma żadnego problemu z kreatywnością i pomysłami na innowacje. Jest natomiast duzy problem dotyczący zarządzania innowacjami rozumianego jako zorganizowany sposób przekuwania pomysłu na wartość biznesową. Tutaj dużo nam brakuje i warto skupić się właśnie na tym elemencie.

Po trzecie ciekawy, aczkolwiek bardzo kontrowersyjny był wątek dotyczący edukacji i tego, czy przez przypadek sposób w jaki kształcimy dzieci i młodzież nie działa przeciw koncepcji budowania gospodarki opartej o innowacje. Czyli mówiąc wprost czy to nie jest tak, że szkoła zabija wszelką innowacyjność i kretywność "produkując" absolwentów, którzy potrafia bardzo dobrze wypełniać pewne reguły działania ale nie są zdolni do stworzenia nowych reguł. Ja mam na ten temat własne przemyślenia, ale na razie odeślę do rewelacyjnej prezentacji na TED o sugerującym tytule "Ken Robinson says schools kill creativity".

Po ostatnie, aczkolwiek najciekawsze muszę powiedzieć, że bardzo pozytywnie zaskoczył mnie przedstawiciel firmy Elektrotim (niestety nie pamiętam nazwiska). Po pierwsze zdrowym podejściem a po drugie tym, że rdzennie polska firma ma tak fajne podejście do świata. Na przykład przeprowadza projekty badawcze z uczelniami. Ale anjbardziej ujęła mnie ta inicjatywa: Elektryzująca pasja. Cytując ze strony "Chcemy inspirować do rozwoju indywidualnej kreatywności i tworzyć podstawy pracy zespołowej. Dlatego też ważnym elementem naszego programu jest konkurs ,Elektryzująca Pasja, który ma na celu wyłonić i nagrodzić prawdziwe talenty. " I faktycznie z tego co opowiadał przedstawiciel Elektrotima takie talenty się znajdują. Dziękujemy i czekamy na więcej. Może w przyszłości polska X-Prize?

O narzędziach, o których mówiłem na seminarium PMI napiszę innym razem.

P.S. A na przyszłość obiecuję, że o wspomnianych wyżej wydarzeniach będę informował PRZED ich terminem a nie PO ;-)

Organizacja a miary

Poniższy tekst po redakcji będzie stanowił wstęp do skróconej wersji książki "Finanse do góry nogami".

Jednym z często poruszanych problemów zarządzania jest tzw. zarządzanie zmianą. Ten aspekt zarządzania najczęściej poruszany jest w kontekście kłopotów, które sprawia wprowadzenie zmian w zachowaniach ludzkich. Taki pogląd opiera się na popartej doświadczeniem obserwacji, że wprowadzenie dowolnej zmiany na poziomie zarządu czy kierownictwa firmy jest bardzo proste, wymaga zwykle jednego lub dwóch spotkań i ustalenia pożądanego kierunku. Natomiast dokonanie tego samego na poziomie zachowań wszystkich pracowników organizacji niespodziewanie staje się bardzo trudne. Pracownicy „nie chcą” się zachowywać zgodnie z wprowadzonymi zasadami.

Doświadczenie wielu organizacji stanowi jednak, że wbrew pozorom pokonanie tego pozornego oporu przed zmianą jest dość proste. Prostota wynika z zauważenia, że zachowania osób będących w organizacji są sterowane poprzez miary, które organizacja stosuje. Z tego powodu nie można oczekiwać prawdziwych zmian w organizacji, jeżeli nie zmieni się systemu miar. Z drugiej zaś strony, i to jest kluczowe spostrzeżenie, jeżeli zmieni się miary to organizacja dostosuje się do nich i zmiany będą albo samoistne albo bardzo łatwe do przeprowadzenia.

Na przykładzie zmian w organizacjach dotyczących wprowadzenia nowoczesnych metod zarządzania w miejsce zastałych wyodrębniono bardzo często popełniany błąd prowadzący wprost do zniweczenia całego procesu wprowadzania zmiany. Błędem tym jest skupienie się podczas wprowadzania zmiany tylko i wyłącznie na zmianie przekonań wyższego kierownictwa oraz na wprowadzeniu konkretnych praktyk nowego sposobu zarządzania. Zwykle polega to na przekonaniu przez konsultanta zarządu do nowej koncepcji oraz sprzedaniu odpowiedniej ilości segregatorów zawierających instrukcje jak swoją pracę mają wykonywać pracownicy. To jednak jest za mało aby odnieść sukces we wprowadzaniu zmiany – głównie ze względu na pojawiający się od razu „opór przed zmianą”. Odniesienie sukcesu gwarantuje tylko wprowadzenie rozwiązania całościowego, czyli oprócz zmiany przekonań i wprowadzenia praktyk powinno zmienić się także miary obowiązujące w organizacji. Prawidłowo przeprowadzony proces zaczyna się od zmiany przekonań kierownictwa. Te przekonania powinny posłużyć do zdefiniowania systemu miar w organizacji, który pozwoli mierzyć dostosowanie się organizacji do nowego sposobu zarządzania. Miary te jednocześnie powinny być tak skonstruowane, aby wspierać stosowanie nowych praktyk. Wdrożenie zaś praktyk to ostatnie co powinno zostać zrobione w procesie wprowadzania nowych metod zarządzania.

Pominięcie środkowego elementu powyższego procesu (czyli definiowania systemu miar) powoduje, że nowe praktyki stają często w sprzeczności ze stosowanym systemem miar. Ze względu zaś na to, że każdy z nas lubi jak się go docenia i jak uzyskuje dobre wyniki to podświadomie będzie starał się tak działać, aby wyniki w nadal stosowanym systemie pomiarowym były dobre. To zaś powoduje, że nie ma wsparcia dla nowych praktyk i są one bardzo szybko zastępowane starymi nawykami. Tymczasem zmiana stosowanych miar powoduje, że nawet jeżeli stare nawyki dalej pozostają, to nie są one wspierane przez system. Często wystarczy sama zmiana sposobu pomiaru, aby całkowicie zmienić zachowania w organizacji. Etap dystrybuowania segregatorów z nowymi instrukcjami można wtedy pominąć.

Rachunkowość przerobowa stanowi obecnie najprostszy i najskuteczniejszy system miar wspierający zmiany systemów zarządzania w organizacjach. Doświadczenia praktyków wskazują, że najbardziej pozytywną zmianą dla organizacji jest wprowadzenie nowego wskaźnika produktywności dla firmy, wyrażonego stosunkiem T/OE (przerób/koszty operacyjne). Ta miara zastępuje tradycyjny miernik efektywności kosztowej w firmie. Wskaźnik zdefiniowany w nowy, prosty sposób jasno uzmysłowia wszystkim w organizacji, że zwiększanie kosztów operacyjnych jest dobre – o ile zwiększa to przerób w sposób jeszcze bardziej znaczący. Zastosowanie takiego miernika, podobnie jak innych mierników rachunkowości przerobowej, bardzo szybko prowadzi do nastawienia całej organizacji na realizację jej celu głównego, czyli zarabiania pieniędzy teraz i w przyszłości.

Dyspozytor vs. Delegujący

Jak wiadomo instytucję szefa wymyślono między innymi po to, aby zarządzać zestawami zadań zbyt dużymi do zrealizowania przez jedną osobę. Istnieją dwie metody w ramach których szef może podzielić się swoim zadaniem. Umownie nazwijmy to byciem dyspozytorem bądź delegującym. Dyspozytor to osoba, która przekazuje konkretną instrukcję do wykonania. Rozdziela pracę rozumianą jako zadania do wykonania. To znaczy każdy z członków zespołu otrzymuje listę rzeczy do wykonania a następnie rozliczany jest z tego czy postąpił zgodnie z przekazaną instrukcją.

Delegowanie natomiast to zupełnie inne podejście. Zamiast przekazywać zadania przekazuje się odpowiedzialność. Czyli określa się pożądany cel i jego parametry jakościowe, natomiast nie przekazuje się wprost instrukcji jakie zadania i w jakiej kolejności należy wykonać, aby określony cel uzyskać. W tym podejściu zakłada się, że sposób dojścia do celu najlepiej znany jest osobom faktycznie wykonującym daną pracę a nie menedżerom. Rolą menedżera jest przekazać odpowiedzialność, zapewnić pracownikowi środowisko, w którym może wykonywać swoją pracę bez przeszkód a następnie odebrać prace sprawdzając czy założone cele zostały osiągnięte.

W metodach zwinnych zarządzania projektami tak naprawdę możliwa jest do zastosowania tylko i wyłącznie metoda druga. Próba zastosowania metody pierwszej (dyspozytora) prowadzi bardzo szybko do powstania wąskich gardeł zarządczych na poziomie kierowników. W środowiskach agile za dużo rzeczy dzieje się zbyt szybko, aby kierownik mógł panować nad nimi na poziomie zadań do wykonania. Jeżeli chcemy aby w naszym środowisku osiągać szybko rezultaty to jedyną opcją jest przekazywanie odpowiedzialności. Fakt, menedżer traci kontrolę nad sposobem wykonywania pracy i musi swoim ludziom zaufać. Ale jednocześnie zyskuje możliwość osiągnięcia końcowego rezultatu wielokrotnie szybciej niż przy użyciu bardziej tradycyjnej metody dyspozytorskiej.

Należy tylko pamiętać, aby razem z odpowiedzialnością wydelegować uprawnienia. Najgorszą sytuacją, którą można zafundować swoim podwładnym jest dać im odpowiedzialność za coś, ale bez uprawnienia do decydowania o wszystkich zasobach i środkach potrzebnych do wykonania danej pracy. Stawiamy wówczas pracowników przed koniecznością wykonania pracy na którą nie mają wpływu. Nie mogą więc sami decydować o jej sukcesie bądź porażce. Taka sytuacja prowadzi wprost do dużej i narastającej frustracji osób zaangażowanych w projekty.

Last but not least wypadałoby jeszcze pamiętać o różnicach kulturowych. Ci z Was, którzy mieli przyjemność pracować z Hindusami dokładnie wiedzą, że zastosowanie znajduje tylko i wyłącznie jedna z opisywanych metod.

Jidoka

Czytając wspomnianą tutaj już książkę “Implementing Lean Software Development” jeden element wybitnie wrył mi się w pamięć jako zupełnie dla mnie nowy. W ramach przedstawiania produkcyjnego lean’u i jego zasad autorzy opisali coś, co nazywa się po japonsku jidoka a po angielsku autonomation. Po polsku będzie chyba autonomizacja (?? choć po przemyśleniach nie wydaje mi się). Koncepcja jest tak prosta i tak oczywista, że wręcz dziwię się, że nigdy nie słyszałem o jej zastosowaniu do rozwoju oprogramowania.

W przypadku produkcji jidoka polega na tym, że każde odchylenie od pożądanego standardu jest natychmiast wychwytywane na bardzo niskim poziomie zarządczym a następnie usuwa się, uwaga, przyczynę powstania problemu a dopiero później powraca się do pracy. W praktyce oznacza to, że każdy z robotników pracujących przy taśmie jeżeli zauważy jakiekolwiek odchylenie od pożądanego stanu ma prawo i obowiązek natychmiast zatrzymać całą linię produkcyjną. Następnie znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem następuje ponowny rozruch linii. Ciekawe jest to, że te działania są podejmowane przez pracowników liniowych, bądź ich bezpośrednich przełożonych bez zwracania się o radę i decyzję do wyższego kierownictwa. Stąd termin autonomizacja - elementy organizacji uzyskują autonomię pozwalającą im podejmować działania podwyższające jakość bez konieczności czekania na decyzję wyższego kierownictwa.

Genialne. Głównie dlatego, że w ten sposób unika się powstawania wąskich gardeł decyzyjnych wyżej w strukturze firmy. Managerowie nie są zasypywani dużą ilością błahych i oczywistych spraw do rozwiązania, tylko mają czas myśleć nad rzeczami strategicznymi. A o jakość dbają ci, którzy są najbliżej czyli pracownicy.

Jak to się ma do rozwoju oprogramowania? Ano tak, że zgodnie z tą koncepcją każdy członek zespołu pracującego nad nowym oprogramowaniem miałby możliwość zatrzymania produkcji jeżeli tylko zobaczyłby, że nie spełnia ona jakościowych wymagań. Następnie miałby obowiązek znaleźć przyczynę wystąpienia tego odstępstwa oraz ją usunąć. Czyli na przykład jeżeli kodując funkcjonalność X przykładowy programista zorientuje się, że funkcjonalność Y nie działa zgodnie ze specyfikacją to ma obowiązek zatrzymać prace i zbadać dlaczego tak się stało. Może brakuje jakiegoś unit testu? To trzeba go dopisać, poprawić funkcjonalność Y i dopiero potem wrócić do pracy nad X. Oprócz unikania wąskich gardeł decyzyjnych ma to też taką oczywistą zaletę, że nie pozwala na zaniedbanie starszego kodu. Ma też tą wadę, że zakłada iż wymagania jakościowe są na tyle dobrze zdefiniowane, że każdy będzie w stanie wychwycić odchyłkę od normy. A to niestety często nie jest prawda. Niestety. Podkreślić tu bowiem należy, że niezależnie od przyjętej metody zarządzania projektem informatycznym te wymagania, które już weszły do produkcji muszą być na tyle dobrze zdefiniowane aby można było sprawdzić ich jakość. No ale to już temat na osobny post, który zresztą już chyba kiedyś się tutaj pojawił.

A jidoke zastosuję przy najbliższej nadarzającej się okazji :-)

Dług technologiczny

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

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

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

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.

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

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.