Menedżer produktu i menedżer rozwoju przychodzą na spotkanie planistyczne... 2. część

Spotkania dotyczące planowania produktów są jednymi z najważniejszych spotkań w całym cyklu życia produktu i dlatego zabierzemy Cię dzisiaj na takie spotkanie w Atlassian. Koniecznie zacznij od zapoznania się z pierwszą częścią wpisu!

Aimie: Ktoś ma jakiekolwiek przemyślenia na temat tego, co można zrobić, aby szacunki były bardziej realistyczne? 

Hannes: Im więcej czasu inwestujemy w rozkładanie planów na czynniki pierwsze i omawianie tego z całym zespołem, tym dokładniejsze uzyskamy szacunki. Jednakże, czas jest bardzo cenny i raczej powinien być przeznaczony na budowę produktów, więc zapraszanie całego zespołu na każde spotkanie planistyczne byłoby mało praktyczne. Realnym rozwiązaniem jest sprowadzenie ludzi na kilka minut, aby mogli odpowiedzieć na konkretne pytania, które pomogą w estymacji.  

Martin: Innym rozwiązaniem mogłoby być wprowadzenie w zespole zasady, żeby podczas każdego sprintu przeprowadzać estymację jednego elementu backlogu z harmonogramu. Wówczas do czasu, kiedy odbędzie się spotkanie planistyczne mielibyśmy gotowy, oszacowany backlog. Poza tym, taki backlog można wykorzystywać do podejmowania decyzji – w niektórych sytuacjach estymacja +/- 100% jest wystarczająco dokładna, aby podjąć ogólną decyzję, czy można działać czy nie. Przydaje się to szczególnie wtedy, kiedy trzeba dostosować się do terminu ukończenia oprogramowania, planowanego uruchomienia i liczy się każdy dzień. Trzeba jednak uważać i mieć świadomość tego, co wiadomo na pewno, a czego nie jest się stuprocentowo pewnym – bardzo łatwo wpaść w pułapkę, kiedy wykona się przybliżony szacunek, a parę tygodni później zacznie się go traktować jako ścisły, szczegółowy plan.

Kiedy zakres jest określony a szacunki gotowe, obaj menedżerowie dokładnie sprawdzają możliwości zespołu w Portfolio for JIRA (narzędzie to połączone jest z zespołowym boardem JIRA Software) i jeśli wszystko jest w porządku, naciskają „oblicz”. Otrzymują pierwszy harmonogram, oparty o wszystkie oszacowane elementy backlogu w połączeniu z szybkością zespołu. W tym momencie dochodzą do definiowania wydań, czyli dzielenia całego backlogu na mniejsze kawałki, które są właśnie wydaniami. Ukończenie wydania bardziej zależy od tego, czy założony zakres prac został wykonany niż od tego, czy nadszedł termin ukończenia. A to dlatego, że najważniejsze jest, aby klient otrzymał konkretne, działające funkcje.

Aby dojść do etapu, w którym produkt posiada minimalną konieczną funkcjonalność (MVP), trzeba często sprawdzać listę pozycji backlogu, odpowiadając na pytania w stylu: „czy ta funkcja jest w tej chwili absolutnie konieczna?”. Spotkanie dobiega końca wtedy, kiedy Martin i Hannes wyczerpią wszelkie możliwości ułożenia harmonogramu i są w pełni z niego zadowoleni.

Na koniec: uściśnięcie sobie dłoni i udostępnienie planu

Po kilku godzinach i ustaleniu dwóch do trzech kamieni milowych w harmonogramie rozwoju produktu, menedżer produktu i menedżer rozwoju mogą opuścić pokój i być spokojni o dobrą przyszłość produktu. 

Jedną z rzeczy, które Martin i Hannes podkreślają jest ogromne znaczenie, jakie ma jak najszybsze poinformowanie zespołu o zmianach w harmonogramie. Martin i Hannes udostępniają zespołowi plan działania przy najbliższej okazji, kiedy cały zespół jest w komplecie (np. na stand-upie). Na takim spotkaniu przedstawiają krótki przegląd harmonogramu, a następnie każdy członek zespołu zapoznaje się z harmonogramem dokładniej na własną rękę. Członkowie zespołu programistycznego omawiają plan ze szczegółami na spotkaniu planowania sprintu, podczas którego rozmawiają i zadają pytania. Gdy wszyscy znają już i rozumieją cały plan, wówczas zaczynają go realizować. 

To oczywiste, że z racji różnych stanowisk Martin i Hannes mają różne cele, kiedy przychodzą na spotkanie dotyczące planowania produktu. Menedżer produktu jest głosem klienta i zazwyczaj przychodzi na spotkanie z głową pełną pomysłów: funkcji i aktualizacji, mających na celu zwiększenie zadowolenia klienta. Menedżer rozwoju przychodzi na spotkanie, aby sprawdzić liczby i upewnić się, że wszelkie zobowiązania podjęte w imieniu zespołu programistycznego są realne do wykonania. Pomimo tych różnic, spotkania te są kluczem do utrzymania na dobrej drodze produktu, harmonogramu rozwoju produktu i oczywiście wydań.