Czarny scenariusz Twojego projektu, czyli co może pójść nie tak, jeśli…

Nie każdą współpracę można zaliczyć do udanych. Przyczyny wybrania nieodpowiedniego usługodawcy mogą być różne – może zależeć Ci na bardzo szybkim starcie aplikacji, możesz kierować się ceną usługi, możesz zaufać przedstawicielowi software house, który obieca Ci, że firma w czasie i budżecie dostarczy złote góry.

Niestety, po pewnym czasie okazuje się, że złote góry istnieją w sprzedażowych bajkach, a Twoją rzeczywistością jest kilkukrotnie przekroczony budżet bądź produkt niskiej jakości.

W ciągu współpracy z różnymi firmami usłyszeliśmy wiele opowieści o podejmowaniu złych decyzji oraz ponoszeniu ich konsekwencji. Zamiast czekać z nauką na popełnienie własnych błędów, możesz zobaczyć już teraz, jakie mogą być skutki wyboru nieodpowiedniego usługodawcy bądź pominięcia istotnych etapów w trakcie trwania realizacji.

…jeśli nawiążesz współpracę jedynie z wykonawcami, a nie kompetentnymi partnerami, którzy zwracają uwagę na cele i wartości biznesowe.

Masz pomysł na platformę internetową – innowacyjne narzędzie, serwis czy portal. Dopracowujesz swoją wizję od tygodni, zbierasz środki na jej realizację. To będzie Twój pierwszy start-up, ale jesteś pewien, że aplikacja doskonale odpowie na zapotrzebowania rynku. Dotychczas nie konsultowałeś z wieloma osobami swojej idei, pielęgnując ją samodzielnie.

Budżet postanawiasz przeznaczyć na opracowanie MVP – minimalnej wersji Twojej platformy. Nawiązujesz współpracę z firmą, która pozwoli Ci jak najszybciej przekazać produkt w wersji minimum Twojej grupie odbiorców. Przekazujesz wytyczne zespołowi, który prawie natychmiast rozpoczyna prace deweloperskie.

Po niespełna dwóch miesiącach publikujecie platformę w wersji produkcyjnej – dostępnej dla użytkowników. Aplikacja wygląda dokładnie tak, jak sobie to wyobrażałeś. Analizujesz  zachowania odbiorców, ich interakcje z systemem, to, jak postrzegają Twój produkt. I okazuje się, że… nie chcą korzystać z Twojego rozwiązania. Że Twój pomysł do nich nie trafił i ciężko będzie jakkolwiek przerobić platformę, by zdobyć ich zainteresowanie.

Utopiłeś kilkadziesiąt (lub nawet kilkaset) tysięcy złotych w realizację projektu, który nie został ciepło przyjęty na rynku. Całe szczęście, że nie postawiłeś od razu na budowę pełnej platformy!

Co poszło nie tak?

Najpewniej przekazałeś swoją ideę wykonawcom, którym zabrakło biznesowego krytycznego spojrzenia. To mógł być software house, który skupia się jedynie na realizacji usługi, a nie na dostarczeniu produktu budującego satysfakcję klienta i użytkownika. Kod Twojej platformy mogli tworzyć najlepsi deweloperzy, ale zabrakło kogoś, kto doradziłby, czy rzeczywiście Twoja wizja ma biznesowy potencjał, czy nie lepiej będzie ją nieco przekształcić lub obrać inny kierunek.

Jak można było temu zapobiec?

Przekazanie platformy w wersji MVP grupie odbiorców nie musi (a wręcz nie powinno!) być pierwszym etapem weryfikacji pomysłu. Doświadczeni i świadomi pracownicy software house’u z pewnością wsparli niejeden start-up i mają nie tylko techniczne, ale też biznesowe zaplecze, z którego możesz korzystać. Bądź otwarty na konstruktywną krytykę i doradztwo – jak ognia wystrzegaj się potakiwaczy, którzy nie mają absolutnie żadnych uwag czy propozycji!

…jeśli pominiecie etap analizy przedwdrożeniowej.

Twoja firma planuje stworzyć wewnętrzne narzędzie – rozbudowaną platformę, która ma wesprzeć efektywność działań pracowników. Jako osoba odpowiedzialna za wdrożenie narzędzia, wiesz doskonale, jakie procesy ma wspierać system, jakie powinien posiadać funkcje, jak użytkownicy mają wchodzić z nim w interakcję. Nawiązujesz współpracę z software house’m, rozmawiacie o wizji i kształcie produktu, ustalacie, kiedy platforma będzie gotowa. Zespół deweloperski startuje z pracami.

Z każdym kolejnym sprint review masz coraz większe wątpliwości, czy usługodawca wyrobi się w ustalonym terminie. Coraz częściej zauważasz, że zespół ma problemy z zamykaniem na czas wyznaczonych etapów. Powoli dociera do Ciebie, że obiecujące ustalenia dotyczące terminu oraz budżetu tak naprawdę nie były poparte żadnymi twardymi danymi.

Pracownicy software house’u są dopiero w połowie prac, a już zbliżacie się do wykorzystania ustalonego budżetu. Twoja firma jednak zainwestowała już zbyt wiele, by przerwać realizację. Kontynuujecie współpracę, lecz tak naprawdę żadna ze stron nie potrafi określić, jak kosztowne będzie całe przedsięwzięcie.

Co poszło nie tak?

Zapewne pominęliście etap analizy przedwdrożeniowej, czego skutki odczuwacie przez cały czas trwania projektu. Budowanie nowej platformy bez odpowiedniego zaplanowania działań, co za tym idzie, opracowania realnych estymacji czasowych, terminu i budżetu, skutkuje przedłużeniem się realizacji bądź stworzeniem złego jakościowo rozwiązania. 

Jak można było temu zapobiec?

Oczywiście, przeprowadzić rzetelną analizę wymagań (analizę przedwdrożeniową). Im większą realizację ma do przeprowadzenia Twoja firma, tym większą wagę powinniście przyłożyć do etapu planowania i tworzenia odpowiedniej dokumentacji. Analiza wymagań obejmuje zapoznanie się z potrzebami klienta, opracowanie specyfikacji funkcjonalnej i technicznej, przygotowanie planu architektury, planu prac oraz określenie rzeczywistego budżetu i realnego terminu oddania w pełni funkcjonalnej wersji platformy. Ma też wpływ na płynną realizację produktu – podczas prowadzenia analizy zespół tworzy backlog (spis działań i prac, jakie należy wykonać), w oparciu o który realizuje kolejne etapy prac.

…jeśli nie zadbacie o odpowiednią jakość od samego początku.

Planujesz budowę platformy. Zależy Ci na szybkim czasie realizacji. Dobrze, by koszt też nie był zbyt wysoki. Zatrudniasz software house, który zaproponował jedną z bardziej atrakcyjnych cen. Po kilku miesiącach współpracy otrzymujesz funkcjonujący produkt.

Twój zespół, samodzielnie lub we współpracy z wykonawcami, utrzymuje i rozwija platformę. Po pewnym czasie – kilku miesiącach, roku, dwóch latach – zauważasz, że na utrzymanie aplikacji i rozwiązywanie problemów przeznaczasz dużo większą kwotę, niż na jej rozwój. Dodanie nowej funkcjonalności bądź modyfikacja istniejącej łączą się z wystąpieniem błędu lub awarii. Każda kolejna rozbudowa oznacza coraz większą liczbą problemów. Rozwój jest bardzo kłopotliwy lub wręcz niemożliwy. Przez przeznaczanie większej części budżetu na utrzymanie niż na rozbudowy, zostajesz w tyle za swoją konkurencją. Widzisz, jak inne firmy rozwijają systemy, wchodzą na kolejne rynki i nawiązują nowe współprace, kiedy wy walczycie o podstawową stabilność systemu. Zastanawiasz się pewnie, co mogło pójść nie tak – przecież to nowa platforma!

Co poszło nie tak?

Usługodawca, z którym tworzyłeś platformę, nie dostarczył odpowiednio wysokiej jakości. Możliwe, że do realizacji projektu zaangażował po swojej stronie niewystarczająco kompetentne osoby – pracowników o niewielkim doświadczeniu, deweloperów, którzy dopiero poznają technologię lub zespół, który dotychczas ze sobą nie współpracował. Całkiem prawdopodobne, że próbując zachować niską cenę usługi przy szybkim czasie realizacji, pominął istotne elementy, takie jak przeprowadzenie analizy przedwdrożeniowej, odpowiednie opracowanie specyfikacji czy przygotowanie planu prac. W efekcie otrzymałeś nowy produkt, który nie był dostosowany do tego, by go bezpiecznie i stabilnie rozwijać.

Jak można było temu zapobiec?

Przy wyborze usługodawcy powinieneś był kierować się nie tylko ceną czy czasem wykonania, ale zwrócić też uwagę na doświadczenie firmy – przejrzeć portfolio, realizacje, może nawet skontaktować z jednym z klientów, by zapytać o referencję. Jeśli wykonawca nie może pochwalić się projektami zrealizowanymi w interesującej Cię technologii, nie powinieneś podejmować współpracy. Masz też możliwość samodzielnej “rekrutacji” osób do zespołu. Jest to oczywiście częste działanie podczas nawiązywania współpracy z freelancerami, ale też coraz częściej praktykuje się to w software house’ach. Firma może dać Ci możliwość przeprowadzenia rozmowy z deweloperami i weryfikację ich umiejętności przez rozwiązanie kilku zadań.

W trakcie trwania realizacji kontroluj na bieżąco jakość dostarczanego rozwiązania i nie wahaj się zwracać zespołowi uwagi na błędy czy niskojakościowe rozwiązania.

Migracja funkcjonalności na wersję 2.0 systemu

Przeniesienie istniejącej platformy na nową, przejrzystą strukturę 2.0. Pełne zniwelowanie długu technologicznego, wprowadzenie skalowalności i możliwości nieograniczonego rozwoju systemu.

…jeśli potraktujecie testy po macoszemu.

Nawiązujesz współpracę z firmą, która ma przeprowadzić usługę dla Twojej platformy. Może być to optymalizacja prędkości, zmiana UX i UI, przebudowa kilku funkcjonalności. Ustaliliście, jakie prace będą wykonywane, w jakim terminie otrzymasz platformę po zmianach w wersji UAT (user acceptance testing) oraz kiedy wersja będzie dostępna dla użytkowników końcowych – Twoich klientów czy pracowników Twojej firmy.

Po ustalonym czasie otrzymujesz dostęp do wersji po zmianach. Zadowolony, że realizacja idzie zgodnie z planem i firma przygotowała wszystko w terminie, zaczynasz “przeklikiwać” platformę. Po paru kliknięciach niestety już wiesz, że nawet nie musisz przekazywać wersji swoim deweloperom czy testerom, by wychwycić błędy. Zaczynasz wypisywać elementy, które nie działają, w tym również te, które funkcjonowały zanim software house ruszył z realizacją usługi. Nie mija godzina, a Ty masz już długą listę uwag. Absolutnie nie możecie opublikować platformy z błędami – cały harmonogram prac wziął w łeb.

Co poszło nie tak?

Firma, której zleciłeś realizację, nie przyłożyła wystarczająco dużej wagi do testów. Możliwe, że zaniedbali jakość już na etapie prac deweloperskich. Nie zmienia to jednak faktu, że błędy powinny zostać wskazane przez specjalistów QA po stronie wykonawcy (specjalistów quality assurance, którzy dbają o zapewnienie między innymi odpowiedniego poziomu jakości, użyteczności czy funkcjonalności aplikacji) i poprawione przez zespół programistów przed przekazaniem Tobie produktu. Możliwe, że software house źle zaplanował prace, a Twój budżet został skonsumowany głównie na development, przez co zostało mało czasu na odpowiednie przetestowanie aplikacji. Inną możliwością jest też, że jakość była weryfikowana przez osobę o niskich kompetencjach lub przez pracownika, który po prostu nie przyłożył się do zadania.

Jak można było temu zapobiec?

Taka sytuacja nie powinna mieć miejsca. Dobry software house nie pozwoli sobie na przekazanie klientowi platformy, na której znajdują się błędy. By jednak zmniejszyć prawdopodobieństwo wystąpienia tego scenariusza, możecie razem z wykonawcą ustalić harmonogram prac, w którym będzie przewidziana odpowiednia ilość czasu na sprawdzenie jakości. Przed uruchomieniem realizacji możecie ustalić też rodzaj prowadzonych testów oraz to, kto będzie odpowiedzialny za ich realizację – czy będzie to senior z wieloletnim doświadczeniem, czy pracownik na niższym stanowisku. 

…jeśli nie zadbacie o odpowiedni poziom bezpieczeństwa informacji.

W piątkowy wieczór wychodzisz do baru. Pijąc drugą lampkę wina czy zaczynając kolejną szklankę whisky, słysz z drugiego końca sali, jak ktoś mówi o funkcjonalnościach, które do złudzenia przypominają te z systemu Twojej firmy. To był trudny tydzień, ale czy jesteś aż tak zmęczony, by mieć omamy słuchowe? W pewnym momencie serce podskakuje Ci do gardła – słyszysz nazwę swojego przedsiębiorstwa. Jak to się stało?!

Innym razem otrzymujesz informację od swojego pracownika, że znalazł na GitHubie plik zamieszczony przez dewelopera z partnerskiego software house’u, zawierający fragmenty kodu źródłowego Twojej platformy. Kod aplikacji, który powinien być najdokładniej strzeżonym elementem całego biznesu, jest dostępny dla każdego – łącznie z Twoją konkurencją!

Co poszło nie tak?

Te sytuacje brzmią abstrakcyjnie, ale naprawdę mogą mieć miejsce, jeśli firma, z którą współpracujesz, nie przywiązuje odpowiedniej wagi do bezpieczeństwa informacji i zaniedbuje wewnętrzne procesy kontroli danych “wynoszonych” poza projekt. Twój produkt jest też zagrożony, jeśli Ty i wykonawca nie macie podpisanej umowy o zachowaniu poufności, znanej też jako NDA (non-disclosure agreement).

Jak można było temu zapobiec?

Dobry software house dba o to, by zapewnić odpowiednie zabezpieczenie kodu źródłowego platformy, utajnić nieoficjalne wersje Twojej platformy (środowiska deweloperskie czy testowe) oraz posiada zasady, które uniemożliwiają pracownikom wynoszenie informacji poza firmę. Możesz zapytać, jakie praktyki zabezpieczania informacji są stosowane w software house, z którym planujesz nawiązać współpracę.

Podstawą bezpieczeństwa Twojego projektu powinno być podpisanie wspomnianej umowy o zachowaniu poufności. Jeśli wykonawca sam nie wyjdzie z propozycją sporządzenia dokumentu, powinna zapalić Ci się lampka ostrzegawcza.

Tym optymistycznym akcentem…

Niektóre z tych historii wydarzyły się naprawdę. Część była inspirowana opowieściami, którymi podzielili się z nami klienci oraz partnerzy biznesowi. 

Bezpieczniej (i przede wszystkim taniej) jest uczyć się na cudzych błędach. Również wychodzimy z tego założenia i zawsze przed rozpoczęciem współpracy – czy realizacji pojedynczej usługi, czy długotrwałej kooperacji – analizujemy potencjalne zagrożenia i planujemy procesy.

Jeśli masz wizję produktu lub plan na ulepszenie istniejącej platformy i zależy Ci na wysokiej jakości, terminowości i stabilności, skontaktuj się z naszymi specjalistami. Nawet jeśli nie zdecydujesz się na przeprowadzenie realizacji z nami, doradzimy Ci, na jakie elementy powinieneś zwrócić uwagę podczas trwania projektu.