01
Вход
Как превратить поток пожеланий бизнеса в понятные задачи и не утонуть в нём?
Единый вход → Тип запроса → Боль вместо просьбы → Обоснование на страницу → Обещание заказчику
На выходе: запрос понят
Читать стадиюМетодология
Как построить IT-департамент, который быстро и качественно реализует пожелания бизнеса
Как Product Owner ведёт запрос бизнеса от первого письма до результата, который можно показать. Пять стадий, у каждой — понятный выход.
- 1 Вход запрос понят
- 2 Решение решение принято
- 3 Обязательства обещание дано
- 4 Поставка поставлено
- 5 Эффект эффект доказан
Под всеми стадиями — контекст и ритм и роли и агенты. Если бизнес просит не доработку, а продукт, — отдельный маршрут: новый продукт.
02
Решение
Что из пожеланий бизнеса брать в работу, а что нет, — и каким способом это делать?
Реальная ёмкость → Связь с целью → Оценка с поправкой → Решение по инициативе → Пересмотр решения
На выходе: решение принято
Читать стадию03
Обязательства
Какой срок можно обещать бизнесу и как управлять изменениями, не теряя доверия?
Что должно быть правдой → Разговор про даты → Уровень и форма → Базовая линия → Обещание наружу
На выходе: обещание дано
Читать стадию04
Поставка
Как поставлять изменения быстро и не терять качество, когда в команде есть ИИ-агенты?
Карта делегирования → Ритм без обхода → Задачи на выяснение → Дрейф и светофор → Решение по отклонению
На выходе: поставлено
Читать стадию05
Эффект
Что изменилось для бизнеса после поставки и как это доказать без ручных отчётов?
Метрика эффекта → Честная метрика выполнения → Управляемость и журнал решений → Отчёт руководителю → Возврат знания в контекст
На выходе: эффект доказан
Читать стадиюПочему IT не успевает
Процессы на месте: планирование, дейли, демо, отчёты. А бизнес всё равно ждёт.
Дело не в процессах, а во внимании. Большая часть встреч и статусов нужна, чтобы пересказать контекст от одного человека другому. Чем больше людей, тем больше пересказов — и тем меньше времени на решения.
Офисный сотрудник получает в среднем 117 писем и 153 сообщения в Teams в день (Microsoft, 2025). ИИ поверх такого потока просто ускорит шум. Сначала нужен порядок.
Пять правил
- Контекст — в системе, а не в головах. Кто что сказал и когда это проверили, записано. Это читают заранее, а не пересказывают на встрече.
- Обещание — по уверенности, а не по надежде. Срок не жёстче, чем позволяет то, что уже проверено.
- Решение — по артефакту, а не по присутствию. Встреча нужна, когда есть что решить.
- Агент считает, человек решает. ИИ собирает и считает. Ресурс, сроки и обещания — за человеком.
- Сначала вы, потом команда. Один руководитель проживает квартал по методологии, и только потом её берёт департамент.
С чего начать
- Руководите департаментом — со стадии «Обязательства»: там теряются сроки и доверие бизнеса.
- Ведёте продукт или направление — со стадии «Вход»: какие запросы брать и как говорить «нет».
- Вы техлид — со стадии «Поставка»: агенты и проверка их работы.
Начать можно одному. Наружу уходят те же статусы и отчёты — меняется только то, на чём они основаны.
Как появилась методология
Весной 2026 года я прочитал руководство PAF по AI Product Operations. Почти все материалы про ИИ-агентов написаны для разработчиков, а это — про операционную работу продуктового руководителя.
Три месяца экспериментов превратились в методологию AI-процессов, затем — в структуру памяти Кортекс. Я понял, что 90% проблем упирается в качество управления контекстом.
Коллегам, оказалось, не хватает самих навыков работы с агентами, — так появились презентации «ИИ для руководителей». А потом стало ясно главное: если быстрее работает один PO, департамент быстрее не становится. Его скорость упирается в соседей. Нужен общий процесс — он на этой странице.
— Алексей Ишманов
Что было по дороге: руководство PAF · AI-процессы · AI-трансформация · Кортекс · Memory · презентации.
Основа — Product Architecture Framework Сергея Тихомирова. Тексты на его основе распространяются по лицензии CC BY-SA 4.0, исходники — в po-helper-org/docs.