Tydzień 4/8 konkursu Firestarters, półmetek i walidacja na serio.

Książka, która zmieniła myślenie o podejściu do tworzenia produktów

Kilka lat temu przeczytałem „Lean Startup”. To książka, która okazała się kamieniem milowym w postrzeganiu tego jak tworzone są rewelacyjne produkty. Przed jej przeczytaniem, wydawało mi się, iż produkt najpierw powstaje, później jest promowany i na końcu sprzedawany użytkownikom. Książka świetnie pokazywała, na jakie pułapki nastawione są osoby budujące produkty w myśl takiej strategii. Jak wiele z naszych założeń, które zbyt późno zwalidujemy, może okazać się błędne, narazić nas na niepotrzebne koszta i spowodować, iż zbudujemy rewelacyjny produkt… z którego nikt nie będzie chciał skorzystać.

Lubię pozycje, które nie marnują mojego czasu. Taką jest Lean Startup, nieco ponad 200 stron, wypełniona po brzegi wiedzą.

Kod jest drogi, a rozmowa tania

Jako początkujący programista, zrozumiałem, iż przed napisaniem pierwszej linijki kodu, często lepiej zainwestować swój czas w inne działania. Może być tym rozmowa 1:1, wysłanie ankiety czy przeprowadzenie wywiadu na temat problemu, dla którego chcemy zbudować produkt (w końcu każdy produkt rozwiązuje jakiś problem, nie?)

Lean Startup + Waterfall to nie ma szansy się udać, gdy jesteś tylko programistą

Niestety pomimo ówczesnego zafascynowania tą pozycją, na przetestowanie tej wiedzy przyszło mi poczekać kilka lat. Aplikacja takich praktyk w firmie mocno nastawionej na realizację projektów w stylu waterfallowym jest trudna, a wręcz niewykonalna. Jako programista, jesteśmy tylko trybikiem procesu, który wykonuje swoją część, ale nie ma tam zbytnio miejsca na walidację, bo ta odbyła się lub nie na wcześniejszym etapie.

W firmie produktowej, tego typu praktyki dziś są już standardem

Aby poznać te zasady w praktyce, musiałem zmienić firmę na taką, która skupia się na budowie własnego produktu. Taką szansę, dał mi TomTom. Dołączając trafiłem w dobry moment. To wtedy bowiem ruszał pomysł zbudowania platformy do analizy danych ruchu drogowego i produktów, które miały ją zasilać. Przez praktyczne doświadczenia wynikające ze współpracy z rewelacyjnymi specjalistami od UX, poczułem na własnej skórze, iż rzeczy, o których pisał Eric Ries nie tylko działają, ale sprawiają, iż finalnie budujemy produkty lepszej jakości. To przez przeprowadzanie testów, wywiadów z użytkownikami, uświadomiłem sobie, jak mocno wpływa to na finalny produkt, który budujemy. Unikamy wtedy marnotractwa, skupiamy się na rzeczach najważniejszych dla naszych użytkowników i budujemy faktycznie coś, za co będą chętni zapłacić często niemałe pieniądze. Do samego wątku UX, jeszcze wrócę w dalszej części, ale wracając do głównego wątku.

Kolejna okazja do przetestowania porad od Erica

Dziś niemal dekadę później chciałbym wykorzystać te zasady w budowie własnego produktu. Miałem okazję przeprowadzić kilka dłuższych rozmów z osobami, które chcą wejść do branży w IT. Wysłałem też otwarte pytanie do grupy z mojej listy mailowej. Przez ostatni miesiąc zbierałem informacje, dziś czas na podsumowanie.

Mała dygresja, nie warto pytać ludzi wprost, bo jest mniejsza szansa, iż odpowiedzą, lepiej zapytać o chęć wzięcia udziału w badaniu (tip wyniesiony z Fabryki Kursów)

Informacje zbierałem do excela, aby łatwiej je kategoryzować i wyciągać z nich esencje.

Pierwsze pytanie – czyli co jest problemem

Pytanie brzmiało tak:

„Co jest największym wyzwaniem podczas nauki programowania i realizacji własnych projektów programistycznych?

Odpowiedzi

Bardzo różne, oto kilka najciekawszych (pisownia oryginalna)

1. Skąd pewność, iż to co robię jest dobre?
2. Brak mentora.
3. Jak pisać czysty kod.
4. Pisanie testów jest mozolne i nie wiem, jak ich użyć w projekcie.
5. POMYSŁ na projekt, nie zbyt prosty i nie strzał w kolano.
6. brak czasu, praca, rodzina
7. brak pomysłu
8. frontend backend – ciężko o odpowiedzi jak to zrobić dobrze?
9. Jak rozpocząć pracę w IT?
10. OAUTH2
11. Brak czasu, Brak motywacji i odpowiednio wysokiego priorytetu dla projektu, Małe dzieci –
12. Brak lub mocno ograniczony dostęp do mentora.
13. Brak wsparcia mentorskiego
14. Brak przykłady aplikacji, na których można się wzorować
15. Konsultacje o wiele ważniejsze od samego kursu, takie korepetycje
16. Ruszyć z miejsca, wysoki próg technologiczny, dużo wymagań związanych z dobrymi praktykami
17. Ilość wolnego czasu
18. Brak wsparcia osoby doświadczonej
19. Nomenklatura stosowana w programowaniu
20. Tutorial hell
21. brak mentora
22. Ruszyć z miejsca, wysoki próg technologiczny, dużo wymagań związanych z dobrymi praktykami
23. Wybór tematu, z reguły logika przykłada i blokuje postęp.
24. Brak wsparcia mentorskiego
25. …

Wśród odpowiedzi kilkakrotnie przewija się brak mentora i wsparcia, w obraniu dobrego kierunku. Niestety, ale najlepszy tutorial, często nie zastąpi współpracy na linii uczeń mentor.

Przy okazji, słyszeliście o Hey EDU? Rewolucji w edukacji, która nadchodzi wielkimi krokami i lada moment będzie miała swoją premierę? o ile nie, to koniecznie poczytajcie. To nasz rodzimy projekt, który łączy elementy grywalizacji, nauki w modelu ucznia i mistrza, wplatając w to wszystko NFT. Polecam śledzić, bo ten projekt ma ogromne szanse namieszać na rynku edukacji. Jest też ogromną inspiracją do tego jak powinna wyglądać edukacja nasza oraz naszych bliskich.

https://heyedu.com

Brak mentora to jeden problem, drugi to brak wytycznych i wskazówek jak to robić dobrze. Są też bardziej prozaiczne problemy jak brak czasu.

Pomimo tego, iż odpowiedzi nie odbiegały mocno o moich oryginalnych założeń, to nie spodziewałem się, aż tak dużego odsetka odpowiedzi poświęconego mentoringowi, czyli bliższej współpracy. Na pewno powinno to zostać zaadresowane w programie.

Pierwsze odpowiedzi, jakie otrzymałem, generowały okazję do dalszej wymiany maili i wyciąganie kolejnych istotnych komentarzy do problemu/projektu, który próbuję zwalidować.

Drugie pytanie – jakie elementy powinny być rozwiązaniem

Kolejnym pytaniem, jakie zadałem, było:

„Co powinno znaleźć się w takim programie?”

Odpowiedzi

(niektórzy byli bardzo hojni w dawaniu porad):

1. Jak zacząć
2. jak zaplanować projekt
3. Pisać samemu czy z kimś? jeżeli z kimś to gdzie go znaleźć i jak dobrać odpowiednią osobę
4. Jak przekonać bliskich, iż kolejna godzinka/dwie przy kompie to nie jest zły pomysł
5. Jak poradzić sobie z brakiem motywacji do ukończenia projektu
6. Jak wyznaczać sobie cele z projektu
7. Jak i czy w ogóle wyznaczać deadliny
8. Review?
9. Prokrastynacja przy pisaniu dla siebie
10. Kiedy pochwalić się swoim projektem
11. Pomysł na projekt spisać/opisać, przygotować wymagania czy pisać na żywca?
12. Jeśli nie dajemy rady, to czy „dopuścić” kogoś do naszego kodu? jeżeli tak to jak zwalczyć uczucie, iż nie jest na tyle idealny jakbyśmy chcieli
13. na pewno rzeczy rozszerzające wiedzę typu jUnit, Jira, SQL,
14. Nie podstawy, bo takich kursów jest już na pęczki
15. Konsultacje 1:1
16. Jak stworzyć aplikację z bazą, restem, np. sklep
17. Proces tworzenia projektów
18. Pomysł na projekt, jak odnaleźć tematykę, wbrew pozorom nie jest to takie proste
19. Wzorce projektowe z przykładami użycia
20. Dobre nawyki – nie, tylko żeby działało
21. Style guide
22. Zaplanowanie projektu, co po kolei i jak należy zrobić, przy bardziej rozbudowanym pokazać jak dzielić go na etapy.
23. Jak dzielić pracę na mniejsze części
24. Czemu dowożenie end to end jest ważniejsze od batchowego rozbudowywania jednej warstwy
25. Przykładowy projekt, przez który przeprowadzi klientów
26. Aktualność materiałów, społeczność i specjaliści aktywni na forum, gwaracja łatwiejszych rekrutacji do firm
27. …

Ten drugi zestaw wśród odpowiedzi, których oczekiwałem, dał też takie, których inicjalnie nigdy nie uwzględniłbym tworząc ten projekt samemu. Kilka moich ulubionych:

Czy projekt budować samemu, czy w drużynie? Kiedy inicjalnie rozpoczynałem pracę nad tym produktem, nie zakładałem, iż warto tutaj poruszać takie kwestie, bo większość projektów będzie realizowana solo. To pytanie spowodowało jednak, iż wcale tak nie musi być i kurs ten może adresować obydwa scenariusze z dobrym wyjaśnieniem konsekwencji dla wszystkich z nich.

Czy planować projekt, czy „pisać na żywca”? – w skrajnościach nigdy nie dzieją się dobre rzeczy, a realia mają odcień szarości Na pewno da się ten temat poruszyć na bazie czynników, jak chociażby to czy projekt realizujemy sami (pewnie proste README z sekcją roadmapy wystarczy) czy realizujemy projekt w kilka osób, gdzie jakiś poziom zaplanowania prac jest potrzebny. Kolejny punkt, którego bym nie poruszył, a znalazł się w odpowiedziach.

Ciekawa uwaga, aby nie poruszać podstaw. Jestem ogromnym fanem reużywania dobrych materiałów. Jeżeli, w sieci możemy znaleźć dobrej jakości materiały, które wyjaśniają jakieś zagadnienie, lepiej posłużyć się oryginałem, a samemu wnieść dodatkową wartość, nieuwzględnioną przez autora, np. częste błędy, na co zwrócić uwagę czy esencję.

Trzecie pytanie – gotowy na zakup?

Ostatnim elementem mojej konwersacji, było pytanie o chęć zakupu takiego programu i ile powinien kosztować.

Wszystkie odpowiedzi, które otrzymałem były twierdzące, tylko jedna osoba nie odpowiedziała na moje pytanie. Co do ceny, propozycje były bardzo różne, zaczynając od 50 zł, kończąc na 4000 zł. Taki rozstrzał nie powinien dziwić, w końcu podobnie wyglądałby zakres cen dla pytania ile kosztuje samochód.

Brakujący element walidacyjny

To wszystko powyżej, nie jest jednak wystarczającą walidacją. To prawda, dowiedziałem się i potwierdziłem szereg istotnych informacji na temat problemu i ewentualnego rozwiązania. o ile jednak daną ideę chcemy zweryfikować w pełni najlepszym podejściem jest poproszenie kogoś o wykonanie przelewu jako przedpłaty.

I to punkt, na którym skupię się w nadchodzącym tygodniu.

Skrót reszty istotnych informacji

Budżet bez zmian.

Do tej pory, nie miałem potrzeby zakupów. Jeszcze nie mam na swoim koncie pierwszego klienta. Niedługo, może się to jednak zmienić.

Testowałem https://www.easycart.pl/

Za namową Grzegorza w jednym z komentarzy pod moim poprzednim wpisem.

Panowie WOW! Wspominałem na początku, iż do tematu UX jeszcze wrócimy. To jest ten moment, kiedy warto wspomnieć, iż tak powinny wyglądać produkty, które rozwiązują konkretne problemy, a ich użycie jest intuicyjne i pozwala na szybkie eksperymentowanie ze zmianami. Na pewno w kolejnym tygodniu przyjrzę się bliżej i spróbuję wykorzystać w przedsprzedaży. Urzeka mnie prostota i dopasowanie do potrzeb grupy docelowej, do której kierujecie ten projekt. Oby mój realizował podobny cel

Nie miałem okazji sprawdzić easylms, to co mnie tam zastanawia, to kontekst użycia w ramach Webflow. Czy ktoś z zerową wiedzą na temat Webflow, da rade łatwo skonfigurować taki kurs?

Szukam platformy pod webinar

Zrobiłem, krótki research platformy webinarowej, ale przez cały czas nie mam nic na oku. Coś konkretnego polecacie? Podpytam też społeczność.

Rozpocząłem budowę agendy

W tym celu wykorzystuję Notion

Co dalej?

Priorytetem jest rozpoczęcie prac związanych z przedsprzedażą, czyli najlepszego sposobu walidacyjnego. Mam ustalony próg, od którego chciałbym ruszyć z pracą nad kursem. W pierwszej kolejności, chce zebrać fundusz na kilka zakupów potrzebnych do startu.