Современные стартапы программного обеспечения имеют значительное преимущество по сравнению с теми, что были даже пять-десять лет назад, отчасти из-за распространения гипермасштабируемых поставщиков облачного хостинга, таких как Google Cloud Platform (GCP), Amazon Web Services (AWS) и Microsoft Azure. Имея множество управляемых сервисов, доступных одним нажатием кнопки, они могут быстро создать прототип своего решения и вывести его на рынок в рекордно короткие сроки и практически в бесконечном масштабе. Хотя сегодня это может показаться проще, подготовка стартапа к масштабированию в облаке по-прежнему требует тщательного рассмотрения.

Мне посчастливилось быть частью различных технологических организаций более двадцати лет, от стартапов, созданных с нуля, до компаний, финансируемых венчурным капиталом и частным капиталом, и даже глобальных конгломератов с выходом на IPO. Учась у столь многих талантливых людей и наставников на этом пути, я выбираю извлеченные уроки, инструменты, методы и процессы для реализации.

Стремясь «заплатить вперед», я хотел бы поделиться некоторыми извлеченными уроками. В этой первой статье серии будут представлены концепции и ресурсы, которые я считаю полезными для создания и масштабирования программных стартапов. Во второй статье мы создадим вымышленный стартап онлайн-знакомств, чтобы проиллюстрировать, как эти части сочетаются друг с другом. В третьей статье мы иллюстрируем, как они в конечном итоге информируют вашу облачную архитектуру с помощью GCP.

• Часть 1: предыстория и введение в методологию
• Часть 2: внедрение методологий с фиктивным стартапом
• Часть 3: проектирование и масштабирование облачной инфраструктуры

В начале 2020 года я решил попробовать что-то новое; вместо того, чтобы создавать и развивать стартапы в области программного обеспечения, я начал консультировать и поддерживать их, присоединившись к облачному партнеру с корнями в Израиле по имени DoiT International . Наша компания полностью удалена и с тех пор выросла с 50 человек до почти 500 по всему миру всего за два года, поддерживая ежегодное потребление облака на сумму более 1 миллиарда долларов. Я постоянно восхищаюсь тем, как хорошо мы сохранили нашу культуру благодаря такому быстрому росту, привлекая и удерживая так много талантливых людей.

Тысячи организаций выбирают DoiT в качестве партнера по облачным услугам. Они получают выгоду от бесплатных консультаций и поддержки, а также передовых программных инструментов, предназначенных для реализации первоначального обещания облака — сосредоточьтесь на своем продукте и клиентах и ​​не беспокойтесь об остальном. Хотя нам хотелось бы думать, что это так просто, обычно этому предшествует наличие у наших клиентов высококвалифицированных технических групп.

Одна тенденция, которую я недавно заметил, — это рост стартапов программного обеспечения на более ранних стадиях, использующих облачные технологии, которые могут не иметь больших команд или глубоких знаний в области облачных вычислений. Как сам предприниматель в области программного обеспечения, я надеюсь, что обмен уроками, извлеченными как из моей «прошлой жизни», так и из DoiT, сделает ваше путешествие еще более успешным.

Первые дни

Отойдя от технологии, давайте сначала рассмотрим путь от выявления проблемы до создания компании, занимающейся ее решением, и дальше. Существует несколько популярных методологий и платформ, выходящих за рамки лучших облачных практик, которые вы сможете оценить по мере развития вашей организации.

Каждый метод, проиллюстрированный выше, сам по себе является итеративным , но, как мы увидим в следующей статье этой серии, результат каждого из них информирует другие.

TL;ДР; Полезные онлайн-ресурсы

Вместо того, чтобы объяснять описанные выше методы и концепции, я рекомендую посмотреть эти видеоролики, чтобы заполнить пробелы и послужить для нас основой для их практического применения.

• Стоит ли мне создавать стартап (14 мин.) — Майкл Сейбел, Y Combinator.
• Стратегия и планирование (9 мин.) — HBR [используйте одностраничный план, например OGSM]
• Краткий обзор бережливого стартапа (13 мин.) — Эрик Рис
• Проверка вашей бизнес-идеи (9 мин) — Эрик Рис
• Lean UX (60 мин.) — Джефф Готельф
• Использование холста Lean UX (15 мин) — Джефф Готхельф
• Building Product (59 мин.) — Майкл Сейбел, Y Combinator
• Как спланировать MVP (13 мин.) — Майкл Сейбел, Y Combinator .
• Картирование пользовательских историй (50 мин.) — Джефф Паттон
• Полное руководство по картированию пользовательских историй — Ник Малдун, Easy Agile
• Архитектура программного обеспечения с моделью C4 (35 мин) — Саймон Браун
• Создание культуры экспериментирования в Spotify (47 мин.) — Бен Дресслер
• DevOps vs SRE (44 мин.) — Сет Варго, Google

Как только вы осознаете проблему, которую считаете необходимым решить, это поможет нарисовать картину того, куда вы движетесь, и некоторые ключевые индикаторы того, что вы находитесь на пути к получению ценности. Это похоже на то, как Amazon требовала от команд подготовить пресс-релиз, в котором описывалось, что они будут создавать в будущем, прежде чем они были одобрены для его создания.

Около 10 лет назад во время однодневного совещания по планированию один наставник, который вывел свою компанию на биржу, а затем продал ее Oracle почти за 2 миллиарда долларов, познакомил меня с OGSM Framework . Это означает цели, цели, стратегии и меры. Это заставляет вас кратко нарисовать картину того, где вы будете через 3–5 лет в будущем, некоторые измеримые цели на этом пути, а также углубляться в стратегии и краткосрочные тактики для их достижения.

В итоге вы получаете одностраничный бизнес-план, живой документ , который вы пересматриваете и уточняете, вокруг которого вся команда может сплотиться и согласовать фокус всех действий. Например, если какое-то действие не соответствует стратегии, определенной для достижения цели, вы задаетесь вопросом, действительно ли это стоит делать, или вам нужно обновить свою стратегию.

Некоторым может быть интересно, в чем отличие от другого популярного фреймворка Цели и ключевые результаты (ОКР). OGSM смотрит на годы вперед, тогда как OKR в основном фокусируется на краткосрочных целях. В зависимости от стадии вашей компании внедрение OKR может иметь смысл, но часто единственное долгосрочное видение, за которое все могут сплотиться, — это необходимая «Полярная звезда».

Есть много других методов, таких как SWOT-анализ, 5 сил Портера, сбалансированная система показателей или 3 горизонта McKinsey, которые могут быть использованы в вашем общем стратегическом плане, но OGSM остается моим личным инструментом для сужения фокуса команды на том, что важно, и обмена информацией. большее видение.

идея

Руководящие принципы и процессы на раннем этапе вашего пути могут помочь скоординировать команды по мере вашего роста. Я считаю, что культура, основанная на данных, и мышление, основанное на измерении всего, должны быть частью вашей культуры, исходить с самого верха и проявляться в каждом взаимодействии.

Несколько моих любимых ресурсов, которые укрепляют эту экспериментальную культуру, включают Lean Startup (и Lean Canvas) Эрика Риса и Lean UX Джеффа Готельфа. Почти каждый консультант и инкубатор стартапов советует основателям измерять все, быстро повторять и создавать минимально жизнеспособный продукт (MVP), чтобы проверить свою идею на рынке. Все это соответствует принципам «бережливого производства».

Джефф Готельф развивает принципы «бережливого производства» в том направлении, которое мне нравится, потому что они применимы к каждой команде, отделу и идее в организациях любого размера. Посылка заключается в том, что «мы ничего не знаем», и для того, чтобы узнать [чего хотят клиенты] и что действительно решает проблему, мы применяем научный метод — формулируем гипотезу, проверяем ее при измерении, анализируем результаты и корректируем курс по мере необходимости. . Ценность этого подхода заключается в минимизации ненужных усилий и подтверждении того, что вы решаете правильные проблемы быстрее.

Дизайн

Когда я вижу, как люди пренебрегают документированием архитектуры своих систем и программного обеспечения, это напоминает мне человека, пытающегося построить дом из кучи бревен. Конечно, в конце концов вы сможете это понять, но если бы у вас был план, вы бы работали намного быстрее и с меньшим количеством ошибок. Два моих любимых метода разработки продуктов включают картографирование пользовательских историй и модель C4 .

Записывая вещи, вы обеспечиваете общее понимание и возлагаете на всех ответственность за выполнение того, что было согласовано.

Несколько лет назад меня пригласили в качестве докладчика на ежегодный саммит технических директоров частной инвестиционной компании Francisco Partners . Я присутствовал на других заседаниях, и одним из самых интригующих было то, что один из партнеров консультировал других технических директоров и руководителей портфолио по отслеживанию показателей в их продуктовых организациях. Одна из метрик, которая меня удивила, но теперь имеет смысл, — это измерение количества переделок для оценки эффективности менеджеров по продукту. С тех пор я спрашивал других инженеров-лидеров, оценивают ли они доработку, и большинство из них ценят это, но пока не делают этого.

Переделка — это ключевой показатель, на который вы можете повлиять, потратив время на то, чтобы понять клиента и расставить приоритеты в предоставлении им самой быстрой ценности. Это именно то, чему помогает упражнение по отображению пользовательских историй, принуждая к сотрудничеству между различными заинтересованными сторонами. Мой аргумент в пользу этого на любом этапе компании заключается в том, что гораздо дешевле и быстрее перемещать несколько ящиков на общей доске, чем запускать циклы разработки, которые позже приводят к доработке.

Я первый должен признать, что в свое время у меня было несколько уродливых архитектурных диаграмм; Я был свидетелем даже большего. Важно уделить время тому, чтобы записать вашу архитектуру и ее связь с другими системами. Модель C4 — один из лучших способов сделать это стандартным способом, не требуя знания UML. Как описано в приведенных выше ссылках на видео, стандартной практикой является проектирование до 3 уровней в глубину (представление компонентов). Существуют продукты, такие как IcePanel , которые упрощают эту задачу, или различные плагины или инструменты на других платформах. Это быстрее, чем вы думаете, и мы проиллюстрируем это в следующей статье этой серии.

Строить

Предположим, ваша команда хорошо разбирается в этом этапе. По мере вашего роста принятие четко определенной структуры для реализации идеологии Agile может помочь вам в масштабировании. Если вы следуете принципам «бережливого производства» и меняете свои приоритеты на основе обучения, вы уже на правильном пути. По мере того как фокус организации смещается со скорости и инноваций на рост и стабильность, помните о переломных моментах и ​​составе команды на этом пути.

Вводить в действие

Наряду с усовершенствованием методов разработки продуктов вам также необходимо поддерживать культуру совместной ответственности. Здесь вступают в действие принципы DevOps. Google поделился своей реализацией DevOps под названием Site Reliability Engineering (SRE), и многие организации переняли эти методы.

Хотя может и не быть необходимости в отдельной команде или функции, минимальное укомплектование команд инженерами, имеющими склонность к эксплуатации, мониторингу и автоматизации, принесет дивиденды. Мы рассмотрим эти концепции более подробно, когда будем углубляться в пример стартапа и определять его архитектуру и облачную инфраструктуру.

Планирование роста

По мере того, как стартап выходит за пределы небольшой группы основателей, возрастает и сложность коммуникации и управления, как показано ниже.

Компании решили эти проблемы масштабирования, распознав переломные моменты своего бизнеса и сформировав специальные, в основном автономные, команды для решения конкретных задач.

Отличным ресурсом по масштабированию вашей команды разработчиков программного обеспечения, например, является этот пост в блоге Сета Бланка , который я настоятельно рекомендую прочитать. Бланк предупреждает, что процессы, а в некоторых случаях даже люди, которые помогли компании подняться с мертвой точки, могут в какой-то момент стать препятствием для ее будущего роста и масштабируемости, или их лучше всего направить на «следующее». Именно здесь 3 горизонта McKinsey становятся актуальными для будущего стратегического планирования. И наоборот, другой Бланк, Стив Бланк, утверждает, почему сегодня это уже недействительно .

Существует еще один ресурс под названием « Topologies Team », который предоставляет практическую, пошаговую, адаптивную модель для проектирования организации и командного взаимодействия. Основное внимание уделяется оптимизации организации и платформы с помощью того, что они называют самой тонкой жизнеспособной платформой (TVP).

Еще одна концепция, которую я считаю полезной для масштабирования организации или продукта, — это AKF Partners Scale Cube . Я впервые узнал об этом много лет назад, когда на него ссылались в книге под названием « Искусство масштабирования », которую я купил для руководителей своей команды в предыдущем запуске — это также еще один полезный справочник в любое время, когда нужно переходить к соответствующим главам.

Однако почти все могут с этим согласиться, поскольку ваша компания продолжает расти и формирует выделенные команды, вместе с этим растет потребность в управлении и четко определенных процессах, документации, наставничестве и обучении. Недавно я был свидетелем того, как многие организации на этом этапе также искали рекомендации о том, как лучше всего структурировать свою облачную инфраструктуру, чтобы эффективно разместить свои многочисленные команды. Мы обратимся к этому позже в этой серии.

Во второй части этой серии мы исследуем объединение этих частей для проектирования, создания и масштабирования вымышленного стартапа программного обеспечения для онлайн-знакомств.

Спасибо, что дочитали до этого места, и я надеюсь, вам понравится вторая часть .