Wycena zadań to temat, który prędzej czy później dotyka każdego, kto pracuje projektowo. Bez względu na to, czy jesteś na etacie czy jesteś freelancerem – zawsze trzeba odpowiedzieć na to samo pytanie: ile to zajmie / ile to będzie warte. I choć nie ma jednego słusznego sposobu, to są pewne zasady, które pozwalają podejść do tego zdrowo.
Na czuja?
Największym błędem przy wycenie jest zgadywanie. Zbyt często „na oko” wydaje się, że coś zajmie kilka godzin, a kończy się kilkoma dniami. Dlatego punktem wyjścia powinna być obserwacja własnej pracy i projektu. Jeśli regularnie logujesz czas, zyskujesz dane, które pozwalają przewidywać z większą precyzją. Po pewnym czasie wiesz, że wdrożenie funkcji w aplikacji zajmuje ci średnio tyle a tyle godzin. To nie tylko lepsze wyceny, ale też spokój, bo nie musisz bazować na przeczuciu.
Czas można logować w systemie, zapisać na kartce, zapamiętać… ważne by wyrobić sobie nawyk patrzenia na zadania i myślenia „ile zajęło mi to ostatnim razem?”.
Ten projekt tak ma
Drugim elementem zdrowego podejścia jest uwzględnianie kontekstu projektu. Samo kodowanie to jedno, ale powinien znaleźć się też czas na zebranie danych, komunikację, poprawki, przerwy czy przełączanie między innymi zadaniami które pojawiają się nagle i „wypychają” Twoje zadanie. Jeśli tego nie wliczasz, zaniżasz wartość swojej pracy. Zamiast zastanawiać się „ile zajmie zrobienie”, lepiej zapytać „ile zajmie doprowadzenie tego do końca”.
W praktyce „doprowadzenie do końca” rzadko oznacza samo wykonanie głównego zadania. Zanim cokolwiek powstanie, trzeba zwykle zrozumieć kontekst – zapoznać się z zadaniem, dopytać o szczegóły, czasem samodzielnie poszukać informacji lub przeanalizować wcześniejsze (podobne) zadania. Potem dochodzi etap testowania lub weryfikacji – sprawdzenie, czy to, co zrobiliśmy, rzeczywiście działa lub ma sens w szerszym kontekście projektu. Często przy tym wychodzą drobne błędy które trzeba poprawić. Do tego dochodzą zadania organizacyjne: wpisanie czasu w Jirze, aktualizacja statusu, komunikacja z zespołem, dopięcie detali przy przekazaniu pracy dalej. To wszystko zajmuje czas. Każdy z tych elementów z osobna wydaje się drobny, ale razem potrafią stanowić istotną część rzeczywistego czasu potrzebnego na wykonanie zadania – i właśnie dlatego powinny być uwzględnione w wycenie.
Starsze i większe projekty mają tendencję do „ogólnego skomplikowania”. Realizacja zadań może rosnąć z czasem, nawet jeśli robimy ciągle to samo. Szczególnie gdy brak w zespole „starych wyjadaczy”.
Szacunek to podstawa
Dobrze też pamiętać, że nie gwarantujesz ale szacujesz – wycena to nie obietnica, tylko prognoza. Zakłada margines błędu i elastyczność. Najczęściej będziesz ją aktualizować w trakcie projektu, jeśli pojawią się nowe informacje. Dzięki temu nie traktujesz wyceny jako wyzwania które trzeba „wygrać”, tylko jak narzędzie do zarządzania pracą.
Zdrowa wycena to taka, która łączy dane z doświadczenia z realistycznym spojrzeniem na kontekst. Nie chodzi o to, żeby robić wycenę pod oczekiwania „klienta” – bo to już będzie cięciem kosztów.
Trzy kroki wyceny
Cały proces można „zautomatyzować”. Szacuj przez porównanie, odhaczaj listy mniejszych elementów a na koniec zabezpiecz wycenę:
1
Porównanie
Wyciągaj wnioski z poprzednich zadań i swojego doświadczenia
2
Checklista
Użyj listy powtarzalnych czynności które wiesz ile zajmą i skomponuj wycenę
3
Narzut
Zawsze dodaj około 30% ekstra na nieprzewidziane problemy
Podsumowanie
Dobrze oszacowane zadanie to takie, które uwzględnia nie tylko samo kodowanie, ale cały proces wokół niej. Im więcej wiesz o tym, jak naprawdę przebiega Twoja praca, tym łatwiej budować wyceny, które są uczciwe – i wobec Ciebie, i wobec zespołu. Zamiast traktować wycenę jako presję, można potraktować ją jako narzędzie znajomości swojej pracy.