8 kosztownych błędów w tworzeniu aplikacji, które wciąż popełniają MŚP

Oto niewygodna prawda o projektach aplikacji, które schodzą na manowce: zanim kod zacznie wyglądać źle, projekt był już stracony tygodnie wcześniej. Kosztowne błędy w tworzeniu aplikacji dla małych firm prawie nigdy nie dzieją się przy klawiaturze. Dzieją się w niezobowiązujących rozmowach — w briefie, którego nigdy nie spisano, w funkcji, którą ktoś dodał „skoro już przy tym jesteśmy”, w programiście wybranym, bo polecił go znajomy. W danej chwili nic z tego nie wydaje się decyzją. Wszystko to kosztuje później.

Widziałem wiele małych firm zamawiających swoją pierwszą aplikację i wielokrotnie wzywano mnie do ratowania projektu po fakcie. Właściciele rzadko bywają osobami niedbałymi. Są bystrzy, uważni, dobrzy w prowadzeniu firmy. Ale oprogramowanie ma własny zestaw pułapek, które nie istnieją nigdzie indziej w ich życiu zawodowym, a nikt ich nie ostrzegł. Wpadają więc prosto w te same osiem pułapek, mniej więcej w tej samej kolejności, za każdym razem.

To jest lista, którą chciałbym, żeby miał każdy właściciel, zanim wyda choć grosz. Nie teoria — prawdziwe, powtarzalne błędy i drobne korekty kursu, które uratowałyby każdy projekt. Jeśli właśnie zamierzasz budować aplikację albo jesteś już w połowie i coś wydaje się nie tak, przeczytaj najpierw to. Większość z nich da się jeszcze naprawić, jeśli wychwycisz je wcześnie.

Błąd 1: budowanie, zanim udowodnisz, że ktoś tego chce

Najkosztowniejszy błąd jest zarazem najczęstszy: zobowiązanie się do pełnej budowy, zanim pojawi się jakikolwiek realny dowód, że aplikacja rozwiązuje problem, za który ludzie zechcą zapłacić albo z którego skorzystają. Pomysł wydaje się właścicielowi oczywisty — przecież klienci tego zechcą — i właśnie ta pewność jest niebezpieczna. Pewność przypomina walidację. Nią nie jest.

Walidacja nie polega na pytaniu dziesięciu znajomych, czy podoba im się pomysł; każdy powie tak, żeby być miłym. Polega na postawieniu najmniejszej możliwej wersji przed prawdziwymi użytkownikami w prawdziwej sytuacji i obserwowaniu, co naprawdę robią. Klikalny prototyp, strona docelowa mierząca zapisy, ręczna wersja „concierge”, w której udajesz automatyzację własnymi rękami — każda z nich powie ci więcej niż gotowa aplikacja zbudowana na przeczuciu. Kolejność ma znaczenie: udowodnij popyt tanio, potem buduj drogo. Odwróć to, a możesz wydać cały budżet na dopieszczanie czegoś, czego nikt nie otworzy drugi raz.

Błąd 2: rozrost zakresu przebrany za ambicję

Każda aplikacja zaczyna się szczupła i schludna. Potem zaczyna się „skoro już przy tym jesteśmy”. Skoro budujemy ekran rezerwacji, czy mógłby też obsługiwać bony podarunkowe? I punkty lojalnościowe? I system poleceń? Każdy dodatek z osobna brzmi rozsądnie. Razem po cichu potrajają harmonogram i rachunek — i odsuwają start tak daleko, że pierwotny rozpęd gaśnie.

Rozwiązaniem nie jest mówienie „nie” dobrym pomysłom. To odłożenie ich na bok. Prowadź widoczną listę „wersji drugiej”, na którą trafia każdy błyszczący pomysł, by zaczekać na swoją kolej. To działa zarówno psychologicznie, jak i praktycznie: ludzie przestają walczyć o wciśnięcie funkcji do pierwszego wydania, gdy uwierzą, że dla ich pomysłu jest później prawdziwe miejsce. Twoja pierwsza wersja powinna robić jedną rzecz naprawdę dobrze, a nie dziesięć rzeczy byle jak. Aplikacja, która perfekcyjnie obsługuje jeden proces, jest używana. Aplikacja robiąca wszystko połowicznie zostaje porzucona.

Błąd 3: brak spisanego briefu — tylko wspólny obraz w głowie

Ten pozostaje niewidoczny, dopóki nie ugryzie. Właściciel ma w głowie wyraźną aplikację. Programista ma w głowie wyraźną aplikację. Wszyscy kiwają głowami na spotkaniu startowym. Nikt nie spisuje tego porządnie — a oba obrazy, jak się okazuje, nigdy nie były tym samym obrazem. Odkrywasz to w połowie, gdy to, co powstaje, nie jest tym, co sobie wyobrażałeś, i zaczyna się spór o to, kto co powiedział.

Nie potrzebujesz stustronicowej specyfikacji. Potrzebujesz kilku stron, które każdy nowy może przeczytać i zrozumieć: kto używa tej aplikacji, jakie są trzy–cztery rzeczy, które muszą w niej zrobić, jak wygląda udany rezultat. Dodaj zgrubny szkic kluczowych ekranów. To wszystko. Sensem briefu nie jest biurokracja — to wspólny punkt odniesienia, na który oboje możecie wskazać, gdy pamięć i rzeczywistość zaczną się rozjeżdżać, co zawsze następuje.

Błąd 4: wybór programisty w niewłaściwy sposób

Większość właścicieli wybiera pierwszego programistę na podstawie jednego z dwóch wątłych sygnałów: najniższej wyceny albo osobistej rekomendacji od kogoś z innej branży. Oba mogą zadziałać przez przypadek. Żaden nie jest niezawodnym sposobem wyboru kogoś, komu powierzasz znaczącą kwotę i kilka miesięcy przyszłości swojej firmy.

Najniższa wycena jest w oprogramowaniu szczególnie zdradliwa, bo przepaść między wyceną a finalnym kosztem jest ogromna i niewidoczna. Tani programista, który potrzebuje trzech rund poprawek, znika na dwa tygodnie i zostawia cię z kodem, którego nikt inny nie utrzyma, jest znacznie droższy niż nieco droższy, który robi to dobrze. Cena to to, co widzisz; koszt całkowity to to, co płacisz.

Co naprawdę sprawdzić

Poproś o pokazanie rzeczy, które wdrożyli i które wciąż działają, a jeśli się da, porozmawiaj z tymi klientami bez programisty w pokoju. Zapytaj, jak radzą sobie ze zmianami w trakcie projektu, bo zmiany będą. Zapytaj, do kogo należy kod i konta po zakończeniu — odpowiedź zawsze powinna brzmieć do ciebie. I zwróć uwagę, czy sami zadają dobre pytania. Programista, który tylko przyjmuje polecenia, zbuduje dokładnie niewłaściwą rzecz bardzo wydajnie. Ci dobrzy oponują, wskazują luki w twoim myśleniu i traktują brief jako punkt wyjścia do rozmowy, a nie sztywną listę zakupów.

Błąd 5: zaplanować budżet na budowę, zapomnieć o reszcie

Aplikacja to nie jednorazowy zakup jak drukowana broszura. To żywy twór, który trzeba karmić. Właściciele rutynowo planują budżet na budowę i nic poza tym, a potem zaskakują ich koszty pojawiające się później: hosting, opłaty sklepów z aplikacjami, utrzymanie nadążające za aktualizacjami systemów telefonów oraz nieunikniona runda poprawek i drobnych ulepszeń, gdy zaczną z niej korzystać prawdziwi ludzie.

Rozsądna reguła kciuka: ile by nie kosztowała budowa, odłóż jej znaczącą część ponownie na pierwszy rok działania. Dokładna kwota bywa różna, ale błąd jest uniwersalny — traktowanie dnia startu jako mety, podczas gdy to w istocie linia startu. Aplikacja, która startuje, a potem zostaje po cichu porzucona, bo nie ma budżetu na jej utrzymanie, to jeden z najsmutniejszych i najczęstszych finałów w całej tej dziedzinie — i całkowicie da się go uniknąć dzięki uczciwemu planowaniu z góry.

Błąd 6: projektowanie dla siebie zamiast dla użytkownika

Znasz swoją firmę na wylot, co czyni cię najgorszym możliwym sędzią tego, czy twoja aplikacja jest łatwa w użyciu. Rzeczy dla ciebie oczywiste — żargon, kolejność, w jakiej wykonujesz zadania, skróty, które robisz bez namysłu — są dla pierwszego użytkownika zagadką. Aplikacja, która ma idealny sens dla właściciela, a wszystkich innych wprawia w zakłopotanie, zawiodła, bez względu na to, jak jest sprytna.

Lekarstwo jest tanie i lekko upokarzające: popatrz, jak prawdziwi ludzie jej używają, zanim wystartujesz. Nie twój zespół, który już wie, jak ma działać — prawdziwi klienci albo pracownicy, którzy nigdy jej nie widzieli. Daj im aplikację, daj zadanie i nie mów nic. Tam, gdzie się wahają, dotykają nie tego, co trzeba, albo wzdychają — to twoja informacja zwrotna o projekcie. Pięć osób wystarczy, by ujawnić najgorsze problemy. Pominięcie tego kroku sprawia, że aplikacje trafiają na rynek z przyciskiem „wyślij”, którego nikt nie może znaleźć, i z procesem rejestracji gubiącym połowę próbujących.

• Daj testerowi prawdziwe zadanie, nie zwiedzanie — „umów wizytę na przyszły wtorek”, a potem milcz.
• Patrz na ich dłonie i twarz, nie tylko na to, czy w końcu im się uda.
• Notuj każde wahanie; pauza to problem projektowy, którego od środka nie widzisz.
• Powstrzymaj chęć tłumaczenia — jeśli musisz tłumaczyć, powinna to zrobić aplikacja.
• Testuj z pięcioma osobami, napraw oczywiste wpadki, a potem testuj znowu.

Błąd 7: budowanie natywnego iOS i Androida, choć nie było to potrzebne

Istnieje odruch, by od pierwszego dnia budować „porządną” aplikację na iPhone'a i Androida, w pełni natywnie, tak jak robią to wielkie marki. Dla większości małych firm to dwu- czy trzykrotność kosztu i złożoności za korzyść, której użytkownicy nigdy nie zauważą. Co gorsza, utrzymujesz teraz na zawsze dwie osobne bazy kodu, podwajając każdą przyszłą poprawkę.

Często właściwym pierwszym krokiem nie jest natywna aplikacja w ogóle. Dobrze zbudowana aplikacja webowa działająca w przeglądarce każdego telefonu albo podejście wieloplatformowe, które wytwarza obie wersje sklepowe z jednej bazy kodu, wprowadzi cię na rynek szybciej i taniej — a w pełni natywną możesz przejść zawsze później, jeśli realne użycie udowodni, że warto. Pytanie, które zadajesz, nigdy nie brzmi abstrakcyjnie „natywna czy webowa”. Brzmi: co jest najmniejszą, najtańszą rzeczą, która pozwala prawdziwym użytkownikom wykonać kluczowe zadanie? Zbuduj to, wyciągnij wnioski, a potem wydaj duże pieniądze na podstawie dowodów, nie założeń.

Błąd 8: traktowanie startu jako końca pracy

Ósmy błąd to wiara, że projekt jest skończony, gdy aplikacja wchodzi na rynek. Nie jest — wtedy zaczyna się prawdziwy projekt. Aplikacja bez planu dotarcia do rąk użytkowników, bez sposobu na usłyszenie, co myślą, i bez zamiaru ulepszania jej na podstawie wniosków, to aplikacja, która gaśnie w ciągu kilku miesięcy. Budowa była łatwą częścią. Adopcja jest częścią trudną i prawie nikt jej nie planuje.

Zanim wystartujesz, wiedz trzy rzeczy: jak ludzie dowiedzą się, że aplikacja istnieje, jak zmierzysz, czy faktycznie z niej korzystają, oraz jak zbierzesz to, co ci mówią, by następną rundę pracy poprowadziła rzeczywistość, a nie zgadywanie. Nic z tego nie jest drogie. To po prostu inny sposób myślenia — aplikacja nie jest czymś, co kończysz i od czego odchodzisz, lecz relacją, którą utrzymujesz. Właściciele, którzy to rozumieją, dostają aplikacje coraz bardziej użyteczne z czasem. Ci, którzy nie rozumieją, dostają skok w dniu startu i długi, cichy zjazd.

Jak ominąć całą ósemkę naraz

Czytane razem, te błędy mają jeden wspólny korzeń: szybkie działanie na założeniach zamiast powolnego na dowodach. Każdy z nich to miejsce, w którym pominięcie starannego kroku wydawało się tańsze. I każdy z nich jest znacznie tańszy do obsłużenia przed budową niż po niej. Oto kolejność, która po cichu omija całą ósemkę.

1. 1
   Udowodnij popyt, zanim zbudujesz

   Prototyp, strona docelowa albo wersja ręczna. Zdobądź realny dowód, że ktoś tego chce, zanim zaangażujesz budżet.
2. 2
   Spisz brief i listę wersji drugiej

   Kilka jasnych stron, które każdy zrozumie, plus parking na każdy pomysł „skoro już przy tym jesteśmy”, by nie wykoleił v1.
3. 3
   Wybierz programistę po dorobku, nie po cenie

   Wdrożone prace, rozmowy referencyjne, jasna własność kodu i kont oraz ktoś, kto sam zadaje dobre pytania.
4. 4
   Zaplanuj budżet na cały pierwszy rok, nie tylko na budowę

   Hosting, utrzymanie, poprawki i wsparcie. Dzień startu to linia startu, więc sfinansuj działanie całości.
5. 5
   Wybierz najmniejszą platformę, która wykona zadanie

   W większości przypadków najpierw web lub rozwiązanie wieloplatformowe. W pełni natywne później, na podstawie dowodów, tylko jeśli wymaga tego użycie.
6. 6
   Przetestuj z prawdziwymi użytkownikami, potem zaplanuj start

   Popatrz, jak pięcioro obcych jej używa, napraw oczywiste wpadki i zdecyduj z góry, jak ludzie ją znajdą i jak zmierzysz użycie.

Częste pytania