За время работы в компании Intuit я научился писать подробные требования к продуктам, которые оставались в области проблем, не переходя в область решений. Нас учили сначала фокусироваться на том, что продукт должен предлагать клиентам, прежде чем переходить к тому, как он может это сделать. Наверняка вы часто слышали, что действительно сильные команды разработчиков проводят четкое различие между понятиями «что» и «как». При этом к категории «Что» относят преимущества, которые разрабатываемый продукт должен дать потребителю. Под «Как» подразумеваются способы достижения и предоставления клиенту этого самого «Что». «Как» – это дизайн продукта и конкретная технология. «Что» находится в пространстве проблем, а «Как» – в пространстве решений.
Разработка продукта «снаружи – внутрь»
Неспособность получить четкое представление о пространстве проблем до перехода в пространство решений присуща компаниям и командам, которые практикуют разработку своих продуктов по схеме «изнутри наружу», где под «внутри» понимается компания-разработчик, а под «снаружи» – потребители и рынок. В таких командах идеи новых продуктов представляют собой то, что, по мнению одного или нескольких сотрудников, было бы неплохо сделать. Они не тестируют свои идеи на пользователях, чтобы убедиться, что придуманный ими продукт действительно удовлетворит реальные потребности клиентов. Лучший способ снизить риск такого мышления «наизнанку» – убедиться, что команда разработчиков общается с потребителями. Вот почему Стив Бланк[2] призывает продуктовые команды «выходить в народ»[3].
Напротив, разработка продукта «снаружи внутрь» начинается с понимания проблемного пространства заказчика. Общение с клиентами позволяет понять их потребности и выяснить, что им нравится или не нравится в уже существующих решениях. Так, еще до начала работы над продуктом разработчики получают четкое представление о проблемном пространстве. Команды, создающие бережливые продукты, выдвигают гипотезы и запрашивают от потребителей обратную связь в отношении предлагаемых дизайнерских решений на ранних стадиях, чтобы таким образом проверить жизнеспособность своих гипотез. Такой подход соответствует самой сути бережливого производства. Впервые он был предложен много лет назад практиками дизайна, ориентированного на пользователя.