Zacznę od wyjaśnienia. Nie mam nic przeciwko kierownikom projektów, a przynajmniej większości z nich. Sam byłem jednym przez kilka lat. Jednak zarządzanie projektami stosowane w rozwoju oprogramowania zwykle bardziej szkodzi niż pomaga. A przyczyny tego stanu rzeczy są systemowe a nie ludzkie.
Co to w ogóle jest “projekt”?
Zacznijmy od definicji projektu. Wikipedia angielska mówi:
„Projekt jest tymczasowym przedsięwzięciem mającym na celu wytworzenie unikalnego produktu, usługi lub rezultatu o określonym początku i końcu (zwykle ograniczonym czasowo i często ograniczonym przez finansowanie lub personel), podejmowanym w celu osiągnięcia unikalnych celów i zadań, zazwyczaj aby uzyskać korzystną zmianę lub wartość dodaną.” (https://en.wikipedia.org/wiki/Project_management
Mamy więc jasno określone początek, koniec, cele i zadania. Ile razy widziałeś je podczas tworzenia oprogramowania? Albo, zapytam inaczej – ile razy widziałeś, jak zmieniają się w wyniku nowej wiedzy czy w reakcji na zachowanie otoczenia?
Produkt, a nie projekty
Projekty są ograniczone czasowo. Praca zwykle kończy się wraz z zamknięciem projektu. Dlatego niezwykle ważne jest w nich kontrolowanie trzech wymiarów (czas, budżet i zakres). Nie dotyczy to jednak większości produktów softwarowych, które są rozwijane przez dekadę albo i dłużej. Popatrz na Facebooka, wyszukiwarkę Google czy Booking.com. Są stale modyfikowane, ulepszane i rozszerzane. Nawet przypadku systemów embedded stworzony kod jest wykorzystywany w następnych wersjach produktu. Jestem pewien, że w iPhone X nadal można znaleźć funkcje z pierwszego iPhone. Osobiście widziałem kod, który był starszy ode mnie. Dlatego, dopóki są klienci, dopóty oprogramowanie jest rozwijane.
Siedem grzechów zwinnego zarządzania projektami
Zastosowanie podejścia projektowego do rozwoju produktów ma więc poważne konsekwencje. Poniżej znajdziesz siedem najważniejszych, które zaobserwowałem w różnych firmach.
1. Długi cykl planowania
Kontrolowanie kosztów jest krytyczne w zarządzaniu projektami. Dlatego przed rozpoczęciem prac tłumaczy się cele projektu na szczegółowe wymagania, aby móc oszacować koszty. Zdefiniowanie zakresu, określenie i zatwierdzenie budżetu wymaga oczywiście czasu. Widziałem projekty, w których więcej miesięcy poświęcono na zatwierdzenie planu, niż na wytworzenie i dostarczenie oprogramowania. A jak powiedział Tom DeMarco „Wszystkie projekty, które kończą się za późno, mają jedną wspólną cechę: zaczynają się za późno”.
2. Wiele równoległych projektów
Długi cykl planowania wydłuża czas dostarczania, co powoduje, że firmy prowadzą wiele projektów jednocześnie. Kiedyś odwiedziłem bank, w którym 40-osobowy dział IT był odpowiedzialny za 120 projektów. Generowało to olbrzymie ilości dodatkowej pracy związanej ze skomplikowanym planowaniem, śledzeniem i raportowaniem tych projektów, nie mówiąc już o marnowaniu czasu na przełączanie kontekstu. Wiele projektów prowadzonych równocześnie jeszcze bardziej wydłuża czas ich realizacji i uniemożliwia organizacjom szybką zmianę kierunku, czyli zwinność.
3. Walka o ludzi i zasoby
Wiele równoległych projektów prowadzi do ciągłych walk między managerami odpowiedzialnymi za ich ukończenie, bo starają się zdobyć potrzebnych ludzi i współdzielone zasoby. Ponieważ wszystkie te projekty są bardzo ważne, w wielu organizacjach to programista zdecyduje, na czym się skupić, a co zignorować. W ekstremalnych sytuacjach ludzie są tak zajęci próbą zrobienia wszystkiego naraz, że niczego nie są w stanie ukończyć.
4. Skupienie na zakresie, a nie celu
Zarządzanie projektami koncentruje się na realizacji planu. Każda zmiana zakresu zwiększa więc ryzyko opóźnienia. Nawet w przypadku „zwinnych” podejść dodawanie nowych wymagań jest raczej postrzegane jako zło konieczne niż szansa. Co jest zupełnie sprzeczne z odkrywaniem nowych informacji i możliwości, które chcielibyśmy widzieć w rozwoju produktu. Tutaj celem jest maksymalizacja wartości - planowanie eksperymentów, weryfikacja hipotez, szybkie uzyskanie informacji zwrotnej i ewentualna zmiana kierunku na podstawie nowych danych. Dodawanie nowych pomysłów i usuwanie już zaplanowanych ma więc sens, bo ciągle odkrywamy, czego tak naprawdę potrzebują klienci i jak korzystają z naszego produktu.
5. Wdrażanie niepotrzebnych funkcji
W zarządzaniu projektami nie ma motywacji do kwestionowania z góry zaplanowanego zakresu. Jednak każda funkcjonalność, to tylko hipoteza, że użytkownik jej będzie używał. Dlatego, z punktu widzenia produktu każdy element, z którego nie korzysta użytkownik to gigantyczny koszt. Nie tylko napisania czy przetestowania. Dużo większe wydatki wiążą się z utrzymaniem: testami regresji, naprawą błędów i zwiększoną złożonością generowaną przez niepotrzebną funkcjonalność. A ponieważ produkt będzie żył dekadę albo dłużej, to koszty utrzymania są nieproporcjonalnie większe od kosztów wytworzenia danej funkcjonalności. Dlatego w zarządzaniu produktem nowe funkcjonalności powinny być weryfikowane i usuwane lub modyfikowane, jeżeli okażą się nie przynosić oczekiwanych rezultatów.
6. Obniżanie jakości
Wraz ze zbliżającym się ostatecznym terminem zakończenia projektu pojawia się tendencja do „lekkiego przyciśnięcia”, żeby zdążyć na czas. Większość programistów reaguje na presję obniżając nieco jakość, pomijając refaktoryzację lub testowanie i stosując skomplikowane, ale działające rozwiązania. Z roku na rok takie podejście powoli, ale stale tworzy dług techniczny, co utrudnia rozwój i utrzymanie produktu. Konsekwencje nie wpływają jednak na dany projekt, ponieważ kończy się on, gdy dotrzymany zostanie termin. Odbiją się czkawką dopiero w następnych projektach.
7. Konflikt między Product Ownerem a kierownikami projektu
W firmach próbujących realizować projekty przy użyciu Scruma pojawia naturalny konflikt między Product Ownerem koncentrującym się na wartości biznesowej a kierownikami projektów skupionym na realizacji planu. Jeśli PMowie wygrają, to Product Owner nie ma właściwie władzy nad produktem, czyli nie jest Product Ownerem. Jego rola najczęściej ogranicza się wtedy do porządkowania backlogu. Jeśli natomiast to PO podejmuje decyzje, kierownicy projektów nie mają wprawdzie władzy, ale wciąż ponoszą odpowiedzialność.
Czy jest aż tak źle?
Niektóre z powyższych przykładów mogą wydawać się zbyt ekstremalne. Wiele organizacji dzielnie walczy z konsekwencjami zastosowania podejścia projektowego do rozwoju produktu, zmniejszając negatywny wpływ takich praktyk. Są też organizacje, które muszą korzystać z zarządzania projektami z różnych powodów. Czy jednak na koniec dnia nie byłoby łatwiej, gdybyśmy zrezygnowali z zarządzania projektami w produktach, które go nie potrzebują?
Zwinne zarządzanie produktem
Jakiś czas temu miałem przyjemność opowiadać na spotkaniu grupy Agile Warsaw o konsekwencjach podejścia projektowego, oraz o Agile Product Management, czyli zwinnym zarządzaniu produktowym, jako jego alternatywie. Zapraszam Cię do oglądnięcia nagrania z mojego wystąpienia.
Zainteresował Cię Temat?
Wersja graficzna siedmiu grzechów
Na koniec udostępniam Ci graficzną wersję siedmiu grzechów Agile Project Managementu. Mam nadzieję, że przyda się w trakcie rozmów w Twojej firmie.
