Dlaczego większość freelancerów nie wyciąga z projektów tyle, ile mogłaby
W trakcie projektu widzisz bardzo dużo. Wiesz, że klient odpowiadał z opóźnieniem, pierwsza wycena była zbyt optymistyczna, trzy godziny zeszły na coś, czego w ogóle nie brałeś pod uwagę, a jeden konkretny etap poszedł wyjątkowo sprawnie. Dopóki projekt trwa, wszystko to jest świeże.
Po zakończeniu szybko jednak wchodzisz w kolejne zlecenie. Po kilku tygodniach zostają ogólne wspomnienia: „ten projekt się nie opłacał”, „następnym razem trzeba lepiej pilnować zakresu”, „tamten klient był fajny”. To za mało, żeby realnie poprawić sposób pracy.
Retrospektywa ma sens wtedy, gdy kończy się decyzją. Nie wystarczy zauważyć, że poprawki trwały za długo. Trzeba ustalić, co zmienisz: liczbę rund poprawek w ofercie, sposób zbierania feedbacku, etap akceptacji albo cenę.
Wniosek bez decyzji jest tylko obserwacją.
Briefstreak
Retrospektywa nie jest raportem z tego, co wydarzyło się w projekcie
Nie chodzi o odtworzenie całej historii współpracy. Nie musisz opisywać każdego maila, spotkania i zadania. Dobra retrospektywa koncentruje się na rzeczach, które mogą zmienić przyszłe decyzje.
- czy projekt był rentowny
- czy zakres był właściwie określony
- gdzie pojawiły się największe odchylenia od planu
- co zabrało więcej czasu, niż zakładałeś
- co poszło wyjątkowo sprawnie
- które ryzyka dało się przewidzieć wcześniej
- jak działała komunikacja z klientem
- czy proces akceptacji był sprawny
- czy klient dostarczał materiały na czas
- jakie elementy procesu warto zmienić przed kolejnym zleceniem
Najpierw sprawdź liczby, zanim zaczniesz oceniać projekt na podstawie odczuć
Projekt może wydawać się udany, bo klient był sympatyczny i nie było konfliktów. Może też wydawać się fatalny, bo ostatni tydzień był nerwowy. Oba odczucia mogą być mylące.
Dlatego warto zacząć od rzeczy mierzalnych. Nawet jeśli nie prowadzisz dokładnego timesheetu, spróbuj odtworzyć najważniejsze dane.
- wartość projektu
- szacowana liczba godzin przed startem
- rzeczywista liczba godzin
- koszty podwykonawców i narzędzi
- liczba rund poprawek
- liczba spotkań
- czas oczekiwania na klienta
- liczba dodatkowych prac poza pierwotnym zakresem
- czas od rozpoczęcia do finalnego odbioru
Przykład: projekt za 8000 zł, który wcale nie był projektem za 8000 zł
Załóżmy, że wyceniłeś stronę internetową na 8000 zł. Zakładałeś 50 godzin pracy, czyli efektywnie około 160 zł za godzinę. Brzmi dobrze.
Po zakończeniu okazuje się jednak, że projekt zajął 82 godziny. Do tego doszło 600 zł za dodatkową usługę podwykonawcy, której nie uwzględniłeś w wycenie.
Realna wartość pozostająca po koszcie zewnętrznym to 7400 zł. Podzielone przez 82 godziny daje około 90 zł za godzinę. To zupełnie inny projekt niż ten, który miałeś w głowie na początku.
Taka analiza nie oznacza automatycznie, że musisz naliczać klientom stawkę godzinową. Pokazuje jedynie, czy cena ryczałtowa była sensowna przy faktycznym nakładzie pracy.
Nie pytaj tylko „czy zarobiłem?”. Sprawdź, gdzie dokładnie uciekła marża
Sama informacja, że projekt był mniej rentowny niż zakładałeś, niewiele zmienia. Najważniejsze pytanie brzmi: dlaczego?
Rozbij nadmiarowy czas na konkretne źródła.
- zbyt niska wycena podstawowego zakresu
- nieprzewidziane problemy techniczne
- zbyt dużo spotkań
- dodatkowe poprawki
- rozszerzenie zakresu bez dopłaty
- brak materiałów po stronie klienta
- wielokrotne wracanie do zaakceptowanych wcześniej decyzji
- zbyt dużo własnego perfekcjonizmu
- brak gotowego procesu albo szablonów
- zadania wykonywane ręcznie, które można było zautomatyzować
Każda z tych przyczyn wymaga innej reakcji. Jeśli problemem była zła estymacja, poprawiasz wyceny. Jeśli nadmiarowe poprawki, zmieniasz zasady feedbacku. Jeśli sam robiłeś dwa razy więcej niż było potrzebne, problem nie leży po stronie klienta.
Oszacowanie kontra rzeczywistość — najważniejsza tabela po projekcie
Jednym z najbardziej użytecznych nawyków jest porównywanie planowanego i faktycznego czasu dla najważniejszych etapów.
- analiza: plan 4 h, rzeczywistość 5 h
- projektowanie: plan 16 h, rzeczywistość 18 h
- wdrożenie: plan 20 h, rzeczywistość 31 h
- poprawki: plan 5 h, rzeczywistość 17 h
- komunikacja i spotkania: plan 5 h, rzeczywistość 11 h
Taka rozpiska od razu pokazuje, gdzie leży problem. Nie musisz więc przy kolejnym projekcie podnosić całej wyceny o 30%. Być może podstawowa realizacja była oszacowana dobrze, a niedoszacowany był wyłącznie etap poprawek i komunikacji.
Sprawdź swoje założenia z początku projektu
Wycena prawie zawsze opiera się na założeniach. Problem zaczyna się wtedy, gdy traktujesz je jak fakty.
Klient dostarczy gotowe treści przed rozpoczęciem wdrożenia.
Przykładowe założenie
W projekcie będzie jedna osoba decyzyjna.
Przykładowe założenie
Integracja będzie możliwa przez dostępne API.
Przykładowe założenie
Po projekcie warto wrócić do takich punktów i sprawdzić, które się potwierdziły. Jeśli jedno nieprawdziwe założenie kosztowało Cię kilkanaście godzin, jest bardzo cenna informacja na przyszłość.
Być może przed kolejną wyceną musisz poprosić o dostęp do dokumentacji API. Być może powinieneś zobaczyć treści przed podaniem ceny. Być może oferta powinna jasno zakładać jedną osobę zbierającą feedback.
Przeanalizuj momenty, w których projekt zaczął odjeżdżać od planu
Rzadko zdarza się, że projekt jednego dnia nagle staje się chaotyczny. Zazwyczaj wcześniej pojawia się kilka małych sygnałów.
Klient dodaje pierwszą rzecz poza zakresem, a Ty robisz ją „na szybko”. Potem pojawia się druga. Akceptacja, która miała trwać dwa dni, zajmuje tydzień. Do projektu dołącza nowa osoba i chce zmienić wcześniej zatwierdzony kierunek.
Retrospektywa powinna odpowiedzieć nie tylko na pytanie „co poszło źle?”, ale też: „w którym momencie mogłem zareagować wcześniej?”.
- Kiedy pojawił się pierwszy element poza zakresem?
- Kiedy zauważyłem, że termin zaczyna być nierealny?
- Czy powiedziałem o tym klientowi od razu?
- Kiedy liczba poprawek zaczęła przekraczać założenia?
- Czy były sygnały, że osoba kontaktowa nie jest faktycznym decydentem?
- Czy problemy techniczne dało się wykryć przed rozpoczęciem prac?
Oddziel problemy projektu od problemów klienta
To ważne, bo po trudnym zleceniu bardzo łatwo dojść do wniosku, że winny był klient. Czasem rzeczywiście był problematyczny. Czasem jednak chaos wynikał z braku procesu po Twojej stronie.
Klient zgłaszał poprawki na Messengerze, e-mailu i telefonicznie. Możesz zapisać: „klient przekazywał feedback w chaosie”. Ale warto też zapytać: czy przed rozpoczęciem projektu ustaliłem jeden kanał zgłaszania poprawek?
Klient wielokrotnie zmieniał zdanie. Czy kolejne etapy były formalnie zatwierdzane? Klient chciał dodatkowe funkcje. Czy miał jasno opisane, co znajduje się w zakresie?
Dobra retrospektywa nie służy do szukania winnego. Ma znaleźć element procesu, który można kontrolować przy następnym zleceniu.
Przeanalizuj komunikację: ile jej było i czy była potrzebna
Komunikacja potrafi być jednym z największych ukrytych kosztów projektu. Szczególnie gdy spotkania nie są uwzględniane w wycenie, bo przecież „to tylko pół godziny”.
Dziesięć półgodzinnych spotkań to pięć godzin samej rozmowy. Dochodzi przygotowanie, przełączanie kontekstu, notatki i późniejsze ustalenia.
- Ile spotkań odbyło się w projekcie?
- Które rzeczywiście wymagały rozmowy?
- Które można było załatwić asynchronicznie?
- Czy każde spotkanie miało agendę i decyzję do podjęcia?
- Czy klient wiedział, kiedy dostanie aktualizację?
- Czy część wiadomości wynikała z tego, że klient nie znał aktualnego statusu?
Jeżeli klient regularnie pytał „jak idzie?”, problemem nie musi być jego niecierpliwość. Być może brakowało prostego rytmu aktualizacji.
Poprawki warto liczyć, nawet jeśli nie rozliczasz ich godzinowo
„Poprawki” są często wrzucane do jednego worka, choć mogą oznaczać zupełnie różne sytuacje.
- poprawienie własnego błędu
- dostosowanie pracy do wcześniej ustalonego kierunku
- zmianę preferencji klienta
- powrót do wcześniej zaakceptowanego elementu
- dodanie nowego wymagania
- naprawę problemu wynikającego z niejasnych ustaleń
W retrospektywie warto rozdzielić te przypadki. Jeśli większość czasu poszła na naprawianie własnych błędów, potrzebujesz lepszej kontroli jakości. Jeśli na nowe pomysły klienta — lepszego zarządzania zakresem. Jeśli na nieporozumienia — lepszego discovery i dokumentowania decyzji.
Nie analizuj tylko problemów. Zapisz też to, co zadziałało wyjątkowo dobrze
Retrospektywa bardzo łatwo zamienia się w listę błędów. To błąd sam w sobie. Jeżeli coś działa dobrze, również warto ustalić dlaczego.
- Klient akceptował projekty bardzo szybko — dlaczego?
- Pierwsza propozycja została przyjęta niemal bez zmian — co pomogło?
- Komunikacja zajmowała wyjątkowo mało czasu — jaki proces zastosowałeś?
- Wdrożenie przebiegło szybciej niż zwykle — czy wykorzystałeś gotowe komponenty?
- Projekt miał wysoką marżę — czy wynikało to z ceny, doświadczenia czy sprawniejszego procesu?
To właśnie w udanych projektach często znajdują się elementy, które warto później standaryzować.
Klient też może być źródłem bardzo wartościowych informacji
Własna retrospektywa pokazuje projekt z jednej strony. Krótki feedback klienta może ujawnić rzeczy, których sam nie zauważyłeś.
Nie musisz wysyłać wielkiej ankiety satysfakcji. Często wystarczą trzy lub cztery pytania.
- Co w naszej współpracy działało najlepiej?
- Czy był moment, w którym coś było dla Ciebie niejasne albo frustrujące?
- Co moglibyśmy zrobić lepiej przy kolejnym projekcie?
- Czy efekt końcowy odpowiada temu, czego oczekiwałeś na początku?
Warto zadawać pytania otwarte. Ocena „9/10” wygląda dobrze w arkuszu, ale niewiele mówi o tym, co konkretnie było dobre.
Nie pytaj klienta o feedback, jeśli nie zamierzasz nic z nim zrobić
To prosty, ale częsty problem. Firma prosi o opinię, klient poświęca czas na odpowiedź, a potem ta odpowiedź trafia do folderu i nic się nie zmienia.
Jeżeli kilku klientów wskazuje, że na początku projektu nie wiedzieli, co będzie działo się dalej, nie potrzebujesz kolejnej ankiety. Potrzebujesz poprawić onboarding albo kickoff.
Jeżeli klienci chwalą regularne podsumowania po każdym etapie, warto upewnić się, że ten element staje się częścią standardowego procesu.
Zidentyfikuj pracę, za którą klient nie zapłacił, bo sam jej nie wyceniłeś
Nie chodzi o to, że klient coś Ci „ukradł”. Chodzi o zadania, które regularnie wykonujesz, ale nie uwzględniasz ich przy planowaniu ceny.
- przygotowanie do spotkań
- notatki i podsumowania
- konfiguracja środowiska
- research
- testowanie
- wdrożenie produkcyjne
- przygotowanie instrukcji dla klienta
- migracja danych
- kontakt z zewnętrznymi dostawcami
- zarządzanie projektem
Jeśli po raz trzeci okazuje się, że wdrożenie i przekazanie projektu zabierają sześć godzin, nie są już nieprzewidywalnym dodatkiem. Są częścią usługi i powinny znaleźć się w kolejnej estymacji.
Sprawdź, czy projekt pasował do Twojego biznesu
Projekt może być rentowny i bezproblemowy, a mimo to niekoniecznie warto powtarzać podobne zlecenia.
Być może wymagał technologii, z którą nie chcesz dalej pracować. Być może klient był z branży, której nie rozumiesz i nie chcesz poznawać. Być może projekt był finansowo dobry, ale zupełnie nie pasował do kierunku, w którym budujesz portfolio.
- Czy chciałbym mieć pięciu podobnych klientów?
- Czy ten typ projektu rozwija kompetencje, które chcę rozwijać?
- Czy mogę wykorzystać zdobyte doświadczenie przy następnych zleceniach?
- Czy podobne projekty da się wykonywać coraz sprawniej?
- Czy chciałbym aktywnie pozyskiwać więcej takich zleceń?
To ważniejsze pytania niż samo „czy klient był zadowolony?”.
Zamień wnioski w zmiany w procesie
To najważniejsza część całej retrospektywy. Po analizie wybierz maksymalnie kilka zmian. Nie twórz listy trzydziestu rzeczy, których już nigdy nie zrobisz.
Dobre wnioski są konkretne.
Następnym razem będę lepiej pilnować zakresu.
Zbyt ogólny wniosek
Od następnego projektu każda nowa funkcja poza ofertą trafia do osobnej wyceny przed rozpoczęciem pracy.
Konkretna zmiana
Muszę lepiej wyceniać.
Zbyt ogólny wniosek
Do estymacji każdego wdrożenia dodaję minimum cztery godziny na testy i przekazanie projektu.
Konkretna zmiana
Jakie rzeczy najczęściej warto poprawiać po retrospektywie
- formularz briefu
- discovery przed wyceną
- strukturę oferty
- sposób szacowania czasu
- minimalny budżet projektu
- zasady poprawek
- liczbę spotkań w cenie
- sposób akceptacji etapów
- harmonogram płatności
- proces onboardingu
- kickoff projektu
- rytuał raportowania postępu
- checklistę przed publikacją
- proces przekazania projektu
Prowadź bazę wniosków, a nie osobne notatki, do których nigdy nie wrócisz
Jedna retrospektywa daje wiedzę o jednym projekcie. Prawdziwa wartość pojawia się wtedy, gdy zaczynasz widzieć wzorce między wieloma realizacjami.
Jeżeli trzy projekty pod rząd przekraczają estymację etapu wdrożenia o 40%, prawdopodobnie problem nie jest przypadkowy. Jeśli przy każdym kliencie większość dodatkowego czasu pochłania feedback, warto zmienić proces jego zbierania.
Możesz prowadzić prostą tabelę, w której po każdym projekcie zapisujesz:
- typ projektu
- wartość
- szacowany czas
- rzeczywisty czas
- największe odchylenie
- główny problem
- najlepszy element procesu
- jedną rzecz do zmiany
- czy chciałbyś realizować podobne projekty ponownie
Po kilkunastu projektach taka baza może być cenniejsza dla Twoich wycen niż dowolny kalkulator znaleziony w internecie, bo opiera się na Twoim realnym sposobie pracy.
Retrospektywa nie musi trwać dwóch godzin
Przy małym zleceniu często wystarczy 15–20 minut. Przy większym projekcie warto poświęcić 30–60 minut i oprzeć się na rzeczywistych danych.
Najważniejsze jest to, żeby robić ją szybko po zakończeniu projektu, kiedy pamiętasz jeszcze szczegóły.
Prosty schemat retrospektywy w 20 minut
- 3 minuty — zapisz wartość projektu, planowany i rzeczywisty czas.
- 4 minuty — wskaż trzy rzeczy, które zadziałały dobrze.
- 4 minuty — wskaż trzy największe problemy lub odchylenia.
- 3 minuty — określ, dlaczego te problemy wystąpiły.
- 3 minuty — sprawdź, które sygnały dało się zauważyć wcześniej.
- 3 minuty — zapisz maksymalnie trzy konkretne zmiany na kolejne projekty.
12 pytań, które warto zadać sobie po każdym większym projekcie
- Czy projekt był faktycznie rentowny?
- Który etap najbardziej przekroczył estymację?
- Co spowodowało największe opóźnienia?
- Czy zakres był wystarczająco precyzyjny?
- Czy zrobiłem coś poza zakresem bez dodatkowej wyceny?
- Czy klient wiedział, czego od niego potrzebuję i kiedy?
- Czy proces akceptacji działał sprawnie?
- Czy komunikacji było za dużo, za mało czy w sam raz?
- Co zrobiłbym inaczej, gdybym rozpoczynał ten sam projekt jutro?
- Co zadziałało tak dobrze, że powinienem wprowadzić to na stałe?
- Czy chciałbym realizować więcej podobnych projektów?
- Jaka jedna zmiana najbardziej poprawi kolejny projekt?
Najczęstszy błąd: wyciąganie złych wniosków z pojedynczego projektu
Jeden trudny klient nie oznacza, że trzeba zmienić cały model współpracy. Jeden projekt, w którym komunikacja zajęła wyjątkowo dużo czasu, nie oznacza, że każdy następny będzie wyglądał tak samo.
Warto odróżniać jednorazowe sytuacje od powtarzających się wzorców. Jeżeli problem wystąpił raz, zapisz go. Jeżeli występuje po raz trzeci, zmień proces.
Nie każda retrospektywa musi kończyć się poprawą efektywności
Czasem najważniejszym wnioskiem jest decyzja biznesowa. Na przykład: nie przyjmuję już projektów poniżej określonej kwoty, nie pracuję z klientami wymagającymi codziennych spotkań albo rezygnuję z usług, które są trudne do skalowania.
Retrospektywa może więc wpływać nie tylko na sposób realizacji, ale również na ofertę, stawki, specjalizację i wybór klientów.
Najlepsza retrospektywa zmienia następny projekt jeszcze przed jego rozpoczęciem
Jeżeli po zakończeniu zlecenia zapiszesz wniosek, a później nigdy do niego nie wrócisz, niewiele się zmieni. Dlatego najważniejsze wnioski powinny trafiać bezpośrednio do procesu.
Jeśli problemem były niejasne materiały — dodaj pytanie do briefu. Jeśli nieznane API rozsadziło estymację — dodaj weryfikację techniczną przed wyceną. Jeśli klient wracał do zatwierdzonych etapów — zmień sposób akceptacji. Jeśli spotkania pochłaniały zbyt dużo czasu — określ ich liczbę już w ofercie.
Wtedy doświadczenie rzeczywiście się kumuluje. Nie dlatego, że zrobiłeś już dwadzieścia projektów, tylko dlatego, że dwudziesty projekt korzysta z wiedzy zdobytej podczas dziewiętnastu poprzednich.
