W pierwszej części tej serii przyjrzeliśmy się metodologiom i frameworkom, które uważam za pomocne w budowaniu i rozwijaniu startupów programistycznych. Celem tego wpisu jest zilustrowanie, w jaki sposób można zastosować te techniki, aby zminimalizować zmarnowany wysiłek i jak planowanie w zakresie oprogramowania przekłada się na infrastrukturę chmurową.

Warunki wstępne dla postępu

• Przeczytałeś pierwszą część serii
• Zapoznałeś się z frameworkami/metodologiami, które eksplorujemy poniżej, oglądając linki wideo udostępnione w części 1

Powyższy diagram ilustruje kluczowe koncepcje wspomnianych metodologii. W tym poście zabawimy się, wymyślając fikcyjny start-up randkowy i „skaluj go”. Zilustrujemy stosowanie tych zasad i związek między strategią firmy a potrzebami dotyczącymi produktów i rozwoju oraz sposób, w jaki wpływają one na nasz projekt infrastruktury chmurowej.

Zidentyfikuj problem, który rozwiązujemy i dla kogo

Załóżmy, że ty i inni macie dość samotności, a istniejące rozwiązania tego nie załatwiają. Byłeś na weselach, właściwie za dużo, byłeś w barach, a nawet wypróbowałeś popularne aplikacje, ale nadal czujesz, że czegoś brakuje. Pasjonujesz się tym problemem i wierzysz, że jesteś zespołem, który pomoże rozwiązać ludzką samotność, w tym własną. Najpierw przeanalizujmy potencjalne strategie innych rozwiązań.

Zastrzeżenie

Nigdy nie korzystałem z aplikacji do randek online, więc po prostu „zgaduję”, jakie funkcje i funkcje zawierają. Korzystając z tego, co jest w telewizji lub w nagłówkach na temat różnych popularnych aplikacji, możemy udawać, że budujemy konkurenta. Jeśli moje założenia są dalekie lub jeśli nie badamy każdego rodzaju relacji, proszę o zawieszenie niedowierzania w celu zilustrowania tych koncepcji .

eHarmonia

Ta usługa miała teorię, że dopasowując w oparciu o naukowy profil osobowości, ludzie czuliby się mniej onieśmieleni. Ich strategia polega na uczynieniu osobowości głównym czynnikiem, przyciągną ludzi mniej pewnych swojego wyglądu, którzy wciąż są samotni, wykorzystując niewykorzystany rynek.

Tinder

Ta usługa miała teorię, że wiele osób jest samotnych, ale nie szukających długotrwałych związków. Ich strategia polegała na zastąpieniu przypadkowych połączeń i zdobyciu tej części rynku.

Bumble

Ta usługa miała teorię, że kobiety czułyby się bardziej komfortowo na platformie, gdyby mogły wybrać, z kim się angażują. Ich strategia polegała na tym, aby kobiety zdecydowały, czy wysłać pierwszą wiadomość po meczu.

eTumble — NOWOŚĆ!

Wychodzimy z założenia , że ​​ludzie są samotni, a rozwiązania na rynku nie rozwiązały jeszcze problemu samotności w skali globalnej . Wierzymy, że zwycięskie rozwiązanie jest połączeniem wszystkich trzech powyższych. Podejrzewamy, że w głębi duszy przypadkowe osoby poszukujące znajomości wolałyby mieć szansę na głębsze osobiste połączenie poprzez wstępne dopasowanie osobowości, ale kobiety dokonują wyboru, czy wejść w interakcję.

Praktyki Lean Startup zalecają działanie jak „wielki eksperyment”, przyjmowanie śmiałych założeń , a następnie obserwację (nie pytanie) zachowań użytkowników, podczas szybkich iteracji. Często wyrzucamy pomysły za pomocą płótna „Lean” , ale zakładamy, że nasz zespół już to zrobił powyżej. Zacznijmy!

Zaczynając od wizji i strategii

Analiza SWOT

Uznając zarówno siły wewnętrzne (mocne strony, słabe strony), jak i zewnętrzne (szanse, zagrożenia), możesz wykorzystać analizę SWOT, aby lepiej określić, co musi się wydarzyć, aby odnieść sukces.

Ta analiza dostarcza informacji do projektowania produktu podczas testowania hipotez dotyczących rozwiązywania nieuniknionych wzlotów i upadków. Na przykład, jeśli duża rotacja użytkowników jest zagrożeniem, możesz nadać priorytet funkcjom, które sprawiają, że ludzie wracają na Twoją platformę. Biorąc pod uwagę słabość, był brak doświadczenia psychologicznego w zespole, wiesz podczas zatrudniania lub przyciągania doradców, do których należy kierować. Jeśli zespół ma ograniczone doświadczenie z konkurencyjnymi aplikacjami, wiesz, że zadaniem jest ich używanie i umawianie się na randki — wygrana, wygrana.

Zdefiniuj wstępny plan strategiczny za pomocą OGSM

Twoim celem na wczesnym etapie będzie szybkie uruchomienie minimalnego opłacalnego produktu (MVP), aby rozpocząć obserwację zachowań użytkowników i iteracyjne testowanie hipotez. W świecie oprogramowania często żartujemy, że prototypy zawsze stają się produkcją, pomimo naszych najlepszych intencji. Zainwestowanie kilku dni na burzę mózgów z zespołem w celu udokumentowania strategii i środków może zmniejszyć liczbę przeróbek i przyspieszyć projektowanie i rozwój produktu — zobaczmy, jak to zrobić poniżej.

Zauważ, że w powyższym przykładzie OGSM zaczynamy już identyfikować nasze przyszłe potrzeby w zakresie zespołu, produktu, wskaźników i infrastruktury. Będziemy potrzebować wiedzy z zakresu aplikacji mobilnych, uczenia maszynowego i tworzenia interfejsów API. Będziemy również potrzebować tłumaczeń językowych, zaciemniania tekstu i obrazu oraz akceptowania płatności online. W przypadku odbiorców na całym świecie musimy spełniać wymogi prawne i dotyczące prywatności, zwłaszcza w Unii Europejskiej.

Oszczędny UX

Lean UX jest lepiej znany w zespołach produktowych, gdzie autor Jeff Gothelf miał swoje skromne początki. Skuteczność przekazywania wszelkich pomysłów za pomocą twierdzeń hipotez gwarantuje świadomość w całej organizacji, a nie tylko w zespołach produktowych. Myślę, że Lean UX należy do strategii i wizji i jest używany wszędzie.

Każda strategia, a następnie taktyka (funkcja) w powyższym planie ZWZA jest zasadniczo hipotezą. Im częściej wyrażamy nasze pomysły w tej strukturze, tym bardziej stają się one wykonalne i skoncentrowane. Na przykład strategię, zgodnie z którą osiągniemy nasze cele poprzez „zapewnienie bezpieczniejszego miejsca do interakcji”, można sformułować w następujący sposób:

„Wierzymy, że [miliony użytkowników] dołączą do naszej usługi, jeśli [kobiety] [czują się bezpieczniej w interakcji] z [tylko one zdecydują się zainicjować rozmowę po meczach]”.

Przekłada się to luźno na „Wierzymy, że [wynik biznesowy] zostanie osiągnięty, jeśli [użytkownik] osiągnie [korzyść] dzięki [funkcji]”. zgodnie z opisem w kanwie Lean UX. Czasami zamieniam ten format na inny, zdefiniowany w zwinnych zasadach „Product Discovery”, ale założenie jest takie samo — ustrukturyzowana komunikacja .

Możesz zobaczyć iteracyjny charakter tych metodologii podczas ich łączenia. Jeśli jeszcze tego nie zrobiłeś, zachęcam do przejrzenia filmów o Lean UX w części 1 tej serii .

Projekt produktu

Wracając do zasad „szczupłego” podejścia, kiedy już masz odważne założenia lub hipotezy dotyczące problemu, który rozwiązujesz, dla kogo go rozwiązujesz i jak zamierzasz go rozwiązać, musisz je szybko powtórzyć i przetestować.

Zamiast pytać użytkowników, zawsze najlepiej jest obserwować ich zachowanie, aby zweryfikować swoje założenia, dlatego zaleca się uruchomienie MVP. W produkcie na żywo możesz również wykorzystać narzędzia do testów A/B lub flagi/przełączniki funkcji.

Nie musimy od razu pomijać wszystkich funkcji w naszym OGSM, aby przetestować nasze teorie, ale teraz mamy całościowe zrozumienie tego, dokąd zmierzamy. Następnie ustalamy priorytety tego, co musi zaoferować nasz MVP, aby zmaksymalizować wartość dla użytkownika, ponieważ szybko przeprowadzamy kolejne iteracje . W tym celu wykorzystamy mapowanie historii użytkowników .

Mapowanie historii użytkownika

To, co widzisz powyżej, to już wersja szósta! Rozpoczynając od całościowego spojrzenia, szybko nakreśliłem ogólną podróż użytkownika. Następnie przejrzałem pudełka i zmieniłem priorytety historii użytkowników, aby zidentyfikować najmniejszą kwotę, jaką moglibyśmy dostarczyć, aby przetestować pożądane wyniki dla docelowych odbiorców.

Testując po drodze hipotezy, stosujesz swoje odkrycia i nadal edytujesz te „żywe dokumenty” w zwinny sposób, zamiast marnować czas na stagnację szczegółowych specyfikacji.

C4 Architektura modelu

Mamy teraz informacje, które pomagają nam zdefiniować nasze oprogramowanie i architekturę systemu, ale robienie tego w znormalizowany sposób jest często pomijane. Upewnij się, że masz plan (lub schemat) tego, co budujesz, aby skutecznie komunikować się z innymi interesariuszami. Podczas gdy UML pozostaje długoletnim standardem, dzisiaj polecam lżejszy model C4 .

Dla zwięzłości tego artykułu zilustrujemy częściowy przykład naszej architektury dla eTumble. Chociaż istnieją 4 poziomy C 4 , standardową praktyką jest ilustrowanie tylko tak głębokie, jak jest to wymagane; poziom „Kod”, który faktycznie byłby notacją UML, jest zwykle pomijany.

Jak zauważono w moim zastrzeżeniu powyżej, jest to fikcyjna aplikacja i nigdy nie korzystałem z internetowego serwisu randkowego, więc są to wyuczone domysły, aby zilustrować ten proces.

Często zaczynam szkicować pomysły na papierze, aby przemyśleć projekt. Kiedy już mam ogólne pojęcie o tym, co jest potrzebne, wymieniam elementy architektury, aby wydobyć szczegóły. Na przykład wiemy, że będziemy potrzebować bazy danych, ale nasza strategia zakłada grę globalną. Musimy zdecydować, czy możemy zacząć od Postgres czy MySQL do uruchomienia i jak trudna może być później migracja do systemu rozproszonego, takiego jak Cockroach DB lub Cloud Spanner GCP.

Doświadczając czasami „blokady pisania”, gdy wpatruję się w ramki i linie na ekranie, stwierdzam, że używanie arkusza kalkulacyjnego takiego jak poniżej ułatwia przenoszenie elementów lub wstawianie wierszy, gdy myślę o większej liczbie rzeczy, przed utworzeniem diagramu.

W niektórych aplikacjach możesz po prostu skopiować/wkleić, tak jak w IcePanel , pokazanym poniżej. Istnieje wsparcie dla Markdown, które jest jeszcze szybsze, gdy już się zaznajomisz.

Mamy nadzieję, że pokazuje to, jak szybko możesz przenieść to, co zapisałeś, do narzędzia do tworzenia diagramów — tworzenie pięknych diagramów zajmuje niecałą godzinę. Wyobraź sobie, że współpracujesz z projektantami i inżynierami z powyższymi projektami i o ile szybciej (i taniej) byliby.

Skalowanie rzeczy

Wcześniejsze wskazówki, że „wyskalujemy to”, oznaczały, że przewidujemy nasze przyszłe potrzeby w oparciu o nasz plan strategiczny i nasz ogólny widok zilustrowany na mapie fabularnej. Wspomniałem wcześniej o kostce AKF Scale Cube i stosując jej zasady osi xyz doszedłem do wniosku, że nasza globalna skala i dziesiątki milionów użytkowników będą potrzebować bezstanowego projektu, systemu sterowanego zdarzeniami, architektury mikrousług i ostatecznie wielu zespołów, z hostingiem obejmującym wiele regionów geograficznych na platformie chmury publicznej.

• Nasza oś x ( duplikat i skalowanie w poziomie ) jest dostosowana do bezstanowych aplikacji kontenerowych i hostingu w chmurze publicznej.
• Nasza oś y ( specjalizacja ) jest obsługiwana przez specjalnie zbudowane mikrousługi, uruchamiane przez HTTP/RPC lub wiadomości Pub/Sub. Pomagają one również określić, w jaki sposób prawdopodobnie rozwiniesz swoje zespoły, pozwalając autonomii i luźnym powiązaniom na posiadanie kluczowej wartości w systemie; często jest to zgodne z bazowym UX przedstawionym na mapie fabuły.
• Nasza oś Z ( podział podobnych rzeczy ) jest dostosowana do regionalizacji. Nie omawiamy tego w pełni w naszym fikcyjnym przykładzie. Załóżmy, biorąc pod uwagę globalną strategię, że ograniczenia jurysdykcyjne dotyczące systemów i suwerenności danych, waluty obce, języki i przyszłe strategie sprzedaży kanałowej Go-to-Market (GTM) mogą wpływać na sposób, w jaki skalujemy tę oś. Może nawet opierać się na tym, gdzie znajdujemy/przyznajemy talent dla naszego zespołu, lub nawet, jak opisuje „Topologie zespołu”, na obciążeniu poznawczym zespołu.

Czego się nauczyliśmy i zbudowaliśmy do tej pory:

Czas spędzony do tej pory na projektowaniu eTumble, naszego fikcyjnego startupu randkowego:

• Szczupłe [Uruchomienie | UX] — nie zilustrowaliśmy tego, ale zwykle jest to moment, w którym zaczynasz pisać, jaki problem rozwiązujesz, dla kogo rozwiązujesz i jakie korzyści/wartość oferujesz. Możesz na przykład zweryfikować swój pomysł za pomocą „MVP zasłony dymnej” i strony docelowej. Obejrzyj filmy w części 1 , aby dowiedzieć się więcej.
• Analiza SWOT — zidentyfikowaliśmy pozytywy, które chcieliśmy wykorzystać, i negatywy, które musimy rozwiązać, informując o naszym planie OGSM. (30 min; spodziewaj się kilku godzin)
• Plan OGSM — zidentyfikowaliśmy kluczowe funkcje, technologie, wskaźniki i zespół, których będziemy potrzebować do wdrożenia naszej strategii, informując o naszej mapie historii. (1 godz.; spodziewaj się 1–2 dni)
• Mapa historii — zorganizowaliśmy i uszeregowaliśmy historie użytkowników, identyfikując naszego kandydata MVP, informując o naszej holistycznej architekturze, jak pokazano powyżej. (3 godziny; spodziewaj się 1–2 dni)
• Architektura modelu C4 — zidentyfikowaliśmy potrzebne systemy, bazy danych i komponenty, informując o wymaganej infrastrukturze. (3 godziny; spodziewaj się 2–5 dni)

Napędzany tymi „żywymi dokumentami”, nasz zespół i interesariusze mają teraz wspólne zrozumienie , dlaczego robimy to, co robimy, jak planujemy wygrać (lub przynajmniej teorie do przetestowania) i co zamierzamy zbudować, aby rozwiązać problem z dużym obrazem.

Zainwestowanie tego czasu na współpracę i zapisywanie upraszcza również proces projektowania infrastruktury chmury, repozytoriów kodu źródłowego oraz monitorowania / wskaźników, które będą nam potrzebne do obsługi eTumble. Omówimy to i wiele więcej w części 3 tej serii .

Dziękuję za przeczytanie do tej pory i mam nadzieję, że spodoba ci się bardziej techniczna głęboka analiza w części 3 .