Вход: как бизнес приходит с запросом

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

Шаг 1. Единый вход

Все запросы заказчика приходят в один канал, где у каждого появляется срок и отслеживание. Запретить писать инженерам лично в один день нельзя — можно сделать общий вход выгоднее остальных.

Когда	Что делаете
Неделя 1	Согласуете с руководителем заказчика единый канал и полномочия: кто вправе ставить приоритет, кто согласует изменения, кто только сообщает
Недели 2–3	Инженеры отвечают на личные сообщения одной фразой: «переношу в общий канал, там будет срок и отслеживание» — и переносят сами
Неделя 4	Срок получают только запросы из общего канала. Заказчик сам переходит туда, где предсказуемее

Кто что делает. Заказчик пишет в общий канал. PO согласует полномочия письменно: одна строка «приоритет меняет только такой-то» снимает половину конфликтов.

Результат. Один поток запросов и записанные полномочия заказчика.

Инструменты:

• Узел знания о заказчике — папка с файлами: договор и SLA, полномочия, поддерживаемые процессы, история обращений, открытые обязательства. Шаблон — poh-cortex.
• Презентация «Лента вместо 100500 чатов» — как видеть все каналы в одной ленте и не пропускать упоминания.

Шаг 2. Тип запроса

Каждый запрос получает один из четырёх типов. Признак определяет путь, путь — обещание.

Тип	Признак	Путь	Что обещаем
Инцидент	Перестало работать то, что работало	Дежурный инженер, эскалация по SLA	Срок реакции — всегда; срок решения — когда понятна причина
Вопрос	Как сделать, где найти, почему так	База знаний; агент готовит черновик, отвечает человек	Срок ответа по SLA
Запрос на изменение	Работает, но нужно иначе	В очередь квартала, стадия «Решение»	Дату рассмотрения
Новая инициатива	Нужно то, чего нет	Обоснование на страницу (шаг 4)	Дату решения

Главное правило: запрос на изменение, пришедший как инцидент, переклассифицируют открыто и сразу, с объяснением заказчику. Первые два-три раза неловко; на четвёртый заказчик начинает классифицировать сам. Третье похожее обращение становится предложением изменения продукта в очередь квартала — только так нагрузка на вход со временем падает.

Кто что делает. Агент разбирает входящие, предлагает тип и ищет похожие прошлые обращения. Тип подтверждает человек — PM потока или PO.

Результат. У запроса есть тип и путь; инциденты и вопросы уходят по маршруту без участия руководителя.

Инструменты:

• Пайплайн /request-intake из po-helper: читает узлы знания и превращает внешний запрос в черновик требований.
• Метрики входа: доля переклассифицированных обращений и доля повторяющихся — обе должны падать от квартала к кварталу.

Шаг 3. Боль вместо просьбы

Просьба — то, что заказчик произносит вслух: «добавьте дашборд». Боль — почему просьба возникла: «полдня уходит на ручную выгрузку отчётов». У боли обычно несколько решений, у просьбы одно, и не всегда верное.

Кто что делает. PO разбирает запросы на изменение и новые инициативы: что мешает сейчас, чем это подтверждено, чего заказчик пытается достичь. Агент находит, что об этой проблеме уже говорилось и кем.

Результат. Записанная боль с источником и связь с целью квартала.

Инструменты:

• Тема «Боль вместо буквальной просьбы» и статья «Боль vs просьба».
• Mom Test — как спрашивать о фактах прошлого, а не о мнениях о будущем.
• Тема «Требования без толстого ТЗ» и презентация «БФТ под управлением руководителя»: агент собирает бизнес-контекст в требования для согласования.

Шаг 4. Обоснование на страницу

Новую инициативу обосновывают за день на одной странице. Генеральный под словом «обоснуйте» спрашивает три вещи: почему сейчас, почему столько ресурса и что будет, если не делать. Аргумент звучит через то, чего бизнес не может делать сейчас, а не через техническую правильность.

Рамка	Формулировка
Снятие ограничения	Бизнес не может делать X, пока это не сделано
Стоимость бездействия	Каждый квартал промедления стоит столько-то
Опцион	Открывает недоступные сейчас возможности — только как дополнение
Риск отказа или регуляторика	Вероятность отказа растёт, последствия известны

У каждой цифры обоснования есть автор и дата. Упущенную выручку не считают сами — запрашивают у владельца направления; если ответа нет, в строке пишут «запрошено у такого-то, ответ ожидается к такой-то дате».

Кто что делает. PO выбирает рамку, запрашивает цифры у владельцев и отвечает за каждое число. Агент собирает выдержки из документов и переписки, считает издержки текущего состояния и три сценария, готовит ответы на вероятные вопросы. Цифры агент не придумывает.

Результат. Страница обоснования с тремя вариантами — не делать, минимальный, полный — и датой решения.

Инструменты: шаблон одной страницы — в разделе «Артефакт» ниже; ценность информации по Хаббарду — сколько стоит выяснить неизвестное до решения.

Шаг 5. Обещание заказчику

Заказчик получает обещание своего типа и ничего сверх него. Дата выполнения на входе не даётся: её основание появится только на стадиях «Решение» и «Обязательства».

Кто что делает. PO отправляет обещание или проверяет черновик, который подготовил агент. Агент не отвечает заказчику сам и не обещает сроков.

Результат. Запрос понят и передан дальше: изменение и инициатива — в стадию «Решение», инцидент и вопрос закрываются на своём пути.

Почему так, а не через общую очередь

В классическом процессе запросы приходят в чаты, в почту и лично инженерам. Всё помечено как срочное, изменения маскируются под инциденты, приоритет меняет любой сотрудник заказчика, а поддержка берёт столько, сколько попросят. Через месяц поддержка съедает квартал.

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

Артефакт: карточка запроса и страница обоснования

Запрос: <дословно, как сформулировал заказчик>
Кто прислал / канал / дата: <имя, роль> / <канал> / <дд.мм>
Вправе ставить приоритет: <да / нет — по узлу заказчика>
Тип: <инцидент | вопрос | запрос на изменение | новая инициатива>
Если тип изменён: <какой был заявлен, почему переклассифицирован, кому объяснено>
Боль: <что мешает сейчас, словами заказчика>
Чем подтверждено: <факт, цифра, письмо — со ссылкой>
Связь с целью квартала: <какую цель приближает | нет связи>
Похожие обращения: <ссылки; если это третье — предложение в очередь квартала>
Обещание заказчику: <срок реакции | срок ответа | дата рассмотрения | дата решения>

Обоснование инициативы — одна страница
1. Какое решение требуется и к какой дате: <…>
2. Что бизнес не может делать сегодня (с владельцем): <…>
3. Сколько стоит каждый квартал в этом состоянии: <диапазон, источник>
4. Три варианта — не делать · минимальный · полный: <объём, срок, что получаем, что нет>
5. Рекомендация и почему именно она: <…>
6. Чем подтверждено: <источник по каждой цифре>
7. Что неизвестно и когда станет известно: <вопрос — кто — дата>

С чего начать завтра

• Выпишите все каналы, по которым к команде приходят запросы, и назовите один общим входом.
• Согласуйте письменно с руководителем заказчика, кто вправе ставить и менять приоритет.
• Разберите последние двадцать запросов по четырём типам и посчитайте, сколько изменений пришло под видом инцидентов.
• Для трёх крупнейших запросов заполните карточку и проверьте, записана ли боль или только просьба.

Источники

• PAF Product Ops для корпоративного PO, адаптация А. Ишманова: кейсы «Поддержка внешнего клиента: один вход, четыре пути» и «Обоснование технологической инициативы за день» — po-helper-org/docs.
• Product Architecture Framework Сергея Тихомирова: нексусы и кортекс как способ хранить контекст.