Co może zrobić programista by lepiej wycenić swoje zadanie – jedna wskazówka
Dzisiejszy wpis dedykuję programistom (i kierownikom projektów, którzy podadzą ten link swojemu zespołowi). Przedstawię w nim pewien tip, który znacząco poprawi jakość wycen zadań programistów, co przełoży się na większą terminowość projektów.
Tworzenie budżetu projektu zazwyczaj powstaje w oparciu o to, co powiedzą programiści. Czyli podstawą bazy ceny projektu, są estymaty dawane przez developerów.
Oczywiście istnieją mechanizmy asekuracyjne podczas wyceny, jak np bufory. Nie zmienia to postaci, rzeczy, że kluczowym elementem dobrej wyceny projektu jest dokładna wycena zadań przez programistów.
Twój pracodawca to twój JEDYNY klient
Przechodząc do sedna, moja wskazówka to… żeby programista był profesjonalny. Wiem, że każdy rozumie to pojęcie inaczej, więc przedstawię Ci co mam na myśli.
W przypadku kiedy firma zaplanuje budżet projektu dla klienta. Taki projekt się opóźni – np programistom wykonanie zadań zajęło 40% więcej czasu niż deklarowali. W takim przypadku firma płaci tą różnicę z „własnej kieszeni”.
Przez bycie profesjonalnym, rozumiem to, że programista traktuje swojego pracodawce tak jakby był jego klientem.
Pisałem już o tym jak kary na programistach za przekroczenie terminów mogą opóźnić twój projekt. Zjawisko nie wyciągania wniosków z opóźnień jest również niebezpieczne (nie mylić z wyciąganiem konsekwencji) bo powoduje sytuację, że zadania są wyceniane „bardzo optymistycznie”.
Jeśli opóźnienie developera nad zadaniem nie poddawane jest żadnym refleksjom, to można wyciągnąć wniosek, że terminowość nie jest istotna. Poruszałem ten temat głębiej w wpisie Co ma wspólnego developer z psem Pawłowa?
Programiści wtedy wyceniają zadania bez głębszej analizy – bo właściwie nie ma znaczenia czy się pomylą.
Podejście, które sugeruję programistom to zmiana sposobu myślenia o wycenianiu. Należy podejść do tego tak, jakby za opóźnienie zadania miał zapłacić z własnej kieszeni.
Nikt z nas nie lubi ponosić konsekwencji, więc w takim przypadku programista przykuwał by większą uwagę do analizy zadania przed jego wyceną. Być może narysowałby sobie kilka diagramów by lepiej zrozumieć zadanie, zadałby więcej pytań odnośnie zakresu.
W każdym razie podjąłby kroki w celu dokładniejszej wyceny bo rozumiałby, że za konsekwencje zapłaci z własnej kieszeni.
Takie podejście często „z defaultu” mają programiści, którzy działają trochę szerzej (więcej niż jeden pracodawca). Mają np kilku klientów, z którymi rozliczają się w sposób projektowy. Doskonale rozumieją jak istotne jest dowożenie na czas.
Rekomenduję takie podejście „bycia profesjonalnym” i traktowaniu swojego pracodawce jakby były między wami relacje firma-klient. Wbrew pozorom nawet będąc na umowę o pracę działasz nieświadomie w takiej formule, bo twój pracodawca to twój jedyny klient.
Pssst… mam dla Ciebie prezent 🙂
Wyciągaj wnioski, nie konsekwencje – retrospektywa projektów
Jeżeli jesteś kierownikiem projektu i zastanawiasz się jak możesz poprawić nastawienie programistów w swoim zespole do wycen. To proponuję byś zaczął robić retrospektywę projektów, w której zastanawialibyście się skąd wynika dane opóźnienie.
Znaleźć konkretną przyczynę, która funkcja projektowa nie spełniła swojego zadania tak jak powinno. Wbrew pozorom bardzo często wina za opóźnienia nie leży w programistach tylko w zarządzaniu programistami.
Musisz pamiętać też, że jest cienka granica pomiędzy wyciąganiem wniosków podczas retrospekcji projektów, a wyciąganiem konsekwencji.
Wyciągnięte wnioski możesz ubierać w procedury, którymi programiści będą mogli posługiwać się podczas wycen. Chodzi o stworzenie pewnego standardu jakości wycen.
Bardzo często retrospekcja nad wycenami kończy się poprawieniem sposobu pracy na przykład u analityków (tworzą w inny sposób dokument, bardziej zrozumiały do wyceny dla programistów) i kierowników projektów (w lepszy sposób zarządzają przepływem informacji projektowych żeby można było dokładniej wycenić zadania).
Generalnie jest to temat rzeka, którego nie sposób opisać na blogu. Dlatego chcę cię odesłać z tego miejsca do mojego kursu Dokładna Wycena Projektów IT – wycenaprojektow.pl, gdzie poruszam to i wiele innych zagadnień.
Podsumowanie
Podsumowując, programista powinien mieć podejście do wycen takie, jakby za opóźnienia miał zapłacić z własnej kieszeni. Po opóźnieniu zadań należy przeprowadzać retrospekcję projektową żeby móc wyciągnąć wnioski z opóźnień i znaleźć przyczynę. Należy uważać, żeby zamiast wniosków nie wyciągnąć konsekwencji za opóźnienia zadań. Taka retrospekcja nad opóźnionymi zadaniami pomoże Ci wyciągnąć wiele cennych uwag dla twojego ekosystemu projektowego.
Być może programiści wyceniają niedokładnie zadania ponieważ analiza przedwykonawcza jest napisana niezrozumiale, być może kierownik projektu nie zapewnia odpowiedniego przepływu informacji itp, itd.
W każdym bardzo podoba mi się podejście linii lotniczych, które z każdej katastrofy wyciągają wnioski, które są ubierane w procedury zabezpieczające przed ponownym wystąpieniem problemu – staraj się robić podobnie.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
