7 błędów, które małe firmy popełniają przy zamawianiu oprogramowania na zamówienie

Większość małych firm, które sparzyły się na projekcie oprogramowania na zamówienie, nie sparzyła się na słabych programistach. Sparzyły się tygodnie przed rozpoczęciem jakiegokolwiek programowania — na spotkaniu otwierającym, w wątku mailowym, przy uścisku dłoni — przez decyzję, która wtedy wydawała się drobna. Zanim kod dotrze, błąd jest już wpisany w projekt. Dobra wiadomość jest taka, że te błędy są nudno powtarzalne, co oznacza, że da się ich uniknąć, jeśli wie się, jak wyglądają.

Oglądałem wiele takich projektów od środka, po obu stronach stołu. Niektóre stały się narzędziami, bez których firma nie wyobrażała sobie pracy. Inne zamieniły się w na wpół ukończony ekran logowania, napięty spór o fakturę i właściciela przysięgającego, że nigdy więcej nie pójdzie w rozwiązanie na zamówienie. Frustrujące jest to, jak niewiele dzieliło te dwa wyniki. Technologia rzadko była problemem. Decyzje wokół technologii niemal zawsze były.

Oto więc siedem błędów, które widzę raz po raz, gdy mała firma zamawia dedykowane oprogramowanie. Żaden z nich nie wymaga technicznego zaplecza, by go uniknąć. Wymagają jedynie świadomości, że istnieją, zanim Państwo cokolwiek podpiszą.

Błąd 1: Kupowanie rozwiązania, zanim się zrozumie problem

Najdroższy błąd pojawia się jako pierwszy i brzmi niewinnie: „Potrzebujemy aplikacji, która robi X”. Zanim ktoś wypowie to na głos, zwykle podjął już decyzję co do kształtu rozwiązania — pulpit, portal, aplikacja mobilna — a nikt nie zapisał prostym językiem rzeczywistego problemu. Realizacja wiernie dostarcza wtedy niewłaściwą rzecz, pięknie wykonaną.

Dobre oprogramowanie zaczyna się od sformułowania problemu, a nie od listy funkcji. „Nasz zespół biurowy przepisuje każde zamówienie z maila do systemu księgowego, a zajmuje to dwóm osobom pół dnia” to problem. „Potrzebujemy CRM-u na zamówienie” to zgadywanie rozwiązania problemu, którego nikt nie zadał sobie trudu nazwać. Pierwsze da się tanio rozwiązać i zmierzyć. Drugie to otwarte zaproszenie do wydawania pieniędzy.

Błąd 2: Próba zbudowania wszystkiego naraz

Oprogramowanie na zamówienie wydaje się zakupem raz na dekadę, więc ludzie próbują upchnąć dekadę życzeń w wersji pierwszej. Każdy dział dorzuca prośbę. Każde „skoro już przy tym jesteśmy” dostaje tak. Zakres puchnie, harmonogram się potraja, a projekt zapada się pod ciężarem własnych ambicji na długo przed tym, zanim ktokolwiek z niego skorzysta.

Firmy, którym się udaje, robią odwrotnie. Wybierają jeden najbardziej bolesny wycinek problemu i budują go najpierw — realną, działającą rzecz na produkcji w ciągu kilku miesięcy. Potem pozwalają, by rzeczywiste użycie podpowiedziało, co dalej. To nie tylko taniej; to bezpieczniej. Dowiadują się Państwo, czy pomysł działa, gdy stawka jest jeszcze niska, zamiast odkrywać po pół roku i sporej fakturze, że zaprojektowali niewłaściwą rzecz.

Pod tym kryje się trudna prawda: na razie naprawdę nie wiedzą Państwo, czego potrzebują. Na starcie nikt tego nie wie. Państwa rozumienie problemu zmieni się w chwili, gdy realni ludzie dotkną realnego narzędzia. Budowanie wszystkiego z góry zamraża najwcześniejsze, najmniej świadome domysły. Budowanie wycinkami utrzymuje elastyczność — i trzyma budżet w ryzach, gdy wciąż się Państwo uczą.

Błąd 3: Wybór wyłącznie według ceny

Dostają Państwo trzy oferty. Jedna jest drastycznie tańsza od pozostałych. Ulga — biorą Państwo tę. To jeden z najpewniejszych sposobów, by zamienić mały projekt w drogi, bo tania oferta niemal nigdy nie oznacza, że praca jest tańsza. Zwykle oznacza, że obie strony inaczej zrozumiały zadanie.

Niska kwota często sygnalizuje jedną z kilku rzeczy: dostawca zaniżył zakres, bo zadał za mało pytań, planuje zarobić marżę później na zmianach, albo jest niedoświadczony i jeszcze nie wie, czego nie wie. Żadna z nich nie kończy się dla Państwa dobrze. Cena z nagłówka to najmniej użyteczna liczba w ofercie. Liczy się to, czy dostawca jasno rozumie Państwa problem, zadaje niewygodne pytania i jest szczery co do tego, czego nie obejmuje oferta.

Błąd 4: Zapominanie, że oprogramowanie to nie zakup jednorazowy

Oprogramowanie na zamówienie często prezentuje się i kupuje jak mebel: zapłać raz, posiadaj na zawsze. Tak nie jest. Oprogramowanie żyje w ruchomym świecie — systemy operacyjne się aktualizują, przeglądarki się zmieniają, pojawiają się łatki bezpieczeństwa, Państwa biznes się przesuwa, narzędzia, z którymi się łączą, zmieniają swoje zasady. Narzędzie, którego nikt nie utrzymuje, powoli przestaje działać, a potem psuje się w najgorszym możliwym momencie.

To boleśnie dotyka małe firmy, bo koszt utrzymania jest niewidoczny przy podpisaniu. Porównują Państwo dwie oferty po cenie budowy i nigdy nie zadają ważniejszego pytania: ile kosztuje utrzymanie tego przy życiu i w zdrowiu co roku? Hosting, aktualizacje, drobne poprawki, sporadyczna zmiana wraz z rozwojem firmy — zaplanujcie to jako normalną, stałą pozycję, tak jak ubezpieczenie czy księgowość. Zwykle jest skromna, ale tylko jeśli się jej Państwo spodziewają.

Błąd 5: Pozostawienie wymagań mglistych i bez właściciela

„Jesteście ekspertami, po prostu zbudujcie coś dobrego” brzmi wspaniałomyślnie. W rzeczywistości tak właśnie projekty zbaczają z kursu. Ludźmi, którzy najlepiej rozumieją Państwa biznes, są Państwo i Państwa zespół — nie programiści. Jeśli przekażą Państwo mgliste wytyczne i znikną, dostawca wypełni luki swoimi najlepszymi domysłami, a Państwo odkryją te domysły w najgorszym momencie: przy odbiorze, gdy ich zmiana kosztuje najwięcej.

Po Państwa stronie trzeba obsadzić dwie role, a małe firmy rutynowo nie obsadzają żadnej. Pierwsza to jeden decydent — osoba, która może powiedzieć tak, rozstrzygnąć spory między działami i nie jest zbyt zajęta, by przez tygodnie odpowiadać na pytania. Druga to gotowość do precyzji w rzeczach, które się liczą: przypadki brzegowe, dziwny wyjątek, który firma zawsze obsługiwała ręcznie, reguła, którą wszyscy znają, ale nikt nie spisał. To dokładnie to, co oprogramowanie musi zrobić dobrze.

Błąd 6: Niepytanie, kto jest właścicielem kodu i danych

To ten cichy i ten, który boli najbardziej lata później. Płacą Państwo za oprogramowanie na zamówienie, zakładają, że jest Państwa. Potem relacja z dostawcą się psuje, albo podnosi on ceny, albo po prostu znika — i odkrywają Państwo, że nie mogą się ruszyć. Nie mają Państwo kodu źródłowego. Dane żyją w systemie, do którego dostęp ma tylko on. Cała Państwa działalność zależy teraz od firmy, której już nie ufają, a nie mają żadnej karty przetargowej.

Żaden z tych scenariuszy nie wymaga prawnika, by mu zapobiec. Wymaga trzech prostych pytań zadanych przed startem, gdy mają Państwo jeszcze całą siłę przetargową: Kto jest właścicielem kodu źródłowego, gdy to będzie gotowe? Czy mogę wyeksportować wszystkie swoje dane, w użytecznym formacie, kiedy tylko zechcę? I jeśli się rozstaniemy, z czym dokładnie odejdę? Renomowany partner odpowiada na nie bez mrugnięcia okiem. Wahanie w tym miejscu to największa czerwona flaga w całym procesie.

• Zapewnijcie sobie na piśmie własność kodu źródłowego albo jasną, uczciwą licencję na niego.
• Potwierdźcie, że możecie eksportować własne dane w standardowym formacie, na żądanie, bez pozwolenia.
• Upewnijcie się, że praca jest udokumentowana na tyle, by inny programista mógł ją podjąć.
• Unikajcie zamknięcia we własnościowych rozwiązaniach tam, gdzie zwykła, znana technologia zrobiłaby to samo.
• Ustalcie z góry, co stanie się z hostingiem i kontami, jeśli kiedyś zmienicie dostawcę.

Błąd 7: Traktowanie wdrożenia jak mety

Oprogramowanie dostarczone, działa, wszystkim ulżyło. Projekt ogłoszono ukończonym. Pół roku później połowa zespołu po cichu wróciła do starego arkusza, a drogie nowe narzędzie używane jest przez dwie osoby do jednej rzeczy. Budowa się udała. Wdrożenie zawiodło — a to dwa zupełnie różne problemy.

Ludzie nie opierają się nowym narzędziom dlatego, że są głupi lub uparci. Opierają się, bo nowy sposób jest nieznany, a stary jakoś tam wciąż działa. Pokonanie tego wymaga świadomego wysiłku, którego nikt nie zaplanował w budżecie: odrobiny szkolenia, jasnego powodu, dlaczego zmiana pomaga im konkretnie, kogoś, kto w pierwszych tygodniach odpowie na głupie pytania bez oceniania, oraz stanowczej decyzji o wycofaniu starego sposobu, by nie było do czego się wycofać.

1. 1
   Wdróżcie najpierw u małej grupy

   Udostępnijcie narzędzie kilku chętnym osobom, zanim zacznie cały zespół. Znajdą szorstkie krawędzie i staną się Państwa wewnętrznymi ambasadorami.
2. 2
   Pokażcie osobistą korzyść, nie firmową

   "To oszczędza firmie pieniądze" nikogo nie motywuje. "To znaczy, że przestaniecie przepisywać adresy dwa razy" zjednuje ludzi.
3. 3
   Wyznaczcie osobę do pytań

   Przez pierwszy miesiąc ktoś bierze na siebie głupie pytania. Tarcie w pierwszym tygodniu zabija wdrożenie na zawsze.
4. 4
   Naprawdę wyłączcie stary sposób

   Dopóki stary arkusz istnieje, ludzie będą go używać. Gdy narzędzie działa, wycofajcie awaryjny powrót — łagodnie, ale wyraźnie.

Złóżmy to w całość: nastawienie kupującego

Niech Państwo przeczytają te siedem ponownie, a przez wszystkie przewija się jedna nić. Niemal żaden nie jest techniczny. Dotyczą jasności, własności i powściągliwości — poznania problemu przed zakupami, budowania małymi krokami, oceniania dostawców po zrozumieniu, a nie cenie, planowania na całe życie narzędzia, a nie tylko jego narodziny, pozostawania zaangażowanym, ochrony swojego wyjścia i traktowania wdrożenia jako początku prawdziwej pracy.

Oprogramowanie na zamówienie to naprawdę jedna z najlepszych inwestycji, jaką mała firma może poczynić, gdy wyrośnie już z gotowych narzędzi dzielonych przez wszystkich. System ukształtowany dokładnie wokół tego, jak Państwo pracują, zamiast zmuszać biznes do wyginania się wokół cudzego produktu, to realna i trwała przewaga. Firmy, które tam docierają, to nie te z największymi budżetami. To te, które uniknęły siedmiu powyższych błędów — a to kwestia osądu, nie pieniędzy.

Częste pytania