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

Понравился пост Адама Елдарова в его канале "Записки 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

☕️ MCP (Model Context Protocol)?

MCP — это новый стандарт от компании Anthropic, который помогает искусственным интеллектам (например, модели Claude) работать с внешними системами: базами данных, файлами, API и другими инструментами.

Представьте его как "универсальный переводчик" , который упрощает общение ИИ с разными программами без написания сложного кода.

MCP — это не фреймворк или инструмент, а именно протокол, аналогичный: HTTP для интернета, SMTP для обмена сообщениями.

🖥 Пример использования
Представьте, что ваш ассистент (например, ИИ-бот) должен одновременно искать информацию в интернете и обрабатывать голосовые команды. MCP позволяет этим разным системам (поисковой модели и голосовому движку) работать вместе по единому протоколу, не запутавшись в деталях друг друга.

🧐 Как это работает?
MCP строится на клиент-серверной архитектуре и состоит из трёх частей:
— Host (хост): Это среда, где работает ИИ (например, приложение Claude). Он предоставляет доступ к инструментам (БД, API) через MCP. Пример : Вы спрашиваете ИИ: «Проанализируй продажи за квартал». Хост запускает MCP Client, чтобы связаться с базой данных.
— MCP Client (клиент): Часть ИИ, которая формирует запросы к внешним системам. Пример : Если ИИ нужно взять данные из PostgreSQL, MCP Client превращает запрос в структурированный код (например, SQL-запрос).
— MCP Server (сервер): «Переводчик», который связывает ИИ с внешним миром (Google Drive, API, БД). Пример : MCP Server для PostgreSQL получает SQL-запрос от клиента, выполняет его в базе и возвращает результат ИИ.

🧩 Ключевые элементы MCP
Они делятся между клиентом и сервером и реализуют «правила общения»:

Для клиента (MCP Client):
❶ Roots (Корни) — Безопасный доступ к файлам и данным.
Пример : ИИ может открыть файл в Google Drive через MCP Server, но не увидит другие файлы пользователя.
❷ Sampling (Выборка) — Запрос помощи у ИИ для задачи.
Пример : ИИ просит пользователя уточнить, какую именно таблицу из БД использовать.

Для сервера (MCP Server):
❸ Prompts (Инструкции) — Подсказки для ИИ, чтобы он понимал контекст.
Пример : «Ты работаешь с финансовыми данными, используй формат отчета X».
❹ Resources (Ресурсы) — Данные, к которым обращается ИИ.
Пример : Таблицы из PostgreSQL или файлы из Dropbox.
❺ Tools (Инструменты) — Функции, которые ИИ может вызывать.
Пример : Выполнить SQL-запрос, отправить письмо через API или обработать изображение.

🤌 Как это работает на практике?
Сценарий: Вы спрашиваете: «Покажи график продаж за 2023 год».
1. Host (ваш ИИ-ассистент) запускает MCP Client.
2. MCP Client формирует запрос к MCP Server для PostgreSQL: «Получи данные о продажах».
3. MCP Server подключается к БД, выполняет SQL-запрос и возвращает данные.
4. Resources (данные о продажах) и Tools (график) используются для создания ответа.
5. ИИ показывает вам график, используя Prompts (например, «График должен быть в формате PDF»).

🔗 Полезные материалы
— Учебная программа MCP для начинающих от MS
— Документация MCP
— Спецификация MCP
— GitHub репозиторий MCP
— Сообщество MCP

#ai #mcp #bytebytego