Проблема, а не решение

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

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

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

Скорость исполнения не отменяет необходимости думать. Она её усиливает.

Просьба говорит решениями

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

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

Чем проблема отличается от решения

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

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

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

У этой оптики есть имя — «работа, на которую нанимают», в англоязычной литературе jobs to be done. Идею сформулировал Клейтон Кристенсен, и притча про дрель и отверстие — её самая известная иллюстрация. Практическая польза от знания названия одна, но существенная: у подхода есть свой набор вопросов, и они точнее, чем просто «зачем тебе это».

Три из них стоит взять в работу сразу:

• Что человек делал до того, как попросил? Обходной путь, который он уже придумал, — самая честная подсказка о настоящей задаче. Скриншоты в письме, таблица на своём компьютере, сообщение коллеге «посмотри, пожалуйста» — всё это описание работы точнее любой формулировки.
• Что послужило спусковым крючком именно сейчас? Задача существовала месяцами, а просьба пришла сегодня. Ответ («выходим на площадку к сезону», «директор стал спрашивать каждую неделю») обычно и есть настоящая формулировка проблемы вместе со сроком.
• Что он перестанет делать, если это появится? Если ответ «ничего», механизм не закрывает работу — он добавляет шаг. Именно это и происходит с кнопкой экспорта в примере ниже.

Последний вопрос — самый дешёвый способ проверить решение, не построив его.

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

Докопаться до задачи за просьбой

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

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

Excel в этой формулировке исчез — он был лишь одной из догадок. Может оказаться, что у продавца уже есть выгрузка из его системы, и интеграция закроет задачу лучше; а может, хватит шаблона и проверки на ошибки. Решение выбирается после того, как проблема названа, а не до.

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

Хорошая проверка: напиши одним предложением, чья конкретно боль и в чём именно она. Если предложение выходит длиннее двух строк или в нём появляется «и» — вероятно, там два разных препятствия. Это не значит, что оба не важны; просто браться за них нужно по очереди, иначе непонятно, что именно проверяется после выкатки.

Когда просьба-решение и есть правильный ответ

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

Дно достигнуто, если выполнены три условия сразу:

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

Случаи, где просьба почти всегда верна, узнаются по признакам:

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

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

Как это выглядит: один человек с агентом

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

Менеджер отвечает: «Я каждую неделю отправляю сводку по клиентам директору». Второй вопрос: «А как делаешь это сейчас?» — «Скриншоты делаю и вставляю в письмо, это неудобно». Третий: «Директор потом открывает саму таблицу или просто смотрит на цифры в письме?» — «Нет, просто смотрит на числа».

Проблема изменилась. Человеку не нужен Excel — ему нужно без ручной работы отправлять директору читаемую сводку раз в неделю. Это может быть автоматическая рассылка прямо из системы.

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

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

Иногда на этом этапе возникает сопротивление: «Я знаю, что мне нужно, просто сделай». Это не повод сдаться, но и не место для трёх вопросов подряд: их сжимают до одного, самого полезного — «Хорошо, а как это будет использоваться?». Два-три шага раскопки остаются правилом по умолчанию; один вопрос — то, чем его заменяют, когда человек упирается. Один вопрос редко вызывает раздражение. Ответа на него часто хватает, чтобы понять, правильную ли задачу ты берёшь.

Почему это первый шаг продукт-инженера

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

Для продукт-инженера это особенно важно, потому что один человек ведёт весь путь — и некому подстраховать на входе. В большой команде неверно понятую задачу иногда ловит аналитик или тестировщик. Когда продукт делает один с ИИ, ошибка на входе проходит дальше беспрепятственно. ИИ быстро и охотно построит ровно ту догадку, которую ты ему дал. Чем мощнее исполнитель, тем дороже обходится неназванная проблема — он доведёт до прода не то.

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

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

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

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

Типичные ошибки, которые делают чаще всего:

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

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

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

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

Что работает вместо трёх вопросов:

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

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

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

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

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

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

Глубже: когда раскопку не делаютрасширенное

Раскопка стоит времени, и это время не всегда есть. Пять случаев, где правило по умолчанию отменяется, — и что делают вместо него.

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

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

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

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

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

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

Глубже: где держать формулировку проблемырасширенное

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

Одна строка в начале задачи. Минимум, который работает всегда: первая строка описания задачи — формулировка проблемы, а не решения. «Новому продавцу нужно поднять каталог в 500 позиций за разумное время, иначе он не выйдет к сезону» — и дальше уже что делаем. Агент читает эту строку вместе с задачей, и она удерживает его от достраивания лишнего.

То же предложение — в контракте среза. Там оно становится сценарием словами пользователя, о чём статья про контракт. Это не дублирование: в задаче оно живёт неделю, в контракте — вместе с кодом.

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

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

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

И минимальная форма, если заводить ничего не хочется: файл problems.md в репозитории, по абзацу на проблему, с датой и пометкой о подтверждении. Пять минут на запись, и через полгода это самый полезный документ в проекте — он показывает, что вы действительно узнали о своих пользователях.

Коротко

• Люди приносят не проблему, а первое попавшееся решение; приняв его как данность, вы наследуете чужой выбор вместе со слепыми пятнами.
• Проблема это тройка «кто, какую работу делает, что мешает» — без единого слова о механизме; решений всегда несколько, и просьба схлопывает веер в одну ветку.
• Оптика «работа, на которую нанимают» даёт три рабочих вопроса: что человек делал до просьбы, что послужило спусковым крючком сейчас, что он перестанет делать, когда решение появится.
• Инструмент раскопки — два-три вопроса «что пытаешься сделать» и «что будет, если этого не будет»; после них формулировка съезжает с механизма на задачу.
• Дно достигнуто, когда названа работа, следующее «зачем» выходит за пределы продукта, а веер вариантов перебран и просьба оказалась лучшей; глубина раскопки соразмерна цене решения.
• Решение от руководителя разбирают иначе: спрашивают «откуда просьба» и по чему поймём, что сработало, предлагают варианты с ценой вместо возражения, а если настояли — делают и записывают.
• Раскопку не делают при жёстком сроке, недоступном носителе проблемы, дешёвом решении и неизбежной работе; отменяется разговор, но не формулировка — тогда её пишут как гипотезу.
• Формулировка живёт первой строкой задачи и сценарием в контракте, а список названных проблем держат отдельно от списка работ и от списка «не строим», с пометкой «подтверждена» или «гипотеза».

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

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

• Контакт с пользователем — как проверить названную проблему в живом разговоре.
• Наименьший ценный срез — как найти самый дешёвый способ её закрыть.
• Бизнес-результат вместо выпуска — чем измерить, что боль действительно снята.
• От модели к контракту — где формулировка проблемы живёт рядом с кодом.