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