Czas budżetu, uważaj na obietnicę "zrobimy z AI"

Jesteśmy w okresie budżetu w większości firm, i prawdopodobnie usłyszałeś już tę frazę na jakimś spotkaniu: "ten system zbudujemy wewnętrznie, z AI wyjdzie taniej". Propozycja wydaje się oczywista. Problem jest taki, że nie zawsze liczą właściwy koszt.

Z rozwojem AI stało się powszechne używanie Vibe Coding, by budować systemy szybko, bez przechodzenia przez formalny proces inżynierii oprogramowania. I właśnie tam jest ryzyko, przed którym chcę ostrzec w tym artykule.

Ryzyko zamiany SaaS na oprogramowanie zbudowane w Vibe Coding

Vibe Coding rozwiązuje konkretny problem: szybkość. AI buduje kod szybko, ale kod jest tylko częścią budowy oprogramowania. Proces jest tym, co organizuje rzeczy, definiuje wymagania, architekturę, warstwy odpowiedzialności, testy automatyczne, wersjonowanie i zarządzanie konfiguracją.

Bez procesu nie masz systemu. Masz prototyp, który działa dzisiaj i który trudno komuś wyjaśnić jutro.

Największy koszt to nie budowa, to utrzymanie

Pracuję w projektach budowy i utrzymania systemów ponad 16 lat i mogę potwierdzić: to jest punkt, który waży najwięcej w decyzji i najmniej pojawia się w rozmowie o budżecie. Większość wysiłku i pieniędzy oprogramowania nie jest w budowie, jest w utrzymaniu na przestrzeni lat.

Kiedy zarząd ocenia zamianę SaaS na wewnętrzny system, zazwyczaj porównuje koszt obecnej subskrypcji z kosztem budowy. Ten rachunek jest niekompletny. Brakuje zapytać: ile kosztuje utrzymanie tego nowego oprogramowania? Kto będzie naprawiać błędy, aktualizować zależności, dostosowywać do systemów, które się zmieniają, szkolić tych, kto przyjdzie później? Jak już mówiłem o kto płaci, kto kupuje i kto utrzymuje system, każda z tych publiczności płaci inny rachunek, i ten, kto kończy płacąc za źle policzone utrzymanie, jest zawsze zespołem, który został poza tą decyzją.

Bez dobrze zdefiniowanego procesu rozwoju w budowie, utrzymanie staje się droższe, niż wyobrażano sobie w budżecie.

Klonowanie obecnego systemu nie rozwiązuje problemu

Innym częstym błędem w tej decyzji jest traktowanie projektu jako kopii. Firma chce, w praktyce, zduplikować SaaS, który już używa, włącznie z funkcjonalnościami, których nigdy naprawdę nie użyła i które zostały pomyślane dla innej rzeczywistości (sprzedać jak największej liczbie klientów), innej firmy, innego kontekstu.

To nie jest budowanie nowego systemu. To replikowanie własności intelektualnej osób trzecich i przenoszenie do domu tych samych problemów, które obecny system już miał, jak wymagania i funkcjonalności, które mało dodają wartości. Celem powinno być inne: myślenie o tym, czym to nowe oprogramowanie musi być dla konkretnej rzeczywistości twojej firmy, nie o tym, co dostawca SaaS zdecydował zbudować. To jest w zasadzie kwestionowanie specyfikacji przed kopiowaniem.

Droga, która działa: proces, nie tylko kod

Budowanie oparte na solidnym modelu jest tym, co pozwala utrzymywać i rozwijać system przez lata, ponieważ większość pracy jest w utrzymaniu, nie w budowie.

To nie znaczy rezygnować z AI. Znaczy używać jej w ramach procesu. Agenci AI wchodzą, by poszerzyć zdolność inżyniera oprogramowania, i działają w przepływie, który łączy szybkość AI z kontrolą procesu. Frameworki organizują pracę tych agentów w ramach przepływu rozwoju. A kontekst, pliki, reguły, zaangażowane osoby, to jest to, co utrzymuje tych agentów zaktualizowanych i zgodnych z rzeczywistością firmy.

Wierzę, że ta kombinacja, proces plus AI, jest tym, co podtrzymuje system na długi termin. Vibe Coding sam, bez procesu, dostarcza szybkość w jakimkolwiek kierunku. Mówię to z własnego doświadczenia: próbowałem utrzymać przez 3 miesiące system zbudowany bez fundamentu, i wynik był oczywisty, odrzucenie i zaczęcie we właściwy sposób.

Pytanie, które zostaje przed zatwierdzeniem budżetu

Przed odwołaniem tego SaaS, myśląc, że zaoszczędzisz, zadaj to pytanie zespołowi: usuwamy koszt z jednej strony, ale jaki koszt generujemy z drugiej? Ile kosztuje utrzymanie tego nowego oprogramowania i co musimy mieć zestrukturyzowane, architektura, wersjonowanie, konfiguracja, proces, by podtrzymać to utrzymanie w następnych latach? A jeśli ta technologia wyjdzie z firmy? Co można zrobić? Jakie jest ryzyko tego ruchu dla biznesu?

Jeśli ta odpowiedź nie istnieje przed zatwierdzeniem budżetu, problem nie jest technologia. Jest decyzja.

Pozdrawiam! Leandro | PMP | Kierownik Projektów i PMO