Jak wyznaczyć granice zlecenia, żeby o cenie nie spierać się po fakcie

Spór o cenę zaczyna się na długo przed ostatnią fakturą. Zaczyna się od zdania „przecież to oczywiste”.

Wyobraź sobie zlecenie „ewidencja zamówień”. Strona zamawiająca rozumie pod tym także eksport do księgowości. Strona wykonująca nie. Nikt nie kłamał, po prostu nikt nie napisał o tym ani jednego wiersza. Na końcu jedna strona uważa eksport za oczywistość, a druga za dodatkową pracę.

Takim sporom można w dużej mierze zapobiec. Wystarczy przed rozpoczęciem uzgodnić trzy rzeczy: co jest, a czego nie ma w zakresie, po czym poznać, że jest gotowe, i jak wycenia się zmiany.

Zakres to także lista tego, czego w cenie nie ma

Zwykła oferta mówi, co zostanie zbudowane. Równie ważne jest spisanie, czego budować się nie będzie. To najsilniejsze narzędzie z całego artykułu, bo luki w zleceniu zamieniają się dzięki temu w otwarte pytania.

Na liście rzeczy wyłączonych zwykle znajdują się:

• migracja danych z dotychczasowego systemu,
• ingerencje w systemy sąsiednie,
• strojenie wydajności powyżej uzgodnionej granicy,
• kolejne wersje językowe,
• połączenia z usługami, których nie ma w zleceniu,
• szkolenie użytkowników,
• wsparcie i zmiany po odbiorze.

Nie znaczy to, że tych rzeczy nie chcesz. Być może chcesz i będą w cenie. Chodzi o to, żeby o każdej z nich ktoś zdecydował świadomie.

Potem uzgodnij prostą zasadę: co nie należy do zakresu, jest zmianą i zostaje wycenione z góry. Dzięki temu odpada większość kłótni o to, co miało być oczywiste.

Obok zakresu spisz także założenia. Na przykład „dane dostarcza strona zamawiająca” albo „program księgowy potrafi eksportować do pliku”. Gdy założenie okaże się nieprawdziwe, jest to zmiana, a nie dochodzenie, kto miał to przewidzieć.

Odbiór uzgodniony z góry

Gotowe to nie opinia. To odhaczona lista. Żeby tak było, każda pozycja musi dać się zweryfikować i być uzgodniona, zanim zacznie się praca.

Różnicę widać na tych przykładach ilustracyjnych:

Spisywanie odbioru ma użyteczny efekt uboczny: od razu widać, gdzie zlecenie ma dziury. Gdy nikt nie umie powiedzieć, po czym poznać, że raport jest poprawny, nie jest to wystarczająco określone. Teraz jest to najtańsze miejsce, żeby się o tym przekonać.

Większe zlecenie podziel na mniejsze części z własnym odbiorem. Spór o jedną część rozwiązuje się łatwiej niż spór o całe dzieło. Uzgodnij też termin na zgłoszenie uwag i zasadę, że odmowa musi wskazywać konkretne niespełnione kryterium. Czy milczenie ma oznaczać przyjęcie, niech oceni prawnik lub prawniczka.

Zmiany wycenia się, zanim zostaną wykonane

Zmiana zlecenia nie jest porażką. W trakcie prac często okazuje się, że chcesz czegoś innego. Problemem jest zmiana, której cenę poznajesz dopiero z faktury.

Procedura może być krótka:

1. Zmiana zostaje spisana, wystarczy kilka zdań w e-mailu.
2. Strona wykonująca podaje cenę i wpływ na termin.
3. Ty ją zatwierdzasz albo odrzucasz.
4. Dopiero potem zaczyna się nad nią praca.

Dotyczy to także małych zmian, bo właśnie one niepostrzeżenie się sumują. I obowiązuje obie strony: strona wykonująca nie robi niczego niezatwierdzonego, a strona zamawiająca nie oczekuje, że „jeszcze to” zmieści się w cenie.

To samo dotyczy terminów. Gdy strona wykonująca trzy tygodnie czeka na dostępy albo na twoje uwagi, termin przesuwa się o trzy tygodnie. Uczciwie jest zapisać to z góry.

Dlaczego stała cena na nieotwarty system to zakład

Stała cena to dla strony zamawiającej dobra rzecz. Ryzyko błędnej wyceny ponosi strona wykonująca, nie ty. Działa to jednak tylko wtedy, gdy zakres jest naprawdę ograniczony.

Zlecenie można przeczytać w jedno popołudnie. Starego systemu, do którego ma się podłączyć nowa część, nie. Kryją się w nim nieudokumentowane połączenia, brakujące testy i dane, które nie wyglądają tak, jak powinny. Kto podaje stałą cenę, nie otwierając systemu, zgaduje. Możliwe wyniki są trzy:

• Zgadnie wysoko. Przepłacisz rezerwę na ryzyka, które może w ogóle nie wystąpią.
• Zgadnie nisko. Wtedy zacznie oszczędzać na jakości albo każdy drobiazg wykazywać jako zmianę.
• Trafi. To dobrze, ale to przypadek.

Uczciwa kolejność to dostęp do kodu, potem wycena szacunkowa i dopiero potem cena. Co możesz z tym zrobić:

• Daj stronie wykonującej przed podpisaniem dostęp do kodu, na przykład na podstawie umowy o poufności.
• Zamów najpierw krótki płatny audyt. Kosztuje, ale jest tańszy niż nieudane zlecenie.
• Jeśli dostępu dać nie można, niech strona wykonująca policzy pełną rezerwę albo nie obiecuje stałej ceny wcale.
• Zapytaj, z czego powstała cena i jaką ma rezerwę. Kto system widział, odpowie konkretnie.

Jeśli ktoś podaje stałą cenę po krótkiej rozmowie telefonicznej, nie jest to oznaka pewności siebie. To pytanie o to, kto ten zakład ostatecznie zapłaci.

Zanim podpiszesz

Tak działamy przy oprogramowaniu na zamówienie i przy outsourcingu, gdzie budujemy wyodrębnioną część twojego systemu według twojej specyfikacji.