Skip to content

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ę, że 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ć, że 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, że 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, że rzeczy, o których pisał Eric Ries nie tylko działają, ale sprawiają, że 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, że 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ść, że 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

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ę? Jeżeli 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, że 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śli z kimś to gdzie go znaleźć i jak dobrać odpowiednią osobę
  4. Jak przekonać bliskich, że 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śli tak to jak zwalczyć uczucie, że 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

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, że warto tutaj poruszać takie kwestie, bo większość projektów będzie realizowana solo. To pytanie spowodowało jednak, że wcale tak nie musi być i kurs ten może adresować obydwa scenariusze z dobrym wyjaśnieniem konsekwencji dla każdego 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. Jeżeli 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, że do tematu UX jeszcze wrócimy. To jest ten moment, kiedy warto wspomnieć, że 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 nadal 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.