Jeśli świadczysz usługi w ramach IT i nie tylko, zastanów się czy rozliczasz wszystkie swoje działania na rzecz klienta. Czy robisz jakieś prace, które nie są wrzucane na fakturę? Jeśli tak, to dlaczego?! Przeczytaj jak wygląda moje rozliczenie z klientem?
„Klient nasz Pan!”. Znacie to? Ok, ale jako przedsiębiorca też mam rodzinę i obowiązki. Jeśli poświęcam czas dla klienta, to oczekuję zapłaty za każdą godzinę, ba nawet minutę, spędzoną przy zleceniu. Wtedy rodzina cieszy się, że tatuś przyniósł coś zamian, bo go długo nie było. Niby proste, a jednak nie do końca…
Rozliczenie na zmęczenie
Skupię się na usługach IT. Np. zlecenie oprogramowania portalu X. Zgłasza się do Ciebie klient i informuje, że jest zainteresowany. Po czym znika na 2 tygodnie, potem nagle pisze maila z listą 20 pytań, Ty spędzasz po 3h na odpisywaniu i tak parę razy. Trzymasz zasoby w blokach (koszty), odrywasz się od pracy. Same „przyjemności”.
W końcu dochodzi do spotkania i ustalasz, że będziecie pisać specyfikację. Klient traktuje ją jako rodzaj załącznika do umowy (a to także jeden z produktów zlecenia), więc prosi Cię abyście spisali wszystko. Potem czyta i okazuje się, że 90% jest nie tak. Kilka kolejnych spotkań spędzacie na dalszej analizie biznesowej i systemowej. Faktury ni widu ni słychu.
Ruszyliście z implementacją… ufff. Zleceniodawca dzwoni co godzinę i zasypuje Cię nowymi pomysłami. Dopisujesz kolejne zmiany w specyfikacji, a cena jest stała (!).
Jesteś w połowie projektu i okazuje się, że za 50 godzin (z wyłączeniem działań programistycznych), które nad nim spędziłeś, klient Ci nie płaci! Rozliczenie, jego zdaniem, obejmuje wyłącznie twarde artefakty. A robocizna to co? Kafelki same się położą?
Żona i dziecko płaczą i wołają. Wracaj do domu! Nie daj się robić w balona! 😀
Ja od dawna w to nie wchodzę. Chcesz czegoś ode mnie – zapłać. Proste.
„Rozwiązania”
Nie ma gotowych rozwiązań, aby bronić się przed przyzwyczajeniami klientów, którzy chcą abyśmy wiele czynności zlecenia upychali do darmowego worka bez dna. Wiele technik obronnych leży bardziej w psychologii niż w konkretnych metodach. Ale spróbujmy defensywy:
- Gratis na start – żeby nie było, że od razu wyciągamy kasę fiskalną, po rozpoczęciu rozmów z nowym klientem, informujesz go, że w ramach usług konsultacji, na rozruch projektu, dajesz X pierwszych godzin za darmo! „Cenimy Cię więc masz kliencie prezent”, ale po X godzinach jest granica, po której wracamy do zarabiania. Cel działania Twojej firmy jest jasny – dolary. Zamiast milczeć lepiej ustalić zasady już na początku – „nie pracujemy za darmo”.
- Iteracje zamiast fixed price – chodzi o podejście w ramach Agile (szkolenie). Patrzycie na projekt całościowo (zakres), ale rozliczenie robicie np. co miesiąc, gdzie raportujesz ilość poświęconych godzin, które trafiają na fakturę. Po prostu traktujesz swoją firmę jak pracownika, któremu się płaci za konkretny czas pracy. Przedstaw klientowi taki punkt widzenia. Pokaż także zalety Agile, gdzie głównie dotyczą one elastyczności zakresu, który zawsze się w projekcie zmienia. Zmiany to dostosowanie produktu do rynku, a w trakcie rocznego projektu specyfikacja może być już nieaktualna. Wtedy ta możliwość zmian to pewna wolność dla klienta! Uświadom go czy sam chce sobie zakładać „kaganiec” w postaci fixed price? Jeśli tak, to fixed price = fixed scope. Amen.
- Fixed price z „encyklopedią” – jeśli klient koniecznie chce „cenę z kosmosu” za całość (fixed price), skup się na dokładnej specyfikacji. To Twoja umowa, „paragraf po paragrafie”. Wykonanie specyfikacji także dodawaj w rozliczenie (z góry zaplanowane godziny analizy systemowej). Potem idziesz jak po sznureczku. Jeśli klient wrzuca zmiany to bierzesz pieniądze za wszelkie czynności z tym związane (techniczne, komunikacyjne, itd.). Najlepiej obok takiej specyfikacji stworzyć cennik usług dodatkowych.
- Fixed price z widełkami – niektórzy wykonawcy zleceń IT pompują cenę dokładając marginesy, aby mieć zapas na „wybryki” klienta. Nie lubię tego robić. Ale jeśli klient pogania mnie ze specyfikacją (wciąż niedokładna), to ryzyko jakie biorę siebie (w przyszłości praca za 0 zł), to muszę gdzieś je zniwelować. Można również poinformować klienta o marginesach w ramach fixed-price, „bo mogą być zmiany”.
- Raport działań – czasem nawet w podejściu iteracyjnym klient ma wrażenie, że wrzucamy za dużo godzin w rozliczenie. Wtedy warto abyś udostępnił mu raport w Google Docs, gdzie Twój zespół wpisuje codziennie po 2 zdania co robili. Wtedy często klientowi „otwierają się oczy”, że nie śpicie tam po drugiej stronie oraz że projekt to nie samo programowanie (np. praca PM-a w raporcie).
- Umowa „na wojnę” – tej metody najbardziej nie lubię, bo zaczynamy projekt od braku zaufania, a poza tym często taką umowę „procesuje się” (obustronne korygowanie zapisów) po pół roku. Jednak czasami taka umowa + szczegółowa specyfikacja to jedyne rozwiązanie. Zapisy w umowie mogą np. opisywać rozliczenie w razie zmian z zakresie i inne włącznie z karami umownymi.
Uwielbiam klientów Agile
Dlaczego? Minimum dokumentacji, specyfikacji i bólów głowy. Klient „dzierżawi” nasze zasoby i tyle. Tym samym mniej czasu poświęcamy na przeładowaną komunikację. Fakt, że niezbędne jest zaufanie i nierzetelny wykonawca zlecenia może się okazać oszustem w tak lekkim podejściu. Kij ma dwa końce.
W kontekście moich klientów, gdzie głównie pracuję iteracyjnie, staram się pokazywać efektywność, czyli co wykonałem w ramach 1h z raportu. Jeśli klientowi to się podoba powstaje zaufanie, a ja nie mam poczucia, że mój czas poświęcony na projekt kosztuje o zł.