Każdy właściciel firmy chce od projektu IT tych samych dwóch rzeczy: budżetu, na którym można polegać, i pewności że efekt pokryje faktyczne potrzeby, nie wstępne założenia. Tradycyjna wycena zmusza do wyboru. Niepotrzebnie.
Złota zasada, o której się zapomina
Złota zasada każdej inwestycji w firmie: dostać to, czego potrzebujesz, i zmieścić się w budżecie.
Wycena oprogramowania jakimś cudem ją ignoruje – i to podwójnie.
Stawka godzinowa przerzuca ryzyko na Ciebie. Dostajesz szacunki wysiłku, nie gwarancje efektu; gdy projekt się przeciąga – a zwykle tak się kończy – zawsze czeka gotowe techniczne wytłumaczenie. Problem tkwi w samej konstrukcji: im dłużej to trwa, tym więcej zarabia wykonawca.
Stała cena i sztywny zakres to problem odwrotny. Budżet się trzyma, ale każda zmiana oznacza renegocjacje – więc system zaplanowany na ślepo pierwszego dnia jest systemem, z którym zostajesz, nawet gdy praca z nim pokaże, że nie do końca pasuje. A pokaże: nikt, po żadnej stronie, nie przygotuje kompletnej specyfikacji przed startem prac. Nikt nie powinien tego od Ciebie oczekiwać.
Jeden model karze Cię za tempo wykonawcy. Drugi – za to, że się uczysz.
Trzecia droga: budżet według złożoności, nie szczegółów
Oto jak wyceniamy my.
Każda funkcja jest określona przez rezultat biznesowy i złożoność – co musi dać Twojej firmie i mniej więcej jak rozbudowanego rozwiązania to wymaga. Budżet jest przypisany właśnie do tego.
Szczegóły techniczne pozostają otwarte i są dopracowywane w zderzeniu z rzeczywistością. Gdy w połowie prac czegoś się dowiesz – jakiś krok okaże się ważniejszy, niż zakładano, ekran powinien działać inaczej, specyfikacja nie do końca trafnie opisała proces – plan się dostosowuje. Dopóki nie zmienia się złożoność, nie zmienia się cena. Żadnych faktur za zlecenia zmian, żadnych zasadzek w zakresie.
Jedna uczciwa granica, bo to ona uwiarygadnia resztę: jeśli prośba naprawdę zwiększa złożoność – nowy moduł, funkcja, której nikt nie przewidział – mówimy o tym zanim się za nią weźmiemy, i proponujemy skorygowaną cenę i termin. Decydujesz, mając liczby przed sobą. Różnica względem sztywnego zakresu nie polega na tym, że duże zmiany są za darmo; polega na tym, że małe przestają być negocjacjami z nożem na gardle.
Ty już tak prowadzisz swoją firmę
Zlecenie wraca do poprawki. Dostawca spóźnia się o tydzień. Wpada pilne zamówienie. Twój plan zmienia się nieustannie – i radzisz sobie z tym. Nie renegocjujesz każdej umowy z klientem, bo tydzień nie poszedł zgodnie z planem.
Oprogramowanie powinno powstawać z tą samą dyscypliną: plan się dostosowuje, zobowiązanie zostaje.
Czego to wymaga od wykonawcy
To nie jest łatwa droga – dla nas. Wycena według złożoności z góry wymaga wiedzy z doświadczenia, ile rzeczy naprawdę zajmują; przyjmowanie zmian w szczegółach wymaga architektury, która jest na nie gotowa. Wykonawca, który nie potrafi rzetelnie szacować ani budować elastycznie, potrzebuje stawki godzinowej albo sztywnego zakresu – te modele istnieją, by chronić jego, nie Ciebie.
Dlatego ten model wyceny jest nierozerwalnie związany z resztą współpracy: to połowa umowy, w której ryzyko ponosi wykonawca ￫, i naturalne uzupełnienie wyceny powiązanej z wartością biznesową, a nie godzinami ￫.