Dla części z Was będzie to szok. Na naszym blogu o zwinności poruszymy kwestie związane z PM-owym podejściem do realizacji projektu. Dziś zajmiemy się RAG i Watermelon Projects. Zaintrygowani?
RAG
Jaki RAG? Jakie arbuzowe projekty? Wiele razy powtarzaliśmy, że jesteśmy praktykami, a oznaczanie projektów paletą RAG czy etykietka Watermelon Projects to codzienność również zwinnych projektów. Ale po kolei…
RAG jest niebezpiecznie blisko WAGs.
To taki suchar na początek, bo blog ten nie jest przecież portalem plotkarskim, a porządnym źródłem wiedzy. Skrót RAG pochodzi od pierwszych liter kolorów, którymi oznaczyć możemy stan naszego… no właśnie, stan wszystkiego. Red, Amber, Green, czerwony, żółty (bursztynowy), zielony.
Dlaczego napisałem stan wszystkiego? Niezależnie od tego, czy oznaczamy stan Projektu, Produktu, Sprintu, Zespołu czy czegokolwiek innego, możemy wykorzystać do tego właśnie barwy z palety RAG. Proste i jasne dla wszystkich, są to przecież kolory sygnalizatorów ulicznych. Wszyscy wiemy, co oznaczają poszczególne pozycje.
Red, Amber, Green
Znamy już rozwinięcie tego tajemniczego skrótu, zastanówmy się w takim razie „po co?„. Odpowiedzi częściowo udzieliłem powyżej. Wspólne, jasne rozumienie obserwowanego stanu, jak również ujednolicenie komunikacji, to najważniejsze cele RAG.
System najczęściej wykorzystywany jest w komunikacji do senior managementu, gdzie nie ma czasu i potrzeby wchodzenia w szczegóły, a nacisk powinien był położony na najistotniejsze elementy związane z realizacją przedsięwzięcia. Takie osoby chcą wiedzieć czy jest „zielono”, „żółto”, czy „czerwono”.
Jakie elementy weźmiemy pod uwagę określając RAG? Te, które określimy jako niezbędne. Ważne jednak, abyśmy jasno zakomunikowali na podstawie jakich kryteriów i jak weryfikujemy elementy, będące podstawą kategoryzacji. W przeciwnym wypadku Red, Amber, Green będą podstawą do ciągłych dywagacji w zakresie prawidłowości wskazanego koloru. Bo czy jednodniowe opóźnienie to już status czerwony, żółty czy może jeszcze zielony? „To zależy.” No właśnie, więc warto ustalić konkretne zasady.
RAG i Watermelon Projects
Watermelon Projects to projekty, które są Zielone (Green) na zewnątrz, jednak czerwone (Red) w środku. Tak, jak arbuz. Stąd zresztą nazwa.
Natrafiłem na ten termin, tak jak na setki innych, przez całkowity przypadek. Był mi do dziś obcy, ale założę się, że każdy z nas widział lub nawet może uczestniczy w chwili obecnej w takim projekcie. Mylę się? Kto z nas nie widział projektu, którego fasada pięknie się zieleni, ale środek jest jednak mocno czerwony? W języku polskim synonimem Watermelon Projekcts, będzie malowanie trawy na zielono.
Zajrzyjmy do środka tego „owocu”. Co powoduje, że patrząc z zewnątrz jest on zielony (G), a zaglądając do środka czerwony (R)? Na każdy projekt, który ma na końcu dostarczyć pewien Produkt składają się trzy główne czynniki: czas (harmonogram), koszty (pieniądze) oraz zakres (wymagania).
Wielu Project Managerów rozliczanych jest głównie z tych dwóch pierwszych aspektów. Ba, wiele projektów weryfikowanych jest przez Senior Management w kontekście właśnie nieprzekraczalnego czasu i budżetu. Z tego punktu widzenia wszystko wygląda na Zielone. Niejednokrotnie jednak, kiedy zajrzymy do środka okazuje się, że owszem, jesteśmy na ścieżce, w harmonogramie i budżecie, jednak Produkt nad którym pracujemy delikatnie mówiąc się nie sprawdzi. Jego komercjalizacja prawdopodobnie zakończy się porażką.
Czy to nie idealny przykład Watermelon Project?
Coś jest zrobione, albo nie
Przedstawiona powyżej sytuacja to tylko jedna z możliwości. Co możemy o niej powiedzieć? Z jednej strony mamy osoby, które dbają o budżet i koszty nie dbając o zakres, z drugiej osoby, które nie dbają ani o budżet, koszty czy zakres. Wykonują jedynie (albo aż) swoją pracę w zadanym zakresie. Jeśli ktoś powie mi, że osoba Product Ownera lub Scrum Mastera w takiej sytuacji jest niepotrzebna, chętnie z nią podyskutuję.
Charakterystyczną cechą zwinnych projektów jest sposób traktowania Produktu jako „zrobiony”. Na przykład według metodyki Scrum za zrobione można uznać Produkty, które spełniają definicję ukończenia, czyli Definiton of Done. Co więcej, idealnie, jeśli to „zrobienie” następuje w przeciągu jednego Sprintu. Za każdym razem mamy mieć coś używalnego. Nie ma tutaj więc miejsca na kolorowanie stanu produktu, nie ma miejsca na kolor żółty, nie można powiedzieć, że coś jest zrobione w 82%. Coś jest zrobione, albo nie. Z RAG zostaje nam więc Red i Green, a więc RG. Zadbajmy tylko o to, aby jeden kolor móc zastosować do całości, a nie co innego dla fasady, a co innego w środku.
Jak się wydaje pozwala nam to zaoszczędzić niepotrzebnych dyskusji, problemów z ustaleniem koloru per Produkt, Zespół czy Sprint. Uwierzcie mi, nie ma nic bardziej kłopotliwego niż ustalenie (w oparciu o jakieś kryteria) jasnej definicji poszczególnych kolorów z RAG a później obrana ich przed pytaniami czy to ze strony zespołu („A dlaczego tak?„) czy Managementu („Co się dzieje w tym zespole?„) Nie uważacie, że całkiem łatwo można zaoszczędzić sobie tego kłopotu?
