Data końca projektu jest dla freelancera bardzo ważna. To dzień, w którym może świętować swój, bądź co bądź, sukces. To dzień, po którym może zacząć czytać nową książkę. Dzień, po którym wreszcie może pograć na komputerze. W oczekiwaniu na zapłatę wyjść na browar czy do kina. Albo planować kolejny projekt. Ostatni dzień kawowo-redbullowo-bezsennego maratonu.
Czy wiąże się to z możliwością wykasowania kodu, wycięcia z pamięci ostatnich tygodni, całkowitą wolnością i pełnym relaksem? Niekoniecznie…
Zmiany, zmiany, zmiany…
Mija kilka dni i przychodzi mail od klienta:
“Ej wiesz co, jednak po zastanowieniu chciałbym mieć przycisk OK w kolorze zielonym a przycisk CANCEL w kolorze czerwonym. To dla ciebie na pewno chwila, mógłbyś…?”
Albo:
“Nie wiem co się dzieje, ale gdy pokazywałeś system to wszystko działało tak szybko. Czemu teraz jest wolniej? Zupełnie inaczej się z tego korzysta. Zrób coś z tym.”
Albo:
“Pani Jadzia inaczej wyobrażała sobie raport pokazujący podsumowanie miesięcznej sprzedaży, trzeba to zmienić i dostosować do jej oczekiwań.”
Albo:
“Doszliśmy do wniosku że SQL Server jest jednak dla nas za drogi, mógłbyś raz/dwa zmienić aplikację aby korzystała z jakiejś darmowej bazy? Najlepiej takiej która będzie działała na Linuxie?”
Trochę to wszystko przerysowane, ale na pewno wielu “zleceniobiorców” miało do czynienia z podobną sytuacją.
Jak do tego doszło?
Reakcja na takie zachowanie może być różna. Jak zawsze – “to zależy”.
Wydaje mi się, że odpowiedź na podobną prośbę uwarunkowana jest wszystkimi okolicznościami, które do niej doprowadziły. Czy podczas negocjacji i podpisywania umowy zgodziliście się, że po oddaniu projektu programista nadal będzie wprowadzał modyfikacje? Jak wyglądała współpraca na etapie tworzenia systemu? Czy ktoś go faktycznie testował w warunkach bojowych? Czy ostateczni użytkownicy mieli okazję się z nim zapoznać?
Odpowiedzialnością wykonawcy jest jasne przedstawienie konieczności testowania systemu przez klienta podczas jego powstawania. Sytuacja, w której programista tworzy swoją radosną wizję programu, a weryfikacja zgodności efektu tych prac z oczekiwaniami zleceniodawcy ma miejsce dopiero po oddaniu projektu i faktycznym rozpoczęciu produkcyjnego wykorzystania w codziennym życiu, jest trochę… chora. Klient MUSI wiedzieć, że system może działać inaczej u niego w firmie niż na komputerze programisty. Że powinien sprawdzić to działanie wcześniej niż dopiero po zakończeniu prac. Że jedynie śledzenie na bieżąco procesu powstawania programu może prowadzić do całkowitej satysfakcji. Że podejście “masz tu moje luźne oczekiwania – zrób coś z tym i do zobaczenia za X tygodni” jest… ZŁE. Że powinien interesować się rozwojem zlecenia i poświęcać swój czas na wytyczanie kierunku prac.
A wykonawca MUSI udostępnić mu możliwość takiej weryfikacji (wiem że opis sytuacji brzmi nie-pro, ale w terminy takie jak agile nie zamierzam teraz wchodzić).
I najważniejsze: klient MUSI być świadom tego, że słowa “akceptuję / zatwierdzam” mają ogromne znaczenie. Luźne traktowanie ich jako pustego sposobu na zakończenie spotkania czy automatyczne odpisanie na maila z pytaniem/sugestią najzwyczajniej w świecie dowodzi braku szacunku dla programisty. Podejście “przecież zawsze można zmienić zdanie” uwłacza osobie ślęczącej przed klawiaturą. Owszem, zdanie można zmienić, ale decyzje nie powinny być podejmowane i wdrażane w życie bez uprzedniego, porządnego przemyślenia. I odpowiednich konsultacji, jeśli są konieczne.
I co wtedy?
Jeżeli współpraca przebiegała wzorowo, klient był świadom wagi wszystkich podjętych decyzji, przeprowadzane przez niego testy faktycznie pomogły w podniesieniu jakości końcowego produktu, a mimo to chciałby wprowadzić drobną modyfikację – to jak dla mnie nie ma problemu. Nie będzie to priorytet na zasadzie “za godzinę dostaniesz nową wersję”, ale poświęcenie jednego wieczoru na jakieś niewielkie zmiany traktowałbym jako podziękowanie za udany biznes i potencjalną inwestycję w przyszłe kontakty.
Z drugiej strony mój czas może nie być dla klienta ważny i przez niego szanowany. Akceptowane pomysły mogły być nieprzemyślanymi i nieuzgodnionymi ze wszystkimi zainteresowanymi bzdurami. Wymagania mogły być wielokrotnie modyfikowane, a testowanie traktowane jako obowiązek WYŁĄCZNIE wykonawcy, czyli mój. W takim przypadku przykro mi – twój czas minął, zią! Koniec projektu to koniec projektu, ja byłem opłacony wcześniej.
Czyli, jak widać – w sytuacji nieuregulowanej umową panuje moim zdaniem całkowita dowolność. Po zakończeniu współpracy jedna strona nie może od drugiej niczego wymagać. Wszystko to kwestia dobrej woli.
Bardzo niebezpiecznym zjawiskiem byłoby przeświadczenie osób “zlecających”, że zamówione rozwiązanie ma być dopieszczane przez wykonawcę aż do osiągnięcia 100% satysfakcji niezależnie od procesu jego początkowego tworzenia. Nie może być tak, że po terminie nadchodzi czas na “dostosowanie” projektu do faktycznych potrzeb. Podpisanie umowy na projekt nie czyni programisty “maszynką do kodowania” dostępną dla klienta na czas nieokreślony – aż do momentu gdy program będzie w 100% odpowiadał jego wyobrażeniom.
Przecież wyobrażenia nieuchronnie ewoluują – jest to całkowicie normalna rzecz. Wymagania zawarte w specyfikacji dołączonej do umowy w ogromnej większości przypadków będą nieco (lub znacznie) odbiegać od wymagań istniejących w dniu zakończenia prac. Czy to jednak oznacza, że projekt uznajemy za “zaakceptowany” dopiero w momencie realizacji wszystkich nowych zachcianek? Nie. Nie zapominajmy na co się umawialiśmy. Oczywiście specyfikacja początkowa nie jest żadną świętością i może w moim przekonaniu podlegać modyfikacjom (o tym więcej kiedy indziej), ale trzeba mieć na uwadze, że to oryginalne założenia MUSZĄ być spełnione, a nie te wymyślone w trakcie.
Wszystko to sprowadza się do zrozumienia i zaakceptowania przez klienta prostego faktu, że freelancer musi mieć świadomość: “dzień po zakończeniu aktualnego projektu mogę zabierać się za następny“. Bo inaczej… jak planować pracę?
Błędy i utrzymanie
Co jednak w przypadku, gdy stworzone oprogramowanie najzwyczajniej w świecie nie działa do końca tak jak powinno? Wracamy tu do punktu “testowanie”… Czy podczas prac ktoś w ogóle zainteresował się czy długie godziny spędzone przed komputerem przez programistę przeradzają się w coś godnego uwagi? Czy też może odbiorca softu doszedł do wniosku, że najpierw dostanie gotowy produkt a dopiero potem będzie zgłaszał bugi?
Oczywiście wszystko zależy od umowy pomiędzy stronami, jednak moim zdaniem zleceniobiorca nie powinien być odpowiedzialny za błędy w oprogramowaniu, które zostało zaakceptowane, odebrane i opłacone. Od tego jest proces testowania, aby błędy wychwycić wcześniej. Może zabrzmi to dość impertynencko, ale do czego prowadziłoby oczekiwanie “tworzysz projekt, a następnie odpowiadasz za jego poprawne działanie do końca życia”? Do tego, że każdy z nas nie znałby dnia ani godziny…:).
Coś takiego jak “oprogramowanie bez bugów” NIE ISTNIEJE. Jeśli ktoś się łudzi, że jest inaczej, to niechaj przestanie. Czy powinniśmy być gotowi na każde zawołanie poprawiać błędy w projektach oddanych pół roku temu? Rok temu? Trzy lata temu? Przecież doprowadziłoby to do paradoksalnej sytuacji, w której dla freelancera z każdym kolejnym zleceniem rośnie ryzyko darmowego, potencjalnie czasochłonnego, zaangażowania w proces “babrania się w przeszłości”.
Takie rozumowanie to pomyłka i bardzo ważne jest, aby OBIE strony w pełni rozumiały jego przyczyny i skutki. OBIE strony powinny akceptować konsekwencje wynikającego ze zrezygnowania z takiego podejścia.
Naprawienie błędu, zmiana koloru przycisku czy jakakolwiek inna modyfikacja zakończonego projektu powinna być traktowana jako przysługa wyświadczana zleceniodawcy przez wykonawcę. Klient nie powinien OCZEKIWAĆ, że programista będzie na jego każde skinienie tylko dlatego, że mają za sobą jakąś współpracę. Nie powinien też obrażać się (z braku lepszego słowa) w razie odmowy.
(a teraz analogia, którą właśnie wymyśliłem i która bardzo mi się podoba :) )
Zamieńmy role i wyobraźmy sobie sytuację odwrotną. Wykonawca przychodzi do klienta kilka tygodni/miesięcy po zakończeniu współpracy i mówi “Siema, dobrze nam się współpracowało i mam prośbę – czy mógłbyś mi za ten projekt, co go dla ciebie kiedyś robiłem, dopłacić teraz jeszcze trochę? Bo doszedłem do wniosku że powinienem wziąć za niego więcej. No nie bądź świnia, zgódź się…”
Prawda, że brzmi absurdalnie? Dlaczego więc traktować mniej absurdalnie dokładnie tą samą sytuację… tyle że widzianą oczami programisty?
Gwarancja
Najlepszym wyjściem z przedstawionego tematu jest, jak to zwykle bywa, przewidzenie kłopotów jeszcze ZANIM one nastąpią. Osiągnąć to można poprzez gwarancję udzielaną na końcowy efekt pracy przez jej autora.
Ma to wiele zalet. Po pierwsze, klient dokładnie wie, jakiej reakcji może spodziewać się po wykonawcy zlecenia. Po drugie, klient dokładnie wie, na co zwracać uwagę obserwując proces powstawania systemu. Po trzecie, klient dzięki temu ROZUMIE jak ważne jest słowo “zatwierdzam” – bo widzi, że często nie będzie od tego odwrotu.
Pełna jasność, pełne zrozumienie. Takie podejście zmusza do rozwiązania problemu jeszcze zanim on nastąpi, eliminując potencjalnie bardzo niezręczną sytuację.
Skąd w ogóle pomysł na notkę? Otóż zdarzyło mi się niedawno własnoręcznie napisać taką “klauzulę gwarancyjną” dołączoną do umowy na projekt. Skłoniło mnie to do dalszych rozmyślań na ten temat.
Efekt swojej pracy przedstawiam poniżej, jeśli ktoś ma ochotę skorzystać – proszę bardzo.
“Zleceniobiorca udziela trzymiesięcznej gwarancji na wytworzone oprogramowanie w zakresie:
– wydajności rozwiązania
– poprawności logiki kierującej programem
Poprzez problemy wydajnościowe rozumie się przynajmniej dwukrotnie wydłużenie średniego czasu reakcji programu na wybrane polecenia użytkownika w stosunku do pomiarów wykonanych przy oddaniu i akceptacji projektu przez Zleceniodawcę. Pomiar czasu reakcji oprogramowania na wybrane akcje użytkownika wykonany będzie na oprogramowaniu podłączonym do pełnej, aktualnie używanej przez Klienta bazy danych. Pomiary w momencie oddania projektu i zgłoszenia usterki odbędą się na takim samym komputerze, przy takim samym obciążeniu sprzętu.
Gwarancja nie obejmuje w szczególności:
– wprowadzania udogodnień w interfejsie użytkownika aplikacji – interfejs użytkownika będzie modyfikowany zgodnie z sugestiami podczas implementacji systemu
– modyfikacji logiki działania aplikacji, o ile zaimplementowane rozwiązanie zgodne jest z ustaleniami dołączonymi do umowy w postaci specyfikacji
– modyfikacji utworzonych raportów, o ile zostaną one utworzone zgodnie z informacjami uzyskanymi podczas procesu analizy i implementacji; weryfikacja poprawności raportów powinna odbyć się przed zakończeniem prac nad systemem na podstawie danych historycznych zawartych w produkcyjnej bazie danych Klienta
Zleceniobiorca zobowiązuje się do wyeliminowania zgłoszonej usterki w ciągu 7 dni od stwierdzenia jej zasadności.”
Wiem, że przedstawione tu poglądy mogą negatywnie nastawić do mnie jakąś część potencjalnych klientów. Wiem, że “na zewnątrz” powinno się mówić “spoko spoko, będzie dokładnie jak chcesz, będę pracował aż będziesz zadowolony”. Wiem, że nad konsekwencjami przykrych sytuacji nie powinno się zastanawiać aż do momentu wystąpienia takowych.
Ale z drugiej strony… szanujmy się. Wolę ustalić wszystko na samym początku, wyłożyć karty na stół i ewentualnie stracić klienta jeszcze przed rozpoczęciem projektu, niż brać udział we frustrującym spektaklu przerzucania się wzajemnymi oczekiwaniami w razie jakichś problemów.
Co o tym myślicie? Mam rację, czy może nie powinienem tak pisać? Ktoś ma inne poglądy i inne praktyki? Może jakaś doświadczona dusza napisze o ciekawych przygodach w tym zakresie?
Jak zwykle trafiasz w samo sedno problemu :)
Ja ostatnio mam problem z klientem, który zachowuje się jakbyśmy byli kolegami – "a tu weź mi popraw to, a tu tamto, to przecież drobiazg" i w ten oto sposób z planowanych trzech tygodni zrobił się drugi miesiąc…
Od strony zamawiającego, to nigdy nie zamówiłbym softu bez gwarancji. Wiadomo, że nie może być ona dożywotnia.
Zmiana wymagań, to szeroki temat, o którym (chyba) każdy mógłby mówić długo. Kiedyś było dla mnie zaskakujące, że nieprecyzyjne wymagania dotyczą różnych projektów, niezależnie od ceny, teraz się przyzwyczaiłem ;)
1. Tylko wymagania w umowie powinny interesowac programiste. Jego zadaniem jest doprecyzowac tak umowe, zeby wszystko bylo jasne i nie dalo sie dorzucac dodatkowych funkcjonalnosci w ramach podpisanej wczesniej umowy.
2. Bledy i utrzymanie – w umowie powininie byc punkt mowiacy, ze zleceniobiorca w momencie odbioru programu, akceptuje je takie jakie jest. Jezeli nie wykruje jakiegos bledu w czasie testowania (tez poparte w umowie) to kazda poprawka lezy w gestii programist. Takze to czy bedzie ona platna, czy darmowa.
3. niezly pomysl z ta gwarancja, jednak daje tylna furtke do wrzucania nowych funkcjonalnosci pod pretekstem naprawy istniejacych(naprawa przez ulepszenie).
A swoją drogą jak reagują Twoi Kliencie na koszty platformy MS?
Bądź co bądź koszta są większe niż klasycznego rozwiązania na Linuksie.
PS. Opcja "Powiadom mnie o nowych komentarzach" nie wysyła maili :(
Do tej pory jeszcze nie miałem okazji podpisywać umowy z klientem (bo i "poważnych" klientów było tylko kilku) ale po woli będzie trzeba się do tego przygotować, żeby na starcie można było spokojnie myśleć o planach na przyszłość.
Jak zwykle, bardzo dobry post! :)
"dobry post – powinieneś przedstawiać swoim klientom" – komentarz mojego klienta ;)
@uolot:
No właśnie… jak nie być "kolegą" tylko "partnerem w interesach" a jednocześnie pozostać "nie-chamem"?
@Artur:
O zmianie wymagań planuję napisać w osobnym poście, ale aż ciężko w jakikolwiek sposób usystematyzować myśli na ten temat – więc pewnie trochę to potrwa:).
@klm_:
Nie chcę być jak księżniczka w wielkim zamku obwarowanym umowami. Współpraca oparta tylko i wyłącznie na zapisach prawnych kończy się moim zdaniem w momencie powoływania się na te zapisy… bo wtedy przestaje być współpracą pozwalającą na "dogadanie się".
Nie traktuję też specyfikacji jak cyrografu, który, raz podpisany nie może ulec zmianom. Na dodatkowe sugestie jestem otwarty i rozumiem że w trakcie prac jakaś decyzja podjęta wcześniej może okazać się nieodpowiednia. Kluczowe jest jedynie uświadomienie, że takie podejście nie jest równoznaczne z pozwoleniem na podejmowanie nieprzemyślanych decyzji bo "wszystko można zmienić". Znalezienie złotego środka nie jest łatwe (o ile w ogóle jest możliwe).
W tym co piszesz masz absolutną rację! Moja pierwsza umowa przedłużyła się o kilka miesięcy ponieważ klient/odbiorca podczas procesu implementacji wymyślał sobie coraz to nowe walidacje, zmiany, które szczegółowo nie były ujęte w umowie. Moja rada jest taka – po oddaniu fragmentu (pewnych modułów) i zaakceptowaniu przez odbiorcę, po kłopoczcie się o jakąkolwiek gwarancję zatwierdzenia tejże części, tak ażeby po stokroć do niej nie wracać.
@Grzegorz K:
W małych projektach koszt, jakiekolwiek rozwiązanie nie zostałoby wybrane, i tak będzie mały.
W projektach dużych różnica w kosztach (o ile faktycznie będzie występować) może być prawdopodobnie pominięta w stosunku do skali całego przedsięwzięcia.
Właściwie to nie interesuje mnie koszt "wdrożenia". Ja piszę w .NET i jeśli ktoś mnie "wynajmuje" to decyduje się na .NET. Nie robię stronek zakładów fryzjerskich, gdzie .NET to 200zł miesięcznie a PHP to 0zł miesięcznie, więc różnica w kosztach jest nieskończona:).
Nigdy nie miałem "prawdziwej" rozmowy na temat porównania kosztów MS z kosztem choćby LAMP. A jestem ciekaw jak w projekcie na większą skalę się one przedstawiają.
P.S. Zerknę co jest nie tak…
@Cieszak:
Nie można przeholować w stronę zbytniej "oficjalizacji" (?) stosunków pomiędzy klientem a wykonawcą. Freelancer ma tą zaletę, że jest człowiekiem z krwi i kości, a nie abstrakcyjnym bytem tworzącym oprogramowanie.
@Mirosław Pragłowski:
To git że ktoś "z drugiej strony" jest w stanie się z tym zgodzić :)
@Łukasz K:
No właśnie, to kwestia uświadomienia klientowi że jego niezdecydowanie/złe decyzje/wahania są naprawdę dla programisty ogromnym problemem. To przecież nie jest rynek.
Bardzo dobry post. Z doświadczenia wiem, że czas trwania projektu programistycznego jest zawsze niedoszacowany, więc strony powinny wcześniej w umowie ustalić kto i za co odpowiada. Dobrym zwyczajem jest podzielenie projektu na etapy kończone protokołem odbioru z ewentualną listą usterek lub TODO, dzięki czemu programista może przewidzieć ile jeszcze pracy mu zostało a klient ma gwarancję terminu wykonania pracy.
Sprawdzonym przeze mnie pomysłem który świetnie eliminuje potencjalne problemy z dogadaniem się po zakończeniu projektu jest umowa supportowa. Za określoną miesięczną kwotę autor dopieszcza projekt (zawsze pojawiają się jakieś drobne poprawki) i wszyscy są zadowoleni.
@twk:
Z tym supportem fajny pomysł. Tylko oznaczałoby na samym starcie powiedzenie "moja praca będzie wymagała poprawek, z które będziesz musiał mi dodatkowo płacić przez X miesięcy". Część "świadomych" klientów na to pójdzie – a część nie. Klient może wychodzić z założenia, że od tego jest umowa i termin końcowy, aby po tym terminie mieć to za co zapłacił. I o ile wiem jak jest w rzeczywistości, to z takim podejściem nie mogę się sprzeczać.
Sam napisałeś, że zmiany zawsze będą (to jest zresztą truizm).
To nie twoja praca będzie wymagała poprawek, ale zmiana wymagań klienta będzie wymagała poprawek. Efekt jest ten sam.
Jakoś wszyscy wielcy producenci software nie ukrywają tego że ich praca wymaga poprawek :)
Również jestem freelancerem i nauczyłem się na bolesnych błędach, że dobrze napisana umowa to świętość i warto jest poświęcić nawet tydzień na wybadanie klienta przed napisaniem chociażby jednej linijki kodu dla niego. Z doświadczenia wiem, że polska jest pełna naciągaczy szukających jelenia, który napisze im w ciągu pół roku serwis typu allegro za 5k zł (każdy kto ma trochę oleju w głowie wie że to bzdura). I zazwyczaj gdy taki koleś zobaczy precyzyjną umowę to wymięka i wycofuje się ze współpracy, bo wie że nie udało mu się znaleźć niewolnika, który w nieskończoność będzie spełniał jego zachcianki. Nieco wkurzające; ale mam świadomość, że mi gość nie nabruździ w połowie projektu. Co do poprawiania błędów i gwarancji, to do umowy dołączam aneks opisujący gwarancję i doliczam opłatę jako procent od należności za całości projektu (im większy projekt, tym większe prawdopodobieństwo bug-ów, tym więcej czasu będę musiał spędzić łatając bugi). Freelancerem nie jestem dla zabawy ale żeby zarabiać na utrzymanie, tymczasem większość klientów mało to obchodzi. Mało tego świadomość klientów odnośnie tworzenia oprogramowania komputerowego jest bardzo niska. Wydaje im się, że zamówienie oprogramowania to tak jakby kupić ogórki w warzywniaku. Tymczasem tutaj kupuje się umiejętności intelektualne i doświadczenie programistów, których można określić chirurgami cyber-przestrzeni.
Witam,
Czytam wszystko co zostalo napisane przez Ciebie jak i czytalnikow. Super ze poruszyles ten temat. Super ze opisales jakie miales przygody z klientami. Wg mnie prawda jest taka ze duzo zalezy z kim prowadzimy interesy i jak prowadzimy te interesy. Ja sam jestem freelancerem prowadzacym swoja wlasna firme ale jestem tez i osoba ktora ta prace chce dawac.
Mam teraz pytanie do Wszystkich : Ile chcecie zaplacic za soft ktory ma Wam umilic i uproscic zycie. Najlepiej nic i jak jest za FREE to zaraz trafia do Waszych komputerow (90% osob tak zrobi). Sadze ze z klientami jest tak samo. Chocby niewiem ile mieli kasy (a im wiecej tym gorzej) klient niechce placic za soft i czas spedzony nad jego realizacje. Najlepiej jakby dostla oferte na zespol np 3 osob ktory bedzie za darmo pracowac przez rok a po zakonczeniu projektu klient oceni czy program mu sie podoba i ewentualnie zaplaci :)
I tutaj pojawia sie cos co nazywa sie menadzerka i dobrym zmyslem do biznesow. Wg mnie jezeli odpowiednio uargumentuje sie klientowi (nie sam program) ale caly proces ktory sie wokol niego toczy i wciagnie sie go do niego to gwarantuje ze klient predzej czy pozniej bedzie placic kazde pieniadze. Wg mnie zastosowanie scrum jest tutaj pomocne. Zasypuje sie wtedy klient nowymi wersjami programu i klient odrazu reaguje. Niema nieporozumien i gwarancji na X miesiecy po oddaniu softu. Kiedy klient zglosi jakies poprawki po projekcie to najpierw 2 razy sie zastanowi zanim podwazy cos co zostalo zrobione. Jezeli nie bedzie mial uwag na koncu to nie widze przeszkod aby nie dawac nawet rocznej gwarancji poniewaz wg mojego stanu wiedzy klient bedzie wtedy zglaszac nowe rzeczy do realizaci a nie do poprawy. Oczywiscie jezeli zlapiemy dusigrosza i osoby myslaca ze pracujemy zadarmo (np po miesiacu projektu) to juz nasz problem ze wogole wzielismy ten projekt.
salut … Janet
Ja stosuję metodę podobną jak twk (jak to nazwał "umowa supportowa") i sprawdza się ona bardzo dobrze. Mało tego, taka umowa przewiduje tylko pewne drobne modyfikacje / usprawnienia, a każde większe wdrożenie jest omawiane osobno. Skutkiem tego klient płaci, szanuje mój czas i również jest zadowolony.