Грамотная статья, классифицирующая стадии жизненного цикла компании. Начиная с идеи (основание стартапа) до поиска Product-Market-Fit (через MVP и поиск инвестора для экспериментов), далее идет выход на рынок и рост (growth/scale), после чего идет этап зрелости и оптимизации (Maturity).

Сразу же захотелось наложить эту классификацию на модель из Digital Practitioner. Уж очень стадии близки и ровно ложатся друг на друга: Team of teams – однозначно стадия роста, Enterprise – стадия зрелости и оптимизации.

А еще на модель из книги Crossing the Chasm. Product-Market-Fit – как раз этап преодоления пропасти.

Ок, это все про мысли и будущее публикации. Давайте поговорим про модель из статьи и про роль архитектора на каждом из этапов. Поехали!

Этапы жизненного цикла

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

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

1. Поиск идеи (Ideation)
   • Вы нашли сообщество с проблемой, для которой нет удовлетворительного решения;
   • Вы подтвердили, что достаточно людей готовы платить за решение этой проблемы (потенциал рынка);
   • Вы сформулировали гипотезу решения этой проблемы.
2. MVP
   • Вы создали минимально жизнеспособный продукт, с самой базовой версией ключевой функции, которую вы предлагаете;
   • Вы протестировали ценностное предложение и каналы вашего MVP, собрав отзывы от потенциальных клиентов и изучив их;
   • Вы решили, нужно ли доработать минимально жизнеспособный продукт или переключиться на новый MVP.
3. Поиск инвестиций (Investment)
   • Вы подготовили свой стартап к получению инвестиций правильным образом;
   • Вы проверили, на каком этапе финансирования вам следует сосредоточиться в данный момент;
   • Вы изучили лучших инвесторов для вашего бизнеса, подготовили свою презентацию и начали развивать отношения с ними.
4. Product-market fit
   • Вы находитесь на хорошем рынке с продуктом, который удовлетворяет этот рынок;
   • Вы наблюдаете устойчивый и предсказуемый рост пользователей и доходов;
   • Вы видите хорошие показатели удержания клиентов.
5. Выход на рынок (Go-to-market)
   • Вы нашли маркетинговые, сбытовые, ценовые стратегии и стратегии удержания клиентов, которые сохраняют ваши CАС и LTV на здоровом уровне;
   • Эти стратегии не легко скопировать конкурентам, так как вы создали вокруг них защитные барьеры;
   • У вас есть повторяемая, масштабируемая и прибыльная модель генерации доходов.
6. Рост (Growth/Scale)
   • Вы достигли соответствия продукта рынку, выхода на рынок и прибыли;
   • Вы наблюдали устойчивый рост на протяжении длительного периода времени;
   • Вы нашли успешные стратегии для поддержания этого роста, такие как приобретение других компаний или выход на новые рынки.
7. Зрелость (Maturity)
   • Вы красавчик. Радуйтесь жизни
   • Оптимизируйте продукт или же:
     • переходите к пункту 4 (с другим продуктом);
     • или п5 (с другим маркетом);
     • или п1 (с другой идеей).

Применение к архитектуре и архитекторам

Теперь, когда мы знакомы со стадиями стартапов, поговорим о ключевых аспектах и роли архитектора в каждой из них.

Ideation – Investment

Слоган: некогда думать – трясти нужно.

Первые стадии. Тут важны коммуникации, исследование вашей аудитории, работа с инвесторами.

С точки зрения технологий важно умение быстро “на коленке” слепить прототип, потом MVP, чтобы показывать демонстрации как пользователям, так и инвесторам.

Архитектор на данном этапе не нужен – достаточно адекватного Тим Лида в роли CTO. Не мешать разработчикам “творить” и умение собрать демо-стенд для “звонка инвесторам через полчаса” – ключевые требования.

Product-Market-Fit

Слоган: добыли карту сокровищ – давайте искать клад.

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

На данном этапе важна гибкость и умение быстро ставить эксперименты. Т.е. архитектура должна поддерживать эксперименты. Так же она не должна ограничивать – иначе ее “выкинут”. Необходимо уметь считать метрики – чтобы понять успешность экспериментов. Для этого нужно уметь интегрироваться с системами сбора и анализа данных.

С точки зрения разработки происходит развитие dev-excellence процессов (continious delivery, configuration management (как умение версионировать и мигрировать схему данных), DevOps, …). Если об этом не позаботились на предыдущих этапах.

Go-to-Market

Слоган: вроде клад нашли – давайте его выкопаем.

У вас есть решение, есть пользователи которые хотят это решение – нужно им его дать.

На этом этапе происходит наведение порядка, адаптация продукта к рынку. Т.е. усложнение продукта, увеличение количества фич. Проработка их вглубь, причесывание UI/UX. Пользователи уже не Early Adopters, они более серьезно относятся к качеству и визуальной привлекательности продукта. Плюс увеличивается вариативность – поддержка разных способов оплаты, интеграция с популярными меседжерами, заточка под разные платформы, …

Для архитектора на этом этапе 2 фокуса:

• Вклад в надежность и доступность – в качество сервиса. Появляются интеграции с системами мониторинга, краш аналитики, …
• А так же в вариативность – выделение “commodity” сервисов в платформу с целью подключить еще 10 способов оплаты, еще 3 интеграции со стандартными решениями на рынке, android, iOS, Web, Desktop, …

Growth

Слоган: быстрее, выше, сильнее.

Пользователи довольны качеством решения их проблемы. Советуют продукт другим. Вы “преодолели пропасть” – вам легко привлекать новых клиентов. Есть что показать инвесторам.

Продукт понятен, рынок его принимает, соответственно есть деньги. Начинается экспансия. Экспансия всегда сопровождается ростом персонала, а люди, когда их больше 10 уже мешают друг другу. А уж когда их 50+, то тем более.

Начинает играть первую скрипку организационная архитектура (у нас ведь 50+ человек и будет больше), выделение платформенного слоя (чтобы не делать по 100 раз одно и то же), независимое масштабирование разных каналов поставки “пользы” (value) и этапов Value Stream основного продукта. Complience (не знаю хорошего перевода этого термина) становится важным (еще не является ключевым аспектом, но уже сильно рядом). Team Topologies – наше все (Stream aligned teams появляются из Value Stream).

От архитектора нужно:

• бежать впереди и убирать с пути все лишнее – лишние коммуникации (правильно разбив команды и продукты), лишнюю работу (выделив общие вещи в платформу).
• смотреть чтобы все бежали примерно одинаково (но каждый в свою сторону) – гаверненс и комплаенс.

Т.е. это про работу Chief Architect-a (70% – Enterprise Architect и 30% – Solution Architect).

Maturity

Слоган: бег на месте, общеукрепляющий.

Расти уже некуда – сохраняем статус-кво и сокращаем издержки. Бежать уже никуда не нужно. Бизнес понятен, пользователи понятны. Сохранить бы это все и, желательно, показывать динамику (позитивную).

(Хорошо если ваша компания смогла опять выбить себя в Growth стадию – новый маркет: география, сегменты аудитории, новый продукт/линейка продуктов, расширение текущего продукта, выстраивание экосистемы из продуктов. Тогда возможен Continious Growth – мечта инвестора.)

Тут нужны:

• большие платформы и продукты (желательно коробочные);
• серьезный гаверненс (а не как раньше). Т.е. разные борды умных “дядек” для наведения порядка;
• жесткая рука “бухгалтера/счетовода” – надо ведь сокращать;
• так же нужно держать руку на пульсе и не пропустить “the next big thing”. Как интернет, или мобилки, или Big Data & Realtime Analytics, blockchain (нет), или GenAI (да?);
• не пропустить “the current thing”. Во-время перейти на Java с Power Builder, с SOAP на REST, с Cobol/Fortran на… ой, ничего адекватного не придумали (Java, к сожалению, не ответ).
• cкупать и/или убивать конкурентов – да, это не про архитектуру.

ИМХО, архитектор на данном этапе нужен чтобы:

• Помогать оптимизировать издержки (чаще всего передавая поддержку подрядчикам, а лучше переходить на коробочные решения на поддержке у подрядчика);
• держать руку на пульсе новых технологий и понимать куда дует ветер (чаще всего с помощью консультантов);
• пилотировать и внедрять новые технологии, проводить обучение сотрудников;
• надувать щеки и растить свою команду.

Каждому этапу свой архитектор

Видно, что на каждом из этапов разные вызовы для архитектора. Соответственно нужны разные таланты, знания и навыки.

Если на первых стадиях важна скорость и гибкость. То для стадии Go-To-Market важно умение строить надежные решения и внедрять вариативность. На стадии роста необходимы организаторские способности и умение увидеть “Big Picture”. Во время стадии Maturity нужен хороший администратор (т.е. 100% Enterprise Architect здорового человека).

Все это очень хорошо ложиться на модель роста (зрелости) архитектора о которой я рассказывал на митапе Hard&Soft Skills.

Какой я архитектор

Мне лучше всего подходят компании роста (growth/scale). Я там чувствую себя лучше всего. Продукт понятен, рынок его принимает, соответственно есть деньги. Но задор в глазах еще горит и есть желание “замутить еще”. Идет мощная экспансия на соседние рынки и бизнес вкладываются в линейку продуктов и соседние ниши. Есть поле как для экспериментов, так и для “посидеть-подумать”.

Моя текущая компания, в основном, работает с компаниями этапа Maturity (этапа Зрелости). Я не люблю работать в таких компаниях (ничего против не имею, но не люблю) – уж очень часто на первое место выступает корпоративная политика и вместо полезной и нужной работы мы делаем то, что было “продано” руководителем (своему руководителю). Поэтому я всегда стараюсь выйти на уровень выше или, хотя бы, понимать что там происходит.

Кроме того у меня, как инженера, всегда ощущение, что “пациент” уж слишком запустил себя. Причем большинство проблем он создал себе сам и их можно было избежать просто (что совсем не просто) следуя индустриальным лучшим практикам (best practices) пару лет назад. Да, тупо, следовал бы лучшим практикам. Причем не обязательно брать что-то образца 24го или даже 19го года. Возьмите Digital Practitioner – посмотрите что вам нужно на этапе Team of Teams и при переходе к этапу Enterprise и возьмите оттуда ТОЛЬКО здравый смысл.

(Это как делать зарядку по утрам и смотреть что мы “суем в рот” (я про еду) – сильно помогает в самочувствии. Особенно по сравнению с теми кто сидит днями в кресле или диване, а вечером поедает чипсы с пивом.)

Заключение. Какой вы архитектор?

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

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

Какой вы архитектор? Читая про какой этап у вас было наибольшее количество “флэшбэков”? Расскажите об этом в обсуждении: https://t.me/akava_t/360.

P.S. Еще про этап Maturity. Несмотря на то что уже все понятно, никто не выделит бюджет под “переписывание всего, в этот раз правильно”. Хоть вы и сможете убедить всех, что “при правильной архитектуре” издержки будут кратно ниже. Но такое говорят раз в 5-10 лет в этой компании, но никто не знает как “это вот все” вместе работает (вспомните мем про голупя) – поэтому ничего масштабного вам не удастся протащить. Если же удастся – надеюсь вас не погребет под этим масштабом. В одной из моих компаний-клиентов до сих гуляет байка про прошлую попытку переписывания, стоящее компании 160 мультов за 2 года (снимаю шляпу перед менеджером, я в восхищении!, – освоить 80М в год! Мои “комплименты”).