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?
The post Odpowiedzialność za oddany projekt appeared first on devstyle | Maciej Aniserowicz.