Большинство ненужных функций попадает в разработку не потому, что кто-то ошибся в оценке, а потому, что запрос никто не проверил. Проверка занимает один разговор и состоит из трёх вопросов: кто конкретно просил, что человек делает сейчас вместо этого, и что изменится в его работе после. Если на второй вопрос нет ответа, задачи нет — есть пожелание.
Три вопроса, снимающие половину запросов
- Кто конкретно просил? Не «клиенты», а имя и компания. Если названо «клиенты» во множественном числе без имён, обычно это один разговор недельной давности.
- Что он делает сейчас вместо этого? Если ответ «ничего» — задача несрочная. Если «выгружает в таблицу и считает руками» — задача настоящая, и понятен масштаб боли.
- Что изменится, когда функция появится? Ответ должен быть про действие, а не про ощущение. «Перестанет выгружать» — это ответ; «будет удобнее» — нет.
Шесть признаков, что делать не стоит
- Запрос пришёл ровно один раз. И от того клиента, с которым вчера был сложный разговор.
- Формулировка описывает решение, а не проблему. «Нужна кнопка экспорта» — это решение; какая задача за ним, обычно выясняется другим.
- Обещано в сделке до обсуждения с продуктом. Такие функции делаются под срок, а используются одним клиентом.
- Никто не может назвать, как поймёт, что получилось. Нет критерия — нет и способа закрыть задачу.
- Есть обходной путь, которым пользуются. Значит боль терпимая, и приоритет ниже, чем кажется.
- Функция нужна, чтобы догнать конкурента. Догонять по списку функций — способ всегда быть вторым.
Что делать с запросом, который отклонили
Отклонённый запрос не должен исчезать. Полезная практика — короткая запись: кто просил, какая задача, почему сейчас не делаем. Через квартал видно, повторяется ли запрос. Три независимых обращения по одной задаче — сильный сигнал, а один настойчивый человек — нет. Без такой записи вы каждый раз обсуждаете запрос как впервые.
Особый случай: просьба от крупного клиента
Что считать доказательством
| Слабый сигнал | Сильный сигнал |
|---|---|
| Клиент сказал, что было бы удобно | Клиент делает это руками и тратит время |
| Просит один человек | Просят независимо друг от друга трое |
| Есть у конкурента | Из-за отсутствия проиграли сделку и это подтверждено разбором |
| Продавец считает, что поможет | Есть сделка, где это названо условием |
Разбор одного запроса
Запрос от продавца: «Клиентам нужна массовая рассылка прямо из системы, без неё теряем сделки». Звучит как понятная задача на две недели разработки.
Первый вопрос: кто конкретно просил. Ответ: два клиента за последний месяц. Уже лучше, чем «клиенты». Второй вопрос: что они делают сейчас. Оказывается, выгружают контакты в таблицу и отправляют через отдельный сервис рассылок. То есть задача решена, просто неудобно. Третий вопрос: что изменится. Ответ: перестанут выгружать.
Дальше уточнение, которое меняет всё: как часто они это делают. Один клиент — раз в квартал, второй — раз в месяц. Экономия составляет примерно двадцать минут в месяц на клиента. Две недели разработки ради этого — плохая сделка, и понятно это стало за три вопроса.
Но у истории есть продолжение. При разговоре выяснилось, что оба клиента жалуются не на выгрузку, а на то, что после рассылки не видят в системе, кто открыл письмо и с кем стоит связаться. Настоящая задача — не рассылка, а возврат данных о реакции. Она решается интеграцией за два дня вместо собственного модуля за две недели.
Как отличить настоящую боль от неудобства
| Признак настоящей боли | Признак неудобства |
|---|---|
| Человек тратит время регулярно | Вспоминает о проблеме, когда его спрашивают |
| Придумал обходной путь и им пользуется | Просто не делает |
| Может назвать, сколько времени уходит | Говорит «долго» |
| Спрашивает повторно через месяц | Больше не возвращается к теме |
| Готов участвовать в тестировании | Отвечает уклончиво на предложение показать |
Что делать с обещаниями, данными в сделке
Ситуация, знакомая любому продуктовому руководителю: продавец пообещал функцию, чтобы закрыть сделку, и приходит с уже подписанным договором. Ругаться поздно, а делать придётся.
Профилактика проще лечения и состоит из двух правил. Первое: любое обещание функции требует согласования с продуктом до, а не после. Второе: если обещание уже дано и оно уникально для одного клиента, стоимость разработки закладывается в цену сделки отдельной строкой. Это превращает разговор из спора между отделами в обычный расчёт экономики сделки.
И отдельно стоит считать, сколько таких обещаний было выполнено и что с ними стало через год. Обычно обнаруживается, что половина функций, сделанных под конкретную сделку, не используется даже тем клиентом, ради которого делались.
Как ведётся перечень отклонённого
- Одна строка на запрос. Дата, кто просил, какой клиент, какая задача, почему сейчас не делаем.
- Общий доступ на чтение. Продавцы должны видеть, что запрос зафиксирован, а не пропал.
- Пересмотр раз в квартал. Ищем повторы: три независимых обращения по одной задаче меняют приоритет.
- Отметка о выполнении. Когда задачу всё-таки делаем, отмечаем — это показывает, что перечень живой.
Частые вопросы
Ненужные функции появляются не от плохих решений, а от непроверенных запросов. Один вопрос — что человек делает сейчас вместо этого — отсеивает больше, чем любая система приоритизации.
Материал обновлён 3 сентября 2026