Mit pełnego obłożenia

Kontynując temat mitów dotyczących rozwoju produktów: dlaczego „pełne obłożenie zasobów” i minimalizacja zmian w harmonogramach utrudniają rozwój? Jak większość rzeczy, o których piszę, problem dotyczy większych organizacji. Jednak ich natura i przyczyny zainteresują wszystkich, którzy rozwijają produkty. Również w start-upach.

W dużych firmach część realizacyjna czesto jest niezależna od produktów. Składa się z kilkudziesięciu osób – programistów, projektantów, grafików i innych specjalistów. Z jej usług korzystają działy produktowe. Zadanie zarządzających polega na tym, by z ich pomysłów wybrać najkorzystniejsze dla organizacji i zapewnić im sprawną realizację.

W takiej sytuacji naturalnym wydaje się dążenie do systemu, w którym jak najmniej jest „przestojów” i każdy z ludzi odpowiedzialnych za realizację ma co robić cały czas. Dla każdego, kto miał styk z procesami produkcji „pełne obłożenie zasobów” jest kuszącym celem. Dla specjalizujących się w czystym zarządzaniu (taki MBA bez specjalistycznych dodatków – dziś robię internet, pojutrze pastę do zębów) to również dobry, prosty cel. Łatwo powiązać go z efektywnościa. Większość firm dąży w rozwoju produktów właśnie do pełnego obłożenia zasobów.

Problem w tym, że jest to zły cel – piszą autorzy omawianego artykułu. Osiągnięcie pełnego obłożenia ma sens w produkcji. Tu mamy powtarzalne, opisane procesy. W rozwoju produktów nie da się wszystkiego przewidzieć i zaplanować. Gdy zaczynamy projekt rozwojowy, możemy określić dla niego pewne ramy – co mniej więcej ma powstać i jaki problem trzeba rozwiązać. Można narzucić budżet i termin, ale to nie gwarantuje stworzenia sensownego produktu.

Gdy chcemy mieć wyniki – tworzyć produkty, które mają znaczenie – maksymalizacja wykorzystania zasobów będzie szkodliwa. Jak wpłynie na projekty? Będzie wymuszała pracę kaskadową, w której projekt w kolejnych fazach przechodzi przez analizę, projektowanie, grafikę a potem jest kodowany. Gdy zaczynają się prace programiści rzadko są potrzebni. Ich umiejętności nie są wykorzystywane np. przy ustalaniu potrzeb użytkowników. Dlatego nieefektywne jest „wyjmowanie” na ten czas programisty z innych projektów. W efekcie poznaje on projekt dopiero, gdy przychodzi jego kolej. Nie jest już w niego tak zaangażowany, jak inni członkowie (oby byli).

Samej pracy kaskadowej nie da się zaplacować tak, by projekty gładko, bez przerw, przechodziły od fazy do fazy. Programista ani projektant nie potrafi dokładnie określić kiedy skończy swoje prace. Nie wynika ze złej woli czy braku umiejętności. Oni po prostu za każdym razem robią coś pierwszy raz w życiu. Na dodatek często zmieniają kontekst pracy. Jeśli ktoś robi jedną rzecz przez 20 godzin rozsmarowanych na 3 tygodnie – a tak czasem wygląda praca w takiej organizacji – nie ma szans szans głęboko wejść w temat. Dłużej czeka też na feedback dotyczący tego co wytworzył. Trudniej wtedy wytworzyć coś wartościowego.

Gdy projekt dobiega końca możliwe są dwie sytuacje. Zespół uznaje, że osiągnął wszystko i można zamknąć projekt, albo domaga się tuningu i poprawek w produkcie. Gdy komuś zależy na efekcie, przeważnie ma miejsce to drugie. Spełnienie żądań zespołu – dodanie czasu pracy – powoduje, że inni muszą czekać dłużej. Paradoks polega więc na tym, że im bardziej chcemy być w tym układzie efektywni, tym dłuższe kolejki sobie fundujemy. Zarządzanie wieloma projektami realizowanymi przez określone „zasoby” zawsze kończy się żonglerką i stałą aktualizacją planów.

Jak z tym sobie radzić? Wg autorów HBR zamiast poziomu obłożenia lepiej monitorować czas całkowitej realizacji i długość przestojów. Naturalnym sposobem wydaje się zwiększanie zasobów w wąskich gardłach. Trzeba też kontrolować ilość projektów w toku. W Gazeta.pl ustaliliśmy limit równolegle trwających projektów na 30. Apple radzi sobie z tematem wybierając tylko nieliczne projekty do realizacji. Jak mówił kiedyś Steve Jobs, nie była to nigdy firma, która ma nadmiar zasobów. Kolejny sposób to tworzenie buforów przy planowaniu projektów i dokładanie do planu zasobów „wolnych” slotów. W efekcie od początku wiadomo, że zrobi się mniej projektów jednak szanse na ich powodzenie będą większe. Problemy w mniejszym stopniu występują w firmach, które mają działy realizacyjne bezpośrednio przypisane do produktu. Siłą rzeczy muszą one jednak zatrudniać stosunkowo więcej realizujących.

Wpis jest kontynuacją poprzedniego. Zainspirował mnie artykuł, który można znaleźć na stronach HBR. Dorzucam własne obserwacje. Wkrótce o tym, jakie są przyczyny takiego stanu rzeczy.

Mity na temat rozwoju produktów

Nieporozumienia i błędy związane z rozwojem produktów są dość uniwersalne – problemy znane z branży cyfrowej występują również w inżynierii kosmicznej i branży farmaceutycznej. Świetnie omawiają to autorzy artykułu „Six Myths Of Product Development” opublikowanego w Harvard Business Review. Jakie są ich wnioski?

  • Prace rozwojowe warto dzielić na małe części, realizowane w krótkich cyklach. Dzięki temu łatwiej weryfikować tezy projektowe i reagować w razie niepowodzenia. Po latach porażek z wielkimi projektami wydaje się dziwne jak rzadko się tak robi.
  • Zmiana planu to rzecz nieunikniona i dobra. A nawet: w rozwoju nie da się nic dokładnie zaplanować i wszystkiego przewidzieć. Wybór rozwiązania ustala się dzięki testom i na początku procesu nie można określić, które powinno być wdrożone i ile to zajmie. Autorzy piszą, że w całej swojej historii nie spotkali produktu, co do którego wymagania nie zmieniły się w procesie projektowania.
    Dlatego planowanie to zgadywanie (jeden z podrozdziałów „Rework” ma taki tytuł). Plany warto mieć, ale ze świadomością, że oparte są na fałszywych przesłankach i trzymanie się ich może być przepisem na porażkę.
  • To, że projekt zaczynamy wcześniej, nie oznacza, że wcześniej go skończymy. To ma bezpośredni związek z dostępnością zasobów. Rzecz dotyczy raczej większych organizacji – takich, w których ludzie nie pracują stale nad jednym produktem, tylko realizują różne projekty. Jedna z zasad kanbana mówi, że należy kontrolować ilość prac w toku. Ważna reguła w prowadzeniu projektów natomiast „nie zaczynaj, dopóki nie masz wszystkich zasobów”. Zamiast dbać o to, by projekty ruszały „tak szybko jak się da”, lepiej troszczyć się o to, by całkowity czas trwania – od pierwszego spotkania zespołu do zakończenia poprawek – się skracał.
  • Liczba funkcji nie przekłada się na jakość produktu. Dla zainteresowanych projektowaniem to nic nowego. Dobre produkty robią kluczowe rzeczy bardzo dobrze. Jeden z głównych powodów: mniejsza liczba funkcji pozwala skupić się zespołom na najważniejszych.
  • Sukces rzadko oznacza powodzenie przy pierwszej próbie. Lepiej się pomylić i szybko wyciągnąć wnioski. Przeważnie paraliżuje nas lęk przed porażką. Sięgamy po bezpieczne rozwiązania, które niczego nie zmieniają i nie tworzą wartości.

Polecam lekturę. Artykuł można znaleźć nie tylko na stronach HBR.

Generalizując wnioski: budując organizację, która zajmuje się rozwojem lepiej skupić się na tworzeniu zespołów, które sprawnie eksperymentują i zdolne są do zwrotów, szybkiego wyciągania wniosków i porzucania błędnych tropów. Ważniejsza jest gospodarka odpadami niż tworzenie ambitnych, fikcyjnych planów. Ważniejsza jest realizacja niż pomysły z powerpointa.

Najciekawszy wątek artykułu to jednak teza, że w takiej organizacji dążenie do pełnego wykorzystania zasobów jest błędem. O tym jednak w następnym wpisie.

Co własciciel produktu robi w projektach?

Jak wygląda udział produkt ownera w realizacji projektów? Co takiego trzeba robić, by sprawnie tworzyć i rozwijać produkty cyfrowe? To kolejny wpis o tym zawodzie. Będzie więcej, bo temat jest dość gorący – świadczy o tym choćby ilość dyskusji na serwisie Quora od jakiegoś czasu.

W Google produkt ownerzy zdobywają szlify w dwuletnim programie Associate Product Manager, który przez 10 lat tworzyła i rozwijała Marissa Mayer – dziś szefowa Yahoo! Łatwo znajdziecie strony, na których firma poszukuje kandydatów do tej pracy. Jedna z trzech kluczowych odpowiedzialności tych ludzi to praca w zespołach rozwojowych nad wdrożeniami.

Nie znający tematu mogą mieć problem z rozróżnieniem właściciela produktu od project managera. Choć różne to nazwy, ciągle komuś się to miesza. Może lepiej używać określenia właściciel (owner) a nie manager. Przynajmniej skróty są różne – PO i PM. Google wcale się tym nie przejmuje, ale to nie znaczy, że jego model zadziała wszędzie. Zdarzają się ownerzy, którzy świetnie sobie radzą z zadaniami pma. Jednak PM zawsze powinien być adwokatem projektu – dbać o to, by został zakończony z powodzeniem, w budżecie i o czasie. Te dwa ostatnie elementy PO chętnie będzie poświęcał.

Gdy produkt owner nad czymś pracuje, zdarza się ktoś mówi o nim, że „prowadzi projekt” nawet wtedy, gdy projekt wcale się nie toczy. Tu jest kluczowa różnica – to pm projekty prowadzi i jest aktywny wyłącznie w czasie ich trwania. PO jest przy produkcie zawsze. PM sprawia, by każdy wykonał swoją pracę w zaplanowanym czasie. PO musi się zapewić, by były to właściwe rzeczy.

Jak to robi? Przede wszystkim zna wizję oraz strategię produktu. Wie, dokąd produkt zmierza i jaką drogą najlepiej tam dojść. Potrafi to przekazać ludziom, z którymi współpracuje. Musi zmotywować zespół projektowy w dążeniu do celu i sprawić, by jego członkowie rozumieli po co projekty są realizowane i co jest w nich ważne. Można działać bez tego, ale ludzie o wiele lepiej pracują, gdy wiedzą jaki jest cel.

Wizja to bardzo szerokie spojrzenie na produkt. Ona daje ramy działania. To co w danym momencie ważne – to priorytety. Produkt owner wie, co i w jakiej kolejności chce osiągnąć. Potrafi wybrać zmiany, które przyniosą mu największe korzyści (finansowe, rynkowe) w stosunku do poniesionych kosztów. Rezygnuje przy tym z 99 proc. pomysłów na rozwój, które się pojawiają. To typowe, że pomysłów zawsze jest więcej. Produkt owner zna je i wie dlaczego je odrzucił.

Między innymi dzięki takiemu podejściu PO dostarcza kolejne wersje produktu na rynek. Dopiero wdrażając sprawdza czy jego idee i teorie wypracowane np. z projektantami trafiają do użytkowników. Im częściej to robi, tym szybciej się uczy i mniej marnuje wysiłku. Realizując szuka prostych rozwiązań dla złożonych problemów. Rozwój produktów cyfrowych to nie służba w armii, nie trzeba myć sal gimnastycznych za pomocą sznurówek. Nie ilość wysiłku ma znaczenie, tylko efekt – dla użytkowników i dla biznesu. Efektywność i spryt to konieczność.

Inspiracje: wpis na blogu Michael Karnjanaprakorna, materiały o programie APM Google, wypowiedzi PO na Quora, lata praktyki i prac terenowych.

Nowy zawód: właściciel produktu

Oto nowy zawód: właściciel produktu cyfrowego. Coraz częściej w firmach potrzebne są osoby, które rozumiejąc rynek i użytkowników sprawnie poruszają się na styku biznesu i technologii. Ich głównym zadaniem jest podejmowanie decyzji związanych z rozwojem.

Właściciel musi wiedzieć co najbardziej dolega produktowi i czego brakuje jego użytkownikom. Powinien ich i produkt znać na wylot. Rozumieć każdy aspekt jego działania, rozumieć jak funkcjonuje obsługująca go technologia, ale też jakie procesy są z nim związane – co i jak robią pracujący przy nim ludzie. Musi też wiedzieć z czym produkt najmocniej odstaje od konkurencji (co nie znaczy, że tę konkurencję ma gonić).

W branży cyfrowej nie ma produktów skończonych. Zawsze są jakieś rzeczy do poprawienia lub zbudowania. Dynamicznie zmienia się oferta konkurencji i technologia. Inspiracji do rozwoju nie brakuje. Niestety realizacja większości dostępnych pomysłów nic zmienia, a za każdym razem zajmuje czas i kosztuje. Rozwój wymaga wyborów: nawet jeśli idzie szybko, to cokolwiek robimy, nie robimy w tym czasie czegoś innego. By osiągać efekt można robić dużo, licząc, że czasem się trafi, albo niewiele, starając się dobrze wybierać.

Praca właściciela produktu to ciągłe podejmowanie decyzji o rozwoju i współpraca z ludźmi w projektach, w których te decyzje są realizowane. To komplikuje się wraz z wielkością organizacji. Złożone, popularne produkty obsługuje często kilka grup osób. Może to być nawet kilkudziesięciu ludzi z kilkoma szefami w strukturze. Zajmują się jego sprzedażą, tworzą zapełniające go treści, komunikują się z użytkownikami. Z drugiej strony, do każdego projektu rozwojowego trzeba zwykle zaangażowac kilku ludzi: programistów, webmastera, projektanta i grafika. Gdyby zebrać wszystkich szefów i ludzi niezbędnych w realizacji, czasem trudno znaleźć dla nich salę. Poza kłopotami logistycznymi, udział tych wszystkich ludzi może powodować paraliż decyzyjny.

Jak z tego wybrnąć? Rozwiązanie to właśnie „product owner” reprezentujący wszystkich zajmujących się produktem. Musi on ich dobrze znać, słuchać i rozumieć. Pracuje z nimi nad wizją i strategią rozwoju. Jej świadomośc pozwala mu ocenić, co jest ważne, które zmiany ją wspierają, a które nie. Jako jedyny przedstawiciel biznesu jest kluczowym członkiem zespołu projektowego.

Idealnie gdy właścicielem jest to sam szef biznesu związanego z produktem. Gdy jednak biznes jest duży – ktoś bezpośrednio raportujący do niego. Produkt owner musi być stale dostępny dla zespołu projektowego. Musi mieć przy tym wiedzę niezbędną do pracy z technologią nad produktami dla ludzi. Musi rozumieć jak użytkownicy korzystają oni z cyfrowej komunikacji (z internetu, komputerów, smartfonów itp.). Nie może nie potrafić dogadać się z programistami. To kluczowa rzecz – dogadać to znaczy umieć zyskać szacunek, potrafić uzyskać kluczowe informacje i wspólnie znaleźć optymalne drogi realizacji celów. Umieć zadawać dobre pytania i prowadzić dialog. Nie korpo-dialog oparty na władzy i hierarchii, ale normalną otwartą rozmowę.