Projekt vs Produkt

Mottem naszego bootcampa „Product Management Academy” nie bez powodu jest hasło: „Przestań robić projekty, zacznij rozwijać produkty! Rób tylko to co ma sens!”. Prowadząc szkolenia i doradzając firmom, zauważam dość często, że osobom, które przez wiele lat pracowały w projektowym środowisku, niezwykle ciężko jest z dnia na dzień przestawić się na inny sposób myślenia.

Żebyście mnie źle nie zrozumieli – nie widzę nic złego w stosowaniu dobrych praktyk znanych z project managementu. Zbyt często widzę natomiast, w jaki sposób projektowe myślenie wpływa na realizację danej inicjatywy, jak choćby brak refleksji „po co coś robimy” lub „czy to jest faktycznie użyteczne dla końcowego użytkownika”. Dysfunkcje typu: „nie musicie wiedzieć po co, po prostu to zróbcie” na potrzeby dzisiejszego artykułu na razie przemilczmy 😉

Przyjrzyjmy się z jakimi (niektórymi) wątpliwościami musi się zmierzyć sponsor nowej inicjatywy:

• Czy na koniec etapu „realizacji” otrzymam coś co działa?
• Czy zmieścimy się w terminie i (obiecanym/zdefiniowanym z góry) budżecie?
• Czy dostanę wszystko, o co prosiłem? (zakres)

Zobaczmy jak powyższe ryzyka są zaadresowane w dobrych praktykach product managementu, lean startup czy zwinnych metodykach.

1. Czy na koniec etapu „realizacji” otrzymam coś co działa?

Tworzenie produktu to nie jest kupowanie samochodu. Nie wystarczy przejść się do salonu, wybrać konfigurację samochodu (załóżmy, że była ona niestandardowa) i po 3-4 miesiącach przyjść pod odbiór z checklistą do sprawdzenia czy wszystko jest tak jak sobie założyliśmy.

Metodyki zwinne zakładają, że po każdej iteracji powinien nastąpić wartościowy z perspektywy końcowego użytkownika przyrost. Dodatkowo częste wdrożenia:

• pokazują nam, że potrafimy wdrażać i mamy przepracowany proces wdrożeń (ryzyko integracji)
• pozwala nam na pokazanie efektu prac interesariuszom i zweryfikowanie tego czy idziemy w dobrą stronę (patrz: Potęga szybkiego feedbacku)
• pozwala nam zarabiać / korzystać z produktu wcześniej niż końcowa data oddania „projektu”

2. Czy zmieścimy się w terminie i (obiecanym/zdefiniowanym z góry) budżecie?

Termin w projekcie powinien być stały, ponieważ często z konkretnymi datami wiążą się istotne wydarzenia: np. akcje marketingowe, wykupiony czas reklamowy, czy po prostu wchodzi ustawa i od konkretnego dnia mamy spełnić określone wymagania.

Budżet też jesteśmy w stanie sobie oszacować (a wręcz powinniśmy), ale o to łatwo zadbać, bo np. X osób x Y miesięcy = Z kosztów. Oczywiście te szacunki nie biorą się z powietrza, ale o tym w osobnym artykule.

Co zrobić, żeby skupić się na najważniejszym i nie przestrzelić budżetu i terminu?

Z pomocą przychodzi nam przede wszystkim podzielenie wymagań na mniejsze, czyli tzw. dekompozycja wymagań biznesowych.

Druga sprawa to priorytetyzacja – czyli najpierw robimy rzeczy „must-have” zanim zabierzemy się za te „nice-to-have”.

Plus, co często pojawia się w kontraktach zwinnych – to możliwość przerwania developmentu po każdym sprincie. (Bo np. zmieniła się sytuacja biznesowa, albo wymyślony przed miesiącami zakres nie ma już większego sensu biznesowego) Natomiast żeby faktycznie Product Owner lub sponsor mógł podjąć w pełni świadomą decyzję biznesową tego typu: muszą być realizowane częste wdrożenia i systematyczne przyrosty.

3. Czy dostanę wszystko, o co prosiłem? (zakres)

Tworzenie początkowego zakresu czasem przypomina pisanie listu do świętego Mikołaja. Powstaje nam długa lista życzeń, ale:

• Skąd wiemy, czy wszystko jest niezbędne?
• Czy wszystko jest tak samo ważne?
• Co bym wybrał do zakresu gdybym miał tylko miesiąc na realizację? (perspektywa hackatonów: mamy 24/48 h – co najlepszego możemy w tym czasie zrealizować)
• Na jakiej podstawie określane są priorytety? „Wydaje mi się” czy metryki produktowe?
• Z których funkcjonalności tak naprawdę będą korzystali końcowi użytkownicy? Jak to sprawdzę?
• Czy potrzebuję otrzymać cały zakres (biorąc pod uwagę powyższe podpunkty)?

Realizując projekt, często zapominamy o tych, jakże ważnych, pytaniach. (Zwłaszcza w relacjach Zleceniodawca – Podwykonawca, gdzie czasami kontrakt tworzy nam checklistę do odhaczania i nie promuje podejścia produktowego).

Z pomocą przyjdą nam tutaj wspomniane wcześniej: dekompozycja wymagań biznesowych, priorytetyzacja, tworzenie hipotez produktowych i ich walidacja, ciągłe skupienie się na wartości biznesowej (vs. ślepe odhaczanie kolejnych funkcjonalności).

Czy w interesie sponsora jest mieć „stały” zakres?

Raczej nie. Podwykonawca będzie musiał założyć sobie tzw. poduszki bezpieczeństwa, aby uwzględnić pewne ryzyka. Dodatkowo będziemy potrzebowali procesu zarządzania zmianami, który sam w sobie zabiera czas i energię. Zamiast skupiać się na dostarczaniu jak największej wartości biznesowej, będziemy przeglądać maile w poszukiwaniu „dupochronów” oraz będziemy tracili czas na rozmowy typu: „było w zakresie” / „nie było w zakresie”.

Dodatkowo mielibyśmy tutaj założenie nie wprost, że już wszystko wiemy o nowo tworzonym produkcie nie zostawiając sobie miejsca na eksperymenty czy walidację hipotez produktowych, zapominając o tzw. „Product Discovery”.

W dzisiejszym artykule poruszyłem tylko kilka najważniejszych ryzyk projektowych i to, jak podejście produktowe i metodyki zwinne sobie z nimi radzą. Już niedługo zapraszam na kontynuację tego tematu.