Szacowanie czasu projektu

Jak szacować godziny projektu freelancerskiego bez oszukiwania samego siebie

Wiarygodne estymacje powstają z jasno zdefiniowanego rezultatu podzielonego na małe zadania, zakresów dla niepewności i policzenia pracy, której klient nie widzi.

Ilustracja redakcyjna z kartami zadań, przedziałami estymacji, osią czasu projektu i lupą kontroli

Zdefiniuj rezultat, zanim zaczniesz szacować godziny

Nie da się stworzyć obronionej estymacji dla niejasnego hasła typu strona internetowa, kampania, integracja czy redesign. Najpierw opisz obserwowalny rezultat: strony, stany, formaty, integracje, urządzenia, dostarczone treści, proces akceptacji i kryteria odbioru.

Dla każdego rezultatu zapisz krótką definicję gotowe. Jeśli dwie rozsądne osoby mogą się spierać, czy praca jest zakończona, zakres nie jest jeszcze wystarczająco precyzyjny do wyceny czasu. Doprecyzowanie teraz kosztuje mniej niż dyskusja po wyczerpaniu budżetu.

  • Co zostanie dostarczone i w jakim formacie
  • Co klient ma dostarczyć i do kiedy
  • Jakie urządzenia, przeglądarki lub platformy trzeba obsłużyć
  • Ile koncepcji, wariantów i rund poprawek jest w cenie
  • Co jest wyraźnie wyłączone z estymacji

Podziel pracę na fragmenty na tyle małe, aby można je było zakwestionować

Rozbij rezultat na zadania trwające zwykle od jednej do ośmiu godzin. Zadanie zbudować aplikację – 60 godzin ukrywa zbyt wiele założeń. Uwierzytelnianie, stany konta, walidacja formularzy, responsywny layout, analityka i wdrożenie mogą być szacowane osobno.

Oddziel pracę powtarzalną od niepewnej. Strona budowana z istniejącej biblioteki komponentów nie ma takiego samego ryzyka jak nieudokumentowana integracja z zewnętrznym systemem. Połączenie ich w jedną liczbę sprawia, że znana praca finansuje nieznaną.

Dla niepewnych zadań używaj estymacji trzypunktowej

Dla zadania z istotną niepewnością zapisz czas optymistyczny, najbardziej prawdopodobny i pesymistyczny. Praktyczna estymacja ważona to: oczekiwane godziny = (optymistyczne + 4 × najbardziej prawdopodobne + pesymistyczne) ÷ 6.

Załóżmy, że integracja zajmie 4 godziny, jeśli dokumentacja i dostępy są poprawne, 8 godzin w najbardziej prawdopodobnym przypadku i 20 godzin, jeśli API będzie sprawiać problemy. Estymacja ważona wynosi 9,3 godziny. Wzór nie usuwa niepewności; zapobiega jedynie temu, by wariant optymistyczny po cichu stał się oficjalnym planem.

Jeśli scenariusz pesymistyczny rozwaliłby projekt, nie ukrywaj go w procentowym buforze. Zaproponuj płatny discovery, etap godzinowy albo punkt decyzyjny przed zobowiązaniem się do ceny stałej.

Policz ukrytą pracę i zależności po stronie klienta

Czas produkcji to tylko część realizacji. Discovery, spotkania, statusy, przygotowanie plików, analiza feedbacku, testy, dostępność, przekazanie i wdrożenie zużywają czas. Jeśli są wymagane, należą do estymacji.

Zależności potrzebują właściciela i terminu. Czekanie na dostęp lub treść może nie tworzyć godzin rozliczeniowych, ale może przesunąć dostawę i wywołać kosztowne zmiany kontekstu. Zapisz, co dzieje się przy opóźnieniu inputu, zamiast udawać, że harmonogram jest odporny na rzeczywistość.

  • Discovery, research i doprecyzowanie wymagań
  • Zarządzanie projektem i skonsolidowana komunikacja z klientem
  • Przygotowanie treści, migracja lub czyszczenie danych
  • Kontrola jakości, dostępność i testy urządzeń
  • Poprawki w cenie, wdrożenie i przekazanie
  • Koszty bezpośrednie i specjaliści zewnętrzni

Przykład: mała aktualizacja strony

Odświeżenie pięciostronicowej witryny wymaga 4 godzin discovery i struktury, 10 godzin designu, 22 wdrożenia, 8 wprowadzania treści i QA, 5 komunikacji i przekazania oraz 5 na rundę poprawek w cenie. Zdefiniowana praca daje 54 godziny.

Integracja CRM pozostaje niepewna. Estymacja trzypunktowa 4, 8 i 20 godzin daje 9,3 godziny oczekiwane. Dodaj 20% bufora ceny stałej wyłącznie do tej niepewnej części: 1,9 godziny. Plan wynosi około 65 godzin, a nie 54 i nie losowe 70.

Wewnętrznie zachowaj estymację na poziomie zadań. Klientowi przedstaw rezultaty, założenia, poprawki w cenie, cenę i harmonogram. Godziny są dowodem dla twojej decyzji; nie muszą być protokołem dołączanym do każdej oferty.

Zamieniaj każdy zakończony projekt w lepsze dane do estymacji

Mierz rzeczywisty czas w tych samych kategoriach co estymacja. Po realizacji zanotuj źródło różnicy: niejasne wymagania, opóźnienie klienta, techniczna niespodzianka, poprawki lub po prostu zbyt optymistyczna estymacja.

Po kilku projektach zastąp ogólne bufory własnymi przedziałami. Możesz odkryć, że implementacja jest przewidywalna, a przygotowanie treści i akceptacje nie. To cenna dana operacyjna i znacznie bardziej użyteczna niż pytanie internetu, ile powinna trwać strona internetowa.

  • Porównuj godziny szacowane i rzeczywiste per zadanie, nie tylko cały projekt
  • Zapisuj przyczynę każdego istotnego odchylenia
  • Aktualizuj szablony zadań po realizacji
  • Duże estymacje konsultuj z innym specjalistą przed zobowiązaniem

Zamień metodę w realną wycenę

Podziel pracę na zadania, dodaj czas i stawki, a następnie utwórz czytelną wycenę dla klienta.

Otwórz darmowy kalkulator

Najczęstsze pytania

Jaki bufor dodać do estymacji projektu?

Nie ma uniwersalnego procentu. Nazwij niepewne zadania i dodaj czas lub koszt do konkretnych ryzyk. Gdy niepewność dominuje, lepiej zastosować płatny discovery lub rozliczenie godzinowe niż ukrywać ją w dużym buforze.

Co jeśli nie mam danych historycznych?

Zacznij od szczegółowego podziału zadań, stosuj estymacje trzypunktowe dla nieznanej pracy, poproś inną osobę o zakwestionowanie założeń i rozdziel discovery od realizacji, jeśli przedział jest zbyt szeroki.

Czy pokazywać klientowi każdą oszacowaną godzinę?

Nie musi. Szczegóły trzymaj wewnętrznie, a klientowi pokaż jasne rezultaty, założenia, granice, kamienie milowe, cenę i proces zmian.

Wesprzyj 5SOLO