Приоритизация: наименьший ценный срез

Когда проблема названа, а бизнес-результат выбран, возникает соблазн построить всё и сразу: раз уж взялись, сделаем по-хорошему, со всеми ветками и крайними случаями. Этот соблазн — самый тихий способ не выпустить ничего вовремя. Объём растёт незаметно, срок уезжает, а пользователь всё это время живёт со своей болью.

Приоритизация — это два решения, и второе важнее первого. Первое: что делать раньше. Второе, которое обычно избегают: чего не делать вовсе. Продукт-инженер умеет резать — доводить задачу до наименьшего среза, который реально снимает боль и проверяет, что мы не ошиблись.

Всё сразу значит ничего вовремя

У объёма есть свойство расти само. Каждый крайний случай кажется обязательным, каждая соседняя функция — логичным дополнением, каждое «а что если» — поводом добавить ветку. По отдельности всё разумно; в сумме получается план, который не доезжает до пользователя месяцами. А до тех пор обратной связи нет, и весь этот объём строится на непроверенных догадках.

Цена тут не только во времени. Чем больше построено до первого контакта с реальностью, тем дороже разворот, когда выяснится, что догадка была неверной. Большой объём — это не «сделали много», это «много поставили на ставку, которую не проверяли».

Есть простой способ поймать себя на этом: посмотреть на задачу и спросить, какая её часть доедет до пользователя раньше всего остального. Если ответа нет — значит, всё связано в единый пакет и выпустить что-то раньше невозможно без переосмысления структуры задачи. Именно тогда стоит резать.

Наименьший ценный срез

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

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

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

Хороший срез отвечает на два вопроса сразу: даёт ли он ценность хоть кому-то прямо сейчас и проверяет ли он самое рискованное предположение. Если он только проверяет, но не помогает, — это эксперимент, не продукт. Если только помогает, но ничего не проверяет, — тебе везёт, что угадал.

Пример: личный кабинет

Возьмём задачу, которая с самого начала кажется неделимой, и покажем, как срез находится через бизнес-результат, а не через «что было бы хорошо».

Команда решает запустить личный кабинет для клиентов B2B-сервиса. Первоначальный список выглядит разумно: история заказов, текущий статус, документы (счета и акты), профиль компании, управление пользователями, уведомления по почте, фильтры и экспорт. Восемь блоков — каждый логичный, каждый «нужен».

На это уйдёт три месяца минимум. Всё это время реальные клиенты продолжают звонить менеджерам с вопросом «где мой заказ» — именно эта боль и назвалась в начале. Объём задачи и боль пользователя разъехались: строим много, а боль не снимается до самого конца.

Шаг первый — сформулировать бизнес-результат точно: клиент самостоятельно отвечает на вопрос «где мой заказ», не обращаясь к менеджеру. Под этот бизнес-результат нужны только две вещи: список заказов и статус каждого. Профиль компании, управление пользователями, документы, фильтры, экспорт — всё это бизнес-результата не двигает. В список «не строим сейчас» ушло шесть из восьми пунктов. Не отложено — именно не строим, пока данные не покажут иначе.

Шаг второй — найти самое рискованное предположение. Оно звучит так: клиенты вообще будут заходить в кабинет, а не привычно позвонят менеджеру. Если не проверить это первым, три месяца работы могут оказаться ставкой на поведение, которого нет.

Наименьший срез: страница со списком заказов и статусом, доступная по ссылке из письма-подтверждения. Без отдельного логина, без управления аккаунтом, без истории документов. «Без логина» здесь не значит «без защиты»: в ссылке лежит длинный случайный токен, который не подобрать перебором, он привязан к одному клиенту и живёт ограниченный срок. Без этого достаточно поменять цифру в адресе, чтобы увидеть чужие заказы. Сделано за две недели.

После запуска смотрели одно число: доля входящих обращений с вопросом «где мой заказ». Базу записали до выката — такие обращения занимали около четверти всех звонков менеджерам. За следующий месяц доля упала на 40% от этой базы, до пятнадцати процентов. Гипотеза подтвердилась — клиенты идут в кабинет. Следующим срезом добавили документы: именно их просили чаще всего по результатам первого контакта с реальностью.

Ключевой момент в этой истории — не размер среза, а последовательность решений. Сначала бизнес-результат, потом главный риск, потом минимальный путь, который проверяет и то и другое. Шесть из восьми блоков не «отложили» — убрали явно и по причине. Это позволило запустить через две недели то, что иначе ждало бы три месяца.

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

А если бы гипотеза не подтвердилась

В примере всё получилось, и это самый удобный из исходов. Разберём противоположный, потому что происходит он не реже: срез выкатили, а доля обращений «где мой заказ» осталась той же четвертью.

Первое: это не провал, а результат. Две недели работы купили знание, которое иначе стоило бы три месяца. Формулировать это стоит именно так — не из бодрости духа, а потому что от формулировки зависит следующее действие: провал закрывают и забывают, результат разбирают.

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

Третья строка — самая ценная и самая неприятная. Она означает, что названная проблема была не той: клиент звонит не потому, что не знает статуса, а потому что хочет повлиять на него, или потому что не доверяет цифре на экране, или потому что заодно решает три других вопроса. Это возврат к формулировке проблемы, а не к следующему срезу.

Третье: решить одно из четырёх, явно.

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

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

И записать исход. Одна строка: что предполагали, что сделали, что получили, что решили. Через полгода, когда кто-то предложит «а давайте сделаем личный кабинет», это единственный документ, который ответит, что уже пробовали и чем кончилось. Без записи неудачная гипотеза возвращается каждый год.

Что не строить

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

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

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

Кто возвращает пункт в работу

Список «не строим» работает, пока на него не давят. А давят на него всегда, и фраза «это в нашем списке не строим» без второй половины звучит как отказ по причине «я так решил». Вторая половина — правила возврата, и их стоит сформулировать заранее, до первого спора.

Пункт возвращается по факту, а не по настойчивости. Это главное правило, и оно защищает обе стороны: вас — от того, что решение пересматривается всякий раз, когда кто-то повторил просьбу громче; собеседника — от произвола, потому что у него появляется понятный способ добиться своего.

Что считается фактом:

• Новые данные. Метрика показала, что без этого пункта результат не достигается. Самый сильный довод, и он снимает спор мгновенно.
• Повторяемость. Третий разный человек с той же просьбой. Один — случай, два — совпадение, три — признак.
• Изменившиеся обстоятельства. Появилось требование регулятора, сменился сегмент, вырос объём — то, чего при первом решении не было.
• Цена ошибки выросла. Раньше отсутствие пункта раздражало, теперь стоит денег или сделки.

Что фактом не считается: повторение просьбы, ссылка на конкурента, «это же очевидно нужно» и настойчивость по должности. Последнее требует оговорки — см. ниже.

Как отвечать тому, кто настаивает. Работающая форма состоит из трёх частей, и порядок в ней важен:

1. Назвать решение и причину. «Управление пользователями мы решили не делать: бизнес-результат — чтобы клиент сам отвечал на вопрос „где мой заказ“, а этот блок его не двигает».
2. Назвать цену. «Это примерно три недели, и они уйдут вместо документов, которые просили чаще».
3. Назвать условие возврата. «Вернём, если: появится второй-третий клиент с этой просьбой, или окажется, что без него не работает то-то». Это ключевая часть: она превращает «нет» в «пока нет, и вот при каком условии да».

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

Кто имеет право решить вопреки. Если весь путь ведёт один человек, решение о списке — его. Но реальность бывает другой, и это стоит признать: руководитель, заказчик, тот, кто платит, может вернуть пункт своей волей. Тогда порядок такой же, как с любым решением сверху: назвать цену и последствия (что не будет сделано вместо этого), сделать и записать — что попросили, кто, что предлагали взамен. Записанное решение через квартал становится материалом для разговора, а не поводом для обиды.

И обязательный срок пересмотра. Список «не строим» без даты пересмотра постепенно превращается в кладбище: там лежат решения, принятые в других обстоятельствах, и никто не помнит, почему. Раз в квартал по списку проходят и перечитывают причины — на это уходит полчаса, и обычно два-три пункта переезжают в работу, потому что обстоятельства действительно изменились. Именно этот проход и отличает осознанный выбор от забывчивости.

Приоритет по бизнес-результату и риску

Чем резать и что оставлять — решает не вкус, а две оси: вклад в бизнес-результат и риск гипотезы. Вклад в бизнес-результат отвечает, насколько кусок двигает ту метрику, ради которой всё делается; всё, что её не двигает, опускается вниз автоматически. Риск гипотезы отвечает, что будет дороже всего, если мы ошиблись; самое рискованное предположение стоит проверять раньше, пока цена разворота мала.

Из этих двух осей складывается простое правило очерёдности: раньше делается то, что и даёт ценность, и снимает главный риск:

• дёшево и неважно — подождёт;
• дорого и неважно — в список «не строим»;
• важно, но проверяемо позже — после первого среза.

Когда приоритизировать трудно, полезно задать себе один вопрос: «Что случится, если мы ошиблись в главном предположении?» Если ответ — «придётся переделать большой кусок», значит, это предположение нужно проверить первым, и именно вокруг него строится наименьший срез.

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

Доведённый до пользователя узкий срез бьёт любой широкий план, застрявший на полпути.

Когда сквозной срез не нарезается

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

Перенос данных. Кажется, что это одно неделимое действие: либо старая структура, либо новая. На самом деле он отлично режется, просто не по объёму данных, а по этапам совместимости — это тот же приём, которым делают несовместимые изменения схемы:

1. Новая структура появляется рядом со старой, пустая. Выкатывается, ничего не меняет.
2. Запись идёт в обе структуры, чтение — из старой. Выкатывается, ничего не меняет для пользователя, но новая структура начинает наполняться.
3. Перенос исторических данных, кусками, с возможностью остановиться. Проверяется сверкой: совпадают ли результаты чтения из двух структур.
4. Чтение переключается на новую, запись по-прежнему в обе. Это точка возврата: переключить обратно — одна настройка.
5. Старая структура перестаёт использоваться и позже удаляется.

Каждый шаг выкатывается отдельно и отдельно откатывается. Ценности для пользователя ни один из них не несёт — и это нормально: срез здесь проверяет не гипотезу о пользе, а гипотезу о безопасности. Вопрос «сработало ли» здесь звучит как «совпали ли данные», и это проверяемый вопрос.

Интеграция с внешней системой. Тоже кажется неделимой: пока не получили от партнёра всё, ничего не работает. Оси нарезки здесь другие:

• По сценарию. Один случай использования из десяти: только создание, без изменения и отмены. Работает на одном сценарии — уже можно выпустить для части пользователей.
• По направлению. Сначала только чтение из внешней системы (безопасно, ничего не ломает), потом запись.
• По объёму. Один тип документа вместо всех, одна валюта, один регион.
• Через заглушку. Свою сторону собирают и выпускают против заглушки партнёра. Ценность появляется позже, но риск снимается раньше: выясняется, что контракт неполный, до того, как партнёр подключён.
• Вручную на первое время. Самый недооценённый ход: сценарий работает, но на чужой стороне человек. Десять заявок в день закрываются руками, и это даёт полную проверку гипотезы без интеграции вовсе.

Замена движка или библиотеки. Здесь режут по области применения: новый способ применяется к одному модулю или одному сценарию, старый продолжает работать рядом. Два способа в проекте одновременно — временная цена, которую платят осознанно и с датой окончания. Если параллельное существование невозможно технически, остаётся резать по шагам совместимости, как с данными: сначала слой, скрывающий разницу, потом переключение за настройкой, потом удаление старого.

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

И честная оговорка про срок. Правило «одна-две недели» на такие работы не распространяется — перенос данных живой системы идёт месяцами. Что распространяется, так это требование выкатывать по шагам: работа на три месяца, выходящая одним изменением в конце, — самый дорогой из возможных способов её сделать. Если из неё нельзя выпустить ни одного отдельного шага, это первое, что стоит перепроектировать.

Что это значит на практике

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

Типичные ошибки:

• Срез режут горизонтально. «Сначала всё API, потом весь интерфейс» — и месяцами нет ничего проверяемого. Полезный срез всегда сквозной: от пользователя до базы данных, пусть и для самого узкого случая.
• Откладывают проверку самого рискованного. Приятнее начать с понятного и надёжного — и оставить «мы не знаем, будут ли пользоваться» на потом. Но чем позже проверяется главная догадка, тем дороже её опровержение.
• «Потом доделаем» записывают как план. Список «потом» не разгребается. Если функция не вошла в срез, честнее сразу пометить её как «не строим», а не «строим позже» — это меняет ожидания и снимает накапливающееся чувство долга.
• Срез режут, не называя бизнес-результата. Без ответа на вопрос «какую метрику сдвинет этот срез» непонятно, что оставить, а что выкинуть. Нарезка без бизнес-результата — это угадывание, а не приоритизация.
• Называют большой план «минимальным». «Минимальный» — это не «меньше, чем хотелось бы», а «наименьшее, что даёт ценность и проверяет гипотезу». Если срез нельзя выпустить за одну-две недели, скорее всего, он ещё не минимальный.

Глубже: какую из трёх проблем брать первойрасширенное

Разговоры с пользователями оставляют не одну проблему, а три-пять, и статья учит резать одну. Выбор между ними это тоже решение, и оно принимается по трём осям, а не по громкости просьбы.

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

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

Стоимость проверки. Сколько стоит наименьший срез, который подтвердит или опровергнет гипотезу по этой проблеме. Иногда проблема номер два по боли проверяется за день, а номер один за месяц, и брать надо вторую: она быстрее даст факт, а не потому, что она важнее.

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

Две поправки. Стратегия: проблема, которая мала сейчас, но лежит на пути, куда идёт продукт, поднимается. И зависимость: проблема, решение которой делает дешевле следующие две, тоже. Остальные три проблемы после выбора не «в очереди», а «не сейчас» с датой пересмотра, о чём раздел про «потом» выше.

Глубже: назвать срок и не совратьрасширенное

Один человек всё равно называет срок: заказчику, руководителю, себе. Фраза «если срез нельзя выпустить за одну-две недели, он не минимальный» это правило резки, а не способ оценить, влезает ли конкретный срез, и вот способ.

Оценка от похожего, а не от ощущения. Сколько заняли последние три среза похожего размера, по факту, от начала до проверенного результата; это число честнее любого разложения на задачи, потому что включает всё, что забывают: приёмку, выкат, обратную связь. Если похожих нет, срез раскладывают на шаги по дню и добавляют половину сверху на неизвестное.

Диапазон, а не точка. «К среде уверенно, к пятнице если всплывёт интеграция» честнее «в четверг»; диапазон показывает, где риск, и заказчик может решить, важна ли ему среда настолько, чтобы убрать интеграцию из среза.

Обещать срез, а не дату. Если срок жёсткий (событие, договор), под него режут объём, а не растягивают часы; это разговор в начале, а не за день до срока. Если объём жёсткий, дату называют диапазоном и пересматривают раз в неделю по факту, сообщая заранее, а не по истечении.

Когда не влезает. Это выясняется к середине, а не в конце, если считать сделанное против плана каждые пару дней. Три хода: сузить срез (что убрать, чтобы влезть), сдвинуть срок с объяснением, что узнали, или остановить и признать, что гипотеза дороже, чем думали. Худший ход это молча работать до срока и в день срока сообщить, что не готово; он стоит доверия, которое одиночке восстанавливать некому.

Коротко

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

Что почитать дальше

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