Własna aplikacja jest zobowiązaniem na lata. Warto sprawdzić, czy potrzeba naprawdę wykracza poza to, co da się kupić gotowe.
Objawy realnej potrzeby
Potrzeba rzadko zgłasza się wprost. Widać ją w drobiazgach, które zespół uznał już za normę:
- proces prowadzony jest w kilku arkuszach jednocześnie,
- te same dane wpisywane są w dwóch miejscach,
- ktoś jest jedynym człowiekiem umiejącym obsłużyć narzędzie,
- informacja o stanie sprawy wymaga zapytania konkretnej osoby,
- gotowe programy wymagają zmiany sposobu pracy, a nie odwrotnie.
Jeden punkt z tej listy zwykle znaczy, że wystarczy uporządkować pracę. Większość punktów naraz znaczy, że obejścia kosztują już więcej niż narzędzie.
Najpierw gotowe
Program z rynku kosztuje ułamek własnego i ma wsparcie. Jeśli pokrywa potrzebę w większości, zwykle warto dopasować proces do narzędzia, a nie odwrotnie.
Zanim odrzucisz gotowe rozwiązanie, sprawdź dwie rzeczy. Czy brakujący element jest naprawdę istotny, czy tylko inny niż dotychczasowe przyzwyczajenie. I czy program udostępnia interfejs wymiany danych — wtedy brakującą część można dobudować obok, zamiast pisać całość od zera. Osobnym wariantem jest arkusz kalkulacyjny, który przy jednej osobie i prostym procesie bywa w zupełności wystarczający.
Kiedy własne jest uzasadnione
Gdy sposób działania firmy jest jej przewagą i żadne gotowe rozwiązanie go nie odwzorowuje. Albo gdy chodzi o połączenie kilku systemów, których nikt nie łączy standardowo.
Trzeci przypadek to skala pracy ręcznej: czynność powtarzana codziennie przez kilka osób, której żaden dostępny program nie obejmuje. Koszt budowy porównuje się wtedy nie z ceną licencji, tylko z godzinami, które i tak są wydawane.
Rachunek
Po stronie kosztów: budowa, utrzymanie, poprawki, zależność od wykonawcy. Po stronie korzyści: zaoszczędzony czas przeliczony na godziny w skali roku. Ta druga liczba zwykle rozstrzyga.
Do kosztów trzeba doliczyć pozycje, o których łatwo zapomnieć: przeniesienie danych z arkuszy, przeszkolenie zespołu i utrzymanie po wdrożeniu. Rozliczenie prowadzi się stawką godzinową albo wyceną za projekt, zależnie od zakresu. Część elementów jest gotowa, więc proste wdrożenia zamykają się w kilka dni.
Najmniejsza możliwa wersja
Pierwsza aplikacja powinna rozwiązywać jeden problem. Rozbudowana wizja obejmująca wszystko naraz kończy się projektem, który nigdy nie wchodzi do użycia.
Zanim powstanie kod, warto przygotować prototyp ekranów i sprawdzić go z osobami, które będą na nim pracować. Poprawka na makiecie jest tania. Ta sama poprawka w działającym narzędziu już nie.
Kiedy się nie opłaca
Gdy proces zmienia się co kilka miesięcy — aplikacja utrwala wtedy stan, który zaraz przestanie obowiązywać. Gdy narzędzie ma obsłużyć jedną osobę i kilkanaście operacji miesięcznie. I gdy w firmie nie ma nikogo, kto odpowie na pytania o reguły procesu. Bez takiej osoby projekt stoi niezależnie od budżetu.
