Miłe złego początki
Przychodzi baba do lekarza…
Tfu. Przychodzi klient do freelancera. Wręcza całkiem niezłą i dokładną specyfikację.
– Za ile?
– Za tyle.
– Ile czasu?
– Tyle.
– To robimy.
I projekt rusza. Wszystko jest jasne, dograne i wytłumaczone. Zakres prac określono w specyfikacji, ptaszki ćwierkają, freelancer z zapałem uderza w klawiaturę, klient z nie mniejszym zapałem śledzi efekty prac i wysyła na konto kolejne transze wynagrodzenia. Miodem to wszystko i mlekiem płynie.
Nadchodzi jednak czas, gdy do tego miodu dołącza strumyk dziegciu. A do mleka… no, nieważne. W pewnym momencie bowiem klient stwierdza “o cholera, nie przemyślałem tego… jednak chcę inaczej“.
Vonnegut napisałby: “i wtedy właśnie gówno wpadło w szprychy“.
Jeśli jest to jakaś kosmetyczna zmiana to jeszcze pół biedy, kilka minut i klient jest nadal happy. Gorzej, gdy rozchodzi się o całkiem nową funkcjonalność albo wprowadzenie znacznych zmian w opisanych w specyfikacji fragmentach. Oczywiście będą to fragmenty już zaimplementowane, bo klient dopiero wtedy zobaczy że coś nie jest tak jak planował.
Co wtedy?
Wiadomo o co się rozchodzi: o kasę. Jeżeli uzgodniono rozliczenie godzinowe to problemu nie ma żadnego – za każdą taką zmianę klient dodatkowo płaci, ponieważ niesie to za sobą czas spędzony przy komputerze. A co za tym idzie – każdą taką zmianę wielokrotnie przemyśli. Gorzej gdy z góry, na podstawie specyfikacji, ustalono budżet.
Kluczem do udanej współpracy jest uświadomienie sobie przez klienta, że umowa zawarta z wykonawcą ma tak naprawdę bardzo sztywne granice. Za z góry określoną kwotę programista realizuje z góry ustaloną funkcjonalność. Pewna ilość waluty zostaje wymieniona na swoją równowartość w kodzie. Tak jak w sklepie jakaś gotówka jest wymieniana na jakiś towar.
Każda zmiana w funkcjonalności, nie niosąca za sobą zmiany w wynagrodzeniu, jest w stu procentach uznaniowa i jej ewentualna realizacja zawsze wynika wyłącznie z dobrej woli wykonawcy.
Gdy klient oczekuje, że każde jego widzimisię zostanie spełnione “bo klient – pan, klient płaci, klient wymaga” czy “bo to przecież mało roboty” to tak, jakby…
Kreatywne analogie
To tak, jakby w mięsnym powiedział “do tych 10 kg mielonej krowy dorzuć mi trzy świńskie ryje, bo to przecież grosze”.
To tak, jakby w kiosku powiedział “do fajek daj mi gratis gazetę bo jest tańsza”.
To tak, jakby na stacji benzynowej powiedział “do tej zatankowanej benzyny dorzuć mi za darmo myjnię, bo przecież tak dużo zatankowałem”.
To tak, jakby w monopolu powiedział “do tych flaszek dorzuć mi gratis kilka browarów, bo one przecież mało kosztują”.
To tak, jakby u mechanika powiedział “naprawiłeś mi samochód, to teraz jeszcze za darmo zmień mi opony”.
To tak, jakby w restauracji powiedział “to rozumiem, że deser gratis?”.
To tak, jakby…
Wreszcie: to dokładnie tak, jakby zleceniobiorca powiedział do klienta “a dorzuć mi jednak jeszcze kilka tysięcy bo to przecież mało pieniędzy”.
I tak dalej, i tak dalej… Niestety, często jest to postrzegane zupełnie inaczej.
Wszystko albo nic
Kiedyś pisałem, że zadowolenie klienta powinno być najwyższym dobrem dla freelancera i to ono jest celem realizacji każdego projektu. Bynajmniej nie zmieniam zdania, jednak należy zdawać sobie sprawę z tego, że to zadowolenie nie może być osiągnięte kosztem wszystkiego innego. Czasem po prostu trzeba powiedzieć dość! Bo bywa tak, że ile zmian byśmy nie zaakceptowali, ciągle pojawiają się kolejne.
Wyobraźmy sobie sytuację, w której freelancer robi to co zawarto specyfikacji, a następnie do wykonanej implementacji wprowadza zmiany za zmianami. Tu jakaś jedna akcja – kilka minut. Tu większa zmiana funkcjonalności – kilka godzin. Tu to, tu tamto. Ale spoko, klient jest zadowolony. Przychodzi jednak wspomniany wyżej moment dość. Freelancer mówi: nie, nie akceptuję więcej zmian bo nigdy tego projektu nie skończę. Można wtedy zaobserwować dziwne zjawisko. Mianowicie wszystkie wcześniejsze ustępstwa i przyjęte uwagi odnośnie zmian w stosunku do oryginalnej specyfikacji są… zapominane. Wykonawca jest be, bo wykonawca nie chce dalej robić więcej niż powinien. A że wcześniej sporo tego zrobił – no to co?
Nasuwa się wniosek dość, niestety, negatywny… Skoro i tak freelancer jest be jeśli w którymkolwiek momencie powie zmianom STOP, to równie dobrze może to zrobić na samym początku. Efekt będzie ten sam, a o ile mniej pracy!
Remedium?
Wydaje mi się, że jest lek na to całe zło, jednak trzeba go zaaplikować na zasadzie szczepionki – zanim pojawią się jeszcze jakiekolwiek objawy. Być może wystarczy podzielić cały projekt na dwa etapy? Chodzi głównie o budżet nań przeznaczony. 70-80% budżetu idzie na pierwszą część projektu, czyli realizację całego silnika, core. Po prostu: spełnienie wymagań zawartych w specyfikacji. Podczas prac i testów klient zbiera swoje uwagi oraz zmiany które chciałby wprowadzić i bezpośrednio po etapie pierwszym – czyli działającej, nazwijmy to, becie – rusza etap drugi, czyli dostosowanie działania systemu do nowych wymagań.
Wilk syty – nikt nie pracuje za darmo. Owca cała – klient ma dokładnie to o chciał. Czy to tak działa? Nie wiem…
Jak zawsze kluczem jest klarowna komunikacja z obu stron i jasne określanie swoich oczekiwań.
Jakie macie doświadczenia w tym temacie? Czy wynalazł ktoś złotą metodę na radzenie sobie z takimi sytuacjami? Jak to u Was wygląda?
