Współpraca z klientem vs. negocjacja umów
Nadszedł czas na kolejne „przykazanie” z manifestu zwinności. W moim odczuciu jest ono najważniejsze ze wszystkich, a jednocześnie najtrudniejsze w realizacji.
Zasada głosi, że zamiast negocjować szczegóły wymagań funkcjonalnych przed podpisaniem kontraktu, lepiej blisko współpracować z klientem przez cały czas realizacji projektu.
Zagrożenia
Koronny argument przeciwników takiego podejścia brzmi:
Jeżeli nie uzgodnimy szczegółowych wymagań przed rozpoczęciem prac nad programem, to klient zawsze będzie mógł powiedzieć, że on chciał inny produkt, że umawialiśmy się na inną kwotę, że dodatkowy wysiłek programistów powinien być wliczony w cenę produktu…
Natomiast po podpisaniu kontraktu zawierającego dokładną specyfikację projektu, zawsze można pokazać klientowi odpowiedni punkt umowy, z którego wynika, że wszystko jest napisane zgodnie z wcześniejszymi ustaleniami.
Zgadzam się – bez dopracowania szczegółów na początku, klient będzie co chwila zmieniał zdanie. Ale będzie je zmieniał niezależnie od formy kontraktu.
Niezwykle problematyczny jest częsty kontakt z firmą klienta – szczególnie, gdy znajduje się w innym mieście. Może się też okazać, że druga strona nie zgadza się na taką formę współpracy.
Nie ma niestety dobrego wyjścia z tej sytuacji. Kontakt telefoniczny czy wideokonferencja nie zastąpią bezpośredniej rozmowy.
Jedynym wyjściem jest taki wybór klienta (przynajmniej pierwszego dla danego produktu) lub taka organizacja pracy, aby częste spotkania były możliwe.
Przykład 1
Pisałem kiedyś program na zamówienie. Przed rozpoczęciem pracy dokładnie omówiłem działanie gotowego produktu. Kilka godzin poświęciłem na zrozumienie wszystkich wymagań klienta, aby mieć pewność, że rezultat mojej pracy będzie zgodny z oczekiwaniami drugiej strony.
Dwa miesiące później okazało się, że absolutnie nie pojąłem idei działania programu. Jest to największa z moich dotychczasowych porażek.
Przykład 2
Kilkanaście lat temu na zlecenie dużej firmy powstał złożony system informatyczny. Od tego czasu co 6–12 miesięcy powstawał nowy kontrakt, zawierający szczegółowe wymagania dotyczące zmian funkcjonalności. Każdy kolejny wymagał większych nakładów pracy niż poprzedni. Nie wiem, czy produkt jest jeszcze rozwijany.
Podsumowanie
Możemy napisać całkowicie nieprzydatny program w 100% zgodny z kontraktem, a następnie spędzić kolejne 2 lata na jego rozwijaniu (czytaj: poprawianiu). Jednak możemy poświęcić o połowę więcej czasu na wytworzenie systemu odpowiadającego oczekiwaniom klienta.
Jedyna trudność polega na przekonaniu klienta do ścisłej współpracy przez kilka tygodni albo i miesięcy. Ale to już nie zależy tylko od nas.
