poniedziałek, 12 listopada 2012

Efekt Guru


Efekt Guru

Nie pamiętam kto mi o tym powiedział i skąd pochodzi poniższa definicja, ale na początek chciałbym temu zapomnianemu przyjacielowi serdecznie podziękować za wprowadzenie do słownika nowego pojęcia. Czy jest Efekt Guru? Jest to sytuacja w organizacji, w której ludzie zamiast samemu pracować nad rozwiązaniem problemu wolą spytać się tego, kto wie (Guru). W praktyce polega to na tym, że ludzie w organizacji pracują normalnie do czasu napotkania problemu. Jak tylko taki się pojawi przerywają prace i kontaktują się z Guru w celu znalezienia rozwiązania tego problemu. Po kontakcie czekają na reakcję Guru i gotowe rozwiązanie, zwykle nie podejmując żadnych działań, bo przecież problem już jest rozwiązywany.

To jest bardzo niebezpieczny efekt i powinno się mu aktywnie przeciwdziałać.

Zacznijmy od oczywistości, czyli dlaczego taki efekt jest niebezpieczny. Z punktu widzenia kierownika projektu pierwszym i jednym z najważniejszych negatywnych efektów jest to, że prace dramatycznie się opóźniają. Wynika to z tego, że napotkane problemy rozwiązywane są tylko przez jednego człowieka. Spływają do niego wszystkie, co sprawia że często Guru ma tych problemów na głowie kilka albo kilkanaście. Oczywiście nie może się nimi wszystkimi jednocześnie zająć, więc tworzy się kolejka zadań do rozwiązania. Mówiąc językiem Teorii Ograniczeń pojawia się w systemie wąskie gardło i to co najgorsze w miejscu, którego nie widać na żadnym schemacie organizacyjnym. Głównie dlatego, że Efekt Guru jest elementem kultury pracy a nie systemu zarządzania. Zarządzanie takim "niewidocznym" ograniczeniem jest bardzo trudne/niemożliwe. Natomiast cały ten problem zarządczy wcale nie jest najgorszym skutkiem Efektu Guru. Dużo gorszy jest brak rozwoju w zespole. Jeżeli kultura pracy jest taka, że członkowie zespołu zamiast myśleć pytają i czekają na odpowiedź, to niestety ale zespół zaczyna rozwijać się bardzo nierównomiernie. Podczas gdy większość zespołu się nie rozwija (tylko czeka na rozwiązanie ich problemów) jedna osoba rozwija się niewspółmiernie szybko - właśnie dlatego, że rozwiązuje coraz więcej różnego typu problemów. Oczywiście można teraz by długo pisać na temat tego jaki zły wpływ to ma na zespół i organizację, ale pozwólcie, że cay ten wywód ograniczę do idealnie go obrazującego sparafrazowania pytania mojego kolegi: "A co się stanie z organizacją, jeżeli Guru jutro wpadnie pod tramwaj?". Czego oczywiście nikomu nie życzę.

Skąd się bierze Efekt Guru? Wbrew pozorom wcale nie z lenistwa ludzi. Wręcz przeciwnie :) W życiu dwa razy miałem okazję obserwować tworzenie się kultury Guru w zespole. W obu przypadkach wynikało to z bardzo dobrych chęci zaangażowanych osób. Zaczyna się od tego, że chcemy projekt zrobić szybko i "nie mamy czasu". Wówczas kiedy pojawią się problemy to zaczynamy szukać najszybszego sposobu rozwiązania tych problemów. Jaki jest najszybszy sposób? Dać je do rozwiązania najlepszemu człowiekowi z zespołu. No to je dajemy, a reszta w tym czasie robi te rzeczy, z którymi problemów nie ma. Efekt jest taki, że ta jedna osoba staje się coraz lepsza i ma coraz większe doświadczenie. Jeżeli pojawią się kolejne problemy i dalej mamy tą samą presję czasową to co zrobimy? Czy znów damy te problemy do rozwiązania najlepszemu z zespołu? Jeżeli tak, to jesteśmy na najlepszej drodze do stworzenia Efektu Guru. Tu by się musiał wypowiedzieć ktoś znający dogłębnie psychologię zespołu jak to dokładnie się rozwija, ale z doświadczenia po kilku lub kilkunastu tygodniach tego typu akcji zespół przechodzi automatycznie w tryb "problemy dajemy do Guru". I efekt mamy gotowy.

Jak przeciwdziałać Efektowi Guru? Metodyki agile mają kilka ciekawych propozycji, choć i tak wszystko koniec końców sprowadza się do zasad i kultury pracy danego zespołu. Dwa elementy, które osobiście widziałem w akcji, sprawdzały się dla konkretnych projektów w których pracowałem. Oczywiście wcale nie oznacza to, że będą sprawdzały się w każdej sytuacji. Pierwszym elementem utrudniającym powstawanie Efektu Guru jest nie-przydzielanie zadań do poszczególnych osób podczas planowania. Czyli postępowanie ściśle z wymaganiami metody agile. Warto natomiast dołożyć do tego aktywne sprawdzanie przez zespół i kierowników, czy ludzie nie mają tendencji do brania zadań tylko tych, które wydają się dla nich proste, czyli takich na których się znają. Ten sposób jest skuteczny, natomiast widziałem już wiele sytuacji, w których nie dało się go w prosty sposób wdrożyć. Drugi sposób, to oddziaływanie na kulturę pracy poprzez ustalenie konkretnych zasad. Kiedyś pracowałem w zespole, w którym ustaliliśmy standardowy sposób postępowania w momencie, kiedy ktoś napotykał na problem. Polegało to na tym, że jeżeli ktoś napotkał na problem to najpierw miał spróbować rozwiązać go samemu. Jeżeli po 15 minutach pracowania nad problemem pozostawał on nierozwiązany, osoba na głos mówiła wszystkim w zespole, że napotkała problem i jakiego on jest rodzaju (siedzieliśmy całym zespołem w jednym pokoju). Potem następowała wymiana zdań, której celem było ustalenie kto będzie najbardziej pomocny w rozwiązaniu tego konkretnego problemu. Ta osoba siadała ze zgłaszającym problem i we dwójkę (ale tylko we dwójkę) siedzieli nad problemem dopóki go nie rozwiązali. Dział ten sposób bardzo dobrze, bo z jednej strony zmuszał do własnego wysiłku (te 15 minut), z drugiej strony powodował uczenie się (przez tą drugą osobę), z trzeciej nie powodował zbyt dużego rozwalenia prac w zespole (tylko dwie osoby zaangażowane).

Na koniec zachęcam do przyjrzenia się samemu sobie i dokonania analizy, czy przez przypadek nie generujemy Efektu Guru w swoim zespole. Zupełnie nieświadomie oczywiście. A może to Ty sam jesteś Guru?

niedziela, 2 września 2012

O tym co robić, kiedy nie ma nic do roboty

Załóżmy, że jesteś Product Ownerem. Twój zespół realizuje projekt, który jeszcze chwilę mu zajmie. Oczywiście cały czas na bieżąco wspierasz zespół i przyglądasz się pracy, ale osiągnęliście już takie zrozumienie, że zajmuje Ci to nie więcej niż 30% Twojego czasu. Co robić z resztą?

Odpowiedź jest w zasadzie prosta: przygotowywać się do następnego projektu. Przecież on nadejdzie. I to zwykle szybciej niż się wszyscy spodziewają. To jest oczywiste i większość product ownerów to robi. Co jednak, jeżeli jest już stworzona lista historii użytkownika? Czy można sobie odpuścić? Moim zdaniem nie. Co więc robić? Na początek dwie odpowiedzi ogólne.

Pierwszym obszarem, którym powinien zająć się product owner jest odpowiednie zarządzenie ryzykiem projektu. Jeżeli projektu jeszcze nie ma a wiadomo już o czym będzie to warto zrobić sobie porządną analizę ryzyka, zdecydować jakie będzie podejście w ramach projektu do poszczególnych ryzyk i zacząć wprowadzać w życie elementy strategii zarządzania poszczególnymi ryzykami. Może się okazać, że do projektu dojdzie cała masa zadań, które trzeba zrobić nie dlatego, że stanowią jego zasadniczą treść, ale dlatego że będą efektem przyjętej strategii zarządzania ryzykiem. Aha, oczywiście ponieważ rozmawiamy tu o product ownerze, to ryzyka te będą ryzykami biznesowymi i takie też będą działania na nie odpowiadające. Przykład? Może w ramach projektu trzeba bardzo wcześnie zrobić release do klienta? Może trzeba zrobić MVP? Może trzeba zarządzić kwestią wydajności rozwiązania? Itp.

Drugą odpowiedzią ogólną jest pojęcie wzięte z teorii ograniczeń i nazywające się "full kitting". Na polskie nie mam pojęcia jak się tłumaczy. Generalnie koncepcja polega na tym, aby zapewnić osobom zajmującym się daną czynnością absolutnie wszystkiego, co jest im potrzebne do wykonania tej czynności zanim zaczną się prace. Chodzi o to, aby sama czynność została wykonana bez przestojów spowodowanych brakami. Czyli czas pracy był maksymalnie efektywnie wykorzystany. W teorii ograniczeń o full kittingu mówi się zwykle w kontekście zadania w projekcie, jednak samą koncepcję można przenieść o jeden logiczny poziom wyżej i przyłożyć do całego projektu. Chodzi o to, aby zespół mógł od pierwszego dnia spędzać czas w projekcie w pełni efektywnie. Przykłady? Czy w ramach projektu będzie potrzeby dostęp do jakichś systemów? Czy są jakieś dane biznesowe/marketingowe/operacyjne, które dane zespołowi spowodowałyby szybsze i sprawniejsze prace?

Jeżeli zaś chodzi o szczegóły to poniżej kilka czynności, które mi szczególnie utkwiły w pamięci, a które wykonywałem w "czasie wolnym" kiedy aktualny projekt nabrał już rozpędu a do następnego było całkiem dużo czasu:

  • rozmowy z architekatmi - generalnie jeżeli pisałem user stories zawsze starałem się pokazać je architektom zanim zobaczył ją zespół. Dlaczego? Żeby się upewnić o ich technicznej wykonalności. Architekci też, to zwykle bardzo inteligentni ludzie z zupełnie inną perspektywą spojrzenia na projekt i produkt. Warto ich posłuchać. Jak nie ma architektów to zawsze warto się zwrócić do senior programistów czy kogokolwiek technicznego, kto rozumie stronę biznesową.
  • doszczegóławianie user stories - tak, to nie zawsze jest zgodnie z duchem metod agile, ale z praktyki wynika, że doszczegóławianie user stories często pomaga. Jeżeli na etapie przed projektem wyjdzie, ze user stories są niejasne albo zbyt ogólne, to nie ma co się łudzić - jak projekt ruszy i tak trzeba będzie to doszczegółowić. Po co czekać? Jeżeli jest czas można to zrobić wcześniej.
  • projekty graficzne - doświadczenie wskazuje, że jeden obraz jest wart więcej niż tysiąc słów. Generalnie pokazanie rozwiązania na projekcie graficznym (albo nawet na wystarczająco szczegółowej makiecie) powoduje, że product owner musi sobie przemyśleć dużo więcej rzeczy niż jak tylko stosuje opis słowny. Po drugie natomiast wprowadzenie dodatkowego projektu powoduje, że osoby, które będą wykonywały projekt mogą zobaczyć wizję w postaci obrazka. I bardzo często zgłosić trafne uwagi na temat wykonalności tej wizji.
  • zapewnienie dostępów - tzw. krótka piłka: jeżeli potrzebny jest do czegoś dostęp, to trzeba go załatwić i tyle. Im większa organizacja tym trwa to dłużej. Choć są wyjątki potwierdzające tę regułę. Wyjątki w obie strony.
  • zapewnienie zasobów współdzielonych - jeżeli będą potrzebne jakieś zasoby, czy to ludzie czy sprzęt, które nie są normalnie "na stanie" zespołu to trzeba się odpowiednio wcześniej zatroszczyć, aby były dostępne. I potem odpowiednio często się dopytywać i potwierdzać, czy to aby na pewno jest zagwarantowane. To typowa część "full kittingu" przedprojektowego...

Na koniec jeszcze jedna sprawa. Jeżeli zespół pracuje teraz nad projektem n, to szczegółowe przygotowania warto prowadzić tylko dla projektu n+1. Projekty n+2, n+3 i kolejne, mogą być opisane i przygotowane na dużym stopniu ogólności. Nie ma sensu zajmować się nimi w szczegółach. Dlaczego? Ano dlatego, że do ich rozpoczęcia jest jeszcze dużo czasu. I w tym czasie mogą pojawić się zmiany, które wymuszą kolejne, dokładne planowanie. Tak więc szczegółowe przygotowania dzisiaj mogłyby się obrócić w czysty przypadek waste, czyli straty. Czerpiąc znów z teorii ograniczeń można powiedzieć, że do projektów powinno się szczegółowo przygotowywać tak późno jak to jest możliwe, ale nigdy nie później.

niedziela, 22 lipca 2012

Agile w produkcji iPhone'a(?)

Z obserwacji wynika, że mało osób wie o tym, że ruch agile zaczął się w... środowisku produkcyjnym. Pierwszym artykułem opisującym jak "agilowo" zarządzać projektami jest artykuł opublikowany w styczniu 1986 roku w Harvard Business Review. Autorami są Hirotaka Takeuchi i Ikujiro Nonaka a artykuł jest zatytułowany "The New New Product Development Game" (nie podaję linku, bo mam wątpliwości co do legalności jego przedruków - zainteresowanym polecam samodzielne wyszukanie).

W tym artykule - przypominam z roku 1986 - autorzy opisują nowe procesy zarządzania projektami rozwoju produktów. Generalna idea jest taka, aby odejść od wcześniej stosowanego modelu liniowego. Model liniowy ten zakładał, że nad produktem pracują sekwencyjnie działy marketingowy, projektowy, produkcja i serwis. Tymczasem autorzy opisują bardziej "holistyczne" podejście do tematu, które zakłada że nad produktem pracują przedstawiciele wszystkich specjalności jednocześnie, poszczególne fazy się nakładają a członkowie zespołu "niczym zespół rugby podają piłkę między sobą jednocześnie jako zespół przesuwając się ku końcu boiska". W tym właśnie artykule jako opis tego procesu po raz pierwszy pojawia się określenie SCRUM.

Czemu o tym piszę? Otóż 26 lat później, wczoraj, udało mi się trafić na notkę How Apple Creates Such Great Products w Business Insider, w której czytamy (w wolnym tłumaczeniu):
Apple nazywa to równoległą produkcją. Wszystkie grupy - projektanci, produkcja, inżynierowie, sprzedaż - spotykają się nieustannie przez cały cykl rozwoju produktu, wspólnie rozmyślając, wymieniając się pomysłami i rozwiązaniami, ustalając strategie dotyczące kluczowych zagadnień i ogólnie utrzymując otwartą komunikację ze wszystkimi zainteresowanymi grupami - pozwala to uniknąć typowego problemu pomijania spłycania dobrych pomysłów, w miarę jak przechodzą one przez proces rozwoju produktu.
Czyli dalej działa :) Apple stosuje procesy agilowe opisane ponad 20 lat temu. Co tylko oznacza, że tam gdzie mamy do czynienia z innowacyjnym produktem agile może być stosowany - nawet jeżeli produkt to nie jest sam software. Oczywiście techniki i narzędzia są zapewne inne, ale zasady pozostają te same niezależnie czy mówimy o rozwoju hardware, software czy biznesu.

poniedziałek, 9 lipca 2012

Dopasowanie organizacyjne

W poprzednim wpisie wypisałem 6 mitów według artykułu z Harvard Business Review. Jednym z tych mitów było "Im więcej funkcjonalności będziemy mieli w produkcie, tym więcej klientów będzie go chciało". Oczywiście w sposób kluczowy odnosi się to do starej prawdy o tym, że w innowacjach nie chodzi o to, aby dodawać jak najwięcej funkcjonlaności tylko aby wyrzucić wszystko, oprócz rzeczy absolutnie niezbędnych ((C) Steve Jobs). Omawiając to zjawisko można dużo pisać o podejściach, teoriach, Lean Startup, MVP, itp. Ja natomiast chciałbym się odnieść do realiów życia i przypadku kiedy mit powyższy był podtrzymywany głównie dzięki... strukturze organizacyjnej firmy.


Wyobraźmy sobie firmę, która jest idealnym kandydatem do wprowadzenia metod opartych o Lean czy też Agile. Firma produkuje głównie produkt wirtualny, na rynku liczy się najbardziej time-to-market. Produktem w firmie zarządzają kierownicy produktu - osoby odpowiedzialne za wymyślenie i wprowadzenie do oferty nowego produktu bądź też zmianę istniejącego. Produkt jest mierzony dzięki zestawowi obiektywnych wskaźników. Ze względu na bardzo dużą bazę użytkowników/klientów firma teoretycznie może dowolnie prowadzić eksperymenty produktowe na wybranych grupach. W takim przypadku najsensowniejsze z punktu widzenia zarządzania produktem byłoby oprzeć się o jakieś połączenie iteracyjnego procesu z testami i strategicznym zarządzaniem produktem (właśnie proces Lean Startup, MVP, wsparte przy wytwórstwie metodykami agile). 


Niestety jest jedno "ale". Firma, chcąc oczywiście być bardzo nowoczesną, działa w całości w strukturze projektowej. Czyli zespoły są powoływane do zrealizowania konkretnego projektu, natomiast po projekcie są rozwiązywane. W praktyce wygląda to tak, że kierownicy produktu za każdym razem, kiedy mają pomysł na zmianę produktu lub wprowadzenie nowego zanim jeszcze zaczną implementację, muszą zrobić dwie rzeczy. Najpierw przekonać "komitet produktowy" do danego pomysłu i dostać zielone światło. Jak już ten krok zostanie wykonany, muszą (posługując się mandatem danym przez komitet produktowy) poczekać na "uwolnienie zasobów" i sformowanie grupy projektowej posiadającej umiejętności pozwalające na przeprowadzenie projektu. To oczywiście trwa, bo zwykle wszyscy specjaliści są zaangażowani w jakieś projekty i na własną kolejkę trzeba czekać. Projekty są wpuszczane do realizacji biorąc pod uwagę ich "ważność". Grupa jak już wspomniałem powoływana jest tylko do realizacji danego projektu i zaraz potem jest rozwiązywana.


Jakie to ma konsekwencje dla działania kierowników produktu? Na logikę powinni oni tworzyć małe, inkrementacyjne zmiany produktowe, testować je na małej ilości klientów i dopiero po uzyskaniu odpowiednich rezultatów wdrażać je wszystkim. Co zaś się dzieje? Ponieważ grupa projektowa jest powoływana tylko na czas danego projektu i zaraz potem rozwiązywana, naturalną tendencją kierownika projektu jest stworzenie zakresu... jak największego. Dlaczego? Ano dlatego, że dany kierownik projektu nie ma pewności kiedy będzie miał kolejną szansę rozwinąć dany projekt. Więc w naturalny sposób dąży do  tego, żeby jak już dostanie możliwość realizacji zrealizować możliwie jak najwięcej. Po drugie na logikę powinno się nowe produkty uruchamiać na małej próbce klientów i testować. W tym konkretnym przypadku co by się stało, jeżeli którykolwiek z kierowników produktu przyznałby się do tego, że będzie uruchamiał produkt tylko dla 5% wszystkich klientów (a dla reszty tylko jeżeli wyniki będą zadowalające)? Otóż taki projekt zostały potraktowany jako mało "ważny" - na pewno ważniejsze wydają się te, które są tworzone od razu dla wszystkich klientów. Jak się można domyśleć projekt jest też tym ważniejszy im jest większy. Opis konsekwencji takiego działania pominę - każdy niech sobie wyobrazi a potem przyjmie do wiadomości, że w firmie mogło być jeszcze gorzej.


Morał z tej historii jest taki, że nie wystarczy znać teorii i wdrażać jednego procesu. Czasami takie rzeczy jak kultura czy w tym wypadku organizacja firmy mogą działać przeciw zdrowym praktykom. Ludzie dość szybko przystosowują się do dziwnych systemów i działają w nich nawet jeżeli nie ma to sensu. Dlatego też jeżeli chcesz zaimplementować nawet najlepszą i najbardziej oczywistą zmianę działania, najpierw sprawdź czy system, w którym ta zmiana ma być wprowadzona, jest gotowy na nią i wspiera ludzi w implementacji tejże zmiany.

czwartek, 28 czerwca 2012

Bo nie jednej inicjatywie na imię Projekt...

Witam po przerwie. Na początek rzecz o projektach jako takich. W maju amerykański Harvard Business Review (HBR) opublikował rewelacyjny artykuł pt. "Six Myths of Product Development". Można go sobie przeczytać w całości tutaj (po darmowej rejestracji). Bardzo zachęcam.

Co w tym artykule jest takiego rewelacyjnego? Otóż autorzy zauważyli prawdę oczywistą, ale dość często pomijaną w dyskusjach o zarządzaniu projektami. Otóż "projekt" w dzisiejszej rzeczywistości może oznaczać inicjatywy skrajnie różne. Od wybudowania 1423. domku w stylu kanadyjskim do wymyślenia i wprowadzenia na rynek Google Glass. W związku z tym metody zarządzania tymi inicjatywami powinny różnić się od siebie! Na dzień dzisiejszy nie istnieje jedna, uniwersalna nauka o Zarządzaniu Projektami, bo Projekty nie są ani jedne ani uniwersalne. We wspomnianym artykule w HBR autorzy zastanawiają się akurat nad projektami rozwoju nowych produktów, które ze względu na zainteresowania zawodowe są mi szczególnie bliskie. I pokazują, które z "mitów" dotyczących zarządzania projektami w rzeczywistości są przeciwskuteczne w tym konkretnym środowisku. Warto podkreślić właśnie sprawę środowiska, bo te same "mity" (zasady, przekonania) w zupełnie innym środowisku dają dobre rezultaty.

Te sześć przeciwskutecznych mitów/zasad/przekonań, o których piszą autorzy to:

  1. Wysokie wykorzystanie zasobów polepsza efektywność
  2. Pracowanie na dużych kawałkach "wsadu" (batches) poprawia efektywność procesu
  3. Nasz plan jest wspaniały, musimy się tylko niego trzymać
  4. Im szybciej rozpoczniemy projekt, tym szybciej go skończymy
  5. Im więcej funkcjonalności będziemy mieli w produkcie, tym więcej klientów będzie go chciało
  6. Odniesiemy większy sukces, jeżeli uda się nam za pierwszym razem
Po szczegóły odsyłam do wspomnianego artykułu. Już po samych tytułach widać, że autorzy czerpali garściami z TOC, Lean i Agile. Natomiast najwięcej czerpali z własnego doświadczenia - ponad 50 lat doradzania firmom rozwijającym produkty. Na bazie tych doświadczeń okazuje się, że powyższe mity są szczególnie szkodliwe właśnie dla rozwoju nowych produktów.

Jednocześnie jeszcze raz warto podkreślić, że w środowiskach innych niż rozwój produktu, te mity/zasady mogą być prawdziwe. Dla przykładu jeżeli budujemy most to wolałbym, żeby nikt nie kwestionował mitu/zasady nr 6. Most musi działać poprawnie za pierwszym razem i odniesiony sukces musi być niekwestionowalny. 

To wszystko oznacza tylko, że dzisiejszy Kierownik Projektów musi orientować się nie tylko w konkretnym narzędziu, ale także w tym do czego dane narzędzie należy zastosować. A także powinien znać kilka innych narzędzi razem z ich potencjalnymi zastosowaniami. Przywołując mój ulubiony przykład. Jeżeli macie problem z samochodem i pojechalibyście do mechanika, który w swojej szafce z narzędziami ma tylko młotek, i twierdzi, że ten młotek naprawi każdą usterkę w Waszym samochodzie, to co pomyślelibyście o takim mechaniku? Dokładnie to samo powinni pomyśleć menedżerowie, do których zgłaszają się kierownicy projektów, znający jedną metodę/sposób zarządzania i twierdzący, że rozwiąże on wszystkie problemy. Tak się stało, że problem zarządzania projektem w obecnym świecie wyszedł ze stadium bryczki i coraz częściej przypomina napakowany elektroniką samochód. I dlatego do jego obsługi nie wystarczy jedno tylko narzędzie, niezależnie od tego jak dobre/skuteczne byłoby.

wtorek, 24 kwietnia 2012

Lean Startup warsztaty i przerwa

Z cyklu ogłoszenia: przez kilka tygodni na blogu będzie działo się raczej nic. Spowodowane jest to urlopem okołodługoweekendowym ale także faktem, że jestem w trakcie przygotowywania warsztatu z szeroko pojętej tematyki Lean Startup. Przygotowania te pochłaniają mi m.in. ten czas, który poświęcałem na pisanie postów. Tak więc nowe teksty po przygotowaniu warsztatów czyli zapewne w czerwcu. Odpowiadając na ewentualne pytania: pierwszy warsztat będzie dla studentów WSB we Wrocławiu, później zobaczymy. Postaram się w miarę spływania informacji przekazywać je też na tym blogu.

niedziela, 15 kwietnia 2012

O sensie

Wiele mówi się w metodykach agile o komunikacji. Jedną z zasad jest przecież:
"Inividuals and interactions over processes and tools"
Czyli trochę upraszczając jest to wprost zachęta do wyjścia do ludzi, rozmawiania i komynikowania się z nimi zamiast polegania na bardziej odhumanizowanych metodach zarządzania. Jak to w praktyce zrealizować będąc kierownikiem projektu albo szefem zespołów pracujących metodykami agile?

Można na ten temat napisać wiele zdań. Komunikacja jest tematem szerokim i dotyka praktycznie każdej znanej dzisiaj odnogi nauki o zarządzaniu. Patrząc się jednak na moje doświadczenie jest jedna rzecz, która komunikowana zapewni dużą motywację zespołu i w dłuższej perspektywie jest według mnie najważniejszą rzeczą, którą komunikować powinni wszyscy szefowie.

Co to jest? Sens (rozumiany jako cel, powód, znaczenie, istota). Zadaniem szefów jest w sposób zrozumiały zakomunikować pracownikom 1) sens istnienia organizacji, w której pracują; 2) sens realizacji projektu, w którym uczestniczą 3) sens codziennych zadań.

Jeżeli chodzi o sens istnienia organizacji, to wszystkich, którzy tego jeszcze nie zrobili zapraszam do obejrzenia prezentacji Simona Sinka How Great Leaders Inspire Action. Dokładnie wytłumaczone co to jest i dlaczego warto mówić o sensie istnienia organizacji. Natomiast z doświadczenia wynika, że mówienie tylko o sensie istnienia organizacji nie jest wystarczające w komunikacji do pracowników. Pracownicy muszą też widzieć sens na "niższych" niż organizacja poziomach. Inaczej powstanie wrażenie, że choć organizacja jest powołana do osiągania wyższych celów to codzienne działania nie mają sensu. Kto będzie winny takiej sytuacji? Menedżerowie. A to dobrze nie wróży ani motywacji ani autorytetowi menedżera. Tak więc sens powinien być komunikowane także w odniesieniu do projektów i codziennych działań.

Jeżeli mowa o sensie realizacji projektów, to może pomóc opisywane ostatnio drzewo celów. Dzięki temu narzędziu można łatwo wyjaśnić do czego przydatne są właśnie realizowane projekty i jak wpisują się w całościowe plany organizacji. Wystarczy w zrozumiały sposób wytłumaczyć który spośród celów z drzewa jest realizowany przez aktualny projekt i już mamy ładnie wytłumaczony sens realizacji tegoż projektu.

Najczęściej zapominamy o nadawaniu sensu codziennym działaniom i zadaniom. Teoretycznie prosto jest w przypadku zadań będących częścią projektów - przynajmniej wiadomo po co realizujemy cały projekt. Natomiast dość często zdarza się, że mimo to w natłoku pracy ten cel jest zapominany i wpadamy w rutynę. Do obowiązków szefów powinno należeć przypominane w umiejętny sposób o tym, że codzienne działania są częścią czegoś większego. Do tego nie wolno zapominać o celebrowaniu małych sukcesów a także o przekazywaniu zespołowi wszelkich  dowodów odnoszenia sukcesów przez produkt wytworzony przez ten zespół. Dodatkowo (co jest najtrudniejsze) przy pracy nad zadaniami, które nie wynikają bezpośrednio z projektów także dobrze jest przekazać nie tylko co jest do zrobienia, ale także dlaczego trzeba to zrobić. Najskuteczniejszym sposobem jest jasne komunikowanie aspektów biznesowych zadań a nie tylko technicznych rzeczy, które są do wykonania.

Dlaczego to jest ważne? Po pierwsze sama konieczność  przekazania jaki jest sens poszczególnych działań powoduje, że nad tym sensem trzeba się zastanowić. Co znów oznacza, że być może zastanawiając się sami dojdziemy do wniosku, że pewnych rzeczy nie należy robić, bo nie są istotne z punktu widzenia firmy. Po drugie mówiąc o sensie mówimy o tym po co jest coś robione. Mówiąc zaś po co stawiamy cel, przekazujemy szerszy kontekst. W takich środowiskach jakimi są projekty IT podanie szerszego kontekstu wiele ułatwia pracownikom. Ktoś kiedyś obliczył, że programista podejmuje istotną decyzję technologiczną co 15 minut. Te decyzje będą zdecydowanie lepsze jeżeli programista będzie wiedział nie tylko co ma zrobić, ale będzie też wiedział dlaczego ma to robić. Po trzecie (i najważniejsze) pracując z inteligentnymi ludźmi uzyskamy zdecydowanie lepszą motywację, jeżeli wszyscy w zespole będą wiedzieć po co pracują, Równie ważne jest też po co istnieje organizacja i jak aktualne działania wpisują się w całość sensu istnienia organizacji.

Ten aspekt motywacji opisywał już dawno bodajże Covey, przytaczając znaną anegdotę o łupaniu kamieni. W dzisiejszych czasach nabiera on jednak jeszcze większego znaczenia, jako że coraz więcej osób (zwłaszcza w dziedzinach typu IT) może sobie pozwolić na to, że miejsce pracy wybiera nie tylko ze względu na oferowane zarobki, ale także (a może przede wszystkim) na inne, bardziej "miękkie" aspekty, wśród których poczucie sensu wykonywanej pracy jest bardzo ważne.

PS. Powyższe jest skrótem z prelekcji wygłoszonej przeze mnie w Poznaniu 13 marca.

niedziela, 18 marca 2012

Drzewo celów, czyli które projekty realizować

Dzisiaj dość długi wpis, w którym opiszę jedno z narzędzi, które można wykorzystać do rozwiązania problemów product ownerów czy też innych osób odpowiedzialnych za wybór projektów do realizacji. Zacznę jednak od disclamer'a : Fakt, że poniżej opisane narzędzie działało w określonych warunkach nie może stanowić podstawy do twierdzenia, że zadziała zawsze i wszędzie. Rolą menedżera jest stosować najlepsze narzędzia w danej, konkretnej sytuacji. Poniższe stanowi tylko jedno z wielu narzędzi, których użycie można rozważyć.

Zakładając przez chwilę, że mamy w organizacji niesamowicie sprawny mechanizm pozwalajacy realizować projekty, wcale nie oznacza to, że organizacja odniesie sukces. Aby sukces odnieść należy oprócz sprawnej realizacji, zapewnić wybranie tych projektów, które przyniosą organizacji największy potencjalny zysk w długim terminie. Innymi słowy trzeba wiedzieć jak wybrać projekty do realizacji. Oczywiście można zrobić to posługując się intuicją lub medytacją zen, ale lepiej skorzystać z bardziej namacalnych narzędzi.

Najciekawszym i jednym z najpotężniejszych narzędzi do określania, które projekty w organizacji należy przeprowadzić i w jakiej kolejności, są oparte o teorię ograniczeń Strategy & Tactic Tree (drzewa strategii i taktyki). Dla zainteresowanych jeden z najlepszych opisów na czym one polegają znajduje się tutaj - trochę zawiły, ale w sieci nie ma ogólnodostępnych opisów procesu tworzenia drzewa S&T. Niestety przy wielu zaletach drzew S&T mają one też dwie bardzo duże wady: są skomplikowane oraz porządne ich stworzenie wymaga zaangażowania wielu godzin osób dogłębnie znających biznes. Z tego powodu są mało praktyczne w codzienności szybko zmieniającego się biznesu.

Mając powyższe na uwadze można skorzystać z narzędzia podobnego do drzew S&T, prostszego, ale przynoszącego odpowiedź na pytanie jakie projekty powinniśmy realizować oraz które projektu możemy (czy też powinniśmy) odrzucić. Narzędziem tym jest tzw. drzewo celów. Ono też pochodzi z zestawu narzędzi myślowych teorii ograniczeń (jest wykorzystywane jako jeden z kroków do stworzenia drzewa stanu obecnego - CRT). Poniżej opiszę jak zmodyfikowałem tworzenie drzewa celów, tak aby przejęło ono pożądane cechy drzew S&T, zachowując jednak swoją prostotę.

Każda organizacja pracuje na jakiś cel nadrzędny. Może on być nazwany misją, może pochodzić od właścicieli, niektórzy twierdzą nawet, że dla każdej organizacji cel ten jest ten sam ("zarabiać pieniądze teraz i w przyszłości"). Załóżmy, że cel ten jest znany. To znaczy wiemy, po co istnieje organizacja, w której działamy. Znajomość celu pozwala określić czy organizacja odnosi sukces czy nie - wystarczy zmierzyć stopień realizacji celu. Realizując w takiej organizacji projekty, każdy z nich powinien działać na rzecz realizacji celu całej organizacji. Innymi słowy wybierając projekty do realizacji powinniśmy wybierać te, które przybliżają organizację do osiągnięcia jej celu. Proste? W teorii tak. W praktyce zwykle okazuje się, że zwykle cel organizacji jest tak odległy, że nie ma jasnego, bezpośredniego przełożenia realizowanego projektu na cel całej organizacji.


Co zrobić z w takiej sytuacji? Zastosować starą metodę "dziel i rządź". Czyli w tym wypadku podzielić cel organizacji na mniejsze cele. Zadać sobie pytanie "co jest potrzebne, aby osiągnąć cel nadrzędny?". Zakładając, że celem organizacji komercyjnej jest "zarabiać pieniądze teraz i w przyszłości" naturalnymi celami cząstkowymi jest posiadanie dobrego produktu/usługi oraz zdolności sprzedażowych. W niektórych biznesach jeszcze ważna jest obsługa/utrzymanie, co również może stanowić cel. Rozbicie celu głównego na mniejsze cele powinno zostać zapisane na odpowiednio dużej kartce papieru bądź na żółtych kartkach.  Po tym, jak będziemy już mieli pierwszy poziom rozbicia celu powinniśmy przeprowadzić ten sam proces i rozbić zapisane cele na jeszcze mniejsze. Co to znaczy, że mamy "sprawną sprzedaż"? Prawdopodobnie, że potrafimy dotrzeć do klienta, przedstawić mu ofertę, że mamy ceny postrzegane jako atrakcyjne i że potrafimy skutecznie przeprowadzić proces sprzedaży. Ponownie, cele te powinny zostać zapisane jako uszczegółowienie celu nadrzędnego.

 Cały proces przypomina tworzenie WBSa z jedną bardzo ważną różnicą: pracujemy cały czas na celach. Czyli pytaniem, które zadajemy nie jest "co trzeba zrobić, aby powstało", tylko "co musimy osiągnąć, aby mieć?", "jakie rezultaty są potrzebne, aby osiągnąć?", "co oznacza, że osiągnęliśmy ...?" i podobne pytania. Pracujemy cały czas na celach/korzyściach/rezultatach. Czyli mówimy np., że opakowanie powinno być atrakcyjne dla klienta a nie, że powinno być z ekologicznego papieru. Nie jest to proste ani intuicyjne przy pierwszym podejściu, ale bardzo ważne jest właśnie, aby budować drzewo CELÓW a nie rozwiązań. Rozbicie celów na mniejsze jest nam potrzebne właśnie po to, aby realizowane w organizacji działania mogły odwołać się do tych "mniejszych", bardziej przyziemnych i łatwiej adresowalnych celów. Jednocześnie ponieważ jest to drzewo to mamy pewność, że realizując którykolwiek cel będący liściem drzewa wpływamy na ogólny cel całej organizacji.

Na koniec drzewo powinno przypominać WBS, czyli coś w tym stylu:



Liczba poziomów powinna być wystarczająca dla danej organizacji. Ciężko tu mówić o jakichś standardach, bo zależy to od konkretnego przypadku, ale nigdy nie widziałem drzewa celów z więcej niż 3 poziomami. 


Na każdym elemencie drzewa warto się zastanowić nad i spisać:
  1. Cel, czyli korzyść którą chcemy osiągnąć. Bez tego drzewo nie ma sensu. Pamiętać należy tylko o tym, aby poszczególne poziomy były rozbiciem celu nadrzędnego na cele podrzędne i aby cały czas operować kategorią celu/rezultatu. Sposób osiągnięcia tego celu to jest projekt. Wymyślenie projektów nie stanowi celu tego ćwiczenia. Po skończeniu drzewa celów i głębokim zastanowieniu się zwykle okazuje się, że każdy cel można wypełnić na kilka różnych sposobów.
  2. Sposób mierzenia celu. Innymi słowy jakie czynniki powiedzą nam, że cel ten jest osiągany bądź nie. Ten element jest o tyle istotny, że będziemy potem wiedzieć co monitorować realizując projekty mające wpłynąć na ten cel. Nie zdefiniowanie celu na tym etapie wytworzy pokusę aby "naciągać" rezultaty projektów i w efekcie każdy projekt będzie pozytywnie wpływać na dowolny cel. Dlatego sposób pomiaru celu definiuje się w momencie ustalania celu a nie w momencie uruchamiania projektu mającego ten cel realizować.
  3. Założenie o konieczności. Najtrudniejszy element. Dla każdego celu powinniśmy wyjaśnić, dlaczego realizacja tego celu jest konieczna do osiągnięcia celu nadrzędnego. Oczywiście idąc od góry drzewa do samego dołu. To jest trudne, ale bez założenia o konieczności może się okazać, że nasze drzewo rozrasta się o cele, które nie mają  żadnego związku z celami nadrzędnymi, a są dodawane tylko dlatego, że "inni tak robią", "taki jest standard rynkowy", etc. Spisanie założenia o konieczności pozwala też w przyszłości przypomnieć sobie dlaczego ten cel wpisaliśmy i uchronić go od wyrzucenia "bo nie wiadomo co on tu robi".

Do czego przydaje się gotowe drzewo celów? Przynajmniej do trzech rzeczy.

 Po pierwsze tworzenie drzewa celów to znakomite ćwiczenie pozwalające odpowiedzieć sobie na pytanie co tak naprawdę chcemy osiągnąć, jaką strukturę mają nasze cele i jak będziemy je mierzyć. Sam proces zwykle pozwala poukładać sobie wiele i stworzyć spójną wizję tego po co organizacja istnieje i jakie elementy są kluczowe, aby odniosła sukces.

Po drugie drzewo celów pozwala nam świadomie wybierać projekty do realizacji. Każdy z planowanych projektów powinien być sprawdzony pod kątem tego ile i jakie cele z drzewa realizuje. Mając zdefiniowane cele na dość niskim poziomie łatwo jest dopasować je do projektów. Łatwo jest też zrobić rzecz odwrotną, czyli szukać projektów, które realizują poszczególne cele (te, które na daną chwilę są najważniejsze dla organizacji). Dodatkowo, tak jak już zostało to wspomniane, ponieważ mamy informacje o tym jak będziemy mierzyć poszczególne cele, bardzo łatwe staje się przydzielenie projektom miar sukcesów.

Najciekawsze dzieje się jednak, kiedy okazuje się, że projekt po prostu nie pasuje do żadnego celu z drzewa (pamiętajcie, że dzięki założeniom o konieczności cele są ograniczone do tych niezbędnych). Zdarza się tak wbrew pozorom dość często. Projekt wydaje się być "fajny" i ogólnie wszyscy są bardzo zmotywowani, aby go robić, ale... nie pasuje do żadnego celu. Bez drzewa dość łatwo się zdecydować na jego wprowadzenie w życie (przecież jest "fajny") natomiast weryfikacja jego sensu z drzewem często powoduje konieczność zadania ciężkich pytań. Efektem zwykle jest zaniechanie realizacji projektu albo powrót do prac nad drzewem celów. Z doświadczenia wynika, że powrót do drzewa zwykle skutkuje tym, że po chwili stwierdzamy, że dotychczasowe drzewo jednak było dobre i to jednak coś jest nie tak z projektem. Zwłaszcza, jeżeli drzewo jest przemyślane i na jego tworzenie poświęciliśmy odpowiednio dużo czasu.

Dodatkowo posiadanie spisanego drzewa celów pozwala osobom odpowiedzialnym za biznes dość świadomie decydować o strategii i punktach skupienia organizacji w danych okresach czasu. Zakładając przez moment, że jedną gałęzią drzewa jest produkt, drugą sprzedaż a trzecią obsługa/utrzymanie można np. świadomie wybrać do realizacji w pierwszym kwartale te projekty, które mają wpływ na najwięcej liści w gałęzi dotyczącej obsługi/utrzymania. Organizacja jasno będzie wiedziała co jest priorytetem a dobierając projekty zapewnimy skokowy wzrost parametrów w danym obszarze. Patrząc się natomiast na drzewo naprawdę nie jest trudno ocenić, które z projektów mają największy wpływ na dany element/gałąź. Natomiast jeżeli takich projektów nie ma zdefiniowanych na dany moment to łatwo jest poprosić zespół o zgłoszenie pomysłów na projekty, które wpłyną pozytywnie na wybrany zestaw celów.

Trzecim możliwym wykorzystaniem drzewa jest komunikacja. Zarówno z zespołem jak i innymi interesariuszami projektu. Drzewo może posłużyć do komunikacji dwóch ważnych przekazów: co robi nasza organizacja i dlaczego to robi. Innymi słowy pytani o realizowane projekty zawsze możemy pokazać nad którymi celami aktualnie pracujemy. Natomiast pokazując hierarchię celów łatwo wytłumaczymy, dlaczego realizacja właśnie tych projektów jest ważna i jak one wpływają na cel całej organizacji. Tylko uwaga: to jest broń obosieczna. Tak jak łatwo jest wytłumaczyć strukturę celów, tak samo łatwo ją zakwestionować. Dlatego warto komunikować tylko dobrze przemyślane i opracowane drzewa.

Warto też raz jeszcze wspomnieć, że największym niebezpieczeństwem stosowania metody drzewa celów jest zapisanie w drzewie nie celów a rozwiązań. W drzewie powinny znajdować się zdefiniowane cele biznesowe i operacyjne (tzn. rezultaty), które chcemy osiągnąć. Sposób osiągnięcia tych rezultatów powinien być wymyślany poza drzewem. Tylko w ten sposób narzędzie będzie na tyle elastyczne, aby faktycznie pomagać w wyborze projektów. Przekształcenie drzewa celów w hierarchię projektów w firmie spowoduje znaczące zawężenie pola manewru i przy błędnych założeniach może spowodować katastrofę.

Na koniec podkreślę, że drzewa celów widziałem w akcji kilkukrotnie. Zawsze rezultatem była większa jasność tego, jak i dlaczego działa organizacja. Za tym postępowała większa motywacja ludzi. Zawsze też proces tworzenia drzewa był trudny i długotrwały. Natomiast tak jak wspomniałem na początku, to że coś działa w jednej czy drugiej organizacji nie stanowi gwarancji, że działać będzie w każdej.

niedziela, 12 lutego 2012

Lean Startup - co to jest?

Rozmawiając ostatnio z kilkoma osobami na temat Lean Startup zaczęło mi brakować jasnej definicji czym jest  Lean Startup. Zaczynając z kimś rozmowę na ten temat dobrze jest podać jeżeli nie definicję to chociaż krótkie "zdanie w windzie", które szybko i sprawnie przekaże ideę tego czym jest Lean Startup. Na własne potrzeby stworzyłem więc taki opis, która w minimalnej liczbie słów stara się przekazać co to jest Lean Startup.
Lean Startup to zorientowana na budowanie wartości dla właścicieli, metoda iteracyjnego prowadzenia projektów rozwoju biznesu, w której miarą postępu jest dostosowywanie modelu biznesowego do realiów rynkowych.
Powyższe zdanie jest jednocześnie kwintesencją trzech najważniejszych cech metody Lean Startup. Co ciekawe cechy te są bardzo zbieżne z "tradycyjnym" agile, tylko są one dostosowane do realiów zarządzania projektami rozwoju biznesu.

Najważniejszym elementem metody Lean Startup jest budowanie wartości rozwijanego biznesu. Wszystkie metodyki agile opierają się o przepływ wartości dodanej dla użytkownika końcowego. Agile jest tak skonstruowane, aby możliwie szybko dostarczać wartość (działające funkcjonalności) i sprawdzać je w praktyce, tzn. umożliwiając użytkownikowi końcowemu skorzystanie z nich. Bardzo podobnie działa Lean Startup, tylko inaczej definiowane jest pojęcie wartości. Ponieważ jest to metoda prowadzenia projektów rozwoju biznesu a nie operacyjnych to wartość jest generowana poprzez stworzenie "lepszego biznesu". Czyli innymi słowy poprzez stworzenie biznesu, który ma większe szanse przetrwać na rynku i przynieść oczekiwane zyski dla właścicieli.

Metoda Lean Startup jest iteracyjna, co nie powinno dziwić w kontekście tego jaki sukces metody iteracyjne odniosły w tworzeniu produktów. Jedyne, co może dziwić to fakt, że tak długo trwało zanim ktoś opisał jak dokładnie przełożyć iteracyjność na projekt rozwoju biznesu. W przypadku tego typu projektów najbardziej istotną sprawą jest to, że wcześniej założenie było takie, że zanim zaczniemy tworzyć biznes powinniśmy mieć wszystkie możliwe badania rynkowe i plany modeli biznesowych. Sam projekt był tylko ich implementacją. Lean Startup natomiast postuluje, aby pierwsze badania i plany były ograniczone do absolutnego minimum (powstaje MVP - Minimum Viable Product), który natychmiast po powstaniu jest wypuszczany na rynek, gdzie próbuje się go sprzedać. Dostosowanie biznesu do oczekiwań rynku dzieje się natomiast już na bazie istniejącego MVP i realnych klientów w kolejnych iteracjach. Tak jak w agile oprogramowanie po każdej iteracji dostaje klient, aby mógł w nie poklikać.

Iteracje w metodzie Lean Startup służą do tego, aby wypracować lepszy model biznesowy. To jest chyba największa zmiana mentalna w porównaniu z agile. W agile na koniec każdej iteracji mamy namacalny (bądź klikalny) produkt. W Lean Startup mamy... lepszy model biznesowy, czyli nową zapisaną kartkę papieru. Innymi słowy: firmę lepiej dostosowaną do potrzeb rynku i mającą większe szanse na przetrwanie na rynku. Zmiany w modelu biznesowym nie muszą być wielkie, ważne aby przynosiły skutek w postaci lepszych wyników. Wyników, które rozumiane są jako lepsze wartości kluczowych wskaźników biznesu. .Te kluczowe wskaźniki to wbrew pozorom nie są pieniądze. Na wczesnym etapie rozwoju biznesu ważniejsze są np. wskaźniki dotyczące pozyskiwania nowych klientów, konwersji, etc. Ważne jest, że model biznesowy po każdej iteracji ma skuteczniej realizować te wskaźniki. To natomiast oznacza, że firma lepiej realizuje potrzeby rynku, czyli zwiększa się jej wartość (oczywiście przy założeniu, że wskaźniki są dobrze dobrane). Co znów jasno potwierdza, że metodyka nastawiona jest na szybkie i efektywne dostarczanie wartości właścicielom projektu (czyli w większości przypadków właścicielom biznesu).

Warto też podkreślić, że iteracja kończy się nie z chwila wypuszczenia nowej wersji produktu na rynek, tylko z chwila zmierzenia reakcji tego rynku i wyciągnięcia wniosku. W agile trzeba zamykać iteracje agile produkując działający produkt, potwierdzony na demie przez klienta. W Lean Startup trzeba zamykać iteracje dostarczając model biznesowy lepiej akceptowany przez rynek. Demo odbywa się tutaj w realnym świecie, na realnych klientach. Iterację zamknąć jednak trzeba, jeżeli ma z niej wyniknąć jakakolwiek nauka i lepszy model biznesowy.

Powyższe w skrócie tłumaczy czym jest Lean Startup. Definicja słownikowa to może nie jest, ale zacytowane na początku zdanie plus wyjaśnienia poniżej pomogły mi już nie raz zainteresować osoby, które wcześniej o tej koncepcji nie słyszały.

niedziela, 5 lutego 2012

Inicjowanie projektu

Według klasycznych metod zarządzania projektami, zanim zaczniemy projekt planować powinniśmy przeprowadzić fazę zwaną inicjowaniem projektu. Po szczegółowy opis co należy w tej fazie zrobić zapraszam do PMBOK'a czy innej książki. Chciałbym natomiast przypomnieć, że także w projektach wysoce innowacyjnych, realizowanych przy użyciu technik agile projekt zanim zaczniemy robić wypadałoby zainicjować. Być może, faza inicjacji jest w tych projektach jeszcze ważniejsza niż w projektach tradycyjnych, w których z założenia występuje mniej zmienności/niepewności.

Jim Highsmith w swoim klasyku nazwał pierwszą fazę projektu "Envision" czyli stwórz wizję tego, co chcesz dokonać. Cytując innego klasyka "zaczynaj z wizją końca". Im projekt bardziej innowacyjny i obarczony większą niepewnością tym tworzenie wizji tego, co ma być efektem projektu jest ważniejsze. Jeżeli tego nie zrobimy nie będziemy w stanie określić czy projekt jest prowadzony we właściwym kierunku ani czy odsniósł sukces czy nie. Po zestaw narzędzi do tworzenia wizji zapraszam do wspomnianej książki Hiugsmitha - w szczególności polecam "zdanie w windzie" oraz "pudełko produktu".

Nie zapominając o innych elementach, które powinny powstać w fazie inicjacji projektu, warto podkreślić, że wizja tego, co robimy jest elementem, który musi być znany całemu zespołowi wykonawczemu. Jest to szczególnie ważne w przypadku projektów informatycznych. Podczas realizacji takiego projektu wszyscy w niego zaangażowani wykonują de facto twórczą pracę podejmując dziesiątki decyzji dziennie. Dotyczących technologii, projektu interfejsu, projektu technicznego, wykorzystania wzorców, itp. Podejmowanie tych decyzji jest sporo łatwiejsze jeżeli wiadomo jaki ma być efekt końcowy. Efekt określony nie tylko poprzez funkcję, która jest do zrealizowania, ale także szerszą wizję tego, co chcemy osiągnąć. I po co. Jasne określenie celów, które przyświecają projektowi pomaga stworzyć efekt realizujący te cele. Jeżeli bowiem nie zostaną one zespołowi przekazane to prawdopodobieństwo ich zrealizowania jest dużo mniejsze. I właśnie z tego powodu w projektach agile przekazywana zespołowi wizja projektu powinna zawierać oprócz informacji o samym produkcie możliwie dokładne informacje o celach, które ten produkt ma realizować, klientach dla których jest przeznaczony oraz efekcie, który ma się pojawić po jego wdrożeniu. Im więcej informacji tym większe prawdopodobieństwo, że setki decyzji podejmowanych w trakcie realizacji projektu będą budowały jego sukces.

Dodatkowo pełna wizja projektu, łącznie ze spodziewanym sukcesem na każdej płaszczyźnie pomaga od strony motywacyjnej. Każdy woli pracować nad czymś ważnym i dużym zamiast nad kolejnym "ficzerem". Znowu cytując klasyka lepiej jest budować katedrę niż tłuc kamienie.

Na koniec jeszcze raz podkreślę: wizja to nie wszytko! Zachęcam do poczytania/zastanowienia się co jeszcze jest niezbędne do zrobienia na początku projektu, aby najbardziej jak to możliwe uprawdopodobnić sukces projektu.

sobota, 21 stycznia 2012

Identyfikacja ryzyk

Temat ryzyka powrócił do mnie szybciej niż się spodziewałem. W wersji teoretycznej, podczas ożywionej dyskusji w trakcie Agilopolis Community Day oraz w wersji praktycznej w projektach, nad którymi teraz pracuję. Warto więc "na gorąco" zebrać krótkie podsumowanie.

Jaki jest najważniejszy element zarządzania ryzykiem? Choć do sprawnego zarządzania projektem i ryzykami w projekcie potrzeba na pewno wielu elementów, to na bazie ostatnich doświadczeń powiem, że jeżeli ktoś ma robić jedną i tylko jedną rzecz to niech zacznie od identyfikacji ryzyk. Dlaczego? Otóż dlatego, że w przypadku projektów agile czasami pytanie o ryzyka nigdy nie pada. I stąd być może wydaje się, że ryzyko jest w tych projektach dobrze zarządzane. Po prostu nigdy nie zostało wystarczająco uwidocznione albo nazwane.

Tymczasem wystarczy trochę zastanowić się nad tym, co w projekcie może być ryzykiem i od razu inaczej spogląda się na projekt. Przykład. Ogólnie znaną zasadą jest, że w ramach release (wydania?) powinno się planować funkcjonalności, które mają dużą wartość biznesową i są obarczone dużym ryzykiem. Skąd natomiast wiadomo, co jest obarczone dużym ryzykiem? Zwykle "wychodzi to" podczas planowania (np. podczas planning pokera następują duże rozbieżności pomiędzy członkami zespołu albo trudno jest ustalić liczbę punktów). Pytanie natomiast czy ryzykowne funkcjonalności określane są na zasadzie przeczucia czy też na podstawie analizy. Wystarczy podczas planowania poświęcić chwilę nie tylko na omówienie funkcjonalności, ale także na omówienie spraw technicznych związanych z jej implementacją, włączając w to np. integracje, które będzie trzeba zrobić oraz zależności od elementów będących poza kontrolą zespołu. Zespoły wykonawcze są zwykle bardzo kreatywne w znajdowaniu rzeczy, które mogą pójść źle. Ważne jednak jest, aby w sposób świadomy przeprowadzić analizę i sprawdzić jakie i ile wydarzeń może przeszkodzić w realizacji danych funkcjonalności.  Będzie to podstawa do dalszych działań.

Co się stanie w wyniku przeprowadzenia świadomej analizy ryzyka? Przede wszystkim jeżeli będzie już wiadomo co może pójść źle, to trzeba będzie jakoś podejść do zidentyfikowanych potencjalnych problemów. Czyli de facto zastosować kolejny element zarządzania ryzykiem: planowanie odpowiedzi na ryzyka. Nawet jeżeli patrząc się na listę zespół zdecyduje, że nic z tym nie zrobi to jest to również nieświadome przyjęcie jednej ze strategii (akceptacji). Zdecydowanie bardziej prawdopodobne jest jednak, że zespół patrząc się na listę ryzyk zaproponuje działania. Pierwszym skutkiem może być w pełni świadome (a nie na podstawie przeczucia) wybranie funkcjonalności, które powinny być realizowane najpierw. Albo zespół zaproponuje przeprowadzenie iteracji zero, albo dopisanie do release planu kilku spike'ów. Podobnie Product Owner zobaczy, co może pójść źle i gdzie ewentualnie musi interweniować. W tym w szczególności "załatwić" rzeczy, które powstają poza zespołem a mogą mieć negatywny skutek dla jego wydajności/prac. Można też oczywiście spróbować podejścia formalnego, przekazać zespołowi podstawową wiedzę nt. dostępnych strategii odpowiedzi na ryzyka i ująć planowanie w bardziej uporządkowane ramy. Ale o tym innym razem. Niezależnie natomiast od podejścia po zobaczeniu listy ryzyk zespól na pewno zaproponuje co można z nimi zrobić, albo przynajmniej będzie o nich pamiętał realizując poszczególne funkcjonalności.

Identyfikację ryzyk warto robić właśnie dlatego, że sama świadomość ich istnienia powoduje zmianę podejścia do projektu i ułatwia osiągnięcie sukcesu.

Być może to, co opisane zostało powyżej jest robione przez wszystkich SCRUM Managerów i Product Ownerów na świecie (oby!). Natomiast jest to ewidentnie jeden z elementów procesu zarządzania ryzykiem. Jeżeli jest on robiony, to proszę nie mówić, że w agile nie ma zarządzania ryzykiem, bo metodyka radzi sobie z tym "sama". Nie sama, tylko dzięki takim właśnie działaniom. A jeżeli identyfikacja ryzyk z jakichś powodów nie jest robiona to warto przeprowadzić eksperyment i spróbować.

Na koniec napiszę tylko, że powyższe to tylko bardzo krótkie i skupione na jednym aspekcie podsumowanie przemyśleń po ostatnich wydarzeniach. Wszystkim polecam własne zbadanie tego tematu, najlepiej praktyczne. I stosowanie zarządzania ryzykiem we własnych projektach. Naprawdę działa.

niedziela, 8 stycznia 2012

Lean startup czyli agile business project management (?)

W Nowym Roku bardzo polecam przeczytanie jednej z najlepszych książek biznesowych wydanych w 2011, czyli Lean Startup Erica Riesa. Książka wybitna. Jej głównym atutem jest opisanie procesu zarządzania innowacją i przedsiębiorczością (rozumianą jako angielskie entrepreneurship - to coś trochę innego niż nasze tłumaczenie). Eric Ries postarał się zobrazować sposób postępowania przy tworzeniu nowego, innowacyjnego przedsięwzięcia. Z naciskiem właśnie na stronę biznesową. Co jest niezmiernie interesujące w tej książce to fakt, że opisany jest proces analizowania klientów, tworzenia wartości, modelu biznesowego i dostosowywania się do zmian. Oczywiście w ramach tego procesu należy także stworzyć sam produkt, natomiast jest to niewątpliwie tylko jeden z elementów całego procesu, którego efektem jest sprawnie działający biznes.

Metodyki agile zarządzania projektami dotychczas skupiały się głównie na projektach rozwoju produktu. Agile jest sterowane przez dostarczanie wartości dodanej dla klienta, natomiast mało kto skupiał się na zastanowieniu się jak sprawdzić komu tą wartość dostarczamy, czy co ten produkt jest faktycznie warty dla klienta i jak ewentualnie można go zmienić, aby warty był więcej. Innymi słowy to, co zrobił Eric Ries to poszerzenie procesowego punktu widzenia "tradycyjnego" agile (hmm - niedawno agile był w awangardzie, teraz staje się tradycyjne). Tak jak np. SCRUM opisuje sposób prowadzenia projektu operacyjnego (dostarczyć produkt), tak Lean Startup opisuje sposób prowadzenia projektu biznesowego (dostarczyć rezultat ekonomiczny).

Cały proces jest dość przejrzyście opisany, choć jak się można było spodziewać w książce jest więcej odpowiedzi na pytania co zrobić a dużo mniej odpowiedzi na pytania jak tego dokonać. Cały proces jest oczywiście iteracyjny, jego ogólną wizualizację można zobaczyć tutaj. W dużym skrócie każda iteracja biznesowa zaczyna się od wygenerowania pewnych pomysłów, hipotez dotyczących zachować klientów i wartości, którą chcą otrzymywać. Następnie budujemy produkt, aby potwierdzić tą hipotezę. Produkt poddawany jest ścisłym pomiarom, które dostarczają dane. Na podstawie danych weryfikujemy hipotezy, co prowadzi do wniosków, z których pojawiają się nowe pomysły. Niby nic nowego, wiele osób z pewnością zauważy wpływ agile oraz metody naukowej. Z drugiej strony nikt wcześniej takiej koncepcji nie opisał, a już na pewno nie w tak jasnej i gotowej do zastosowania formule. Z ciekawostek Ries postuluje, aby zamykać całe iteracje. To znaczy, aby do dalszego rozwoju produktu przystępować dopiero, kiedy poprzedni eksperyment został zmierzony i zostały wyciągnięte wnioski. To zupełnie inne podejście od "tradycyjnego", gdzie przyspieszając produkcję nowych funkcjonalności zwykle nie zostawiamy czasu na analizę. W tym czasie zresztą według "tradycyjnych" miar mielibyśmy niewykorzystane zasoby, więc "tracilibyśmy". Ries postuluje, że organizacji powinno zależeć na maksymalnym skracaniu i optymalizacji całego cyklu (tworzenie, mierzenie, wyciąganie wniosków) a nie tylko na optymalizacji samego cyklu wytwarzania.

Teorie Lean Startup z oczywistych względów można zastosować najszybciej i najprościej w produktach opartych o sieć WWW. Tam bowiem zmiany wprowadzane na serwerach są widoczne od razu, co więcej można przeprowadzać eksperymenty nie na całych populacjach, a jedynie na wybranych użytkownikach. Nie są to jednak jedyne zastosowania teorii Lean Startup. W samej książce podanych jest kilka przykładów spoza świata WWW. Natomiast samo podejście Lean Startup zostało użyte (łącznie z Customer Development oraz Business Model Templates) do jednego z najciekawszych eksperymentów dotyczących komercjalizacji innowacji w USA. Polecam o tym poczytać: The Innovation Corps.