10 sposobów na udaną prezentację harmonogramu produktu

Prezentacja harmonogramu produktu może być stresującym wydarzeniem zarówno dla programistów, jak i menedżerów produktu. Jedna ze stron ciężko pracowała, aby przygotować wizję, a druga nie może się doczekać, aby poznać plan, który wyznaczy kierunek ich pracy.

Odczuwałem to napięcie, gdy pracowałem jako programista. Harmonogramy opracowane przez zespół zarządzający często nie budziły mojego entuzjazmu. Nie zawsze zgadzałem się z podejmowanymi decyzjami i często wychodziłem ze spotkania poświęconego planowaniu, myśląc sobie „Moim zdaniem to nie ma sensu, ale jeśli tak chcą…”, lub jeszcze gorzej „Wygląda na to, że sami będziemy musieli coś wymyślić i udawać, że realizujemy harmonogram.

Ktoś mógłby słusznie argumentować, że odrzucałem plan, ponieważ nie ja go wymyśliłem. Jako programista, miałem ugruntowaną opinię na temat tego, co należy zrobić. Ale teraz jako menedżer produktu, widzę, z czego wynikało to niezrozumienie i czego menedżerowie produktu mogą się na jego podstawie nauczyć, aby skutecznie docierać do odbiorców podczas prezentacji harmonogramu. Jeśli zespół techniczny zrozumie i zaakceptuje wizję ogólną, jego członkowie będą mogli podejmować codzienne decyzje projektowe i wdrożeniowe, mając odpowiedni kontekst, a otrzymasz swój wymarzony produkt.

Poniżej przedstawiam moje dziesięć najlepszych sposobów na dotarcie do zespołów podczas prezentacji harmonogramu produktu.

O ile popularne hasła, takie jak „analiza danych big data”, „uczenie maszynowe” czy „Internet rzeczy (IoT)”, przemówią do interesariuszy biznesowych, którzy potraktują je, jako ambitne cechy produktu, dla zespołów technicznych pojęcia te nie będą przydatne. Programiści muszą dokładnie wiedzieć, co tworzą, jak to się odnosi do istniejących produktów, jak należy to dostarczyć oraz kto będzie z tego korzystał i w jakim celu.

Dodając do harmonogramu ambitne tematy, nadasz mu strukturę i zbudujesz kontekst. Ale nie możesz na tym poprzestać. Musisz potrafić wyjaśnić, co kryje się za każdą ambitną ideą. Na przykład, jeśli wprowadzisz temat „inteligentnych usług”, rozłóż to pojęcie na kluczowe inicjatywy i epiki, które są potrzebne do jego realizacji.

Zespoły techniczne muszą wiedzieć, dlaczego chcesz dodać daną pozycję do harmonogramu. Żaden zespół techniczny nie przygotuje rozwiązania bez kontekstu. Przeciwnie, inżynierów trzeba przekonać, że na daną funkcję jest zapotrzebowania, prezentując dowody. Wykorzystaj do tego dane, ale najbardziej przekonywujące będą opinie użytkowników. Wykorzystaj persona, przedstaw wykluczone przez Ciebie rozwiązania alternatywne i wyjaśnij, dlaczego inne są lepsze. Jeśli chcesz, aby cały zespół zrozumiał harmonogram, skup się jednakowo na tym „co” jest do zrobienia i „dlaczego”.

Dodawanie do harmonogramu słabo przemyślanej funkcji, której realizacja nie jest realistyczna, to z pewnością niewłaściwa droga. Zespół techniczny mógłby odnieść wrażenie, że musi przygotowywać rozwiązania tylko dlatego, że ktoś je komuś obiecał. Na przykład w związku ze zobowiązaniem wobec klienta lub na polecenie kadry zarządzającej”. Warto zatem uważać, do czego się zobowiązujemy. Nawet jeśli sytuacja wymusza wprowadzenie zmian, upewnij się, że rozumiesz uzasadnienie, przekaż je zespołowi i wesprzyj swoim autorytetem.

Warto stworzyć wizję, ale trzeba też upewnić się, że wszyscy wierzą w jej realizację. Plan nie musi być precyzyjny, ale jeśli pierwszą rzeczą, którą menedżer programistów w nim dostrzega, jest wąskie gardło, możesz spodziewać się kłopotów podczas prezentacji. Może do tego dojść, na przykład, gdy w harmonogramie będzie dużo zadań związanych z projektowaniem rozwiązań front-endowych, a w zespole, który w ciągu ostatnich kilku miesięcy zmagał się z tematami związanymi z front-endem jest tylko jeden projektant.

Przed prezentacją skonsultuj się z zespołem, aby ustalić, co jest wykonalne i jakie są alternatywy. Zanim zaapelujesz do ludzi o zaangażowanie, musisz mieć odpowiedzi, jasny plan działania i pomysł, jak go zrealizować.

Musisz mieć świadomość, na jakim etapie jest produkt i jakie są rzeczywiste umiejętności zespołu, względem Twoich oczekiwań. Rozszerzenie zakresu działalności o nowe dziedziny, to dobra droga, ale może wymagać nowych umiejętności w zespole lub odejścia od istniejącej technologii. Musisz wziąć to pod uwagę, zanim wyznaczysz nieosiągalne cele na następny rok. Najpierw zastanów się, jak realistycznie dotrzeć tam, gdzie chcesz być. Pozyskiwanie talentów i wdrażanie nowych technologii wymaga czasu, a porzucenie istniejących produktów wymaga dużego zaangażowania i planu przejścia.

Uzasadnienie biznesowe? Tak. Zespoły techniczne interesuje uzasadnienie biznesowe. Może nie w takim samym stopniu jak kierownictwo wyższego szczebla, ale zespół programistów chce wiedzieć, dlaczego coś jest istotne dla firmy, czy rzeczywiście się sprawdza i jak to będzie mierzone. Skorzystaj z biznesowego wyczucia swojego zespołu technicznego. Wszystkim jego członkom zależy na tym, aby firma jako całość odniosła sukces, dlatego mogą być doskonałym źródłem opinii i dodatkowych pomysłów.

Poparta przykładami wiedza na temat efektów biznesowych stanowi też doskonały czynnik motywacyjny. Programiści czerpią satysfakcję nie tylko z tworzenia i dostarczania funkcji, ale też generowania wyników.

Inżynierowie chcą tworzyć wyjątkowe, innowacyjne produkty, z których mogą być dumni. Jeśli usłyszą tę samą bajkę, którą inni opowiadali już wiele razy w przeszłości, mogą stracić motywację. Upewnij się, że Twój przekaz jest tak innowacyjny, jak Ci się wydaje. Brak innowacji demotywuje programistów, ale jego negatywny wpływ na biznes jest jeszcze większy.

Należy jednak pamiętać, że tworzenie harmonogramu to sztuka poszukiwania równowagi pomiędzy nowymi ekscytującymi funkcjami i elementami mniej interesującymi pod względem technicznym, które trzeba po prostu zrobić. W swoim planie staraj się przedstawiać nawet monotonne zadania w sposób motywujący.

Stworzenie produktu o minimalnej wymaganej funkcjonalności, a następnie wersji nr 1 to nie wszystko. O wiele rzeczy trzeba też zadbać po premierze: eksploatacja, obsługa techniczna, zgłoszenia zapotrzebowania na funkcje od użytkowników, ciągłe wprowadzanie ulepszeń i konieczność integrowania nowych wersji innych produktów lub platform. Nie potrzeba szczegółowej analizy, aby dostrzec, jakie wyzwania i przeszkody mogą wystąpić po premierze. Za to inżynierowie będą wdzięczni, że te potencjalne zagrożenia zostały uwzględnione w planie. Według przybliżonych szacunków początkowe nakłady pracy związane z utworzeniem nowej funkcji stanowią często od jednej trzeciej do połowy całkowitego wysiłku, który trzeba poświęcić przez cały okres jej użytkowania. Innymi słowy: obsługa po premierze jest bardziej pracochłonna niż początkowe prace programistyczne, a niektóre „drobnostki” stają się prawdziwym utrapieniem w dłuższej perspektywie.

Oszacowania są przydatne. Wskazują drogę i są tworzone zgodnie z najlepszą wiedzą menedżera produktu w danym momencie. Jednak wiele założeń przyjętych podczas szacowania okazuje się być błędnych na etapie wdrażania lub udoskonalenia projektu. Przygotowując i przedstawiając harmonogram, zadbaj aby był elastyczny względem zmian.

Harmonogram ma na celu wskazać kierunek działania. Nie stanowi szczegółowego planu realizacji i wszyscy członkowie zespołu programistycznego o tym wiedzą. Nie ma potrzeby przedstawiać go jako czegoś, czym nie jest. Jeśli zatem nie masz jeszcze wszystkich szczegółów na dany temat, powiedz o tym otwarcie. Przekaż to, co wiesz, przedstaw zamiary, wątpliwości oraz obszary ryzyka, którymi nadal trzeba się zająć. Wskaż dziedziny, w których doprecyzowanie celów wymaga eksperymentów i dodatkowych analiz. Pamiętaj tylko, aby w planie uwzględnić czas na eksperymenty.

Twój zespół zasługuje na harmonogram, w którym klarownie przedstawisz ogólną wizję, nie zapominając o realnych możliwościach. Przygotuj dla nich plan działania, który motywuje, ekscytuje i zawiera wystarczająco dużo szczegółów, aby cały zespół programistyczny wiedział, co robić przez następne 1–2 sprinty. Aby każdy wiedział co robić, aby osiągnąć świetne wyniki, które będą miały istotny wpływ na działalność firmy.

Potrzebujesz dodatkowej pomocy? Zapoznaj się z funkcjami harmonogramów w Jira Software oraz szablonem harmonogramu produktu w systemie Jira. Lub wypróbuj za darmo rozwiązanie przeznaczone dla menedżerów produktów — Jira Product Discovery.