Ucieszył mnie wpis Davida HH, na temat wycen i budżetów w projektach. Radzi on, by wstępny szacunek czasu pracy uznawać za budżet i trzymać się go w czasie realizacji, poświęcając na projekt tylko tyle na ile go wstępnie wyceniliśmy. Na taki pomysł wpadliśmy pod koniec 2012 roku. Nie jest to łatwe, zwłaszcza w dużej organizacji, ale działa – warto się starać.
Osobom, które „tego” nie robiły, trudno się rzecz tłumaczy. Oczekują one zwykle, że ktoś odpowiedzialnie powie ile potrzeba pracy i czasu by stworzyć nową funkcjonalnośc czy usługę. Doświadczeni (w innych obszarach) menedżerowie mogą takie deklaracje uznawać za „nieprofesjonalne”, ale nie ma czegoś takiego jak sensowna wycena w projektcie programistycznym, zwłaszcza, gdy powstaje w nim produkt dla konsumenta. Nie bez powodu jest to jeden z głównych wątków metodyk rozwoju oprogramowania, których jest bez liku.
Dlaczego tak jest? Z wielu powodów, o których już pisałem. Przede wszystkim, w rozwoju praktycznie nie zdarza się, że robimy to samo po raz kolejny. Tylko w takiej sytuacji możnaby – zakładając identyczne zachowanie zespołu i czynników zewnętrznych – powiedzieć ile coś zajmie. Przeważnie to, co wiemy na początku o produkcie jest zbyt ogólne by można było powiedzieć ile zajmie. Wszystkie niejasności znikają z czasem – kiedy już w trakcie realizacji poznajemy co trzeba stworzyć, by osiągnąć konkretne cele. Żeby było trudniej, koszt realizacji każdej ze składowych projektu zależy od wybranego sposobu rozwiązania. Gdy już dobiegamy do mety, zaczynają się mnożyć błędy, których naprawianie wywołuje następne.
Jeśli nie da się powiedzieć na kiedy i za ile, to jak w takim razie podejmować decyzje? Przecież każda zmiana powinna się opłacać – oczekiwane korzyści mają być mniejsze niż koszt realizacji. Tradycyjne podejście do projektów zakłada, żeby robić to dwustopniowo. Najpierw podejmujemy wstępną decyzję, potem robimy dokładne analizy, projekty i wyceny, wtedy podejmujemy decyzję właściwą. To jednak żółwi proces, dobry np. w banku. Tam – przynajmniej teoretycznie – można policzyć ile coś da. W rozwoju produktów tempo musi być znacznie żywsze, a korzyści tak bardzo zależą od reakcji użytkowników, że opowiadanie o nich zwykle ociera się o wróżenie. Dlatego warto przyspieszać weryfikację założeń o kosztach i zyskach.
Proponowane podejście wychodzi od zrozumienia ograniczeń, po czym je wykorzystuje. Nie udajemy już, że wiemy ile coś zajmie, ale nadal staramy się to w miarę dokładnie przewidzieć. Potem, realizując, tak podejmujemy decyzje, żeby się zmieścić w przyjętym budżecie i czasie. Wymaga to ofiar (pozornych), oraz dyscypliny (która zawsze jest trudna). Nic tak nie pomaga w realizacji jak narzucony termin – nie trzeba znać metodyk rozwoju oprogramowania, żeby wiedzieć, że praca zawsze wypełnia cały dostepny czas…