Читать книгу Антихрупкость в IT - Александр Васильевич Бындю - Страница 10

Раздел I. Управление IT-продуктами
Глава 1. Кнопочное мышление против целостного IT-продукта
Мимикрирующие User Story и хитрые Product Owner'ы

Оглавление

С источниками кнопочного мышления разобрались. Теперь узнаем, что с ними делать. Почему мы даём Решалам порулить? Почему не отбрасываем поверхностные идеи? Как предотвратить собственное решательство?

User Story как фильтр

Когда я думал о фильтрах, не пропускающих кнопочные идеи, вспомнились User Story[4]. Мы используем истории для формирования задач проекта в повседневной практике. Сила User Story в том, что они заставляют описывать ценность. Нет ценности в истории – нет лишней кнопки в интерфейсе.

Работа строится следующим образом. Вносишь в работу идею → опиши в виде User Story. Ответь на вопрос «Чтобы что?».

Хочешь кнопку выгрузки отчёта в Excel. Ок, чтобы что? Чтобы было на всякий случай? В мусорку, не берём в работу.

Бухгалтер Оля сказала, что ей так нравится? В мусорку, не берём в работу.

Вы посовещались внутри отдела экономистов, нарисовали кнопку в интерфейс и теперь хотите, чтобы мы её добавили? Чтобы что? Потому что это ваша идея и она вам нравится? В мусорку.

Вы заказчик и вы так видите? Другого «чтобы что» нет? Увы, в работу не берём. Иногда можно сделать ставку на Pet Feature, но перед этим следует обозначить риски и чётко проговорить бесполезность затеи.

Хитрые Product Owner'ы

User Story отлично отсеивает кнопочные идеи. Проверено на практике. Однако здесь появляется оборотная сторона проблемы. Product Owner'ы и stakeholder'ы поняли, что через User Story не пройти, потому что приходится искать ответ на вопрос «Чтобы что?». А это сложно, если ты пришёл с Pet Feature. Сложно, но сильно хочется.

Product Owner'ы[5] подстроились под новую модель постановки задач. Они научились играть в эту игру.

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

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

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

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

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

Мимикрирующие User Story

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

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

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

Хочу…

Чтобы…

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

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

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

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

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

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

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

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

4

Андрей Шапиро. Руководство по сбору требований в формате User Story Mapping, https://byndyu.ru/footnote/4

5

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

7

Gojko Adzic. Fifty Quick Ideas To Improve Your User Stories

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

Подняться наверх