Дерево решений для требований: как маленькая команда отсеивает 80% ложных потребностей за полчаса

Несколько лет назад, когда я руководил своим первым продуктом, самой большой проблемой было не отсутствие идей, а их переизбыток. Каждую неделю поступали отзывы пользователей, идеи начальства, новости конкурентов. Я брал всё подряд, команда выгорала, а большинство функций оставались невостребованными. Со временем я понял: маленькой команде нужен не лучший метод приоритизации, а дерево решений, которое за полчаса отправит 80% ложных запросов в корзину.

Это дерево не идеально. Это простой процесс, который я выработал на нескольких продуктах (AI-письмо, изучение языка, инструментальные приложения). Его предпосылка: у вас есть минимум три месяца данных о продукте (пусть даже приблизительных) и готовность потратить 30 минут перед каждым ревью.

Узел 1: Детализация сценария — кто, когда и как часто?

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

Моё правило: требование должно соответствовать одному конкретному сценарию, частота которого — не реже раза в неделю. Для инструментальных приложений сценарии реже раза в неделю, если только они не ведут к покупке или высокой удержанию, не стоят разработки. Гипотетический пример: пользователь просил функцию «сравнение версий» в AI-редакторе. После опроса выяснилось, что он боится случайно удалить изменения в еженедельном отчёте. Вместо версионирования мы добавили многошаговую отмену (Ctrl+Z). Разработка заняла 2 часа вместо 3 дней, пользователь доволен.

Узел 2: Замена — как пользователь справляется сейчас?

Если у пользователя нет замены — потребность срочная. Если есть — оцените, насколько это больно. Я всегда спрашиваю: «Без этой функции как вы решаете задачу?» Если ответ: «Жду, когда вы сделаете» или «просто не делаю» — боль низкая. Если: «Копирую текст в другую программу, это муторно» — боль реальна.

Один пользователь просил RSS-агрегатор. Он вручную открывал несколько сайтов каждый день. Замена неэффективна, но занимала 5 минут. Создание RSS-функции — неделя разработки плюс поддержка. Мы сделали простой список закладок с автообновлением заголовков за два дня. Пользователь остался доволен. Чем «терпимее» замена, тем вероятнее, что требование ложное.

Узел 3: Что будет, если не делать? — Оценка оттока

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

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

Узел 4: Стоимость разработки + поддержки — не только время программиста

Маленькие команды часто недооценивают стоимость поддержки. Реализовать функцию можно за три дня, но каждый следующий релиз требует тестирования совместимости, исправления багов, иногда новых проблем с производительностью. Моё правило: если стоимость поддержки (за полгода) превышает 50% стоимости разработки, нужно дополнительно обосновать долгосрочную ценность.

Гипотетический пример: мы думали добавить экспорт Markdown в PDF. Разработка — два дня, но рендеринг PDF на мобильных устройствах вызывает бесконечные проблемы со шрифтами, отступами и разрывами страниц. Каждое обновление ОС требует повторной адаптации. Выяснилось, что пользователям PDF нужен для печати. Мы сделали режим печати в вебе — пользователь печатает через браузер. Полдня работы, нулевая поддержка.

Узел 5: Есть ли более простое решение?

Это последняя линия обороны. Даже если все предыдущие узлы пройдены, спросите: можно ли использовать существующие функции? Написать скрипт автоматизации? Временно поручить оператору обрабатывать вручную, чтобы подтвердить спрос до разработки?

Однажды пользователь попросил функцию автоматического создания еженедельной сводки. Звучало как AI-проект. Но анализ показал, что у пользователей уже есть ежедневные записи, нужно только объединить их по шаблону. Мы написали простой скрипт за три дня. Без новой функции, пользователь доволен, долгов нет.

Когда стоит отказаться от этого дерева?

Эта схема не универсальна. Когда продукт находится в фазе 0→1 (ещё нет PMF) или требование касается совершенно новой области (вы даже не знаете своих пользователей), интуиция и быстрые эксперименты важнее. Дерево опирается на существующие данные о поведении пользователей. Если у вас всего несколько десятков пользователей, выборка слишком мала для узлов 1 и 3. Кроме того, некоторые редкие функции могут принести сарафанное радио — например, нишевая возможность, привлекающая ключевых лидеров мнений. В таких случаях дополняйте качественной оценкой.

Но если вы работаете над продуктом 3–6 месяцев и у вас хотя бы 1000 активных пользователей в месяц, это дерево отсеет большинство шума. На практике мы проводим ревью раз в две недели. Каждый участник заранее прогоняет свои предложения через дерево. Половина отсеивается до встречи. Команда больше не спорит о том, делать ли функцию, а обсуждает, как лучше реализовать несколько настоящих потребностей.

Стройте только самое больное

В итоге: маленькие команды не должны бояться сделать неправильную функцию. Они должны бояться сделать слишком много «нормальных» функций. Каждая «нормальная» функция размывает внимание команды и ухудшает пользовательский опыт. Суть дерева решений не в том, чтобы найти «лучшую» потребность, а в том, чтобы отфильтровать те, которые «достаточно хороши, но отнимают ресурсы». Когда вы концентрируете усилия на реальных болевых точках, удержание, сарафан и доход придут сами. PaxLee