Autorem niniejszego artykułu jest Bernard Łabno, który zezwolił na prezentację artykułu w obecnej formie – sam artykuł jest jego odpowiedzią na wpis No początku jest najtrudniej – umowa między stronami. Od siebie dodałem komentarze, aby na bieżąco odpowiedzieć na zadane pytania.

Great! Dzięki za ten artykuł. Dla mnie najciekawszy jest punkt “7. Wadliwe wykonanie dzieła”. To by trzeba było szerzej opisać. Proponuję zebrać listę case’ów.
1. W dniu oddania aplikacji, klient odmawia przyjęcia dzieła bo stwierdza, że na kalendarzu wydarzeń brak filtrowania po atrybucie X. W specyfikacji było napisane, że ma być filtrowanie kalendarza. Programista wykonał filtrowanie tylko po atrybucie Y.

Darek: Ja bym w takim przypadku zrobił to filtrowanie – to raczej nie jest jakaś duża zmiana funkcjonalna i tutaj poszedł bym na rękę klienta, ale tak żeby miał świadomość że nie musiałem tego robić. Czyli w stylu „w specyfikacji nie było, ale w ramach wyjątku…”.

2. Właściciel biznesowy projektu, który odbiera projekt odsyła programistę na etapie analizy do pani Basi na recepcji, a przy odbiorze aplikacji stwierdza, że coś jest nie tak.

Darek: Standardowa zagrywka, dlatego od pewnego czasu w umowie mam klauzulę z kim będę się kontaktować we wszystkich sprawach związanych z projektem. I informuję Klienta że może to być tylko jedna osoba w danej chwili, a jej decyzje są wiążące. Czyli np. pani Basia mówi że jest fajnie, możemy kontynuować prace, a dwa dni później dzwoni prezes z uwagami, to go uświadamiam że jego uwagi możemy uwzględnić jako osobne zlecenie (oczywiście, jeżeli są to jakieś pierdółki, to takie rzeczy się robi od ręki).

Fajnie byłoby gdybyście podzielili się tym jak u was przebiega realistyczny projekt.
Ja napiszę swoje wyobrażenia, bo do tej pory wykonałem tylko kilka projektów i niestety na wariata, na szczęście klienci się nie czepiali na koniec.
Ostatnio jednak spotkałem się z paroma potencjalnymi, klientami, którzy ewidentnie chcą przyoszczędzić lub szukają frajera
i z takimi trzeba się mieć na baczności. (Wielu wymiataczy, twierdzi, że brzydkie kaczątka trzeba odrzucać, ale czasem zdarza się klient, który przyniesie ci renomę jak projekt się uda,
ale w między czasie będzie starał się ciebie wydoić).

W szkole uczy się, że najpierw jest faza strategiczna (to sprawa klienta), potem analiza, projektowanie, implementacja, testy i wdrożenie.
Jako newbie wydaje mi się, że muszę znać dokładne wymagania, zanim wycenię projekt.
Problem w tym, że żaden klient nie siądzie ze mną na 5 godzin dyskusji na dzień dobry przed wyceną (to i tak mało jak na analizę moim zdaniem).
Zwykle klient daje ogólnikowe wymagania: są użytkownicy, redaktorzy, ma być sklep, raporty, newsletter, itd. i oczekuje natychmiastowego podania widełek cenowych.
Nawet jeśli da mi kilka dni na przygotowanie kosztorysu, to sorry, ale sklep sklepowi nie równy i o co chodzi z tymi raportami, ma być jeden, czy 20, zahardkodowane, czy dynamicznie
definiowane?

Darek: Klient MUSI znaleźć czas na omówienie szczegółów projektu. A Ty powinieneś mu uświadomić że projekt trzeba omówić dla dobra Klienta. Bo na przykład, czy kupując samochód też idzie do pierwszego lepszego salonu i mówi „chcę samochód – ma jeździć i mieć czerwony lakier. Dziękuję.” A dwa dni później stawiają mu pod domem czerwonego rzęcha. Przecież w normalnym życiu taka sytuacja jest absurdalna – ale Twój klient właśnie tego oczekuje. Bo widocznie nie rozumie konsekwencji takiego działania.

Wczoraj rozmawiałem z kolegą, który stwierdził, że podchodzę do sprawy ze złej strony. Ja mam przygotować ofertę, która będzie zawierać wymienione elementy,
ale z moimi założeniami co do szczegółowości. To już łatwiej. Sztuka tylko na wstrzeleniu się w poziom skomplikowania funkcjonalności oczekiwany przez klienta.
Poza tym podajemy widełki, a więc trzeba opracować kilka wariantów rozbudowania aplikacji. Zatem większa robota. Zwłaszcza w przypadku zamówienia
niestandardowego – taki system szyty na miarę. Wydaje mi się, że trzeba mieć bardzo duże doświadczenie, żeby dobrze szacować
pracochłonność różnych wariantów złożoności. Z mojego doświadczenia wynika, że niewielkie zmiany w regułach biznesowych, mogą powodować
wielkie zmiany w strukturze (np. encje) i ilości funkcji do oprogramowania.

Co do przygotowania oferty – oczywiście że Ty powinieneś przygotować ofertę. Ale ofertę sporządza się biorąc pod uwagę to czego oczekuje Klient. Jeżeli sam klient nie wie czego oczekuje, to jak można sporządzić ofertę? Z Twojego opisu wynika, że masz na myśli nie ofertę, ale przygotowanie analizy potrzeb serwisu. To jest ten moment, kiedy klient mówi „chcę stronę”, a Ty mu przygotowujesz zarys tego co fizycznie powinno na takiej stronie być. A za coś takiego firmy kasują grube pieniądze. I powiem to jeszcze raz – to nie jest część stworzenia oferty dla Klienta. Oferta jest wtedy, kiedy Klient wie czego chce a Ty mu mówisz ile to będzie kosztowało.

To co radzi Ci kolega to pomyłka. Wyślesz taką szczegółową „ofertę” (to już bardziej analiza potrzeb niż oferta) do Klienta, a on roześle ją ze swoim nazwiskiem jako zapytanie ofertowe do innych firm. I wybierze wtedy najtańszą firmę. A Ty stracisz cały czas który poświęciłeś na przygotowanie tej „oferty”. Siedziałeś z Klientem, dyskutowaliście, sprawdzaliście wszystkie opcje. I co? Nawet „dziękuję” nie usłyszysz za te kilka dni pracy.

Zatem na pierwszym spotkaniu, klient roztacza swoje wizje. Po spotkaniu wykonawca opracowuje kilka wariantów wykonania i widły cenowe.
Na następnym spotkaniu załóżmy, że klient się wstępnie zgadza, co teraz? Chyba czas na szczegółową analizę.
No ale dla custom’owej aplikacji, albo czegoś większego niż sklepik, czy obsługa lodówki trzeba poświęcić na nią dużo czasu.
Jeśli mamy się skonsultować z 3 pracownikami, którzy będą używać tego systemu i mają przedstawić procesy zachodzące w firmie,
które aplikacja będzie wspierać, to możemy się bujać kilka dni, nawet 2 tygodnie, bo przecież nie każdy ma zawsze czas, by udać się do pokoju zwierzeń.
Co? 2 tygodnie? No to chyba nie za darmo? Zatem wydaje mi się, że przydały by się w takim razie 2 umowy – jedna na wykonanie analizy, a druga na wykonanie projektu.
Bo co jeśli klient powie po analizie, że jednak go nie stać, na to co by chciał, a cokolwiek mniej go nie interesuje?
Jeśli sugerujecie jedną umowę, to jak w niej konkretnie napisać, że klient ma zapłacić tyle a tyle za to co jest zrobione? Trzeba by wtedy w umowie zawrzeć kosztorys
poszczególnych części, ale jak to zrobić przed analizą? Błędne koło.

Darek: Znowu masz rację – w takim przypadku, kiedy przewidujesz że rozmowy o stronie będą trwać więcej niż parę godzin, to obowiązkowo trzeba skasować klienta za konsultacje. I powinno to wyglądać na takiej zasadzie: tyle a tyle bierzesz za godzinę konsultacji, a na zakończenie przedstawiasz raport, czy np. listę funkcjonalności jakie mają się znaleźć w końcowym projekcie. I żeby klient miał świadomość, że z takim raportem może iść do innej firmy która mu na tej podstawie wykona stronę. Oczywiście na 90% nigdzie nie pójdzie, ale Ty chcesz być z nim uczciwy i stawiasz sprawę jasno.

Dobra, jedziemy dalej. Było pierwsze spotkanie, nasza propozycja, analiza. Jest kolejne spotkanie i przedstawiamy dokładny kosztorys i analizę.
Klient, na 99% mówi “Ah, mein Gott! Za drogo! I tak dużo tej dokumentacji?”- strach w oczach, gdy kładziesz na stół plik papierów wyszczególniających
przypadki użycia, wymagania funkcjonalne i niefunkcjonalne – “A co jak w tym gąszczu wykonawca pominął jakąś kluczową rzecz? Podstępna bestia!”.
“No, szkice ekranów, obrazki, to rozumiem!”-myśli klient, gdy jeszcze załączyłeś takie coś.
I co teraz? Załóżmy, że się zgodził na jakiś wycinek, bo całość za droga. Aha, jeszcze do każdej dokładnie opisanej funkcjonalności trzeba dopisać cenę, żeby
można było, jakby co, kazać zapłacić za już wykonane części.

Darek: W tym momencie powinieneś już wystawić fakturę / rachunek za analizę. A teraz z tych proponowanych funkcjonalności Klient wybierze sobie te które chce. I przedstawiasz mu wycenę biorąc to pod uwagę.

Teraz klepiemy kolejną umowę, albo ewentualnie załączamy wynik analizy do tej pierwszej.
Teraz ulubiona część greenhorn’ów (w tym mnie), czyli implementacja. Powiedzmy, że jest ten agile i spotykamy się co dwa tygodnie z klientem (projekt trwa 2-3 miesiące).
Na jakie zmiany mu pozwalamy? W połowie implementacji zmiana na modelu (encje) może być wywrotowa. Wszystkie zmiany bierzemy rzecz jasna na piśmie, a z tego co napisał
autor artykułu i tak wyświadczamy klientowi wielką łaskę. Pasowałoby mu to uświadomić, chociażby w grzeczny sposób.
Zmiana kolorków, pixel w lewo, dziesięć w dół wprowadzamy za darmochę, żeby nie przeciągać struny, co?

Darek: Klientowi pozwalamy na takie zmiany, które nie będą problematyczne. Jeżeli to jest jakaś pierdółka, to robię to od ręki. A pozostałe zmiany do osobnej wyceny. Jeżeli jest to zmiana, która zachwiałaby cały projekt, a oczywiście nic o tym wcześniej nie było mowy – to mówisz że nie da rady wprowadzić zmiany na tym etapie i dziękuję. I jeszcze przykład z życia: budowniczy stawiają dom, kładą dach, a zleceniodawca: „to weźcie mi tu jeszcze walnijcie piwnice”. Da radę? Da, ale to nie będzie zrobione za cukierki. Nawet za tonę cukierków.

W czasie takich agile’owych spotkań w trakcie implementacji miło by było dostać feedback od klienta jak mu testowanie idzie tego co już zrobione.
Powiedzmy, że znów pani Basia z recepcji testowała, bo klient (szef firmy) nie ma na to czasu. Warto by było może w umowie napisać, czyj podpis będzie
wiążący przy zatwierdzaniu testów. Tutaj moglibyśmy wziąć parafkę pani Basi. Tutaj mały kejsik: co jak klient nie chce zatwierdzić testów, bo mu się
nie podoba coś innego niż sama testowana funkcjonalność? Na to chyba już nie ma rady, co? Trafiliśmy na łobuza.

Darek: Klient nie może nie zatwierdzić testów, jeżeli te działają. A to że coś mu się nie podoba – to jest oczywiście kwestia do poprawy, ale najpierw niech odpowie Ci na pytanie: czy wcześniej była o tym mowa? Czy jest to zawarte w założeniach projektowych? Jest? Musisz poprawić Nie ma? To do osobnej wyceny.

No to nadchodzi w końcu Ten dzień. Aplikacja działa, nawet przetestowaliśmy, wow i nawet mamy automatyczne testy jednostkowe i integracyjne zaliczone.
Siadamy z klientem i co? Może powiedzieć “testowała pani Basia i zatwierdziła, więc i ja zatwierdzam”. Bierzemy kasę i na wczasy.
Ale może być rozjazd z wyobrażeniami. “Wolałbym, jakby był jeszcze jeden filtr do tabeli. Nie no, ten raport to inaczej miał wyglądać.” Mniejsza o to co mu nie pasi.
Widać, że drań nie chce zapłacić. Co robimy? To jest dla mnie najciekawsze? Mówimy “w specyfikacji nie ma wyznaczonych szczegółów, jak coś ma działać, to decyzja jak ma działać należy do twórcy, czyli mnie” ?

Powiedzmy, że do klienta to nie trafia. Co teraz? Czytałem, że trzeba mu wysłać wezwanie do zapłaty i rachuneczek + odsetki. Potem ostatnie przed sądne wezwanie do zapłaty i na koniec iść do sądu jeśli to nie pomoże.

Darek: Najpierw spróbować się dogadać. Zapytać czemu nie ma kasy i do kiedy będzie. I postawić sprawę jasno – jak kasy nie będzie, to wtedy będzie kara. Np. dodasz Klienta do KRD – to jest chyba największa kara dla nieuczciwego zleceniodawcy. Żeby wiedział jakie będą konsekwencje tego co zrobi lub nie zrobi. I żeby wiedział że też masz świadomość swoich praw i wiesz jak ich dochodzić. I że jego widzimisię nie stanowi podstawy do uchylania się od zapłaty.

Co wy na to? Jak to u was w praktyce wygląda?

Autorowi dziękuję za ten artykuł, bo napisał go na moją prośbę. Najcenniejsze dla mnie były następujące uwagi:
-przykład istotnej wady (przydałoby się ich dużo więcej)
-”jeżeli w specyfikacji nie ma wyznaczonych szczegółów, jak coś ma działać, to decyzja jak ma działać należy do Ciebie”

Darek: artykuł o którym mowa znajduje się tutaj: No początku jest najtrudniej – umowa między stronami

Coś zostało pominięte? A może masz odmienne zdanie w tym temacie?

Zapraszam do dyskusji. Podziel się swoimi spostrzeżeniami.