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?
W przypadku, który znam jest tak, że wspólnie z klientem zatwierdza się wymagania (czasami wykonywany jest prototyp, który ma w tym pomóc), później implementacja, testy u klienta i… najczęściej kolejnym etapem jest wprowadzanie zmian. Część bezpłatnie na zasadzie dobrej woli, a część odpłatnie. W razie jakby co, to zawsze jest specyfikacja wymagań jako dupochron. Płatności są robione transzami, co trochę pomaga programiście.
W takich sytuacjach zawsze jest się ciężko dogadać z klientami. "Zadowalanie" klientów to średnio przyjemna sprawa ;-)
@Teres Prototyp, to faktycznie dobra sprawa – jak klient sie nim wcześniej nie pobawi, to nie wie co chce :-) Ciekawa jest też kwestia samej specyfikacji. Kiedy dostaje jedną stronę w formie tabelki z 3 wierszami na krzyż, gdzie napisane jest "aplikacja ma służyć do…" – i to wszystko.
Całość wydaje mi się całkiem sensowna. Jeżeli klient się zastanowi, to faktycznie powinien być w stanie przyznać, że zawsze bedzie cos co będzie chciał poprawić. Przeznaczając na to budżet na samym początku, klient ma świadomość, że i wykonawca doskonale zdaje sobie sprawę z mechanizmów funkcjonujących w takiej działalności. Klient powinien starać się (paradoks ? :) ) dostarczyć lepszą specyfikację, bo podświadomie dostał sygnał od developera, że nie jest jasna w 100%. Choćbym nie wiem jak sie freelancer tłumaczył, że tak jest zawsze, to klient może mieć ambicje być tym lepszym klientem…. może dzieki temu sam zrobić krok naprzód :)
By radzić sobie z tymi problemami powstała metodologia agile i jej manifest wyrażający cztery podstawowe wartości:
•ludzie i ich wzajemne oddziaływania ponad procesy i narzędzia,
•działające oprogramowanie ponad obszerną dokumentację,
•współpraca z klientem ponad negocjowanie kontraktów,
•reakcja na zmianę ponad realizację planu.
A jak to przełożyć na projekty fixed price? Nie ograniczać się do bezrefleksyjnej realizacji specyfikacji tylko razem z klientem zastanawiać się czy tworzone oprogramowanie rzeczywiście rozwiąże jego problem. Trzeba wysilić się i opuścić wygodny fotelik myślenia zadaniowego i spojrzeć na cały projekt z dystansu. Zadawać pytania klientowi, które pozwolą mi nie tylko dowiedzieć się gdzie rozmieścić kontrolki lub jaką strukturę tabel zrobić, ale przede wszystkim zrozumieć PO CO w ogóle jest dana funkcjonalność i jak się ona ma do całego projektu. Układ w którym klient jest ekspertem dziedzinowym, a ja programista wykonuję jego zamysł, często sypie się w zderzeniu z realnym życiem.
A kiedy już rzeczywiście dowiemy się po co i dlaczego to możemy projekt dzielić na małe iteracje i oddawać klientowi poszczególne DZIAŁAJĄCE funkcjonalności, które osobno przetestuje i zatwierdzi.
@Ronin:
Agile agilem, ale sytuacja o której piszesz jest nierealna. Bezrefleksyjna realizacja specyfikacji i wygodny fotelik myślenia zadaniowego wcale nie muszą być obecne w przytoczonym przeze mnie scenariuszu. Nie bez przyczyny napisałem na samym początku dwa kluczowe pytania, na które klient chce znać odpowiedź: "za ile" i "na kiedy". Iteracyjność wymagałaby i płynnego budżetu (bo dopiero przed rozpoczęciem iteracji wiadomo co klient chce, więc dopiero wtedy można to wycenić) i płynnego terminu realizacji (z tej samej przyczyny). Przed rozpoczęciem prac można zadać i milion pytań (i tak zwykle robię), a i tak w trakcie usłyszy się "jednak wolę inaczej". A określenie zarówno finansowe jak i czasowe siłą rzeczy polega na informacjach, które uzyskamy ze specyfikacji oraz dyskusji o niej PRZED faktycznym rozpoczęciem projektu.
To co proponujesz jest niebezpiecznie blisko sytuacji "okej, podpisujemy umowę, a potem w trakcie się zobaczy co tak naprawdę z tego wyjdzie". W ten sposób można się wkopać w niekończący się projekt, bo teoretycznie klient może nie zatwierdzić żadnej iteracji zanim nie będzie dokładnie taka jak sobie wymyśli PODCZAS implementacji systemu.
Edżajl-sredżajl to tylko ładna nazwa na to co się _powinno_ robić z klientem, ale jest to też zobowiązanie obu stron. Niestety żyjemy w warunkach *.pl, gdzie dodatkowo może się zmienić sposób liczenia odsetek, podatku (a akurat tego nie zamknięto w jakąś sprytną strategię). Jak ktoś jest ortodoksem i potrafi żywic się powietrzem to naprawdę doskonała metodologia.
No właśnie, bo: "Tfu. Przychodzi klient do freelancera. Wręcza całkiem niezłą i dokładną specyfikację.". W tym momencie powinno być to uznane za bajkopisarstwo, tak naprawdę praca z klientem zaczyna się od wyduszenia z niego i _siebie_ specyfikacji. I niestety w wielu przypadkach trzeba być ekspertem dziedzinowym, albo umieć się nim stać. Jest to też bardzo zależne od relacji i nie da sie opisać prostą regułą.
@PiotrB:
Niekoniecznie między bajki, zdarzało mi się dostawać zarówno gówniane świstki jako "specyfikację" (o których wspomina Darek), ale widziałem też całkiem porządne analizy, ze szkicami, wypunktowanymi scenariuszami itd. Każdą z nich trzeba oczywiście dopracować i doprecyzować, ale… normalne jest, że jak klient widzi postępy prac to ma kolejne pomysły na nowe funkcjonalności albo na usprawnienie tego co chciał jeszcze kilka miesięcy temu. Żadna, nawet wspólna, analiza tego nie wyeliminuje.
@procent
Agile mówi też, że iteracje powinny być krótkie: 2 tyg. do 1 miesiąca. W trakcie realizacji iteracji zmiany jakie można wprowadzić w opowieściach użytkownika do realizacji, to rezygnacja z nich (aby wyrobić się w czasie). Budżet też się zakłada na pojedynczą iterację. Dlatego jak klient po pierwszej iteracji nie chce nic zaakceptować, to jeszcze nie jest to taki szmat czasu. No ale to tylko teoria
@dooh:
Zakładasz, że klient godzi się na jakiś agile. Ja piszę głównie o doświadczeniach freelancera, projektach kilkumiesięcznych-kilkudziesięciotysięcznych, a nie wielkich wieloletnich przedsięwzięciach realizowanych przez duże korporacje dla dużych klientów. W takim przypadku wątpię aby znalazł się klient akceptujący układ "za miesiąc najwyżej się rozejdziemy", bo za miesiąc to on chce mieć działający w połowie system. A już na pewno taki klient nie zgodzi się na to, że zapłaci freelancerowi za miesiąc pracy po to, żeby potem szukać kogoś innego. Z kolei freelancer przecież nie będzie pracował przez miesiąc za darmo tylko po to, żeby po "pierwszej iteracji" okazało się, że jednak nic z tego.
W zdaniu "Wreszcie: to dokładnie tak, jakby zleceniodawca powiedział do klienta "a dorzuć mi jednak jeszcze kilka tysięcy bo to przecież mało pieniędzy"." chodziło chyba o
chodziło chyba o zleceniobiorcę a nie zleceniodawcę :) To tak gwoli ścisłości :)
A poza tym bardzo dobry wpis, w pełni się zgadzam… Wielokrotnie klienci oczekują, że skoro za projekt płacą grube pieniądze, to należy im się jakaś gratisowa funkcjonalność nieskończony support… Owszem, część rzeczy robi się gratis, aby współpraca mogła w przyszłości przynieść kolejne zlecenia, jednak zawsze trzeba znaleźć granicę :)
Pozdrawiam
to ja dam podpowiedz ….
Freelance jak freelance: na poczatku wszystko tak jak opisales powyzej – wszystko dla klienta.
Moze najwyzszy czas realizowac projekty dla powaznych ludzi za konkretne pieniadze ? Wtedy takich problemow jest o wiele mniej,a gdy sie pojawiaja to wszyscy sa ich swiadomi … Z reszta nie bez powodu jedna z przyczyn porazek wiekszosci projektow jest niekompletna specyfikacja lub brak zaangazowania klienta w projekt wiec Ameryki nei odkryles ;-)
@the:
Faktycznie bez sensu to zdanie, poprawione, dzięki:)
@SzymonS:
A czy przypadkiem nie jest tak, że im większy projekt tym większa odpowiedzialność, tym większa specyfikacja, tym większa ewentualna porażka…?
@SzymonS Czyli powinno być tak: przychodzi klajent ze specyfikacją do dupy (90% moich przypadków), to go wysyłamy na drzewo? Podejście słuszne, ale kasy z tego nie będziesz miał.
aha , no to juz tlumacze …
@procent no im wiekszy projekt tym bardziej prosi sie o to by stworzyc zespol, jest granica i projekt ktoremu sam nie podolasz … Zastanawialem sie nie raz dlaczego nie zbierze sie grupka takich freelancerow jak Ty i nie stworzy wlasnego teamu i miejsca pracy.Mam chyba racje ze nie w kazdym aspekcie projektu czujesz sie tak mocno jak w czystym kodowaniu ? ;) Ciekawszych i bardziej dochodowe projekty same przyjda z czasem – chodzi mi glownie o target :))
@Darek
Tak samo moge spytac dlaczego typowy zawodowy programista bawi sie w analityka.Ohhh w8 – bo jest freelancerem … :)) To po przeczytaniu tematu i Twojego posta dochodze do innego wniosku – specyfikacje robie osobno i dopracowywuje z klientem i za nia tez kasuje pieniadze i w tym czasie wogole nie koduje :)
@SzymonS:
Ano właśnie, inne projekty to inne podejście. Ja na razie piszę typowej "freelancerce".
A czemu nie zbierze się kilku freelancerów… Masz rację że nie w każdym aspekcie czuję się "silny", ale dwóm propozycjom współtworzenia takiej "formacji" odmówiłem, na razie jest mi dobrze tak jak jest.
Co do targetu to też bywa różnie. Moim głównym projektem jest naprawdę DUŻY system callcenter dla zagranicznego klienta. Pracuję nad nim już od dwóch lat, więc jest i budżet i duże ambicje. Większość rzeczy robię tam w pojedynkę, czasami dołącza do mnie kumpel z pomocą. Ale da się robić większe rzeczy także samodzielnie albo w bardzo małych grupach (jak u mnie – 2osobowej). No i masz oczywiście rację, jest to całkowicie inna półka, inny klient, inne myślenie – nie ma kombinowania "jak by tu wydrzeć jak najwięcej za darmo", tylko pełna świadomość swoich decyzji i ich konsekwencje (także finansowe).
Odnośnie drugiej części komentarza – "doprecyzowanie specyfikacji" to etap "analizy biznesowej" i w normalnych warunkach to jest także osobno płatne – przed rozpoczęciem implementacji. Z tym że powtórzę się, że w projektach na mniejszą skalę bardzo trudno o klienta który na takie coś pójdzie, bo on chce płacić za kod a nie za dokumenty i rozgryzanie analizy.
@procent
no i wlasnie o to chodzi i podazaj dokladnie ta sciezka – skupiaj sie na takich projektach i na tym poziomie juz zostan, w "drobne rojekciki" sie juz nie baw :) Twoj call center system to w sumie furtka do naprawde ciekawej przyszlosci w IT.
Odnosnie zespolu to patrze na to z 2 stron
– przykladowo chcialbym miec eksperta od baz danych(programiste) czy kolesia od frontendu w teamie gdy potrzebuje
– na zespol freelancerow patrze jako zespol osob tworzacych scisle okreslone rozwiazana, a udzial kazdej z tych osob jest kluczowy dla projektu.
Ponadto czas to pieniadz i glownie pod takim katem mysle o zespole ;) Z Twojej pracy wynika ze glowny projekt realizujesz powoli na boku a normalnie to zajmujesz sie innymi projekcikami.Jesli daja Ci naprawde duzo czasu i porzadne pieniadze to ok – w przeciwnym wypadku wolalbym miec to za soba.
Świetnym rozwiązaniem, które często proponuje podczas doradzania różnym firmom (zwłaszcza tym mniejszym, pracującym na zasadzie outsourcingu, czy może "freelancingu grupowego" :)) jest używanie scrum. Klient płaci za każdą iterację z góry ustaloną kwotę, a co planowanie ustala się które zadania wchodzą do iteracji – zakładając jakiś limit. Orientacyjny koszt też można oszacować na początku projektu bazując na estymacji poszczególnych zadań i średniej velocity.
Ważnym zapisem w umowie jest to, że poza specyfikacją to wykonawca decyduje o tym, co zrobi, a czego nie, bo to ucina wszelkie domysły na zasadzie "ale jak będzie coś ważnego to się dogadamy". Klient zawsze będzie chciał wywrócić projekt do góry nogami i to jest jedyne poprawne założenie dla naszej pracy. Jeśli w umowie została zapisana stała kwota za cały projekt, można też zapisać stawkę godzinową za zmiany nieprzewidziane specyfikacją tak, żeby zabezpieczyć się na każdą ewentualność.