fbpx

Porozmawiajmy o pieniądzach w projekcie.

Created with Sketch.

Porozmawiajmy o pieniądzach w projekcie.

Chodzą słuchy, że nasz kalendarz adwentowy ma zaplanowane, napisane wcześniej posty, nic bardziej mylnego! Wpisy powstają tego samego dnia kiedy są publikowane, czasem zdarzy się, że ktoś napisze artykuł dzień wcześniej. Gdyby były napisane wcześniej, publikacja byłaby na blogu do porannej kawy, a tak jest do wieczornego przeglądania internetu.

Posty często odnoszą się dyskusji, które poruszaliśmy konkretnego dnia między sobą lub z zespołem, z którymi pracujemy, spotkani ludzie tworzą temat każdego dnia.

Dziś jest sobota, więc nie było porannej kawy w biurze, nie było dyskusji nad wyższością frontendu nad backendem, Javy nad .NETem więc zastanawiałam się o czym dziś napiszę… nuda. Wyszłam z domu na ostatnie przedświąteczne zakupy i na miejskim targowisku spotkałam koleżankę, z którą jakiś czas temu pracowałam w jednej firmie (pozdrawiamy Anię). Między pietruszką a słoikami z miodem, narodziła się dyskusja o Product Ownerach vs. Product Managerach.

K: Oooo cześć Ania, co tam słychać, jak życie?
A: Aaa dobrze, dalej pracuje z chłopakami, tworzę im design i fajnie to działa, bo bazujemy na feedbacku od klientów, to oni definiują kolejne kroki rozwoju, Tomek potem decyduje co i w jakiej kolejności dewelopujemy.
K: Aha, czyli Tomek jest takim Product Owner’em tego rozwiązania?
A: Bardziej Managerem, bo zajmuje się sprawami finansowymi.

I tak przemyślenia do dzisiejszego posta zaczęły kiełkować. W naszej dyskusji z Anią doszłyśmy do wniosku, że mało który Product Owner, którego znamy, zajmował się budżetem projektu. Jak ktoś zarządzał budżetem, to organizacje nazywały taką osobę Product Managerem (nie jest źle) lub rozdzielały rolę, i tak Product Owner był odpowiedzialny za backlog i wymagania, a Manager z nim współpracujący za budżet produktu (to już dramat). Jeżeli zajrzymy do Scrum Guide, nie ma tam ani słowa o tym kto zarządza finansami projektu. 

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

1. Clearly expressing Product Backlog items;
2. Ordering the items in the Product Backlog to best achieve goals and missions;
3. Optimizing the value of the work the Development Team performs;
4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
5. Ensuring the Development Team understands items in the Product Backlog to the level needed.

Maksymalizacja wartości produktu, która opiera się na wynikach pracy zespołu developerskiego, brzmi bardzo dobrze, jednak w praktyce częściej spotykałam wartość produktu jako dostarczone kolejne User Story, a nie zwrot z inwestycji w postaci zysku wyrażonego w pieniądzu. Jak więc maksymalizować wartość produktu, jeżeli nie masz pojęcia czy produkt w ogóle zarabia i jakie koszty ponosi (ludzie, infrastruktura, marketing, itd.)?

Co więcej, jestem mocną zwolenniczką, żeby Product Owner, który zarządza budżetem produktu, dzielił się tą informacją z zespołem developerskim, który może wykorzystać ją przy rozwoju technologicznym rozwiązania. Dodatkowo jest w tym walor edukacyjny, ponieważ zespół widzi bezpośrednio, jak przekładają się ich decyzje na koszty.

Jeden z Product Ownerów, z którym współpracuje, przyszedł do mnie, jak to często robią młodzi PO z rozwiązaniem problemu, a nie z problemem, o którym moglibyśmy porozmawiać. Rozwiązanie brzmiało następująco: 

PO: Kamila, rozmawiałem z zespołem, to co musimy zrobić, będzie czasochłonne, potrzebujemy kolejnej osoby do zespołu na już, otwieramy rekrutacje.
K: Aha, a czemu to będzie czasochłonne? Wprowadzenie nowej osoby do projektu, też jest czasochłonne i kosztowne, nowa osoba nie będzie wydajna od początku, trzeba ją wprowadzić, co zajmie czas chłopaków. Sprawdzałeś z chłopakami budżet projektu? Może rozsądniej będzie zmienić priorytety, niż zatrudniać nową osobę co nadszarpnie budżet i wcale nie przyspieszy developmentu od pierwszego dnia.
PO: Nieee wiesz, ja z zespołem nie chcę rozmawiać o budżecie, oni nie powinni o tym wiedzieć.

Tak bardzo się z tym nie zgadzam! Zespoły, które rozwijają produkt to naprawdę świetni specjaliści, a jeżeli będą wiedzieć odrobinę więcej, wcale nie wykorzystają tego przeciwko pracodawcy, a raczej do tego, żeby przygotować rozwiązanie, które będzie mieściło się w zadanych kryteriach (czas lub pieniądze). 

To bez sensu zatrudniać mądrych ludzi, by potem mówić im co mają robić. My zatrudniamy mądrych ludzi po to, aby to oni mówili nam co mamy robić

Steve Jobs

Jak pracowałam przy rozkręcaniu nowych projektów, pytałam klientów wprost: jaki budżet macie na ten projekt? Często dostawałam odpowiedzi wymijające, czasem żadnej, ale byli też tacy którzy (zgodnie z wartością Scruma) byli transparentni i jasno określali jaki budżet chcą przeznaczyć na rozwiązanie IT. Jeżeli, zespół nie dostaje takiej informacji od właściciela produktu, czuje się jak 5 latek w sklepie z cukierkami – ciężko się opanować i nie wybierać tych najdroższych. I wszystkich na raz.

Scrum Guide nie jest wyrocznią, jest tylko ramą, na której opieramy proces, odpowiedzialności i zadania osób pracujących w nad projektem lub produktem. Jeżeli nie ma w nim słowa o tym, że PO nie zarządza budżetem, to nie znaczy, że jest to zabronione.

American management thinks that they can just copy from Japan. But they don’t know what to copy.

W. Edwards Deming

Kto u Was w zespole odpowiada za budżet projektu?