Płacisz za budowę. Potem za poprawki. Potem słyszysz, że system trzeba przepisać. Trzy faktury za jeden system – który od początku powinien być zaprojektowany na lata.
Jak to się dzieje, że płacisz trzy razy
Nikt świadomie się na to nie decyduje; to narasta – faktura po fakturze, każda zasadna w danej chwili.
Poprawka była pilna. Zmiana była „poza zakresem”. Nietypowa sytuacja „nie była w pierwotnej specyfikacji”. Każda poprawka to faktura, każda zmiana to dyskusja o zakresie, każda niewygodna rzeczywistość to „etap drugi”. Każda pozycja z osobna ma sens – a po kilku latach na łatki poszło więcej niż na pierwotną budowę, za system, który wciąż nie do końca pasuje.
Potem przychodzi rozmowa. Kod jest zbyt kruchy. Nie udźwignie tego, czego potrzebujesz dalej. Odpowiedzialnym krokiem – mówią – jest zacząć od nowa.
Więc płacisz po raz trzeci – za problem, który stworzyła ich architektura.
To nie jest wsparcie. To model biznesowy.
Spójrz na bodźce, a ten schemat przestaje dziwić. Gdy naprawianie błędów to przychód, zapobieganie im to koszt. Gdy każda zmiana jest fakturowana osobno, architektura oporna na zmiany to aktywo – ich, nie Twoje. A przepisanie systemu co kilka lat to nie porażka tego modelu; to jego najlepszy kwartał.
Nie trzeba do tego złych ludzi. Wystarczy struktura płatności, w której wykonawcy wiedzie się lepiej, gdy oprogramowaniu wiedzie się gorzej – a taka struktura to standard w branży.
Oprogramowanie zaprojektowane do rozbudowy tak nie działa
Alternatywą nie jest heroiczne utrzymanie. Jest nią elastyczna architektura – ustalona pierwszego dnia, kiedy jest tania.
Przejrzysta struktura, w którą nowe funkcje się wpasowują, zamiast z nią walczyć. Prawdziwa dokumentacja, dzięki której zmiany zaczynają się od wiedzy, a nie od archeologii. Miejsce na nietypowe sytuacje, których jeszcze nie znasz – bo je poznasz, a system powinien być na to gotowy.
Zbudowane w ten sposób oprogramowanie rośnie razem z firmą, zamiast się pod nią kruszyć. Jeden z naszych systemów działa od 2012 roku (ponad 14 lat) – jest dziś trzy razy większy niż na starcie i nigdy nie był przepisywany ￫.
Pełna odpowiedzialność techniczna – w umowie
Tak wyglądają bodźce, gdy są skierowane we właściwą stronę:
Poprawki błędów są bezpłatne, na zawsze. Nie przez rok gwarancji – na zawsze. Dotyczy to rozwiązań w pełni kontrolowanych przez nas (z wyłączeniem integracji zewnętrznych), ale nigdy nie płacisz za problemy wynikające z naszego projektu; ten koszt ponosimy my – i właśnie dlatego nasza metodyka im zapobiega. Utrzymywanie technologii na bieżąco to nasza wewnętrzna inwestycja, nigdy przepisanie systemu na Twój koszt. Płacisz tylko za jedno: nową wartość biznesową – nowe funkcje, realne zmiany w sposobie działania firmy.
Gdy wykonawca sam finansuje swoje błędy, jakość przestaje być obietnicą, a staje się pozycją w budżecie. Naszym.
Powracający koszt czy rosnące aktywo
Na tym polega cała różnica. Standardowy model zamienia oprogramowanie w koszt, który płacisz bez końca – łatki, dyskusje o zakresie, w końcu przepisanie, a potem wszystko od nowa. Zaprojektowane i wspierane inaczej staje się aktywem, które się pomnaża ￫: każdy rok użytkowania dodaje zapisaną wiedzę, dopracowane procesy i zgromadzone dane na fundamencie zbudowanym, by je udźwignąć – a ukryte koszty, które zaskakują większość kupujących, po prostu się nie pojawiają.