Dzisiejsze startupy programistyczne mają znaczną przewagę nad tymi, które istniały jeszcze pięć do dziesięciu lat temu, po części z powodu mnożenia się dostawców hostingu w chmurze hiperskalowej, takich jak Google Cloud Platform (GCP), Amazon Web Services (AWS) i Microsoft Azure. Dzięki mnóstwu usług zarządzanych dostępnych za jednym kliknięciem, mogą szybko prototypować swoje rozwiązanie i wprowadzać je na rynek w rekordowym czasie i na niemal nieskończoną skalę. Choć dziś może się to wydawać prostsze, przygotowanie startupu do skalowania w chmurze nadal wymaga starannego rozważenia.

Mam to szczęście, że od ponad dwudziestu lat jestem częścią różnych organizacji technologicznych, od start-upów typu „greenfield bootstrapped”, po firmy finansowane z funduszy venture capital i private equity, a nawet globalne konglomeraty z IPO. Ucząc się po drodze od tak wielu utalentowanych ludzi i mentorów, „wybieram” wyciągnięte wnioski, narzędzia, techniki i procesy do przeprowadzenia.

Aby „przekazać to dalej”, chciałbym podzielić się kilkoma zdobytymi doświadczeniami. Ten pierwszy artykuł z serii przedstawi koncepcje i zasoby, które uważam za przydatne do budowania i skalowania startupów programistycznych. W drugim artykule , zaprojektujemy fikcyjny startup randkowy, aby zilustrować, jak te elementy pasują do siebie. W trzecim artykule ilustrujemy, w jaki sposób ostatecznie wpływają one na architekturę chmury za pomocą GCP.

• Część 1: tło i wprowadzenie do metodologii
• Część 2: wdrażanie metodologii z fikcyjnym startupem
• Część 3: projektowanie i skalowanie infrastruktury chmurowej

Na początku 2020 roku postanowiłem spróbować czegoś nowego; zamiast budować i rozwijać startupy programistyczne, zacząłem im doradzać i wspierać, dołączając do partnera w chmurze z korzeniami w Izraelu o nazwie DoiT International . Nasza firma jest w pełni zdalna i od tego czasu rozrosła się z około 50 osób do prawie 500 na całym świecie w nieco ponad dwa lata, obsługując ponad 1 miliard USD rocznego zużycia chmury. Nieustannie jestem pod wrażeniem tego, jak dobrze udało nam się zachować naszą kulturę dzięki tak szybkiemu rozwojowi, przyciągając i zatrzymując tak wielu utalentowanych ludzi.

Tysiące organizacji wybiera DoiT jako swojego partnera w zakresie usług w chmurze. Korzystają z bezpłatnego doradztwa i pomocy technicznej oraz najnowocześniejszych narzędzi programowych zaprojektowanych w celu spełnienia pierwotnej obietnicy chmury — skup się na swoim produkcie i klientach, a nie martw się o resztę. Chcielibyśmy myśleć, że to takie proste, ale zwykle poprzedzają to nasi klienci, którzy mają dogłębnie wykwalifikowane zespoły techniczne.

Jednym z trendów, który ostatnio zauważyłem, jest wzrost liczby startupów zajmujących się oprogramowaniem na wcześniejszym etapie, które wdrażają technologię chmury, które mogą nie mieć dużych zespołów ani wiedzy na temat głębokiej chmury. Jako przedsiębiorca zajmujący się oprogramowaniem mam nadzieję, że dzielenie się lekcjami wyciągniętymi zarówno z mojego „poprzedniego życia”, jak iz DoiT sprawi, że Twoja podróż będzie jeszcze bardziej udana.

Wczesne dni

Oddalając się od technologii, najpierw zbadajmy drogę od zidentyfikowania problemu do zbudowania firmy zajmującej się jego rozwiązaniem i nie tylko. Istnieje kilka popularnych metodologii i ram wykraczających poza najlepsze praktyki w chmurze, które możesz docenić w miarę dojrzewania Twojej organizacji.

Każda technika zilustrowana powyżej jest sama w sobie iteracyjna , ale jak zobaczymy w następnym artykule z tej serii, dane wyjściowe każdej z nich informują inne.

TL;DR; Pomocne zasoby internetowe

Zamiast wyjaśniać powyższe techniki i koncepcje, polecam obejrzenie tych filmów, aby wypełnić luki i posłużyć jako elementarz do wprowadzenia ich w życie.

• Czy powinienem zbudować startup (14 min) — Michael Seibel, Y Combinator
• Strategia a planowanie (9 min) — HBR [użyj 1-stronicowego planu, takiego jak OGSM]
• Podsumowanie Lean Startup (13 min) — Eric Ries
• Weryfikacja pomysłu na biznes (9 min) — Eric Ries
• Lean UX (60 min) — Jeff Gothelf
• Korzystanie z płótna Lean UX (15 min) — Jeff Gothelf
• Produkt budowlany (59 min) — Michael Seibel, Y Combinator
• Jak zaplanować MVP (13 min) — Michael Seibel, Y Combinator
• Mapowanie historii użytkownika (50 min) — Jeff Patton
• Kompletny przewodnik po mapowaniu historii użytkowników — Nick Muldoon, Easy Agile
• Architektura oprogramowania z modelem C4 (35 min) — Simon Brown
• Budowanie kultury eksperymentowania w Spotify (47 min) — Ben Dressler
• DevOps a SRE (44 min) — Seth Vargo, Google

Kiedy już rozpoznasz problem, który musisz rozwiązać, warto namalować obraz tego, dokąd zmierzasz, oraz niektórych kluczowych wskaźników, które są na dobrej drodze do dostarczenia wartości. Jest to podobne do tego, w jaki sposób Amazon wymagał od zespołów sporządzenia komunikatu prasowego opisującego, co będą budować w przyszłości, zanim zostaną one zatwierdzone do zbudowania.

Około 10 lat temu, podczas całodziennej sesji planowania, mentor, który wprowadził swoją firmę na giełdę, a następnie sprzedał ją firmie Oracle za prawie 2 miliardy dolarów, przedstawił mi OGSM Framework . Oznacza cele, cele, strategie i środki. Zmusza cię to do zwięzłego namalowania obrazu tego, gdzie będziesz w przyszłości za 3–5 lat, z pewnymi wymiernymi celami po drodze, jednocześnie zagłębiając się w strategie i taktyki krótkoterminowe, aby je osiągnąć.

Kończysz z jednostronicowym biznesplanem, żywym dokumentem , który przeglądasz i udoskonalasz, wokół którego cały zespół może się skupić i skupić wszystkie działania. Na przykład, jeśli jakieś działanie nie jest zgodne ze strategią zdefiniowaną w celu osiągnięcia celu, zastanawiasz się, czy naprawdę warto to robić, czy też aktualizujesz swoją strategię.

Niektórzy mogą się zastanawiać, czym różni się od innego popularnego frameworka Objectives and Key Results (OKR). OGSM patrzy w przyszłość na lata, podczas gdy OKR koncentruje się głównie na celach krótkoterminowych. W zależności od etapu Twojej firmy, wprowadzenie OKR może mieć sens, ale często pojedyncza długoterminowa wizja, za którą każdy może się zmobilizować, to potrzebna „Gwiazda Północna”.

Istnieje wiele innych technik, takich jak analiza SWOT, 5 sił Portera, zrównoważona karta wyników lub 3 horyzonty McKinseya, które mogą stanowić część ogólnego planu strategicznego, ale OGSM pozostaje moim osobistym narzędziem do zawężania koncentracji zespołu na tym, co ważne, i dzielenia się większa wizja.

Ideacja

Zasady przewodnie i procesy na wczesnym etapie Twojej podróży mogą pomóc w dostosowaniu zespołów w miarę rozwoju. Wierzę, że kultura oparta na danych i sposób myślenia o mierzeniu wszystkiego muszą być częścią Twojej kultury i pochodzić z samej góry oraz być widoczne w każdej interakcji.

Kilka moich ulubionych zasobów, które wzmacniają tę eksperymentalną kulturę, to Lean Startup (i Lean Canvas) autorstwa Erica Riesa oraz Lean UX autorstwa Jeffa Gothelfa. Prawie każdy doradca i inkubator startupów radzi założycielom, aby wszystko zmierzyli, szybko wykonali iteracje i zbudowali minimalny opłacalny produkt (MVP), aby przetestować swój pomysł na rynku. Wszystko to rezonuje z zasadami „Lean”.

Jeff Gothelf kieruje się zasadami Lean w kierunku, który kocham, ponieważ dotyczy każdego zespołu, działu i idei w organizacjach dowolnej wielkości. Założeniem jest „nic nie wiemy” i aby dowiedzieć się [czego chcą klienci] i co naprawdę rozwiązuje problem, stosujemy metodę naukową — formułujemy hipotezę, testujemy ją podczas pomiaru, analizujemy wyniki i w razie potrzeby korygujemy kurs . Wartość tego podejścia polega na zminimalizowaniu zmarnowanego wysiłku i potwierdzeniu, że szybciej rozwiązujesz właściwe problemy.

Projekt

Kiedy jestem świadkiem, jak ludzie zaniedbują dokumentowanie swoich systemów i architektury oprogramowania, przypomina mi to kogoś, kto próbuje zbudować dom ze stosu drewna. Pewnie, że w końcu możesz to rozgryźć, ale byłbyś znacznie szybszy i popełniał mniej błędów, gdybyś miał plan. Dwie z moich ulubionych technik projektowania produktów to mapowanie historyjek użytkownika i model C4 .

Zapisując wszystko, zapewniasz wspólne zrozumienie i pociągasz wszystkich do odpowiedzialności za dostarczenie tego, co zostało uzgodnione.

Kilka lat temu zostałem zaproszony jako prelegent na coroczny szczyt CTO firmy private equity (PE), Francisco Partners . Brałem udział w innych sesjach i jedną z najbardziej intrygujących był jeden z partnerów doradzający innym CTO i dyrektorom portfeli w zakresie śledzenia wskaźników w ich organizacjach produktowych. Jednym z mierników, który mnie zaskoczył, ale teraz ma sens, jest pomiar ilości przeróbek w celu oceny skuteczności menedżerów produktu. Od tego czasu pytałem innych liderów inżynierii, czy mierzą przeróbki, i większość to docenia, ale jeszcze tego nie robi.

Przeróbki to kluczowy wskaźnik, na który możesz wpłynąć, poświęcając czas na zrozumienie klienta i priorytetowo traktując dostarczanie mu jak najszybszej wartości. Właśnie to ułatwia mapowanie historyjek użytkownika, jednocześnie wymuszając współpracę między różnymi zainteresowanymi stronami. Moim argumentem za tym, na każdym etapie firmy, jest to, że znacznie taniej i szybciej jest poruszać się po kilku polach na wspólnej tablicy, niż rozpoczynać cykle rozwoju, które później skutkują przeróbkami.

Jako pierwszy przyznaję, że miałem w swoim życiu kilka brzydkich diagramów architektury; Byłem świadkiem jeszcze więcej. Ważne jest, aby poświęcić trochę czasu na zapisanie swojej architektury i jej relacji z innymi systemami. Model C4 to jeden z najlepszych sposobów na zrobienie tego w standardowy sposób bez konieczności znajomości UML. Jak opisano w powyższych linkach wideo, standardową praktyką jest projektowanie do 3 poziomów głębokości (widok komponentów). Istnieją produkty, takie jak IcePanel , które to ułatwiają, lub różne wtyczki lub narzędzia na innych platformach. Jest szybszy, niż myślisz, i zilustrujemy to w następnym artykule z tej serii.

Budować

Załóżmy, że Twój zespół jest dobrze zorientowany w tej fazie. W miarę rozwoju przyjęcie dobrze zdefiniowanych ram w celu wdrożenia ideologii Agile może pomóc w skalowaniu. Jeśli postępujesz zgodnie z zasadami „Lean” i zmieniasz swoje priorytety w oparciu o naukę, jesteś już na dobrej drodze. Gdy nacisk organizacji przesuwa się z szybkości i innowacji na wzrost i stabilność, należy pamiętać o punktach zwrotnych i składzie zespołu po drodze.

Zoperacjonalizować

Wraz z dojrzewaniem praktyk opracowywania produktów będziesz także chciał zachować kulturę współodpowiedzialności. Tutaj wchodzą w grę zasady DevOps. Google udostępnił swoją implementację DevOps o nazwie Site Reliability Engineering (SRE), a wiele organizacji przyjęło te praktyki.

Chociaż może nie być konieczne posiadanie oddzielnego zespołu lub funkcji, minimalna obsada zespołów z inżynierami, którzy mają skłonność do operacji, monitorowania i automatyzacji, przyniesie dywidendy. Przyjrzymy się tym koncepcjom bardziej szczegółowo, gdy zagłębimy się w przykładowy start-up i zdefiniujemy jego architekturę i infrastrukturę chmurową.

Planowanie wzrostu

Gdy startup rozwija się poza mały zespół założycielski, rośnie również złożoność komunikacji i zarządzania, jak pokazano poniżej.

Firmy rozwiązały te wyzwania związane ze skalowaniem, rozpoznając punkty przegięcia ich działalności i tworząc dedykowane, w większości autonomiczne zespoły, aby stawić czoła określonym wyzwaniom.

Doskonałym źródłem informacji na temat skalowania zespołu oprogramowania jest na przykład ten wpis na blogu autorstwa Setha Blanka , który gorąco polecam przeczytać. Blank ostrzega, że ​​procesy, a w niektórych przypadkach nawet ludzie, którzy pomogli firmie wystartować, mogą w pewnym momencie stać się przeszkodą w jej przyszłym rozwoju i skalowalności lub najlepiej wskazać „następną rzecz”. W tym miejscu 3 Horyzonty McKinsey stają się istotne dla przyszłego planowania strategicznego. I odwrotnie, inny Blank, Steve Blank, argumentuje, dlaczego dzisiaj już nie obowiązuje .

Istnieje inny zasób o nazwie „ Topologie zespołu ”, który zapewnia praktyczny, krok po kroku, adaptacyjny model projektowania organizacji i interakcji w zespole. Nacisk kładziony jest na usprawnienie organizacji i platformy za pomocą tego, co nazywają najcieńszą realną platformą (TVP).

Inną koncepcją, którą uważam za przydatną do skalowania organizacji lub produktu, jest kostka AKF Partners Scale Cube . Po raz pierwszy dowiedziałem się o tym wiele lat temu, kiedy wspomniano o tym w książce zatytułowanej „ The Art of Scalability ”, którą kupiłem dla kierowników mojego zespołu podczas wcześniejszego start-upu — jest to również kolejne przydatne odniesienie w dowolnym momencie, umożliwiające przechodzenie do odpowiednich rozdziałów w razie potrzeby.

Jednak prawie wszyscy mogą się zgodzić, że wraz z rozwojem firmy i tworzeniem dedykowanych zespołów rośnie konieczność zarządzania i dobrze zdefiniowanych procesów, dokumentacji, mentoringu i szkoleń. Ostatnio byłem świadkiem, jak wiele organizacji na tym etapie również szukało wskazówek, jak najlepiej ustrukturyzować swoją infrastrukturę chmurową, aby wydajnie obsłużyć wiele zespołów. Zajmiemy się tym w dalszej części tej serii.

W części 2 tej serii , badamy łączenie tych elementów w celu zaprojektowania, zbudowania i skalowania fikcyjnego start-upu oprogramowania randkowego.

Dziękuję za doczytanie do tego momentu i mam nadzieję, że część 2 wam się spodoba .