Pracowałem przez ostatnie 11 lat z najróżniejszymi firmami, od malutkich software house’ów, poprzez korporacje, aż po ministerstwa. Niestety w większości przypadków spotykam się z charakterystycznym problemem, nazywam go syndromem myślenia projektowego. Jest to przeciwieństwo do jak najbardziej pożądanego myślenia produktowego.


Zanim wytłumaczę, na czym polegają oba podejścia oraz przedstawię kilka często spotykanych antywzorców, najpierw usystematyzuję kilka ważnych pojęć. Jak to podobno mawiał Konfucjusz: „Naprawę państwa należy zacząć od naprawy pojęć”.

Projekt to tymczasowe przedsięwzięcie. Jego rezultatem jest unikatowy produkt, usługa lub rezultat. Tymczasowość to nic innego jak początek i koniec. Sukces projektu często jest definiowany przez trzy parametry: zakres, budżet i czas. Te trzy zmienne często są nazywane żelaznym albo magicznym trójkątem projektowym. Mamy projekty technologiczne, infrastrukturalne, budowlane, finansowe, medyczne, organizacyjne, typowo biznesowe. Przykładem projektu było też napisanie artykułu, który właśnie czytasz.

Produkt natomiast to coś, co spełnia potrzeby i oczekiwania użytkowników. Coś, co dostarcza im wartość. Mamy produkty fizyczne takie jak: krzesła, samochody czy kiełbasy. Mamy też produkty cyfrowe takie jak: Youtube, Power Point czy Nasza Klasa. Usługa też może być produktem, na przykład produktami, które ja dostarczam na rynek są szkolenia ze Scruma i Kanbana, ale również usługi konsultacyjne.

Skoro już ustaliliśmy (przynajmniej w teorii), czym się różni projekt od produktu to pojawia się zasadnicze pytanie, kto to jest: Project Manager oraz Product Owner. Każda z tych ról ponosi inną odpowiedzialność i wykonuje inną pracę.

Project Manager odpowiada za sukces projektu, czyli umowne dowiezienie produktu w budżecie i na czas. Product Owner odpowiada za to, aby został stworzony właściwy produkt. Taki, który odniesie sukces na rynku i taki, który będzie dostarczał maksymalnie dużo wartości. Amerykanie często o Product Ownerze mówią Value Maximizer.

Kiedyś mój klient z jednego z ministerstw nie potrafił zrozumieć, jaka jest różnica pomiędzy Project Managerem a Product Ownerem. Powiedziałem mu wtedy, że Project Manager nie może spać po nocach, bo nie uda mu się zrealizować zakresu w określonym budżecie lub na czas. Natomiast Product Owner nie może spać po nocach, bo Pani Krysia z urzędu skarbowego nie będzie potrafiła za pomocą aplikacji szybko i efektywnie wykonać swojej pracy. Obie te role skupiają się na czymś bardzo różnym. Co ważne, interesy tych dwóch ról zawsze powinny być spójne, ale niestety rzeczywistość pokazuje, że czasami są sprzeczne, a to już równia pochyła do klęski!

Samo myślenie projektowe nie jest niczym złym. Jednak, jeżeli ktoś zaczyna myśleć tylko o projekcie, a zapomina o produkcie to mamy do czynienia z czymś, co nazywam syndromem myślenia projektowego. Najprawdopodobniej nic wartościowego z takiego podejścia nie powstanie. Coś na zasadzie „operacja się udała, ale pacjent zmarł”. Dowieźliśmy co prawda na czas, w zakresie i budżecie (sukces!), tylko nikomu niepotrzebny produkt. Widziałem to dziesiątki razy, za każdym razem smuci mnie to tak samo. Syndrom myślenia projektowego przybiera różne postaci, warto je poznać, aby skutecznie im zapobiegać.

1. Prędkość ponad wartość biznesową

…szybko i dużo, ale niewłaściwych rzeczy. Ten antywzorzec najczęściej widzę w korporacyjnych implementacjach Scruma. Chodzi o mierzenie prędkości zespołu (zwanej najczęściej velocity), czyli ilości zrealizowanej pracy (np. User Story) przy jednoczesnym małym skupieniu uwagi, na tym jaka wartość biznesowa jest dostarczana. Przykładowo jeden Product Owner którego zapytałem: „Po czym poznasz sukces Waszego produktu?”, odpowiedział „Jak to po czym? Po ilości Story Pointów na Sprint”. Bez odpowiedniej wizji biznesowej i świadomości biznesowej większość tworzonych funkcjonalności równie dobrze mogłaby w ogóle nie powstać.

 „Szybkość jest najważniejsza, jeżeli poruszamy się we właściwym kierunku” 
 David J. Anderson 

2. Zakres wyryty w kamieniu

Kiedyś jednemu Project Managerowi powiedziałem, że zaproponowane zmiany w zakresie są dobre dla produktu. Odpowiedział: „Może i są dobre dla produktu, ale nie są dobre dla harmonogramu”. To sztywne trzymanie się ustalonego początkowo zakresu. Nawet, jeżeli widać, że rzeczywistość się mocno zmieniła, że potrzeby, które ma realizować produkt uległy zmianie. Pomimo tego, że widzimy, że to, co robimy jest średnio sensowne, dokończymy, bo tak jest w harmonogramie!

3. Predykcja zamiast empiryzmu

Predykcja to przewidywanie przyszłości na podstawie teraźniejszej wiedzy. Predykcyjne tworzenie produktów oznacza zebranie wszystkich wymagań na początku projektu bez ich weryfikacji w trakcie. Jednak użytkownicy produktów to ludzie. Ludzie są trudno przewidywalni, a ich potrzeby zmieniają się w czasie. Projekt oparty o predykcję, który powstaje przez 3 lata, co najwyżej zrealizuje potrzeby użytkowników sprzed 3 lat!

Aby stworzyć produkt, który podbije rynek, nie wystarczy porządna faza specyfikacji wymagań. Wszystko, co myślimy o potrzebach naszych użytkowników i sposobach na ich realizację należy traktować jako hipotezy. Bez częstych pętli zwrotnych i empirycznego potwierdzenia tych biznesowych hipotez, istnieje ogromne ryzyko, że stworzymy produkt o małej wartości rynkowej.

Przykładem „biznesowych” pętli zwrotnych mogą być, np. badania User Experience, szybkie prototypowanie oraz częste wywiady z użytkownikami. Warto też wspomnieć scrumowe Sprint Review – jest to spotkanie, na którym kolejna wersja inkrementu produktu jest poddawana inspekcji ze strony interesariuszy, po czym następuje adaptacja wymagań.

Pamiętajmy jednak, że ostateczną weryfikacją czy nasz produkt dostarcza wartość jest wydanie produktu na rynek – warto zrobić to jak najwcześniej.

4. „Klepnęli nam to niech się martwią”

Kiedyś „sprzątałem” w projekcie, którego efektem miał być produkt – aplikacja dla graczy futbolu amerykańskiego. Klient, który zamówił produkt w software house mocno się zwiódł efektem końcowym. Okazało się, że aplikacja jest niezgodna z zasadami futbolu amerykańskiego! To, co powstało miało zerową wartość biznesową. Na to Project Manager z rozbrajającą szczerością powiedział: „Przecież nie jest napisane w kontrakcie, że ta aplikacja ma być zgodna z zasadami tej gry”.

Tego typu podejście bardzo często widać w zamówieniach publicznych. To zabawne dopóki nie uświadomimy sobie, że jest to finansowane z naszych podatków!.

5. Procedury organizacyjne ponad wartość biznesową

Najgorsze, co może spotkać człowieka zmiany to procedury. Nawet największego wizjonera może sprowadzić na ziemię dowód audytowy. Oczywiście procedury mogą być bardzo pożyteczne: standaryzują procesy, pomagają podjąć następne kroki, zapewniają zgodność. Jednak, jeśli stawiamy je ponad produkt, wartość i zdrowy rozsądek, mamy problem i kolejny antywzorzec.

Warto tworzyć procedury jak „najlżejsze” i często je weryfikować. To, co 5 lat temu dostarczało wartość teraz już może być tylko „tłuszczykiem procesowym” – należy to usunąć. Często też u moich klientów zauważam, że liczne i uciążliwe procedury są wynikiem małego zaufania do pracowników. Niestety często zamiast pochylić się nad prawdziwym problemem jest tendencja do… dodawania kolejnych procedur.

Pamiętajcie, że dobrego Project Managera czy dobrego Product Ownera poznamy po owocach ich pracy. Bez wątpienia owocem ich pracy zawsze jest produkt! Taki, który spełnia lub nie spełnia potrzeb i oczekiwań użytkowników.

Apeluję do wszystkich zostańcie produktowcami! Dostarczajcie wartość! Natomiast zakres, czas i budżet traktujcie jak drogę do celu.