Автор статьи:

Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

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

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

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

Избавиться от лишнего поможет формулирование пользовательской истории в контексте ЧТО нужно пользователю и ЗАЧЕМ. 

Например, Я как <роль/сегмент пользователя> хочу <задача> чтобы <цель> или «Я как покупатель магазина хочу получать кэшбек за покупки, чтобы экономить бюджет».

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

1. Пообщайтесь с пользователями и выявите их основные триггеры и мотивы при совершении покупки, запишите основные триггеры и инсайты.

2. Сформулируйте требования в «Пользовательской истории», задавая вопросы:

• А чего все-таки хочет пользователь?

• Хочет ли он регистрироваться или он хочет копить кэшбек? Хочет ли он создать личный кабинет или хочет вести управлять электронным кошельком?

• Тогда нужна ли нам регистрация или мы можем решить задачу клиента без нее?

• Нужен ли полноценный личный кабинет или нужно отражать баланс пользователя? Поверьте, при взгляде со стороны пользователя у вас 80% работы удалится или изменится.

• Что можно сделать проще и дешевле?

3. Обсудите пользовательские истории с командой. Как вы будете их реализовывать, какие решения придумаете? Не стоит это делать в одиночку только аналитиком. В команде вы получите гораздо больше решений и вовлеченности за счет мозговых штурмов.

4. Приоритезируйте фичи и задачи. Выделите главные, которые образуют минимальную версию решения пользовательской истории, а остальные идеи откиньте на потом. Один из инструментов приоритизации и выделения главного — User Story Map.

Главное — сместить фокус на пользователя, внедрить привычку декомпозировать и отбрасывать лишнее. Это поможет вам создавать лучшие, более простые и дешевые решения и давать пользу клиентам.

Какие реальные бенефиты мы получаем?

1. Сокращается стоимость разработки.

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

Когда мы прикинули все задачи в бэклоге, то примерно оценили, что срок разработки займет не менее 12 месяцев. Это долго и дорого. 

Тогда мы начали смотреть, какие задачи решают потребности, а какие нет. Или в меньшей степени. В итоге удалось сократить бэклог в 3 раза. А срок разработки — до 4 месяцев. 

Из расчета 300 000 руб средняя зарплата разработчика + отчисления, 7 человек в команде — экономия 24 млн рублей.

Далее при запуске Scrum в команде и регулярной и качественной декомпозиции удается сократить еще до 20% задач. А это еще 2 спринта разработки. Таким образом, спустя 3 месяца работы получилось минимально работающее решение, которое уже решает задачи бизнеса и возвращает инвестиции.

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

2. Уменьшается этап длительного анализа и ускоряется старт работы над продуктом.

На практике я часто встречал, что глубокий системный анализ и попытка все задокументировать занимает реально очень много времени. Так в одном проекте этап анализа занял 6 месяцев, так как был ориентирован на детальную проработку перед стартом проекта. При том, что сам проект рассчитан был на 1 год. После написания ТЗ разработка заняла 1.5 года. В итоге вместо предполагаемого года, вышло 2. Основной источник затрат по длительности — это написание детального ТЗ. При разработке по пользовательским историям, вместо того, чтобы писать большое ТЗ, сформулируйте основные пользовательские истории, далее уточните и напишите критерии приемки к ним. То есть те критерии, по которым эта пользовательская история будет приниматься. Далее, когда запустите процесс разработки, итеративно прорабатывайте каждую пользовательскую историю параллельно с разработкой, но не уходите в глубокий анализ, чтобы экономить время.

Итого:

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

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

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

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

Всех желающих приглашаем на открытое занятие «Фиксация требований с помощью Use Case», на котором узнаем:

• как описать взаимодействие Актора и Системы;

• как отобразить все процессы и всех Акторов и не запутаться;

• кто в команде скажет "спасибо" за Use Case;

• как выбрать между Use Case и User Story.

Регистрация доступна по ссылке.

А если вам понравилась статья, жду в своем телеграмм канале и на сайте.