Исходная версия этой статьи была опубликована на Хабре.
Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься, центральные банки разных стран — ужесточать политику, а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно: сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года.
Последние 10 лет я плотно работаю со стартапами, и рынок буквально кричит: «хватит выбрасывать на рынок тонны нового функционала, займитесь уже тем, что у вас получается хорошо».
Если посмотреть на статистику Crunchbase и Dealroom по FinTech / SaaS-стартапам, хорошо видна корреляция между компаниями, которые делали новый функционал на каждый чих, и компаниями, которые выбрали конкретное направление и фокусировались на его развитии. Логично предположить, что в этот сложный период вторые увереннее стоят на ногах — если только первые не занимаются AI.
Проблема с паттерном Feature Factory
Благодаря благодатной венчурной почве, особенно в финтехе, многие стартапы превратились в «заводы по поставке фичей» (en: feature factory). В лучших традициях эти «заводы» не оглядывались назад на выпущенное и не измеряли влияние на экономические метрики. В головах у всех витало: «больше фич = больше ценности = больше денег». Мы-то с вами знаем, что это далеко не всегда правда.
Техническое руководство часто попадает в ловушку бесконечной оптимизации инженерного отдела: работать эффективнее, доставлять быстрее. Если оптимизировать только один отдел, остальной поток создания ценности и его узкие места в рамках организации не меняются. А еще вы упускаете общую картинку.
(в системном мышлении это называют «локальной оптимизацией»)
Начинаем вооружать инженерный отдел продуктовым подходом
Начнем с двух фактов:
- Инженерный отдел обычно очень дорогой. Дороже только отдел продаж.
- В сложные времена руководство часто говорит про эффективное расходование средств, при этом бережливое отношение к деньгам далеко не всегда означает, что пора начинать финансовую оптимизацию или аутсорсинг.
Если вы когда-то работали с CTO / VP Engineering, вы наверняка слышали фразу: «давайте спустим ваших продуктовых с небес на землю и поговорим про реально важные вещи — как мне мерить, что мои инженеры работают эффективно?»
Самое лучшее проявление бережливого отношения к деньгам — использование ваших умений и возможностей самым оптимальным образом. Что такое оптимально? В Scrum есть Product Owner, и коротко его называют Value Maximizer — человеком, ответственным за максимизацию ценности. Если вы руководитель отдела, попробуйте принести максимальную ценность с помощью вашего отдела: сфокусируйтесь на общем продуктовом видении и целях вместо работы над изолированными фичами. Общие цели особенно хорошо улучшают сотрудничество в распределенных командах, где вы постоянно сталкиваетесь с потерей контекста и ценности из-за специфики коммуникации: культурной, асинхронной, непрямой.
Я активно работаю с руководством инженерных отделов, помогая фокусироваться на видении и метриках компании, а также доставке пользователям только самого важного. В рамках этого сотрудничества мы создали простую таблицу, чтобы проанализировать, как чувствуют себя новые фичи и сколько мы в них инвестировали. В интернете очень много комплексных ROI-моделей, а простота этой таблицы в том, что ее данных достаточно, чтобы начать двигаться в продуктовом направлении.
Два инструмента, из которых состоит эта таблица:
- Проверка ROI фичи (Feature ROI Check). Этот высокоуровневый инструмент для SaaS-платформ поможет вам навскидку понять, как ваши уже выпущенные фичи ведут себя в бою. Для каждой фичи мы стараемся оценить:
- Сколько инженерных ресурсов мы потратили на этот функционал;
- Когда мы выкатили этот функционал;
- Как пользователи взаимодействуют с функционалом и сколько их;
- Много ли новых пользователей мы получили благодаря этому функционалу;
- Помогает ли функционал продавать больше подписок на ваш сервис;
- Влияет ли он на ARR.
Представим, что вы собираетесь предложить пользователям новый функционал: «Автоматическая оценка контрагента антифрод-системой». Звучит здорово, правда? Тем не менее после поставки функционала клиентам вы обнаружили, что пользуется им гораздо меньше активных пользователей. Было бы здорово узнавать об этом раньше и менять направление фичи, чтобы поставлять то, что нужно клиентам.
- Калькулятор для подсчета инженерных затрат (Engineering Cost Check). Калькулятор помогает понять детализацию инвестиций инженерного отдела в каждую новую фичу. Он оценивает технологические инвестиции: время на разработку, стоимость инженеров, использованные ресурсы, расходы на инфраструктуру, а также любые сторонние инструменты или сервисы, купленные непосредственно для этой поставки. У меня в подсчетах используется количество времени разработчиков и добавляется соотношение QA / DevOps / менеджмента к разработчикам. Если у вас стабильные Agile Cross-Functional команды, почему бы не использовать среднюю цену спринта всей команды — меняйте как хотите.
Калькулятор помогает совместить все эти факторы и увидеть общую стоимость разработки конечного функционала. Подсчитанная общая сумма используется для понимания ROI: она пишется рядом с прибылью от функционала и другими метриками успеха этой фичи.
Посмотреть и сохранить эксельку с Калькулятором ROI и инженерных затрат можно тут. Каждое поле включает заметку про особенности его заполнения. Это должно дать вам хороший data-driven старт для обсуждения с командой и проведения ретроспектив по фичам, которые не смогли оправдать ожидания.
А что дальше?
Переходить на продуктовое мышление. Начинать полноценно использовать HADI-цикл. Назначить ответственного за оценку (Inspection) в цикле, ввести регулярные проверки успешности гипотез на Monthly / Quarterly Business Review, убедиться, что вы можете проверять гипотезы до имплементации.
Ваши продуктовые менеджеры, команды по продажам и маркетинг могут противостоять изменениям, могут «притворяться», что следуют общему продуктовому видению. Топ-менеджмент будет расходиться в приоритетных идеях и тянуть одеяло на себя. Самое важное для нас — начать мыслить дальше релиза функционала, продумать, как меняется общий подход и ценность, которую вы несете клиентам. Для стартапов, особенно в такие сложные времена, каждое решение должно быть предельно взвешенным. Новый функционал должен решать конкретную проблему и выстраиваться в понятный и амбициозный план.
Сейчас может показаться, что пик волн закрытий и сокращений из-за Стартап-зимы прошел. Мы-то не знаем, как оно на самом деле.
Давайте лучше будем принимать решения, основанные на данных и приближающие нас к общей цели.