Czy powinniśmy to zbudować? Pytanie, które zadajemy, zanim napiszemy jakikolwiek kod

Gdy organizacja zwraca się do firmy tworzącej oprogramowanie, zwykle oczekuje się, że rozmowa zakończy się propozycją zbudowania czegoś: nowej aplikacji, zamiennika dla starzejącego się systemu, platformy łączącej rozproszone procesy. To zrozumiałe założenie, ale pomija pytanie, na które należy odpowiedzieć, zanim ktokolwiek zacznie mówić o technologii, budżetach czy terminach dostaw.

Czy naprawdę powinniśmy to zbudować?

W Libertas Software Research (LSR) uważamy, że wiedzieć, czy tworzyć oprogramowanie, jest równie ważne jak wiedzieć, jak. Czasem aplikacja na zamówienie jest dokładnie tym, czego trzeba. Czasem sprawdzona platforma SaaS doskonale zaspokaja potrzebę albo połączenie systemów, które już Państwo mają, daje efekt bez kosztów i zakłóceń związanych z ich wymianą. Celem jest poprawa działania organizacji, a nie dodanie kolejnej aplikacji do i tak skomplikowanego środowiska.

Zacznij od problemu, nie od rozwiązania

Organizacje zwykle opisują rozwiązanie, którego ich zdaniem potrzebują, zamiast problemu, który mają. „Pulpit raportowy” albo „aplikacja zastępująca nasze arkusze” brzmi na dobrze zdefiniowane, ale niewiele mówi o tym, co wywołało prośbę.

Weźmy comiesięczny raport zarządczy składany ręcznie z kilku arkuszy i systemów. Zajmuje dni, a gdy dociera do odbiorcy, dane są już nieaktualne. Oczywisty wniosek to potrzeba oprogramowania raportowego. Po bliższym przyjrzeniu się prawdziwym problemem są często rozproszone dane i niespójne procesy: skromny projekt integracyjny, a nie nowa aplikacja. A jeśli analiza pokaże, że potrzebne są wyspecjalizowane przepływy pracy lub kontrole, których żaden produkt nie obsługuje, to właśnie wtedy rozwiązanie na zamówienie zasługuje na swoje miejsce.

Kiedy zakup ma więcej sensu

Rynek komercyjny jest dojrzały. CRM, księgowość, planowanie, zarządzanie dokumentami i business intelligence mają produkty dopracowywane przez lata. Jeśli jeden z nich spełnia Państwa potrzeby bez nieuzasadnionych ograniczeń, zamiennik na zamówienie wnosi niewiele wartości.

Należy jednak porównywać całkowity koszt posiadania, a nie ceny subskrypcji. Produkt za 500 £ miesięcznie to 30 000 £ w pięć lat, zanim dodamy konfigurację, integracje, dodatkowe licencje czy zmiany we własnych procesach. Warto sprawdzić, jak skalują się ceny, czy można wyeksportować dane i co się stanie, jeśli dostawca zmieni model. I uważać, by nie zmuszać firmy do rezygnacji z działań, które naprawdę ją wyróżniają, tylko dlatego, że produkt zakłada coś innego.

Czasem odpowiedzią jest połączenie tego, co już mamy

Większość organizacji z czasem gromadzi systemy: finanse w jednym, operacje w drugim, obsługę klienta w trzecim. Każdy działa dobrze; po prostu nie rozmawiają ze sobą, co prowadzi do opóźnień, dublowania pracy i niespójnych informacji.

Wymiana wszystkiego na jedną aplikację kusi, ale jest ryzykowna. Istniejące platformy kryją lata wiedzy operacyjnej i ukryte integracje. Starannie zaprojektowana warstwa integracji (łączenie interfejsów API, automatyzacja transferów, konsolidacja raportowania z wiarygodnych źródeł) może wydłużyć życie tych inwestycji. Wymaga przemyślenia uwierzytelniania, własności danych, obsługi błędów i możliwości audytu, ale rekomendowanie integracji zamiast wymiany nie jest gorszą inżynierią. Często to bardziej przemyślana decyzja architektoniczna.

Kiedy rozwiązanie na zamówienie jest właściwą inwestycją

Niektóre wymagania naprawdę nie pasują do popularnych produktów: wyspecjalizowane operacje, nietypowe potrzeby w zakresie bezpieczeństwa lub danych albo oprogramowanie, które samo jest przewagą konkurencyjną. Tu oprogramowanie na zamówienie pozwala architekturze podążać za tym, jak firma faktycznie działa.

Ta elastyczność wiąże się z długoterminową odpowiedzialnością za utrzymanie, bezpieczeństwo, testowanie i wsparcie. System może spełniać pierwotną specyfikację i mimo to być złą inwestycją, jeśli trudno go utrzymać lub nie potrafi się dostosować. Rozwój na zamówienie jest uzasadniony, gdy korzyści z rozwiązania zbudowanego specjalnie dla nas przewyższają zarówno koszt początkowy, jak i stałe zobowiązanie bycia jego właścicielem.

Nie każdy problem wymaga więcej oprogramowania

Czasem problemem jest sam proces. Zatwierdzenia, raporty i kroki administracyjne gromadzą się przez lata, długo po tym, jak okoliczności, które je stworzyły, zniknęły. Zautomatyzowanie ich dokładnie takimi, jakie są, tylko konserwuje złożoność.

Jeśli dokument wymaga pięciu zatwierdzeń, nie pytajmy, jak zautomatyzować pięć zatwierdzeń, tylko dlaczego każde istnieje i jakie ryzyko pokrywa. Oprogramowanie świetnie stosuje spójne reguły, ale nie powie, czy proces ma sens. Uproszczenie przepływu pracy lub wyjaśnienie odpowiedzialności może przynieść realne korzyści bez kolejnego systemu, którego trzeba się uczyć i który trzeba wspierać.

Patrz poza koszt początkowy

Projekty na zamówienie wiążą się z dużym kosztem początkowym, podczas gdy SaaS rozkłada koszt na subskrypcje, przez co porównanie wygląda na nierówne. Uczciwe porównanie obejmuje cały cykl życia: wdrożenie, licencje, hosting, wsparcie, utrzymanie, integrację, szkolenia i przyszłe zmiany.

Trzeba też uwzględnić koszt bezczynności. Nieefektywny proces pochłaniający 20 godzin pracy tygodniowo to około 1040 godzin rocznie. Przy ilustracyjnej stawce 35 £ za godzinę to około 36 400 £ rocznie, zakładając, że czas można realnie odzyskać i przekierować. Dodajmy słabą jakość danych i powolne decyzje, które trudniej wycenić, ale są równie realne. Najlepsza opcja to nie najtańsza, lecz ta o najlepszym połączeniu wartości, akceptowalnego ryzyka i długoterminowej trwałości.

Dlaczego firma programistyczna miałaby zalecać, by nie budować oprogramowania?

To uczciwe pytanie. Jeśli zalecamy produkt lub małą integrację, na papierze oznacza to mniej pracy programistycznej.

Jest jednak różnica między dostarczaniem mocy wytwórczych a działaniem jako partner w badaniach i architekturze oprogramowania. Nasza praca zaczyna się, zanim powstanie specyfikacja: zrozumienie problemu, rozważenie opcji i pomoc w decyzji, gdzie inwestować. Ma to wartość niezależnie od wyniku, a zwykle pozostaje jeszcze praca analityczna, architektoniczna, planistyczna i integracyjna, nawet gdy rozwiązanie na zamówienie nie jest odpowiedzią.

Zalecanie rozwoju, którego nie potrzebujecie, jest przeciwskuteczne. Projekt dostarczony na czas i zgodnie ze specyfikacją i tak zawodzi, jeśli nie był właściwym rozwiązaniem. Pomaganie klientowi w uniknięciu zbędnych wydatków buduje zaufanie, które trwa.

To, że możemy zbudować, nie jest powodem, by budować

Sztuczna inteligencja i nowoczesne narzędzia sprawiają, że kod powstaje szybciej i taniej. To przydatne, ale czyni wstępne myślenie ważniejszym, nie mniej ważnym, bo wysiłek, który kiedyś zmuszał do pytania „czy naprawdę tego potrzebujemy?”, znika. Zupełnie możliwe jest zbudowanie czegoś technicznie doskonałego, sprawne dostarczenie tego i odkrycie, że to była zła odpowiedź.

Zanim rozpocznie się prace, chcemy jasnych odpowiedzi na temat problemu biznesowego, kosztu pozostawienia go nierozwiązanym, tego, których wymagań istniejące produkty nie spełniają, tego, jak będzie mierzony sukces (czas przetwarzania, dokładność, przejrzystość, zgodność, a nie liczba funkcji) oraz tego, kto będzie później obsługiwał i wspierał rozwiązanie.

Będą projekty, w których oprogramowanie na zamówienie jest wyraźnie słuszne, inne, w których lepszą wartość daje integracja, i jeszcze inne, w których gotowa platforma załatwia sprawę. Liczy się to, by rekomendacja wynikała ze zrozumienia Państwa organizacji, a nie z założenia o tym, co chce sprzedać firma programistyczna.

Zanim zapytamy, jak powinniśmy coś zbudować, warto ustalić, czy w ogóle powinniśmy to budować.

Libertas Software Research współpracuje z organizacjami przy badaniu, ocenie, projektowaniu i tworzeniu rozwiązań programistycznych, ze szczególnym naciskiem na długoterminową utrzymywalność, wartość operacyjną i przemyślane inwestycje technologiczne.