Какой должна быть user_story, и что общего у системных аналитиков и голливудских сценаристов

«Тарас, за что ты получаешь свои деньги? Ты же просто рассказываешь истории!»

За то, что я хорошо их рассказываю.

С user story всё как в Голливуде: кажется, что многие сериалы похожи друг на друга, но написать по-настоящему хороший сценарий даже для ремейка не так-то просто. Ты должен жить этим фильмом, должен знать, что ты хочешь показать, какие моменты взять из жизни и как их развернуть перед зрителем. И это стоит денег.

User story легко зафакапить. А так как от системного аналитика она сразу уходит к разработчикам, то ошибка может стоить очень дорого.

Я тот самый системный аналитик. Однажды в самом начале моей деятельности мы с Product Owner друг друга недопоняли и сделали совсем не то, чего хотел заказчик.

Моя команда работала с магазином для рыбаков и должна была создать весьма нетривиальную форму для заказов, позволяющую подбирать рыболовные снасти по определённым критериям.

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

Решение получилось ровно таким, чтобы быть удобным целевой аудитории. Несмотря на user story. Бывает и так.

Чем занимается системный аналитик?

Информация приходит к разработчикам по цепочке:

• Бизнес, то есть заказчик.
• Product owner (он же — PO) — человек, который контактирует с бизнесом и отвечает за ценность продукта.
• Системный аналитик — тот, кто получает от PO задание и доносит его до команды удобным понятным способом.

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

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



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

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

Для чего вообще нужны разработчику user story?

Одна из аксиом, не требующих доказательств, — бизнес всегда хочет сэкономить и получить максимальный функционал. А корректно и вежливо отказаться от дополнительных обязанностей получается не всегда. Это боль: я несколько лет проработал в веб-студиях, которые постоянно ругались с заказчиками из-за того, кто и что должен был сделать. А потом на меня снизошло божественное откровение: если при заключении договора прописать все user story и use case, то можно договориться обо всём чётко и на понятном бизнесу языке. И в случае чего говорить: «Мы с вами обсудили, что пользователь будет делать такие шаги. Вот первый юзкейс, вот — второй. Третий оказался ошибочным (показывает действия, если происходит ошибка). Двадцать кейсов, про которые мы с вами договаривались, реализовано.

Как здорово, что у вас появились новые идеи! Давайте заключим следующий договор, и мы сделаем новый спринт!»

В тех же веб-студиях, уже в финтехе, я получил интересный опыт международной аналитики. И оказалось, что user story может казаться необязательной, когда работа идёт внутри страны. Но как только на сцену выходят программисты из других государств с совершенно другим менталитетом, начинаются сюрпризы. Код, интеграция, описание параметров, логика — у них всё совершенно другое! Например, китайцы очень любят, особенно на ранних стадиях проекта, пока разрабатывается Api, присылать письмом Excel, который нужно получить, распаковать, загрузить в базу и провести сверку… Поэтому вообще все шаги нужно описывать так, чтобы не оставалось ни одного слова, которое можно было бы понять двояко.

Так что же такое user story и как её построить?

User story — это очень маленькая и очень простая история, буквально из двух-трёх предложений, которая описывает требуемое нам действие. В эти два-три предложения нужно уместить чёткие ответы на самые важные вопросы:

«О каком пользователе идёт речь? Какая у него роль?»

«Чего он хочет?»

«Какого результата он должен достигнуть в конечном итоге? Какое одно действие нужно
улучшить?»

«Зачем он этого хочет?»

Например:

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

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

Хорошая история обязательно оказывает какое-то влияние на выбранного пользователя и отвечает критерию «Invest». Это значит, что она:

I — Independent. Не зависит от других историй. Все они могут быть реализованы в любом порядке.

N — Negotiable. Обсуждаема. Она отражает суть, а не детали, и не содержит конкретных шагов реализации.

V — Valuable. Ценна для клиентов, бизнеса и стейкхолдеров.

E — Estimable. Её можно оценить по сложности и трудозатратам.

S — Small. Она компактна и может быть сделана командой за одну итерацию.

T — Testable. Она имеет определённые критерии приёмки, т. е. тестируема.

Например: Как инвестиционный аналитик я получаю отчет № 17 об инвестициях БЫСТРЕЕ.

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

Любая user story должна быть подкреплена другими фактами и документами. Она не самоцель, а трассер к общей цели продукта. И таких трассеров может быть очень много. Если связи нет, значит, что-то пошло не так.

Прежде чем разбираться с отчётом № 17 из предыдущего примера, нужно определить, какая изначально у компании цель и какая метрика её характеризует. Например, цель — «ускорение сроков согласования инвестиционных бюджетов», метрика — время. Достичь цели поможет инвестиционный аналитик. Возможно, если он будет получать отчёт № 17 быстрее, то сроки согласования бюджетов тоже сократятся… Значит, данная user story нужна для проверки предположения, которое, в свою очередь, служит большой глобальной цели.

Самая типичная ошибка при составлении user story выглядит так:

Я как менеджер хочу завести сделку.

Ты ведь в любом случае заводишь эту сделку. Какую проблему ты хочешь решить? Какую ценность недополучаешь?

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

Поэтому получение конкретных цифр — это крутейший навык всех аналитиков, PO и бизнесов.

Что обязательно должно быть прописано перед началом работы команды?

Есть люди, которые считают user story самодостаточной штукой, на которую команда может опереться, но я считаю, что это не совсем корректно.

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

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

1. Impact map

Если PO попытается разговаривать с бизнесом с помощью user story, то разговор в них утонет. Но можно «нанизать» жемчужинки этих историй на ниточки impact map.

Если уйти от поэтических образов, то impact map — это структурированный разговор PO с бизнесом. Выглядит он почти как диалог с психологом: «Что у вашего бизнеса болит? А почему болит? Давайте представим, что нужно сделать, чтобы оно не болело». В результате из одной большой боли (например: «Я теряю деньги») получается конкретный список очень реальных шагов, кто и что должен сделать, чтобы у бизнеса «не болело». Каждый из этих шагов дальше можно доработать до user story. Если работа построена таким образом, то в любой момент я как представитель команды всегда могу уточнить у PO, к какой большой цели мы идём и чего хотим достичь в финале.



2. User story

Impact map разбирается на конкретные бусинки-истории, которые PO и передаёт системному аналитику. То есть мне.

Но если я покажу их условному тестировщику, то он удивлённо на меня посмотрит и спросит: «А что я, собственно, должен здесь проверить?»

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

3. Use case

Use case — это техническое описание задания, которое помогает быстрее объяснить разработчикам, какими конкретно должны быть действия пользователей в системе, чтобы максимально реализовалась user story.

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

Например:

И этот момент тестировщик уже может проверить. Есть конкретная цифра — 20 %. Допустим, что раньше заказ проходил за пять минут, а теперь — за четыре. Стало быть, у нас всё получилось, можно переходить к следующей задаче.

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

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

И самое главное — в этом процессе все понимают, что происходит. Бизнес оперирует цифрами.

PO оперирует идеями, которые должны улучшить продукт. Команда работает с понятным бэклогом о том, что нужно делать и как это проверить.

Как отличить use case от user story?

Несмотря на то, что user story и use case — это базовые понятия, их часто путают между собой даже опытные айтишники.

User story — механизм передачи информации от product owner’а команде в форме, достаточной для реализации, но наименее бюрократизированной. Маленькая простая история, каждое слово в которой предельно важно.

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

Чтобы разработка и тестирование шли параллельно, нужны оба эти инструмента.

А если что-то где-то не сходится, то всегда можно найти, кто в этом виноват: то ли разработчик, то ли тестировщик, то ли аналитик, который написал кривой use case по дополнительным ТЗ и наброскам интерфейса.


Наглядная разница между user story и use case

И напоследок — парочка баек из жизни системного аналитика.

Байка номер один. Про неожиданности.

Однажды мы участвовали в хакатоне. Заказчик оставил весьма солидное задание, которое нам очень понравилось. Мы составили классный пакмат, заказчик даже сам удивился, насколько хорошо понял, чего он хочет. Всё проговорили. Я расписал команде задание. Ребята накодировали…

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

Мораль: душа заказчика — потёмки, и никакой пакмат не спасёт вас от ошибок на более высоком уровне.

Байка номер два. Про идеальную user story.

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

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

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

Мораль: правильно прописанная user story — отличный фундамент для работы.