Антихрупкость в IT - стр. 6

Я, как корпоративный клиент,

Хочу скачивать отчёт о движениях денежных средств,

Чтобы видеть, что баланс стал отрицательным.

Неопытный разработчик или дизайнер примут такую историю за правильную. Но присмотритесь к ней внимательно. Перечитайте эту историю и попробуйте прикинуть, какие вопросы у вас возникнут к Product Owner'у.

Я бы для начала спросил о дальнейшей жизни скачанного отчёта. О жизни пользователя, который скачает этот отчёт. Что он найдёт в отчёте? С помощью чего найдёт нужное? Как он отделит нужное от ненужного?

Правило User Story соблюдено, но без погружения и дополнительных вопросов в работу оно не работает. Что делать? Копаем, ищем корни проблемы, задаём открытые вопросы, используем принцип 5 Why[6]. Со временем узнаём корень проблемы и записываем в User Story:

Я, как корпоративный клиент,

Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.

Хочу…

Чтобы…

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

Следующий шаг – понять, как мы поменяем жизнь корпоративного клиента. Gojko Adzic в книге Quick Ideas To Improve Your User Stories[7] указывает на то, что лучше прописывать в User Story дельту между тем, как пользователь жил до релиза, и тем, как он заживёт после. Получаем такую историю:

Я, как корпоративный клиент,

Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.

Хочу останавливать работу, если баланс стал критично низким,

Чтобы не терять деньги.

Мы остановим работу пользователя и трату денег, когда баланс станет отрицательным. Когда мы озвучиваем предложение пользователям, они не верят, что можно автоматически остановить работу. Для пользователя боль потери денег настолько сильна, что они сами придумали скачивание отчёта, они готовы смотреть в отчёт, искать в нём ответ на вопрос об отрицательном балансе.

В последней версии User Story кнопочное решение убрано. Раскопана корневая проблема. Предложено решение, которое закроет корневую проблему. Появился шанс принести пользу после релиза, а не добавить ещё одну кнопку для скачивания ещё одного отчёта.

Некоторым людям неймётся выпалить решение. Они как будто играют в «Свою Игру» или «Брейнринг». Ждут вопрос и на скорость предлагают решение.

В спешке между проблемой и идеей возникает слепая зона. Цепочка рассуждений и выводов остаётся за кадром (рис. 1).

Рис. 1. Отсутствие связи между целью и решением

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