Stała cena, zamknięty zakres: jak prowadzę projekty automatyzacji
Rozliczenie godzinowe premiuje wolną pracę. Dlatego wyceniam efekt, nie godziny — a zakres i cena są znane przed startem i nie zmieniają się w trakcie.
Model godzinowy ma wbudowany konflikt interesów: im dłużej trwa projekt, tym więcej zarabia wykonawca. Klient bierze na siebie całe ryzyko, że coś potrwa trzy razy dłużej, niż ktoś obiecał na pierwszym spotkaniu.
Pracuję odwrotnie.
Najpierw zakres, potem cena
Przed wyceną rozrysowujemy proces: co wchodzi na wejściu, co ma wyjść, gdzie są wyjątki, kto tego używa i jak często. To zwykle jedno lub dwa spotkania plus krótki dokument. Dopiero na tej podstawie powstaje wycena.
Dokument zakresu jest prosty i po ludzku napisany — ma go zrozumieć osoba, która będzie z narzędzia korzystać, a nie tylko dział IT.
Cena jest stała
Jeśli coś zajmie mi dwa razy więcej czasu, niż zakładałem, to jest mój problem, nie Twój. Ty znasz kwotę na starcie i planujesz budżet raz.
A jeśli w trakcie pojawi się nowy pomysł?
Pojawia się prawie zawsze — i to dobrze, bo znaczy, że temat żyje. Nowe rzeczy nie wchodzą jednak po cichu do bieżącego zakresu. Trafiają na listę, a po zamknięciu obecnego etapu decydujemy, co robimy dalej i za ile.
Dzięki temu pierwsze wdrożenie kończy się w tygodniach, a nie rozpływa w miesiącach.
Tygodnie, nie miesiące
Typowy pierwszy etap to od dwóch do sześciu tygodni od pierwszego kontaktu do działającego narzędzia u Ciebie. Nie dlatego, że pracuję na skróty — dlatego, że zakres jest celowo mały i domknięty.
Lepiej mieć jedną rzecz, która działa w środę, niż dziesięć, które będą gotowe „w przyszłym kwartale”.