Organizational evolution: From products to user needs Eugene Sergueev (Рубрика Management)

Посмотрел доклад Евгения Сергеева про эволюцию инженерной организации во Flo Health, и у меня было очень сильное чувство дежавю. Лет 6 назад я проходил довольно похожий путь: превращение приложения в супер-апп, закон Конвея, обратный маневр Конвея, Team Topologies, попытки понять, где границы команд помогают продукту, а где начинают ломать архитектуру и пользовательский опыт (есть вот такой мой доклад с Techlead Conf).

С Женей мы записывали ряд подкастов (например, про книгу Will Larson), поэтому смотреть выступление было особенно интересно. Но даже без этого личного контекста доклад, мне кажется, очень полезен для технических менеджеров. Он не столько про Flo Health как компанию, сколько про более общий вопрос: как эволюционировать инженерную организацию, когда продукт растет, а структура прошлого постепенно становится ограничением будущего.

Главная мысль доклада простая и правильная: организацию нужно проектировать так же осознанно, как продукт и архитектуру. Организация - это живой продукт. У нее есть пользователи, ограничения, обратная связь, накопленный долг и моменты, когда старое решение перестает работать. В кейсе Flo это хорошо видно. Компания выросла от трекера цикла к большой health-платформе с 70+ млн месячных пользователей. На раннем этапе нормальной могла быть функциональная структура: отдельно мобильная разработка, отдельно web, отдельно backend и другие функции. Потом потребовался переход к более продуктовой модели с автономными командами вокруг каналов и возможностей. Это ускорило рост, но со временем создало новую проблему: разные каналы начали конкурировать за внимание пользователя, а опыт стал фрагментированным.

И следующий сдвиг оказался уже не про “давайте добавим еще одну продуктовую команду”, а про переход к пользовательским сценариям и Jobs-to-be-Done. То есть вопрос меняется с “как развивать конкретную фичу или канал?” на “что нужно пользователю в конкретном жизненном сценарии?”. Для health-продукта это особенно важно: планирование беременности, раннее материнство, разные состояния здоровья - это не набор независимых фич, а связанные пользовательские пути.

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

Еще одна хорошая практика - Organizational Decision Records. По сути, это аналог ADR, только для организационных решений. Почему мы поменяли структуру? Какую проблему решали? Какие альтернативы рассматривали? Какие компромиссы приняли? Это кажется бюрократией ровно до того момента, пока через год никто уже не помнит, почему команды были нарезаны именно так.

Самый практичный пример в докладе - история с экспериментами в онбординге. Если для каждого изменения пользовательского сценария нужно участие инженеров, то узкое место находится не в разработке конкретной фичи, а в способе доставки ценности. Во Flo доля onboarding-экспериментов, которые можно было запускать без инженеров, выросла примерно с 20% до 87%. И это уже меняет культуру: вместо “можем ли мы это построить?” организация чаще спрашивает “давайте быстро проверим”.

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

#Management #Architecture #Engineering #TeamTopologies #Product #Leadership