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

Меня зовут Александр Козуб, я двадцать лет в финтехе и последние несколько из них CPO. В симптомах вижу систему, об этом и пишу. Это первая из двух статей про бэклог: здесь диагноз, а в следующей лечение.

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

Так вот, почти наверняка это не ваш список и не ваше собственное суждение. Это набор компромиссов, который вы себе присвоили, часто даже не заметив и не осознав этого.

Прописные истины

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

Мысль не моя, ей уже лет десять: Каган, Торрес, вся линия outcome over output про это и говорят. Я не продаю вам открытие и не делаю вид, что придумал «идти от проблем». Это профессиональная гигиена.

На это удобно посмотреть через спрос и предложение, и тогда становится видно, почему «проблема» первична не из соображений чистоты метода, а по сути и устройству.

Спрос и предложение

Пользователь владеет спросом. У него есть проблема, потребность, задача в его контексте, и он платит за то, чтобы это закрыли. Продакт владеет предложением: фичами, изменениями, решениями. Успех это попадание предложения в спрос, и ничего больше.

Проблема это форма спроса. Задача это форма предложения. И когда вы ведете бэклог задач, вы фокусируетесь и управляете предложением, а спрос остается за кадром. Вы готовите ответ, не держа в голове вопроса. Иногда попадаете, чаще нет, и не понимаете почему: ведь предложение собрано аккуратно, по всем канонам.

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

Почему мы все равно ведем бэклог задач?

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

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

Посмотрите, кто на самом деле наполняет ваш список. Рядом идут несколько параллельных треков, и каждый тянет в свою сторону:

у продакта свой трек: KPI, исследованные пользовательские проблемы, продуктовое видение;

у разработки свой: технический долг, новые технологии, смена архитектуры, инженерное видение;

у дизайна свой: редизайн, переход на дизайн-систему, систематизация элементов;

у маркетинга свой, и зачастую он показывает только верхушки айсбергов, симптомы, которые они просят починить, а систему под ними со стороны не разглядеть;

у CEO свой, и самый властный, он приходит и говорит «надо», причем обычно в виде очень конкретного интерфейсного решения, а не проблемы, и времени объяснять замысел у него нет;

и есть внешние стейкхолдеры, регуляторы, поставщики, посредники, чьи интересы понятны еще хуже.

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

Присвоение

А ставит задачу в этот список продакт. Под своим именем, в своем инструменте. И со стороны это выглядит так, будто он сам все взвесил, сам сравнил и сам решил делать именно в таком порядке.

Происходит тихая подмена авторства: продакт присваивает чужой компромисс и выдает его за собственное продуктовое суждение.

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

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

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

Кому принадлежит проблема, а кому решение

Здесь корень того, почему спор за бэклог почти неразрешим.

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

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

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

Получается порочный круг: продакт несет риск по всем чужим решениям, не имея авторства ни на одном.

Ответственность без власти

Под присвоением и собственностью лежит то, чего в моей декабрьской статье не было совсем: власть.

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

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

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

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

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

Что здесь от меня

Остановлюсь, чтобы не приписать себе чужое.

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

Другой вопрос

Что со всем этим делать, тема следующей статьи, потому что лечение длиннее диагноза, и «шесть шагов к успеху» я вам тут не дам. Здесь я хочу оставить вас не с инструкцией, а со смещенным вопросом.

Перестаньте спрашивать «какую задачу взять следующей». Это вопрос про сортировку предложения, и он всегда даст ответ внутри уже сложившегося компромисса.

Начните спрашивать «чей это спрос, и сидит ли за столом тот, кто за него платит». Это вопрос не про сортировку, а про то, кто вообще голосует в вашем бэклоге.

Финал

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

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

Пока все чинят симптомы, я разбираю системы, которые их создают. Безрезультатный бэклог это симптом. Система это документ, в котором лоббируют все, кроме пользователя. В следующей статье разберу, как вернуть в этот документ его голос, не имея на это лишней власти.

Чей это бэклог? Почему приоритизация это политика, а не методология