Brałeś kiedyś udział w projekcie, który poszedł do kosza? Lub nie poszedł do kosza, ale wygenerował koszty większe niż przychód? Prawdopodobnie brałeś, bo nierentowne projekty w IT zdarzają się w wielu firmach, tylko nie wszystkich przyczyna nierentowności jest taka sama. W tym artykule mówimy o jednej z głównych przyczyn generowania waste'u w projektach IT.
Źródło fotki: Studio Republic (dziękuję!)
Opisujemy pierwszą z listy przyczynę generowania zbędnych kosztów w projektach IT. Czy znasz to zjawisko z autopsji?
#Zbyt wiele inicjatyw "in progress" na raz
Zgodnie z definicją przyjętą przez PMI.org, mały projekt to ten, w którym bierze udział do 10 osób i trwa do 6 miesięcy. Dlaczego tak się dzieje, że zarówno w małych organizacjach, jak i korporacjach, obserwujemy dążenie, aby wypełnić czas deweloperów do ostatniej godziny? Najczęściej wynika to:
ze zobowiązań biznesowych wobec klientów - podpisane kontrakty z klientami gwarantują wytworzenie usług lub rozwój już istniejących w określonym czasie bez względu na obłożenie zespołu deweloperskiego i innych współpracujących zespołów (np. zespołu designerskiego, produktowego, UX)
w wyniku niewystarczającej lub niejasnej komunikacji między zespołami w firmie - łatwo wyobrazić sobie Account Managera, który świętuje kolejny podpisany kontrakt i - w tym samym czasie, załamanego Project Managera czy Product Managera, który ten sprzedany "deal" będzie musiał wcisnąć w harmonogram prac i tak już po brzegi wypchany już takimi "dealami"
z pracy w silosach, z których każdy zespół ma swoje KPI i ludzie z zespołów dążą do realizacji własnych celów lub celów zespołowych, a nie celów firmy. Dlatego właśnie Account Manager będzie zadowolony z nowego kontraktu (zdobył nowe źródło przychodów) a PM już niekoniecznie
z wyścigiem z konkurencją i z chęci wytworzenia wartości biznesowej w postaci konkurencyjnej usługi w jak najszybszym czasie (nierzadko "na termin" mimo braku estymacji i "dopiętego" zakresu), gdzie argument brzmi "konkurencja już to ma, zostajemy w tyle!"
z braku doświadczenia i świadomości osób decyzyjnych w projekcie, że ciągły shifting między wieloma różnymi projektami zmniejsza wydajność zespołu i sprawia, że pracuje on wolniej w wyniku ciągłej zmiany kontekstów. Przyjmuje się, że jedna osoba w projekcie, bez względu na to czy to UX czy deweloper, jest w stanie efektywnie pracować maksymalnie w 2-3 projektach jednocześnie
z braku decyzyjności i ownershipu w rękach Product Managera (w scrumie - Product Ownera). Słowo klucz to empowerment, czyli zapewnianie decyzyjności odpowiedniej osobie, w tym przypadku właśnie PM-owi. Sponsorzy projektu mogą zmieniać strategię rozwoju firmy, mogą też zmieniać priorytety na Road Mapie i - choć to niewygodne, mają do tego prawo. Rolą Product Managera jest stała komunikacja ze sponsorem projektu, zbieranie informacji o jego potrzebach i głębokie rozumie celów biznesowych przez niego wyznaczanych tak, aby przekazanie tych celów i wyjaśnienie, dlaczego Road Mapa się zmienia, było w ogóle możliwe, problem pojawia się, gdy Sponsor i / lub osoba przez nią wyznaczona do komunikacji, są niedostępni
Co możesz zrobić jako Product Manager?
Nie mam jednoznacznej odpowiedzi na takie pytanie, choć każdy PM powinien je sobie zadać. Działania, które sama podejmowałam i jakie Ty możesz podjąć:
jeśli pracujesz w metodykach zwinnych i Twoja firma przyswoiła lub nawet -oswoiła Scruma (albo wdrożyła jakąś hand-made hybrydę), walcz o to, by być osobą decyzyjną w zakresie zarządzania Road Mapą, planowania sprintów i realizacji zadań w sprintach. Decision maker to miano, które Ci się należy i każda sytuacja, w której deweloperzy otrzymują dyspozycje zmiany priorytetów lub dodatkowe zadania bez Ciebie jest incydentem (bo w takim razie, po co Ty jesteś?). Dlaczego tak mocno nazywam to zjawisko? Dlatego, że u podstaw braku decyzyjności PM czy PO leży szereg różnych problemów, w tym waste w postaci wykonywania zbędnej pracy wielu osób, które pracują nad realizacją wymagań. Jesteś w stanie sobie wyobrazić sobie, że deweloperzy po decyzje dotyczące interfejsu biegają do designera, a nie do Ciebie? A designer ma szczątkową wiedzę o wartości biznesowej (swoją drogą - to też niedobrze, jeśli tak jest :P) i podejmuje decyzję, która wycina lub chowa w cień funkcjonalność lub jej część zapewniającą integrację usługi z innym, istotnym dla działania produktu systemem?
jeśli opisana sytuacja występuje, zakomunikuj, że to nie jest ok, a jeśli to nie pomaga - zaangażuj Scrum Mastera (zresztą - SM powinien wiedzieć, z czym się borykasz!). Poruszcie ten problem na retrospektywie. Robota Scrum Mastera polega na tym, by pomóc Ci usuwać przeszkody i wycinać szkodliwe działania w teamie i nie dlatego, że scrum guide tak mówi, a dlatego, ze odpowiedzialnością każdej osoby w zespole jest efektywne działanie i wytwarzanie zgodnie z wymaganiami tak, by dowieźć wartość biznesową w zaplanowanym czasie
a co, jeśli Scrum Master nie pomaga, a zespół wciąż biega po wymagania do kogoś innego? Licz na siebie i analizuj na bieżąco statystyki, nie tylko statystyki sprintu, ale również mierniki biznesowe (o modelu HEART w innym artykule), tak byś mógł nie tylko posmęcić, że jest Ci źle, ale również - byś mógł sypać argumentami, dzięki którym ludzie będą wiedzieć, że masz rację i należy po prostu słuchać, co masz do powiedzenia
jeśli ludzie w projekcie biegają wciąż do kogoś innego po szczegóły wymagań niezbędne do realizacji Twoich wymagań, zastanów się, czy na pewno z Twoimi wymaganiami jest wszystko ok. Zwróć uwagę, do kogo biegają. Jedną z przyczyn stosowania takich praktyk przez zespół jest to, że po prostu nie wiesz, jak dokładnie powinna działać wytwarzana funkcjonalność i Twoje wymagania są niezrozumiałe, niekompletne, nielogiczne. Jeśli jest jakiś guru, który wie lepiej od Ciebie, zastanów się, dlaczego to on jest guru Twoich wymagań, a nie Ty. Przyczyn takiego stanu jest naprawdę dużo: nie znasz się wystarczająco na dziedzinie, nie poświęciłeś wystarczająco dużo czasu na zrozumienie, co powinniście w zespole wytworzyć, dostałeś za mało szczegółów od interesariuszy, ktoś Cię pozbawia dostępu do wiedzy, bo wie lepiej (czyli uprawnia micromanagement) i Ty się przez to pocisz. To wszystko jednak nie usprawiedliwia Cię, bo jeśli nie masz wiedzy, to powinieneś ją zdobyć - choćby dzięki rozmowie w zespole. Jeśli nikt nie wie, co trzeba zrobić, to znaczy, że w ogóle nie powinniście brać się za projekt / epik i zaczynać pracy nad niejasnymi wymaganiami. Pomyśl też, czy na pewno Wasze refinementy przebiegają efektywnie?
Najtrudniejsza do usunięcia przyczyna pracy Twojej i ludzi nad wieloma inicjatywami jednocześnie to nieumiejętny management osób odpowiedzialnych za realizację strategii biznesowej (lub - brak tej strategii). Nierzadko, zwłaszcza w mniejszych firmach - przyczyną trudności w projektach (nie bójmy się tego powiedzieć!) jest mocna pozycja szefa / prezesa / dyrektora, który rozdaje karty i wie najlepiej, co i jak należy zrobić, bo przecież urodził dziecko, jakim jest usługa, nad którą wszyscy pracujecie. Mocno wierzę, że efektywnie pracujący zespół to taki, w którym sponsor umie wyrazić "why" i określić cele, do których wszyscy w firmie dążymy, product managerowie są w stanie powiedzieć, jaki środkami należy te cele osiągnąć (gdzie środkami są projekty i współistniejące inicjatywy), a team deweloperski decyduje we współpracy z produktowcami, w jaki (techniczny) sposób te cele należy osiągnąć (jak budować usługi na podstawie wymagań)
No i wreszcie - powodem waste'u i wytwarzania wszystkiego na raz i "na już" jest kultura organizacji. Z obserwacji własnych i z licznych rozmów ze znajomymi produktowcami i deweloperami wiem, że świat IT zachłysnął się dążeniem do osiągnięcia KPI. Słupki statystyk stały się wyznacznikiem tego, jak pracujemy i zaczęły definiować nas jako pracowników, a nawet szerzej - jako ludzi. Dążenie do ciągłego wzrostu to na dłuższą metę killer skutecznego działania. Oczywiście, biznes jest najważniejszy, ale wzrosty można prognozować, biorąc pod uwagę popyt i podaż, historyczne wyniki, napływ nowych klientów, analizę źródeł napływu, ryzyka wewnętrzne i rynkowe, działania konkurencji i sytuację gospodarczą na rynkach, na których organizacja działa. Jednak, nie można zapominać o tym, kogo mamy w zespole, jaka jest jego obecna wydajność i kompetencje i jak one zmieniają się w czasie. Wraz z prognozą wyników na następny rok powinna iść praca na poziomie hiring planu
Wiele zależy od Ciebie, ale nie wszystko. Jeśli zgłaszasz problemy i próbujesz je rozwiązywać, a osoby odpowiedzialne za zarządzanie organizacją nie słuchają lub słuchają, jednak nie podejmują działań naprawczych, możesz zrobić tak:
próbować wpływać na osoby zarządzające, szukając sprzymierzeńców i dostarczając dane, dzięki czemu będziecie rozmawiać o faktach, nie opiniach
zmienić zespół, projekt, pracodawcę
Źródła:
Statystyki - z opracowań Harward Business Review, PMI.org
Comentarios