Kiedy firma powinna zbudować własne oprogramowanie?

Załóżmy, że wiadomo już, że budowa może być uzasadniona. Kolejne pytanie dotyczy momentu — a odpowiedź zwykle brzmi: „później, niż by się chciało, ale wcześniej, niż zmusi do tego sytuacja”.

Sześć sygnałów, że to już ten moment

1. Arkusz stał się krytyczną infrastrukturą. Jeden plik, kilka zakładek, formuły, których nikt nie odważy się ruszyć, i jedna osoba, która to rozumie. Gdy ten plik się zepsuje, firma staje. Taki arkusz to specyfikacja oprogramowania, które powinno istnieć.

2. Wzrost liniowo kosztuje etaty. Każdy nowy klient, produkt czy lokalizacja dokłada tę samą ręczną pracę przy konfiguracji. Firmy, które skalują się z zyskiem, zrywają to powiązanie; zwykle robi się to oprogramowaniem.

3. Dwa systemy się nie zgadzają i nikt nie wie, który ma rację. Ktoś spędza dzień w miesiącu na uzgadnianiu. To uzgadnianie jest sygnałem.

4. Najlepsi ludzie spędzają dzień na administracji. Wykwalifikowani pracownicy przepisujący dane to najdroższa automatyzacja, jaką można kupić.

5. Błędy stały się normą. „Czasem tak się zdarza” w odniesieniu do czegoś, co kosztuje pieniądze, to problem procesu z rozwiązaniem technicznym.

6. Tracisz zlecenia, bo działasz za wolno. Oferty przygotowywane trzy dni, bo składanie ich jest ręczne. Zapytania, które stygną, bo nikt ich nie zauważył.

Trzy sygnały, że jest za wcześnie

• Proces zmienia się co miesiąc. Automatyzacja niestabilnego procesu utrwala decyzje, których jeszcze nie podjęto. Najpierw go ustabilizuj.
• Nikt nie potrafi opisać procesu od początku do końca. Jeśli trzy osoby opisują go na trzy różne sposoby, nie czas jeszcze na specyfikację oprogramowania — choć samo zmapowanie procesu jest naprawdę przydatne.
• Prawdziwy problem jest organizacyjny. Oprogramowanie nie naprawi braku właściciela, złych bodźców ani dwóch działów, które ze sobą nie rozmawiają. Sprawi tylko, że dysfunkcja będzie szybsza i bardziej widoczna.

Zacznij od czegoś mniejszego, niż się wydaje słuszne

Najpewniejszy sposób na porażkę przy oprogramowaniu na zamówienie to budowanie wersji trzeciej, zanim wyjdzie wersja pierwsza.

Dobra pierwsza wersja:

• rozwiązuje najbardziej bolesną część procesu, a nie cały proces;
• trafia do prawdziwych ludzi wykonujących prawdziwą pracę w ciągu tygodni, a nie kwartałów;
• ma architekturę, która może rosnąć, więc wersja druga nie wymaga przepisania wszystkiego;
• uczciwie mówi, co na razie zostaje ręczne.

Cztery tygodnie prawdziwego używania nauczą więcej niż cztery miesiące specyfikacji. Połowa rzeczy, co do których była pewność, okaże się błędna — i odkrycie tego wcześnie to cały sens tego podejścia.

Co przygotować przed startem

Konkretnego właściciela po Twojej stronie. Kogoś, kto podejmuje decyzje bez komitetu. Projekty bez takiej osoby dryfują.

Uzgodnioną definicję sukcesu. „Oferta gotowa w mniej niż dwie godziny” albo „żadnego ręcznego przepisywania zamówień”. Coś, co da się sprawdzić.

Punkt odniesienia. Zmierz obecny proces, zanim go zmienisz: czas na sprawę, liczbę spraw tygodniowo, odsetek błędów. Bez tego nie da się ocenić, czy zadziałało, a za pół roku będzie się dyskutować o wrażeniach.

Dostęp. Do systemów, danych i — co najważniejsze — do ludzi, którzy faktycznie wykonują pracę. Nie do opisu tej pracy od ich przełożonego.

Uczciwy budżet na drugi rok. Używane oprogramowanie się zmienia. Jeśli nie ma budżetu na jego rozwój, zamieni się w coś, na co wszyscy narzekają.

Od czego zaczynamy my

Nasze projekty oprogramowania zaczynają się od etapu analizy, który naprawdę może zakończyć się wnioskiem „nie budujcie tego”. Czasem odpowiedzią jest zmiana konfiguracji, automatyzacja procesu albo połączenie dwóch systemów, które już macie.

To mniejsza faktura dla nas i lepszy wynik dla Ciebie — i mniej więcej taką wymianę staramy się konsekwentnie proponować.

Jeśli masz proces, który zabiera Ci czas, opisz go nam. Już sama rozmowa zwykle sporo wyjaśnia.