Fuckup nie startup – o tym jak dwuletni projekt poleciał do kosza

F

1 950 000 linijek kodu. 24 miesiące. 9 programistów. 1 fuckup. Jak to się stało? Dziś opowiem wam o tym, czego nauczyłem się popełniając grzech za grzechem przy moim startupie, który trwał 2 lata. O całym fuckupie projektu miałem przyjemność mówić na wydarzeniu Luzer Experience w Pomorskim Parku Naukowo-Technologicznym w Gdyni 20 lipca 2017 roku. Jeśli zastanawiacie się czy wybrać się na kolejną edycję to szczerze polecam, dużo wiedzy, doświadczeń, nie raz płaczu do łez, ale też cennych wskazówek jak nie popełnić tych samych błędów we własnym projekcie.

o tym jak nie zabierać się za projekt
© Strefa Startup Gdynia

Przemyśl model biznesowy

Bez tego ani rusz. Mój model biznesowy był „kropką nad i” do decyzji o przeniesieniu do kosza całego projektu. W moim przypadku wydatków było więcej niż dochodów. Różnica sięgała blisko 95 tysięcy polskich złotych miesięcznie. Wysokie koszta utrzymania, wkład na marketing, promocja to wszystko kosztuje. Skąd brać pieniądze jak nie od użytkowników? Jeśli brać to ile? Jak ich zachęcić? Takie problemy mają nawet najwięksi. Jakiś czas temu Spotify ogłosiło, że będzie produkować głośniki, by zwiększyć dochody. Od pewnego czasu jeden z największych graczy w streamingu muzyki ma problemy z finansami. Tylko 15 mln użytkowników zdecydowało się kupić abonament. Pozostałe 45 mln woli korzystać z darmowej wersji[1]. Tak samo Facebook sięgnął sufitu. Użytkowników z roku na rok przybywa co raz mniej. Model biznesowy zaczyna się wypalać. Stąd też, społecznościowy gigant posuwa się do wdrażania nowych usług biznesowych – najbardziej widać to na przykładzie Facebook Ads Managera.

W dokładnym rozplanowaniu tego, na czym będziesz zarabiać może Ci bardzo pomóc business canvas.

business canva

MVP First

W świecie projektowania ważne jest podejście Mobile First. Ja po moim fuckupie wyciągnąłem bardzo cenny wniosek – MVP first. Bez tego nie jesteśmy w stanie zebrać feedbacku. Nie jesteśmy w stanie zaprezentować projektu potencjalnym inwestorom. Nie tworząc MVP odcinamy sobie drogę do ewentualnej zmiany założeń podczas trwania projektu. Niejako narzucamy sobie kaskadowość. Nad moim startupem pracowało łącznie 9 programistów. W 2 lata napisaliśmy setki tysięcy linii kodu. Tona rozgrzebanych funkcjonalności. Nic nie można przetestować bo większość nie działa. Nie oszukujmy się – świat idealny nie istnieje, produkt idealny w wersji 1.0 też nie 😉

UX Twym zbawieniem

W moim przypadku, gdzie w projekcie byli sami programiści, powstało wiele nieużytecznych rzeczy. Bo my, programiści, bardzo często zapominamy, że użytkownik końcowy może przecież nie wiedzieć czym jest kod błędu 522. Dla przykładu, programista zrobiłby tak:

a programista wraz z UX’em tak:

Projektowanie formularzy z uxem

I tak wiem, naginam rzeczywistość. Ale tak też się dzieje. W swoim otoczeniu, znam wielu programistów, którzy z użytecznością interfejsów nie mają wiele wspólnego. O tym, dlaczego warto projektować użytecznie napiszę kiedyś osobny artykuł.

Nieustannie monitoruj konkurencję

Na samym początku projektu zrobiłem analizę konkurencji. Przez czas trwania projektu zrobiła się ona nieaktualna – ku mojemu zdziwieniu wyrosła całkiem pokaźna konkurencja. Normalnie jak grzyby po deszczu wyskoczyli, a zanim się zorientowałem, zdominowali cały rynek. Z drugiej strony. Z konkurencji można się też cieszyć. Wejść, zobaczyć jak inni rozwiązali podobny problem. Zobaczyć na co skarżą się użytkownicy, sprawdzić czy ta konkurencja nie ma innej konkurencji, która dla nas może okazać się sojusznikiem. Dzięki temu, jesteśmy jeszcze w fazie projektowania uwzględnić to, co źle zrobili inni. Jedno jest pewne. Nigdy nie ignoruj konkurencji.

Zbierz feedback

Zjadłem na tym zęby. Mój punkt widzenia rozumiałem tylko ja. Nikt nie czuł produktu, który przez tak długi czas tworzyłem. Warto zbierać opinie innych, bo może się okazać, że to, co wydaje Ci się strzałem w dziesiątkę, dla innych może być totalną klapą.

Pracuj zwinnie

Zgodnie z manifestem Agile, miarą postępu projektu jest działające oprogramowanie. Zwinność to także umiejętność budowania MVP. Narzucając kaskadowość, nie jesteś w stanie zrozumieć czy podążasz w dobrym kierunku. mvp

Więcej o zwinności, scrumie i iteracyjności możesz dowiedzieć się na blogu Tomka, z którym miałem przyjemność pracować przez blisko rok. Jeśli miałbym polecić dobrego scrum mastera to na myśl przychodzi mi tylko on. Nie znam nikogo innego, kto tak dobrze czuje zwinność. Gorąco zachęcam do zapoznania się z jego notkami, zarówno dla żółtodziobów jak i zawodowych project managerów – każdy coś dla siebie znajdzie.

Słowem zakończenia

Nie bójmy się popełniać błędów. Fuckup to nic złego. Mówi się, że lepiej jest uczyć się na błędach innych – ale zapewniam, że nic nie daje tak do myślenia jak własne wtopy. Mniejsze, większe, to bez znaczenia. Projekt, nad którym spędziłem blisko 3 tysiące godzin dał mi naprawdę sporo. 19 nowych technologii, kilka ofert pracy, umiejętność zarządzania projektem oraz masa nowych znajomości. Gdyby ktoś mnie spytał czy gdybym wiedział od samego początku, że ten projekt się wywali, to czy chciałbym go nadal kontynuować – moja odpowiedź wciąż brzmi tak. Warto się samemu poparzyć, by móc trzeźwo myśleć przy kolejnym projekcie. No i można przy okazji podzielić się wiedzą na blogu 🙂

[1] – http://gadzetomania.pl/56827,spotify-ma-15-mln-placacych-uzytkownikow-to-duzo-niekoniecznie

O autorze

Filip Nowacki

Swoją przygodę z IT rozpoczął mając 13 lat, kiedy to stworzył swoją pierwszą stronę internetową. Obecnie pracuje jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Prywatnie maniak optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

2 komentarze