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.

Brak komentarzy: