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.

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.

Poprawianie sprawności operacyjnej

Dzisiaj będzie z trochę innej perspektywy niż zwykle. Wyobraźmy sobie taki przypadek:

Jest sobie firma, w której wszelkie zmiany wprowadzane są dzięki projektom. Firma  wprowadza zmiany zarówno do swojej oferty, produktu jak i działania poprzez uruchamianie i realizowanie projektów. Firma ma jednak podwójny problem. Po pierwsze same projekty na warstwie operacyjnej nie są doskonałe. Zwykle kończą się dostarczeniem zakresu w zakładanym budżecie, ale gorzej bywa z czasem a jeszcze gorzej z jakością procesową (zgodności z procedurami, wymiana informacji, raportowanie, itp.). Drugim problemem firmy jest to, że wdrażanie kolejnych projektów nie przekłada się na wskaźniki biznesowe firmy. Mimo wysiłków, inwestycji w projekty, zakańczania projektów i wprowadzania zmian wskaźniki biznesowe albo pozostają na tym samym poziomie (a przecież gospodarka się rozwija) albo wręcz spadają.

Pytanie: czy opisanej wyżej sytuacji warto pracować nad poprawą efektywności procesów zarządzania projektami?

TAK - patrząc się przez pryzmat efektywności operacyjnej. Przecież jest dużo do zrobienia, zwłaszcza na warstwie proceduralnej. To może przełożyć się na polepszenie efektywności rozumianej jako zakańczanie projektów na czas, czyli innymi słowy szybsze zakańczanie projektów. Dodatkowo poprawa jakości procesowej poprzez standaryzację zwykle dobrze wpływa na efektywność operacyjną.

NIE - patrząc się przez pryzmat teorii ograniczeń na całość organizacji to na daną chwilę efektywność organizacyjna nie jest ograniczeniem systemu. System, jakim jest ta firma, nie służy do tego, aby sprawnie realizować projekty, tylko do tego, aby sprawnie zarabiać pieniądze. Z dostępnych informacji wynika natomiast, że problemem nie jest operacyjne działanie, tylko fakt, że projekty nie przynoszą spodziewanych rezultatów biznesowych. Dlatego aby osiągnąć cel, czyli poprawić zdolność organizacji do zarabiania pieniędzy, należy zająć się stroną biznesową projektów a nie operacyjną. Zajmowanie się stroną operacyjną nie jest w tej sytuacji potrzebne, bo nie wpływa na ograniczenie. Takie podejście jednak zupełnie nie bierze pod uwagę ludzkiej strony organizacji - co zrobić jeżeli przyjdzie ktoś z super pomysłem jak usprawnić część operacyjną? Powiedzieć mu wprost: nie, nie potrzebujemy usprawnień? Jaki to ma wpływ na motywację?

TAK - warto poprawić efektywność operacyjną, bo przez to uwolnimy zasoby do prac nad ważniejszymi rzeczami. Być może jest tak, że duża część zasobów firmy jest tak pochłonięta bieżącymi ("pilnymi") sprawami i walką z teraźniejszością, że po prostu nie ma czasu zaprząc uwagi do prac strategicznych i zobaczenia szerszej perspektywy. Dopiero poprawienie sprawności operacyjnej sprawi, że znajdzie się czas na ważne rzeczy. W tym podejściu ukryte jest założenie, że te same osoby mogą rozwiązać problemy operacyjne jak i strategiczne. Jeżeli nad oboma zagadnieniami miałyby pracować inne osoby, to takie podejście nic nie da.

NIE - jeżeli niektóre z projektów przynoszą efekty odwrotne do zamierzonych (wskaźniki biznesowe spadają) to poprawiając sprawność operacyjną tylko przyspieszymy tempo tego spadania, bo szybciej będziemy wdrażać projekty, które mają negatywne skutki. Dlatego nie ma sensu zwiększać efektywności zanim nie upewnimy się, że efekty będą pozytywnie wpływały na organizację. Z drugiej strony posiadanie sprawnej organizacji operacyjnej umożliwi bardzo szybkie osiągnięcie wyników w momencie kiedy część strategiczna zostanie naprawiona.

Co więc zrobić? Prawdopodobnie ilu ekspertów, tyle możliwych odpowiedzi na zadane pytanie. Dużo zależy od kontekstu konkretnej organizacji i tego, jak szeroko się ją analizuje. Moim zdaniem w takiej sytuacji należałoby najpierw uzdrowić sytuację strategiczno/biznesową, nie hamując (ani nie wzbudzając) jednak inicjatyw poprawy operacyjnej. Dopiero po uzdrowieniu sytuacji strategicznej sprawdzić czym zająć się w drugiej kolejności. Być może będzie to zarządzanie projektami, a być może coś zupełnie innego, co okaże się dopiero po zakończeniu działań strategicznych.

Zarządzanie ryzykiem w agile/SCRUM

Większość literatury i metodyk opisujących agile pomija zupełnie temat zarządzania ryzykiem. Jednak ryzyko jest wpisane w projekty z samej ich definicji - jeżeli projekt jest przedsięwzięciem innowacyjnym, to muszą być z nim związane ryzyka. Aby uniknąć wątpliwości przyjmijmy definicję, że ryzyko to jakiekolwiek przyszłe, niepewne wydarzenie, które może mieć wpływ na zakres, czas, zasoby bądź jakość projektu.

Najprościej jest powiedzieć, że agile ma zarządzanie ryzykiem wbudowane w samą metodykę ze względu na krótkie iteracje, dostarczanie działających wersji produktu, stały kontakt z klientem oraz retrospekcje obejmujące zakres, technologię i procesy. Dokładając do tego możliwość poprawnego priorytetyzowania funkcjonalności (te z wysokim ryzykiem jako pierwsze) dostajemy system, który powinien "samodzielnie" poradzić sobie z ryzykiem. Jeżeli ryzyko się zmaterializuje to dzięki krótkiej iteracji będzie można szybko zmienić plan i dostosować zakres do nowej sytuacji. Dzięki wybraniu najbardziej ryzykownych funkcjonalności jako pierwszych będziemy mogli szybko sprawdzić wykonalność całego projektu, itd. (napiszę osobny post na temat tego jak działa to wbudowane w metodykę zarządzanie ryzykiem).

Działania w ramach metodyki agile mogą znacząco ograniczyć ryzyka związane z technologią i niepewnością dotyczącą zakresu produktu. Niestety nie są to jedyne ryzyka, które mogą pojawić się w trakcie realizacji projektu. W szczególności w większych organizacjach i projektach do tych dwóch kategorii ryzyk dochodzi wiele innych związanych np. z finansowaniem inwestycji, integracją z innymi elementami systemu, wdrożeniem systemu na środowiskach produkcyjnych, sytuacją rynkową organizacji czy nawet polityką wewnętrzną. Takimi ryzykami nie zarządzimy tylko dzięki krótkim iteracjom i skupianiu się na dostarczaniu wartości dla klienta. Tego typu ryzyka są zupełnie pomijane w większości literatury dotyczącej agile. Czas więc odkurzyć metody zarządzania ryzykiem rodem z PMI. Co tam znajdujemy?

Pominąwszy procesy związane z identyfikacją ryzyk czy ich jakościową oceną (ilościowa w moim odczuciu nie współgra z duchem projektów agile) pojawia się proces pod nazwą Planowanie Odpowiedzi na Ryzyka. Do każdego z ryzyk można zastosować cztery ogólne strategie: akceptacji (nic nie robię, jak się zdarzy to trudno), unikania (podejmuję aktywne działania, aby ryzyko się nie spełniło), minimalizacji skutków (czekam na ryzyko i mam gotowy plan jak ograniczyć jego skutki jak już zaistnieje) oraz przeniesienia/transferu (płacę komuś żeby się o to martwił - ubezpieczenia). Niezależnie od metody, którą prowadzimy projekt, w przypadku wybrania dla zarządzenia ryzykiem strategii innej niż akceptacja, należy dostosować plan projektu do wybranej strategii zarządzania ryzykiem. W przypadku agile również takie akcje należy podjąć. Jeżeli chcemy unikać jakiegoś ryzyka to działania prowadzące do tego unikania powinny zostać zapisane i przydzielone do realizacji w możliwie najbliższej iteracji. Dzięki temu ryzyko będzie miało mniejsze prawdopodobieństwo zaistnienia. Jeżeli wybieramy strategię minimalizacji skutków to założeniem tej strategii jest opracowanie planu co zrobić zanim ryzyko się zmaterializuje. W tym wypadku przełożenie tego na agile polega na posiadaniu "na boku" zestawu funkcjonalności/karteczek, które wejdą do realizacji jeżeli dane ryzyko się zmaterializuje. O tym czy dany zestaw działań minimalizujących zrealizować czy nie powinno się oczywiście decydować w ramach zwykłego planowania iteracji. Jeżeli natomiast wybieramy strategię transferu ryzyka to takie działanie również pociąga za sobą konieczność wykonania działań, zwykle jednak nie są to działania na poziomie zespołu projektowego.

Co ciekawe ze względu na specyfikę ryzyk, o których tutaj rozmawiamy (nie produkt i nie technologia) bardzo często plany dotyczące radzenia sobie z nimi będą w małym stopniu angażować zespół projektowy a dużo większym np. product ownera. Niemniej jednak takimi ryzykami też trzeba zarządzać w metodykach agile. Zarządzać to znaczy planować, przydzielać odpowiedzialności i później nadzorować ich realizację. Czasami może się to niestety sprowadzić do tego, że będziemy musieli mieć inny niż iteracyjny sposób zarządzania tymi zadaniami (z tego powodu, że zaangażowane osoby nie pracują w takim rygorze).

I tak na koniec: w metodyce PMI w obszarze dotyczącym zarządzania ryzykiem, pierwszy proces, który się pojawia to Zaplanuj Zarządzanie Ryzykiem. Co polecam zrobić dla wszystkich ryzyk, w każdym projekcie, w tym również w tych prowadzonych metodykami agile.

Kontrakty - co zrobić z fixed?

Ostatnimi czasu pokazało się kilka dość ciekawych postów na temat kontraktów agile, na przykład tutaj. Ja sam też kiedyś ten temat poruszałem tutaj. Od tego czasu wiele się jednak zmieniło, warto więc dołożyć trochę uwag wzbogaconych doświadczeniem.

Oczywiście idealną sytuacją jest kiedy możemy pozwolić sobie na zaawansowany i opierający się na zaufaniu kontrakt typu Capped T&M czy Cost Targeted. Niestety w dużej części  przypadków w świecie realnym jest tak, że z różnych powodów jedynym akceptowanym przez zamawiającego kontraktem jest fixed price (stała cena za wykonane prace). Takie ustawienie sprawy teoretycznie od razu wyklucza podejście agile, bo w tym momencie pierwsze co robi dostawca to domaganie się zdefiniowania fixed scope (stały zakres). Jak już mamy stały zakres i stałą cenę to gdzie tu miejsce na agile? Miejsca jest wbrew pozorom dość dużo.

Pierwsza rzecz to podejście iteracyjne do wykonywania projektu. Ten element jest dość często pomijany, natomiast wbrew pozorom bardzo ważny dla zamawiających. Chodzi o ograniczanie ryzyka. Jeżeli nie można wyeliminować ryzyka kontraktu (jest stała cena, więc i tak pojawią się koszty) to można chociaż próbować ograniczyć ryzyko produktowe. Czyli spróbować zapobiec sytuacji, kiedy klient dostanie coś, czego (w jego przekonaniu) wcale nie zamawiał. Z punktu widzenia zamawiającego jest ważne czy produkt projektu zobaczy dopiero raz, na samym końcu projektu czy będzie go widział często, mogąc go testować w trakcie. Zgodnie bowiem z panującym powszechnie przekonaniem klienta interesuje tylko efekt końcowy, ale przy okazji chciałby on osiągnąć go przy optymalnym ekonomicznie ryzyku. Dlatego wbrew powszechnie panującym przekonaniom klienta interesuje to, w jaki sposób dostawca realizuje projekt i jak ta realizacja wpływa na ogólne ryzyko całego projektu. Agile natomiast zmniejsza to ryzyko.

Kolejnym tematem jest wciągnięcie klienta w projekt. Zgodnie z wartościami agile interakcje między ludźmi są ważniejsze niż procesy i narzędzia. I to działa niezależnie od typu kontraktu. Znane mi są przypadki, kiedy dostawcy w sposób aktywny ograniczali dostęp zespołu wykonawczego do klienta. Co więcej kontakt z klientem ograniczał się do regularnych spotkań "na szczycie". Innymi słowy każda informacja przekazana przez klienta przechodziła przez trzy osoby zanim trafiła do programisty. Skutki można dość łatwo przewidzieć. Wszyscy działali w najlepszej wierze a klient i tak dostał nie to co chciał i za co myślał, że zapłacił. Tak więc komunikacja, komunikacja i jeszcze raz komunikacja. Oraz aktywne włączenie klienta w prace.

Trzecia natomiast rzecz to elastyczność w przejściu w tryb "variable scope". To najlepiej wytłumaczyć na przykładzie. Załóżmy, że realizujemy kontrakt typu fixed (stała cena, stały zakres). W połowie projektu klient orientuje się, że chce zmienić jedno z wymagań. Zwykle dlatego, że w jakiś sposób zmieniły się warunki prowadzenia biznesu. Co w takim wypadku może zrobić dostawca? Pierwsza opcja to przyjąć i wycenić "change request" (żądanie zmiany). Bardzo często po stawkach wyższych niż oryginalny projekt (jak to wpływa na jego wizerunek w oczach klienta?). Druga opcja to przyjść do klienta i powiedzieć mu, że może zrealizować tą zmianę w ramach obecnego kontraktu, ale konsekwencją jej zrealizowania będzie nie zrealizowanie całego wcześniej zakontraktowanego zakresu. Takie podejście to właśnie dążenie do projektu "variable scope". Oczywiście na wszelkie tego typu zmiany muszą istnieć później odpowiednie dokumenty (bo to w końcu zmiana warunków kontraktu). Zapewne zależy to od klienta, ale takie podejście może się spotkać z zaskakująco dobrym przyjęciem. Oczywiście również dlatego, że najważniejsze z punktu widzenia klienta funkcjonalności zostały zrealizowane na początku projektu, więc konsekwencje zmiany zakresu nie będą miały na nie wpływu, prawda?

Back

Od ostatniego postu minęło prawie dwa lata... Przez ten okres czas, który wcześniej przeznaczałem m.in. na pisanie tego bloga, pochłaniało mi coś zupełnie innego. Tak dokładnie to cały mój wolny czas pochłonięty był studiami Franklin University MBA. Generalnie bardzo polecam z dwóch powodów. Po pierwsze studia są realizowane w całości w języku angielskim, przez amerykańskich wykładowców, z amerykańskich książek i według amerykańskiego programu. Innymi słowy można się poczuć jak student amerykańskiej uczelni (a podejście mają zupełnie inne niż nasze uczelnie). Po drugie to studia studiami, ale najważniejsze w nich i tak jest poznanie wielu bardzo ciekawych osób, wymiana doświadczeń i uczenie się od siebie. Często dające nieporównywanie więcej niż książki i słuchanie wykładowców. Natomiast uczciwie trzeba też powiedzieć, że takie studia to potężne obciążenie czasowe odbijające się na życiu prywatnym. Amerykanie szacują, że skończenie ich wymaga wkładu około 6-8 godzin dodatkowej pracy co tydzień. Wydaje się, że to jeszcze nie jest aż tak duża tragedia, natomiast należy pamiętać, że zostało to policzone z założeniem, że językiem ojczystym studenta jest angielski. W przypadku gdy tak nie jest czas ten się wydłuża...

 Aby jednak odnieść się do tematyki tego bloga taka refleksja dotycząca innowacyjności. Studia MBA niewątpliwie są interesujące i dają dużo wiedzy, jednak dość ewidentnie widać, że większość z niej dotyczy "tradycyjnych" biznesów. Produkcja, dystrybucja, sprzedaż (w fizycznych sklepach) - takie elementy są bardzo dobrze zbadane, opisane i istnieje ogrom wiedzy pozwalającej na doskonalenie stosowanych tam systemów. Natomiast nie ma bezpośredniego przełożenia tej wiedzy na nowe technologie i nowe media. To nie wynika nawet ze "starości" samej koncepcji studiów czy też niewiedzy wykładowców. Czytając amerykańskie książki akademickie wydawane w roku 2010 czy też 2011 zaskoczony byłem tym jak mało jest tam modeli i teorii znajdujących bezpośrednie zastosowanie w firmach nowych mediów czy nowych technologii. Raczej należało wszystkie teorie przekładać na te realia wykonując dość dużą pracę koncepcyjną. Na szczęście w źródłach reagujących szybciej niż podręczniki akademickie (np. amerykańskie edycje HBR) widać, że coraz częściej autorzy interesują się właśnie zwinnymi firmami nowych technologii. Co też będzie wpływało na kolejne posty na tym blogu :)

Mam dużą nadzieję, motywację i plan, żeby posty na tym blogu znów pojawiały się regularnie. Może nie aż tak często jak kiedyś, ale regularnie.

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.