Kiedy nie budować systemu: trzy sygnały według CTO

Kiedy nie budować systemu? Moim zdaniem w trzech sytuacjach: gdy gotowe narzędzie pokrywa potrzebę, gdy proces, który system ma obsłużyć, nie jest jeszcze ustalony, oraz gdy po stronie firmy nie ma osoby, która weźmie za projekt odpowiedzialność. W każdej z nich dedykowany system staje się drogim sposobem na odkrycie, że problem leżał gdzie indziej. Uważam, że software house powinien to klientowi powiedzieć wprost, nawet jeśli traci przez to zlecenie.

To tekst z opinią, nie poradnik zakupowy. Opisuję sygnały, po których rozpoznaję, że budowa systemu jest złym pomysłem, i to, co proponuję w zamian.

Dlaczego software house w ogóle powinien odradzać

Software house zarabia na budowaniu, więc odradzanie budowy wygląda na działanie wbrew sobie. W praktyce to działanie we własnym interesie, tylko w dłuższym horyzoncie.

System, którego nikt nie używa, nie przynosi wykonawcy nic dobrego. Klient pamięta wydany budżet, a nie to, że projekt powstał zgodnie ze specyfikacją. Nie ma też utrzymania, rozwoju ani poleceń. Z drugiej strony szczera rozmowa na starcie buduje zaufanie, które procentuje przy następnym, sensownym projekcie.

Jest też powód bardziej osobisty. Zespół, który wie, że buduje coś niepotrzebnego, pracuje gorzej. Programiści czują, kiedy wymagania są wymyślane na bieżąco, a decyzje nikogo nie obchodzą.

Sygnał pierwszy: gotowe narzędzie wystarczy

Jeśli proces jest standardowy, a przewaga firmy nie zależy od tego, jak go obsługuje, gotowe narzędzie prawie zawsze wygra z dedykowanym systemem. Fakturowanie, prosty CRM, helpdesk, grafik pracy czy obieg wniosków urlopowych to obszary, w których rynek ma dojrzałe produkty.

Po czym poznaję, że gotowe narzędzie wystarczy:

• wymagania da się opisać bez słów „u nas jest inaczej”, a gdy padają, dotyczą nawyków, nie przewagi,
• różnice względem gotowego narzędzia można obejść konfiguracją albo drobną zmianą procesu,
• liczba użytkowników jest umiarkowana, więc licencje nie przewyższają kosztu własnego rozwiązania,
• firma nie planuje sprzedawać tego procesu jako usługi ani go mocno rozwijać.

Proponuję wtedy prosty test. Spiszcie dziesięć najważniejszych wymagań i sprawdźcie dwa, trzy gotowe narzędzia na wersjach próbnych. Jeśli każde pokrywa większość listy, pytanie nie brzmi już, czy budować, tylko które narzędzie wybrać i jak je połączyć z resztą firmy. Często rozwiązaniem jest gotowe narzędzie z integracją, o czym pisałem w tekście o tym, kiedy automatyzacja procesów przynosi korzyści.

Sygnał drugi: proces jest niejasny

System dedykowany utrwala proces w kodzie. Jeśli procesu nie da się spisać, bo każda osoba opisuje go inaczej, system albo utrwali jedną z tych wersji, albo próbuje obsłużyć wszystkie i staje się nieczytelny.

Rozpoznaję to po kilku zdaniach, które padają na pierwszych spotkaniach: „to zależy od klienta”, „tym zajmuje się jedna osoba i tylko ona wie”, „system ma być elastyczny, żebyśmy mogli to ustalić później”. Elastyczność w systemie kosztuje, a system zaprojektowany tak, żeby obsłużyć dowolny proces, zwykle nie obsługuje dobrze żadnego.

W takiej sytuacji zamiast budowy proponuję etap porządkowania procesu. Warsztaty z osobami, które go wykonują, spisanie kroków, wyjątków i decyzji. Czasem po takim warsztacie okazuje się, że problem rozwiązuje zmiana organizacyjna, a nie oprogramowanie. Jeśli nie, dokument z warsztatu staje się podstawą do tego, co opisuję w tekście o tym, jak przygotować specyfikację wymagań systemu.

Sygnał trzeci: brak właściciela po stronie firmy

Każdy projekt potrzebuje po stronie klienta osoby, która zna proces, ma czas na projekt i może podejmować decyzje bez zwoływania zarządu. Bez niej projekt dryfuje, a koszt rośnie z każdym tygodniem oczekiwania na odpowiedź.

Brak właściciela widać szybko. Na spotkania przychodzą różne osoby, każda z innymi priorytetami. Pytania o szczegóły wiszą tygodniami. Akceptacja makiet wymaga podpisu kogoś, kto nie był na żadnym spotkaniu. Projekt zlecił prezes, ale nikt z zespołu, który ma z systemu korzystać, nie uważa go za swój.

W takim przypadku mówię wprost, że nie zaczniemy budowy, dopóki nie ma wskazanej osoby z czasem i decyzyjnością. To nie jest wymóg formalny. Moim zdaniem obecność takiej osoby lepiej zapowiada powodzenie projektu niż jakość specyfikacji.

Inne sytuacje, kiedy nie budować systemu teraz

Poza trzema głównymi sygnałami są sytuacje, w których nie mówię „nie”, tylko „nie teraz”. Odpowiedź na pytanie, kiedy nie budować systemu, bywa bowiem kwestią terminu, a nie samej decyzji.

• Budżet tylko na budowę. Jeśli po wdrożeniu nie ma pieniędzy na utrzymanie i rozwój, system zacznie się starzeć od dnia odbioru.
• Termin pod wydarzenie. Targi, sezon, start kampanii. Termin bez związku z zakresem kończy się cięciem testów, a potem awariami w najgorszym momencie.
• Bo konkurencja ma. Brak odpowiedzi na pytanie, jaki problem system rozwiązuje u nas, to sygnał, że najpierw trzeba to pytanie przemyśleć.
• Problem jest ludzki. Konflikt między działami albo brak zasad nie zniknie dlatego, że pojawi się nowy ekran.
• Dane nie istnieją. System raportowy bez rzetelnych danych źródłowych pokaże tylko ładniejsze wykresy złych liczb.

Kiedy budowa systemu ma sens

Żeby nie było jednostronnie: są sytuacje, w których dedykowany system jest najlepszą decyzją, a odradzanie byłoby błędem. Rozpoznaję je równie łatwo jak te poprzednie.

• proces jest przewagą firmy i odróżnia ją od konkurencji, na przykład sposób wyceny, konfiguracji produktu albo obsługi klienta B2B,
• gotowe narzędzia wymagają tylu obejść, że ludzie pracują obok systemu, w arkuszach,
• system musi połączyć kilka innych systemów w sposób, którego żaden gotowy produkt nie przewiduje,
• koszt licencji przy rosnącej liczbie użytkowników przewyższa koszt budowy i utrzymania.

Nawet wtedy rekomenduję zaczynać od najmniejszej wersji, która rozwiązuje główny problem. Jak ją wyznaczyć, opisuję w tekście o tym, jak zaplanować MVP systemu. Rachunek, który pomaga porównać budowę z gotowym narzędziem, pokazałem przy okazji tematu, od czego zależy koszt systemu dedykowanego.

Czy szybsze programowanie z AI zmienia odpowiedź?

Nie zmienia, a wręcz wzmacnia argument. Narzędzia AI przyspieszają pisanie kodu, więc pokusa, żeby „po prostu coś zbudować”, jest dziś większa niż kiedyś.

Tyle że w żadnym z trzech sygnałów kod nie był problemem. Szybciej napisany system dla niejasnego procesu to szybciej utrwalony chaos. System bez właściciela szybciej trafi na półkę. A każdy dodatkowy moduł, nawet tani w budowie, trzeba potem utrzymywać, aktualizować i zabezpieczać przez lata. Tańsza budowa nie obniża kosztu posiadania tak bardzo, jak sugeruje pierwsza wycena. Dlatego pytanie, kiedy nie budować systemu, zadaję klientom tak samo jak wcześniej, tylko częściej muszę tłumaczyć, dlaczego niska cena prototypu nie jest argumentem za budową całości.

Co proponuję zamiast budowy

Odmowa bez alternatywy niewiele daje klientowi. Dlatego, gdy odradzam budowę, zawsze proponuję następny krok, dopasowany do sygnału, który zobaczyłem.

Sytuacja	Co proponuję zamiast budowy
gotowe narzędzie wystarcza	wybór narzędzia, konfiguracja i integracja z resztą systemów firmy
proces jest niejasny	warsztaty procesowe i spisanie procesu z wyjątkami
brak właściciela	wskazanie osoby i czasu na projekt przed jakąkolwiek wyceną
niepewna potrzeba	prototyp w arkuszu albo narzędziu bez kodu na kilka tygodni
budżet tylko na budowę	mniejszy zakres, który zostawia pieniądze na utrzymanie

Prototyp na gotowych klockach to często najtańszy sposób sprawdzenia, czy ludzie w ogóle będą korzystać z nowego procesu. Jeśli po kilku tygodniach arkusz z prostą automatyzacją pęka w szwach, to dobry znak. Wtedy wiadomo, co budować, i jest dowód, że warto.

Jak zadać sobie to pytanie przed rozmową z wykonawcą

Zanim zaprosisz software house na rozmowę, odpowiedz sobie na kilka pytań. To pięć minut, które oszczędzają tygodnie.

1. Jaki konkretny problem ma rozwiązać system i jak dziś sobie z nim radzimy?
2. Czy sprawdziliśmy przynajmniej dwa gotowe narzędzia i dlaczego nie pasują?
3. Czy umiemy opisać proces krok po kroku, z wyjątkami?
4. Kto u nas będzie właścicielem projektu i ile ma na niego czasu?
5. Czy mamy budżet na utrzymanie i rozwój po wdrożeniu?

Jeśli przy dwóch pierwszych pytaniach odpowiedź jest niepewna, to właśnie jest sytuacja, kiedy nie budować systemu, przynajmniej jeszcze nie teraz. Jeśli odpowiedzi są konkretne, rozmowa z wykonawcą będzie krótsza, a wycena trafniejsza. W obu przypadkach możesz umówić rozmowę o współpracy i przejść przez te pytania razem ze mną.