«Тарас, за что ты получаешь свои деньги? Ты же просто рассказываешь истории!»
За то, что я хорошо их рассказываю.
С 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 можно собрать небольшой блок из юзкейсов, т. к. это понятная для бизнеса вещь, по которой можно как дать задачу, так и отчитаться.
Например:
Область действия |
Веб-приложения магазина |
Действующее лицо |
Пользователь |
Предусловие |
Пользователь находится на детальной странице товара |
Гарантии успеха |
Товар перемещён в корзину |
Триггер |
В любой момент, когда пользователь находится на детальной странице товара |
Описание |
1. Пользователь выбирает количество товара, которое он хочет переместить в корзину. |
Описание альтернативных результатов |
1. Пользователь получает сообщение об отсутствии нужного товара на складе и о возможности уменьшить количество товара. |
И этот момент тестировщик уже может проверить. Есть конкретная цифра — 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 — отличный фундамент для работы.