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.