☕️ Проблемы детального планирования

Понравился пост Адама Елдарова в его канале "Записки C3PO". В нём он высказывает тезис, что детальное планирование фичей на большом горизонте не просто не имеет смысла (в ситуации с высокой изменчивостью среды мы вынуждены будем постоянно корректировать планы), но и вреднО.

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

Когда детальное планирование всё же работает
Есть конечно ситуации, где детальное планирование оправдано:
— Регулируемые отрасли (медицина, финансы).
— Фиксированные дедлайны (например, запуск продукта к выставке).
— Интеграция с внешними системами , где изменения в одном блоке ломают другие.

Здесь план помогает избежать хаоса, но даже в таких случаях стоит внедрять гибкие элементы (например, итеративное тестирование).

Как успокоить внутренних заказчиков
Ещё существуют ситуации, когда внутренним заказчикам определённых фичей надо показать, когда их "заказ будет выполнен", а с учетом того, что эти фичи не всегда в первом приоритете им выпадает доля занять место Q5 (условный «далекий горизонт») в ячейке роадмапа.
Делать такое можно, но с оговоркой: «Мы планируем рассмотреть эту задачу в Q5, но финальный приоритет зависит от результатов текущих экспериментов».


Баланс между гибкостью и структурой
Главная мысль:

Фокусируйтесь на проблемах пользователей и целях бизнеса, а не конкретных фичах.

Рекомендации (с дополнениями):
❶ OKR вместо роадмапа
Лучше потратить время на детальные OKR, чем на расписывание фич по неделям. OKR задаёт направление, но не сковывает руки конкретными решениями.

❷ Фокус на 3–5 ключевых направлениях
Ресурсы ограничены — реализовать всё за раз невозможно. Выберите самые важные направления.

❸ Принципы вместо процессов
Вместо пошаговых инструкций определите правила:
— «Всё, что ускоряет time-to-value, приоритетнее».
— «Любое решение должно быть проверено на MVP».

❹ Принцип набегающей волны
Используйте подход Rolling Wave Planning: детально планируйте только ближайшие этапы, а дальние корректируйте по мере накопления данных.

❺ Итерации через PDCA: адаптация после каждого цикла
Используйте цикл PDCA (Plan-Do-Check-Act) для постоянной корректировки.

Заключение: «Планируйте, но не фанатейте»

Не отвергайте планы полностью, но делайте их живыми.

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

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

#pm #thoughts

☕️ Принципы вместо процессов

«Полный контракт» — миф. В институциональной экономике давно доказано: невозможно заранее учесть все условия сотрудничества. То же верно и для процессов. Пытаясь прописать каждую деталь, мы создаем иллюзию контроля. Реальность же полна неожиданностей.

Можно потратить месяцы на «идеальные» чек-листы/bpmn-схемы. Но как только команда столкнётся с ситуацией вне сценария, всё разрушится. Выход? Используйте принципы, например:
— "Решай быстро",
— "Объясняй причину",
— "Бери ответственность".
— "Пиши поддерживаемый код"
— "Тестируй до мержа"

Так даже в хаосе действия будут согласованы.

Принципы — это не замена процессам, а их фундамент. Например, когда перед вами встанет выбор: внедрять новую библиотеку или использовать проверенное решение? Принцип «Поддерживаемый код» сразу даст ответ — даже если библиотека круче, её сложность может затормозить команду в будущем.

Процессы — это карта, которая не учитывает новые дороги. А принципы — компас. Их цель не контролировать, а направлять. И в этом их сила.

#thoughts #processes

☕️ Почему метрика просела

Дима Некрасов (CEO JetMetrics) в своём канале опубликовал классный гайд, с помощью которого можно "превратить падение метрики в инсайты и действия":
1. Убедитесь, что просадка реальна
2. Разложите метрику на драйверы
3. Изучите динамику драйверов
4. Рассмотрите драйвер в разрезах
5. Сравните сегменты
6. Сформулируйте гипотезы

Этот подход заставляет задавать правильные вопросы:
— Почему метрика упала именно сейчас?
— Где именно произошел сбой?
— Какие изменения могли повлиять?


Если вы из e-commerce, вам точно стоит посмотреть материалы и продукты ребят из Jetmetrics. Более исчерпывающего исследования по метрикам я не видел.

#analytics #ecom #metrics