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

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

❦

Клиент: Я хочу более быстрого коня. (Кто-то записал бы это в карту историй, но не мы).

Изобретатель: Хм… Какая интересная мысль. Скажите, а почему скорость коня так важна для вас?

Клиент: Я хочу доезжать до дома не за 2 часа, а за 15 минут.

Изобретатель думает: «Вот это уже задача». Ему грезится автомобиль или телепорт, но вслух продолжает: Кажется, кое-что начинает проясняться. Скажите, а почему важно доезжать именно за 15 минут?

Клиент: Ну… Понимаете, моя жена ненавидит, когда я приезжаю вспотевшим. Мне не хочется её расстраивать, душ я не люблю, да и некогда, сменных рубах немного, и времени стирать их нет. Я думаю, за 15 минут на скаку моя рубашка не успеет взмокнуть.

Изобретатель думает: «Впору подумать о новом виде одежды?»

❦

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

Внимательный читатель конечно же заметил, что я поставил некоего «изобретателя» в роль сборщика требований. Это сделано намеренно. По моему убеждению лучшие результаты и меньшие потери информации достигаются, когда проблему постигает и ставит задачи тот, кто их будет решать. Так мы делаем в Byndyusoft, когда привлекаем всю команду проекта целиком к этапу аналитикибудущего продукта (Product Discovery). Мы часто слышим от других участников рынка, что это утопия, что это не работает на масштабе, однако именно такое положение вещей помогает нам достигать качества.

Возьмём кусочек карты с историями для разработки системы для организации хранения грузов на внешнем складе. Две представленые на картинке истории записаны для работника склада, использующего терминал сбора данных (ТСД). Терминал показывает предстоящие задачи на размещение и извлечение грузов и помогает регистрировать перемещения грузов.

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

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

Обратите внимание на то, что произошло. Для этой истории теперь можно предложить варианты решения, отличные от авторизации через пару телефон-пароль. Например, мы можем ввести принцип, по которому и клиенты системы, и сотрудники склада будут распределены к зонам погрузки. Тогда работник склада, принимаясь за работу, укажет на ТСД свою зону и получит свои задачи. Либо мы можем выбрать вариант исполнения истории с входом. Важно, что история продвинулась на один уровень понимания глубже и лишилась излишних предписаний.

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

Давайте разберёмся со второй историей. Изначально она звучала так: «Работник склада синхронизирует ТСД, чтобы получить задания с сервера». Как мы сразу замечаем здесь две подробности, недопустимые на уровне историй: «ТСД» и «сервер». Им место в карточках детализирующих задач на релиз, но не в истории. Оставляя такие детали в истории, мы надеваем шоры, мешающие находить хорошие решения.

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

1. оценка человеком состояния как нежелательное (невидима);
2. подача команды на исправление ситуации;
3. получение ответа;
4. оценка состояния как желательное и выход из последовательности или повторение цикла.

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

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

1. Понимание, что задачи давно не обновлялись, и человеку требуется что-то сделать, во всех иных ситуациях новые задачи доставляются на ТСД автоматически.
2. Исправление ситуации: восстановление интернет-соединения, звонок в службу технического сопровождения (производятся вне системы).

Запишем новую историю: «Работник склада понимает, что задачи подозрительно долго не обновлялись, и что предпринять, чтобы исправить ситуацию».

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

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

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

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

Со временем я пришёл к мысли, что это нормальная ситуация, и можно жить с неполными историями. Такие неполные истории формулируют будущие задачи на проектирование.

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

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

То есть с этими недостатками легко бороться, вовлекая команду во встречи со стейкхолдерами и создание карты.

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

Как и любой метод моделирования реальности User Story Mapping помогает нам придумывать модель, но важно не забывать, что это модель, а не реальность. Сторимапинг базируется на модели пользователя, придуманной нами. Содержит предположения проблем пользователя — тоже модель. Содержит предположения о решениях этих проблем — еще одна модель. Модель на модели и моделью погоняет. Важно не забывать этого и проверять их на адекватность реальности.

Один раз нас спросили, почему мы пользуемся «устаревшими» пользовательскими историями, а не методом JTBD и свойственной ему Job Story. Методы имеют сходства и различия, но речь не идёт о том, что один устарел, а другой пришёл ему на смену. Давайте разберёмся.

Когда презентуют метод JTBD чаще всего критикуется модель персоны, «не помогающую» ухватить суть почему люди предпочитают одни продукты другим. Важным прорывом JTBD стало перевод фокуса с модели персоны на контекст.

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

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

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

Для людей более глубоко изучивших JTBD дам ещё несколько пояснений. Вы ничего не потеряете пропустив эту часть статьи, если только начинаете применять один из методов. Я буду детальнее рассмотривать возражения против пользовательских историй одного из апологетов Job Stories, критикующего User Story.

1. «As a person — это предположение». Это так, но мы чаще всего в USM используем функциональные роли вместо персон, с ними таких проблем нет. Возьмём для примера две функциональные роли: продавец и покупатель. Истории для них в большинстве случаев будут разными. Общие для них истории можно пометить карточками обоих пользователей. Когда не удаётся выделить чёткие функциональные роли, я бы предпочёл использовать контексты JTBD для описания входа в ситуацию, вместо выдумывания персон.
2. «I want to do — это предположение». Это так, я писал об это выше. Здесь место, в которое в историю пробирается дизайн. Важно понимать, что степень вреда этого предположения регулируется уровнем детализации в записи этого хочу. Если эта часть записана без излишних деталей, то пользовательская история состоит из двух уровней expected outcome: первый — описывающий, что должно в итоге произойти, второй — описывающий как этог итог будет использован дальше. А это то же самое, что две части формата записи Job Story только наоборот motivation + expected outcome.
3. Добавление When создаёт самое полезное в Job Story — контекст. В USM мы вносим контекст за счёт положения истории между историй и группировкой их в активность, которые так же задаёт контекст. Если контекст важно задать иным образом, ничего не мешает нам записать на карточке историю в формате Job Story внутри USM.
4. Все примеры Job Stories, приведенные автором, длинные и поэтому трудно читаемые. Мне трудно представить как читать карту из таких историй, когда она будет состоять из десятков карточек — типичная карта вновь разрабатываемой сложной системы. Неясно как работать с сотней подобных историй. Как их уложить себе в голову?

❏