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.