Пользовательская история: как одна фраза меняет то, что строит команда
В 1998 году в компании Chrysler запускали проект C3 — систему расчета зарплат для десяти тысяч сотрудников. Проект много лет буксовал на классической документации: аналитики писали спецификации на сотни страниц, разработчики их читали неделями, а к моменту запуска требования успевали устареть дважды. Тогда в команду позвали Кента Бека, и вместе с коллегами он начал экспериментировать с новым подходом — вместо толстых технических заданий команда стала записывать требования на обычных карточках, буквально по одному предложению на карточку. Так родилась практика, которая позже превратилась в методологию Extreme Programming, а сами карточки стали прародителями того, что сегодня называют User Story.
Идея была почти наивной по простоте: если написать требование так, чтобы оно помещалось на карточке и было понятно без переводчика, команда обсудит его вживую, а не будет угадывать смысл между строк спецификации. Через несколько лет Рон Джеффрис, один из соавторов Extreme Programming, сформулировал знаменитое правило трех «C»: Card (карточка с кратким описанием), Conversation (разговор, в котором уточняются детали) и Confirmation (критерии, по которым проверяется, что задача сделана).
Содержание:
- Зачем понадобилась еще одна форма требований
- Анатомия истории
- Как проверить, что история не развалится
- Формат и контекст
- Что дальше
Зачем понадобилась еще одна форма требований
К концу 90-х индустрия разработки уже накопила солидный арсенал форматов документации. Были подробные технические спецификации, были use case — сценарии использования системы, которые предложил Ивар Якобсон и развил Алистер Коберн. Они описывали шаги взаимодействия пользователя с системой вплоть до альтернативных исходов и исключений. Use case работали хорошо для крупных корпоративных систем, где ошибка в логике стоила дорого, но были тяжеловесны для команд, которым нужно было выпускать обновления еженедельно, а не раз в квартал.
User Story решала другую задачу: она фиксировала одну маленькую пользу, которую получит конкретный человек. Разница примерно та же, что между чертежом дома и запиской «хочу, чтобы кухня была светлой, потому что готовлю по утрам, когда солнце уже встало, но лампу включать не хочется». Записка не заменяет чертеж, но без нее архитектор может десять раз повернуть окно не в ту сторону.
В 2004 году Майк Кон в книге User Stories Applied окончательно закрепил формат для широкой аудитории: он показал, как превращать истории в бэклог, разбивать крупные на мелкие и как оценивать их в скраме. К этому моменту практика уже плотно срослась с Agile-манифестом 2001 года, один из принципов которого прямо гласит: «работающий продукт важнее исчерпывающей документации». User Story стала материальным воплощением этого принципа — минимально достаточный текст, который не подменяет живое обсуждение, а запускает его.
User Story описывает потребность и ценность — она отвечает на вопрос «зачем». Задача (task) фиксирует конкретную работу для исполнителя — отвечает на «что сделать». А техническое требование описывает, как система должна себя вести на уровне логики, интеграций и ограничений — отвечает на «как это устроено». Одна история на этапе декомпозиции обычно порождает несколько задач и может тянуть за собой отдельный документ с техническими деталями, если сценарий сложный.
Анатомия истории
Классическая формула выглядит так «Как <роль>, я хочу <действие>, чтобы <польза>». Три части этой фразы работают как система сдержек и противовесов. Роль не дает истории превратиться в абстрактное пожелание «сделать удобнее». Действие не дает ей превратиться в лозунг без содержания. А польза — самая важная часть — не дает команде спутать фичу с ценностью.
Разница между действием и пользой обманчиво тонкая, но на ней ломается половина плохих историй. «Хочу добавить фильтр по цене» — это про решение. «Хочу быстро отсеять товары не по карману» — это про задачу. Если зафиксировать только первое, разработчик добросовестно прикрутит фильтр, а пользователь все равно продолжит листать сорок страниц каталога, потому что фильтр окажется зарыт в третьем уровне меню.
Роль тоже требует аккуратности. «Пользователь» — это почти всегда слишком широко: у новичка, оформляющего первый заказ, и постоянного клиента с сохраненной картой совершенно разные боли, и одна кнопка «оформить в один клик» им нужна по разным причинам. Хорошая практика — держать в команде живой список ролей или, чем дальше, тем чаще — персон с именами и привычками, чтобы формулировка «как маркетолог» не превращалась в фигуру речи, а отсылала к реальному человеку, о котором команда что-то знает.
Как проверить, что история не развалится
Через несколько лет после выхода книги Кона Agile-консультант Билл Уэйк предложил метод INVEST. Каждая буква проверяет историю на конкретный порок.
Independent — история должна быть по возможности независима от других: если ее нельзя оценить и реализовать без пяти соседних историй, приоритизация превращается в фикцию, потому что в бэклоге по факту лежит одна огромная задача, разрезанная для вида. Negotiable — история не контракт, а приглашение к разговору: детали должны обсуждаться в моменте, а не быть высечены в камне на этапе записи идеи. Valuable — история должна нести ценность для пользователя или бизнеса, а не только для внутренней архитектуры; чисто техническую рефакторинговую задачу обычно не стоит рядить в костюм User Story, для нее есть другие форматы. Estimable — команда должна быть в состоянии хотя бы приблизительно оценить объем работы; если оценка невозможна, скорее всего в истории спрятана неопределенность, которую нужно исследовать отдельно. Small — история должна помещаться в один спринт или итерацию, иначе она рискует зависнуть между планированиями. Testable — у истории должен быть понятный критерий, по которому можно сказать «сделано» или «не сделано».
На практике команды чаще всего спотыкаются на Small и Testable: истории пишут с запасом, а критерии оставляют размытыми.
Формат и контекст
Классическая формула прекрасно работает для простых случаев, но реальные сценарии часто требуют больше контекста. Отсюда несколько распространенных модификаций шаблона. Есть вариант с явным указанием ситуации — «когда я нахожусь на странице оплаты, как покупатель, я хочу видеть итоговую сумму с учетом скидки, чтобы не пересчитывать ее вручную». Такая форма особенно полезна, когда задача привязана к конкретному шагу воронки. Есть вариант с ограничением, который сразу называет условие, при котором решение работает — например, «при условии, что данные карты уже сохранены». Такое уточнение экономит команде отдельный раунд обсуждений, потому что сразу отсекает нерелевантные технические варианты.
Здесь же уместно вспомнить подход Jobs to Be Done, который придумал профессор Гарварда Клейтон Кристенсен. Применительно к User Story JTBD работает как проверка на глубину: если история звучит как «хочу сохранить товар в избранное, чтобы вернуться позже», стоит спросить, что на самом деле мешает купить сейчас. Может быть, человек ждет зарплату, сравнивает цены в трех местах или просто не готов принять решение впечатления ради. Ответ на этот вопрос радикально меняет то, что стоит строить: кнопку «избранное» или напоминание о снижении цены, письмо с сравнением или просто отложенную корзину с гарантией цены на неделю.
Что дальше
Написанная история редко остается в исходном виде до релиза. Если она оказывается слишком крупной, команда режет ее на части по шагам сценария, по устройствам, по сегментам аудитории — так, чтобы каждый кусок сохранял самостоятельную ценность и мог быть выпущен отдельно. История «хочу быстро оформить заказ с телефона» может распасться на упрощение полей ввода, адаптацию кнопок под палец, а не курсор, ускорение оплаты и снижение неопределенности через явное указание стоимости доставки до последнего шага. Каждый из этих кусков можно протестировать по отдельности и увидеть, какой из них реально двинул метрику, а какой оказался красивой гипотезой без последствий.
Сама история проходит путь от смутного наблюдения в аналитике до проверенного результата. Сначала команда замечает точку отказа, затем переводит ее в формулировку с ролью, действием и пользой, затем обвешивает контекстом и критериями приемки, затем берет в работу и, наконец, смотрит, изменилась ли метрика, ради которой все затевалось.
Типичные ошибки почти всегда сводятся к одной из двух крайностей. Либо история слишком общая — «как пользователь, хочу удобный интерфейс, чтобы было приятно пользоваться» — и трактуется каждым членом команды по-своему. Либо история подменяет пользу техническим решением — «хочу видеть кнопку в правом верхнем углу» — и тогда команда реализует форму, забыв про функцию.
При этом важно помнить про ограничения самого подхода. User Story не заменяет техническую документацию там, где логика системы сложна и цена ошибки высока — банковские интеграции или медицинские сервисы редко описываются одной фразой про роль и пользу. И история хороша ровно настолько, насколько она опирается на реальное наблюдение за пользователем, а не на догадку продакта, который уверен, что знает, чего хотят люди.
