Deweloper jest jak hydraulik. Czyli jakich rzeczy unikać zlecając stworzenie aplikacji?

Sęk w tym, że zadanie stworzenia aplikacji zlecili „fachowcom”. Podobnym do tych z dialogów Jonasza Kofty i Stefana Friedmanna.

Na zdjęciu (od lewej): Artur Świętonowski i Marcin Podleś z Deming SSC

Dwa lata opóźnień

iGPS jest młodą polską firmą, która stworzyła własne urządzenie GPS. W swych pracach wykorzystali protokoły zalecane przez wielką siódemkę producentów samochodów, dzięki czemu sprzęt bezbłędnie współpracuje z komputerem pokładowym. Potrzebna była jednak aplikacja. O ile firma miała kompetencje elektroniczne, to problem był z tymi stricte programistycznymi. iGPS wiedział jak zaplanować aplikację, nie potrafił jednak jej napisać. Twórcy odpowiedniego sofware’u szukano więc na zewnątrz.

– Znaleźliśmy firmę, która oferowała usługi programistyczne, reklamowała się w Internecie, a ich strona nas zachęciła, podpisaliśmy umowę. Wydawało się, że wszystko jest w porządku – opowiada Adam Welsz z iGPS. – Ale kiedy zaczęły się problemy nauczyliśmy się, że nieważne, że ktoś mówi, że coś robi. Ważne jest to czego nie mówi. A nie mówi tego, czego nie potrafi – konkluduje.

Okazało się, że firma, która podjęła się stworzenia aplikacji, do tej pory realizowała jedynie znacznie prostsze zlecenia. Pomimo zapewnień, nie potrafili sobie poradzić m.in. ze stworzeniem algorytmów, które radziłyby sobie z dekodowaniem i pakietowaniem informacji z urządzenia.

– Firma przeciągała terminy realizacji, nie odpowiadała na telefony – opowiada Zaleski. Prace nad stworzeniem odpowiedniego software’u trwały dwa lata i wciąż nie było efektu. Kiedy iGPS zdecydowało się na szukanie nowego wykonawcy – usłyszało słynne zdanie: Kto Wam to tak… zrobił? Okazało się, że na etapie tworzenia użyto niewłaściwych narzędzi implementacji.

PHP traktuje zmienne jak ciąg znaków, a to utrudniało dekodowanie treści binarnych z rejestratorów. Czas płynął, pojawiały się błędy, a to spowalniało rozwój biznesu.

Zapłać, a ja to zrobię… kiedyś

Podobną historię opowiadał podczas Fuckup Nights Warszawa Marcin Chłopaś, który wymyślił Runguru – wirtualnego trenera dla biegaczy. Na taki pomysł wpadł na długo przed tym, zanim ogromną popularność zdobyły programy typu Endomondo czy Strava. Aplikacja dofinansowana z programu POIG 8.1 Innowacyjna Gospodarka powstawała w bólach. Podpisana umowa określała zarówno terminy powstawania kolejnych modułów, jak i płatności, które mają być dokonane.

Jak mówi sam założyciel Runguru – niemałe problemy stworzyło to, że deweloper miał zagwarantowaną płatność w terminie (inaczej środki unijne nie mogłyby zostać rozliczone). Marcin Chłopaś nie miał więc realnych narzędzi wpływu na podwykonawcę. Kończyło się to tak, że często otrzymywał produkt, który wymagał późniejszych poprawek. A te kosztowały. Najtańsza oferta stawała się najsłabszą.

Poprawkom nie było końca. Zamiast napisać kod raz a dobrze, aplikacja powstawała po kawałku i z ciągłymi poprawkami. Za które założyciel firmy musiał płacić już w 100 procentach z własnej kieszeni.

– Jeśli miałbym kiedykolwiek tworzyć jeszcze aplikację dla mojego biznesu, to nigdy więcej nie będę kierował się ceną. Wolę dołożyć, ale mieć pewność, że będzie to dobrze wykonane – mówił Marcin Chłopaś podczas Fuckup Nights Warszawa. Sytuację z zagwarantowaną płatnością skomentował zaś zdaniem: – Czy ktoś z Was zapłaciłby parkieciarzowi zanim położy parkiet?

Amatorzy i profesjonaliści

Gros innowacyjnych pomysłów na biznes opiera się na stworzeniu odpowiedniej aplikacji. W czasie, kiedy powstawał ten artykuł, przynajmniej trzy razy widziałem na facebookowym wallu poszukiwania programistów do realizacji zlecenia. A jeśli w firmie nie mamy odpowiednich kompetencji programistycznych – możemy zabić nawet najlepszy pomysł i zniweczyć cały wysiłek, jaki włożyliśmy w jego realizację.

Ale jak, samemu nie kodując, odróżnić amatora, który może nam mydlić oczy pięknymi słowami od profesjonalisty, który po prostu dobrze wykona swoją robotę?

– Dobry programista stara się zrozumieć co jest produktem całościowym jego pracy. Nie ogranicza się do programowania wąskich funkcjonalności bez zrozumienia całości. Znajomość kontekstu umożliwia znajdowanie rozwiązań bardziej spójnych dla całości oraz wpływa na bardziej spójny kod – komentuje powyższe historie Artur Świętonowski, Partner w software-house Deming SSC.

– Ważna jest też umiejętność patrzenia na aplikację z pozycji użytkownika. Uwzględnienie punktu widzenia użytkownika w tworzonym produkcie zdecydowanie skraca czas realizacji – dodaje.

Ogromną rolę pełni też zarządzanie projektem. Już na etapie analizy wymagań, można zauważyć sygnały, które mogą świadczyć o powodzeniu projektu. Dobrym znakiem jest to, jeśli programista rozpatruje, uwzględniając odpowiednie aspekty, różne warianty realizacji celu, a nie ogranicza się do „gotowców”. Profesjonalista też nie boi się powiedzieć, czego w danym momencie nie potrafi zrobić. Amator – często nawet sobie nie zdaje z tego sprawy.

– Nie można ograniczać się do „wytwórstwa”. Do programowania trzeba podejść kreatywnie. Wypracowane rozwiązania należy testować i optymalizować – mówi Marcin Podleś z Deming SSC. – Często dobry programista jest tak naprawdę artystą ze wszystkimi minusami i plusami z tego wynikającymi. Dobry menedżer musi umieć wykorzystać te plusy i radzić sobie z minusami – puentuje.

Bez umiejętności zarządzania projektem łatwo wpaść w pułapkę przekroczenia czasu realizacji (casus iGPS) lub założonego budżetu (casus Runguru). Znana zasada mówi, że nie da się zrobić czegoś tanio, szybko i dobrze. Bez względu na to, czy mowa o instalacji hydraulicznej, czy o przełomowej aplikacji, która mogłaby podbić świat… Gdyby tylko była gotowa na czas.

–

Podobne historie porażek poznacie podczas kolejnych edycji Fuckup Nights Warszwa. MamStartup jest partnerem medialnym tej imprezy. Więcej szczegółów na facebookowym profilu FUN.Warszawa.

–

Tomasz Staśkiewicz

organizator Fuckup Nights Warszawa

Mówca motywacyjny/bloger/content manager