Автор статьи: Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом. Согласитесь, что одну и ту же бизнес-задачу можно решить разными способами, и бюджет у разных решений также будет сильно разный. У любой коммерческой компании единственная цель — больше зарабатывать, принося пользу своим клиентам. Поэтому компания заинтересована в том, чтобы создавать простые и дешевые решения, которые приносят выгоду пользователям, которые впоследствии будут платить за продукт. Поэтому у любой продуктовой или проектной команды должен быть фокус на пользователях, чтобы максимизировать ценность того, что они делают и фокус на простых решениях, чтобы максимально быстро и просто создать готовое решение и протестировать его в бою. Какую главную ошибку допускают большинство проектных и продуктовых команд перед стартом разработки? Они сразу формулируют задачи в контексте решения, а не с точки зрения потребности для пользователя. И поэтому делают очень много лишней работы. Давайте разберемся, почему. Пример. Стоит задача сделать личный кабинет пользователя, накопления баллов и кошелек. Ошибка здесь — создавать решение с безумно большим количеством фич и функционала, забыв при этом ответить на вопрос — а зачем это пользователю? При таком подходе мы делаем много лишней и ненужной работы. А теперь посчитайте, сколько вам обходится команда в месяц. Избавиться от лишнего поможет формулирование пользовательской истории в контексте ЧТО нужно пользователю и ЗАЧЕМ.  Например, Я как <роль/сегмент пользователя> хочу <задача> чтобы <цель> или «Я как покупатель магазина хочу получать кэшбек за покупки, чтобы экономить бюджет». Чтобы правильно сформулировать историю, нужно сперва изучить ваших пользователей. Тогда история получится истинно пользовательской, а не просто вашей галлюцинацией. 1. Пообщайтесь с пользователями и выявите их основные триггеры и мотивы при совершении покупки, запишите основные триггеры и инсайты. 2. Сформулируйте требования в «Пользовательской истории», задавая вопросы: А чего все-таки хочет пользователь? Хочет ли он регистрироваться или он хочет копить кэшбек? Хочет ли он создать личный кабинет или хочет вести управлять электронным кошельком? Тогда нужна ли нам регистрация или мы можем решить задачу клиента без нее? Нужен ли полноценный личный кабинет или нужно отражать баланс пользователя? Поверьте, при взгляде со стороны пользователя у вас 80% работы удалится или изменится. Что можно сделать проще и дешевле? 3. Обсудите пользовательские истории с командой. Как вы будете их реализовывать, какие решения придумаете? Не стоит это делать в одиночку только аналитиком. В команде вы получите гораздо больше решений и вовлеченности за счет мозговых штурмов. 4. Приоритезируйте фичи и задачи. Выделите главные, которые образуют минимальную версию решения пользовательской истории, а остальные идеи откиньте на потом. Один из инструментов приоритизации и выделения главного — User Story Map. Главное — сместить фокус на пользователя, внедрить привычку декомпозировать и отбрасывать лишнее. Это поможет вам создавать лучшие, более простые и дешевые решения и давать пользу клиентам. С одним из моих клиентов, который разрабатывает приложение по доставке товаров, мы полностью пересмотрели бэклог по созданию новой функциональности для решения бизнес-задач. Весь список задач, которые потенциально надо было делать, прогнали через пользовательские истории. Через «в какую потребность пользователя они бьют». Когда мы прикинули все задачи в бэклоге, то примерно оценили, что срок разработки займет не менее 12 месяцев. Это долго и дорого.  Тогда мы начали смотреть, какие задачи решают потребности, а какие нет. Или в меньшей степени. В итоге удалось сократить бэклог в 3 раза. А срок разработки — до 4 месяцев.  Из расчета 300 000 руб средняя зарплата разработчика + отчисления, 7 человек в команде — экономия 24 млн рублей. Далее при запуске Scrum в команде и регулярной и качественной декомпозиции удается сократить еще до 20% задач. А это еще 2 спринта разработки. Таким образом, спустя 3 месяца работы получилось минимально работающее решение, которое уже решает задачи бизнеса и возвращает инвестиции. Во многих случаях на практике задач отпадает до 80% и, таким образом, вы быстрее выпускаете работающий продукт и начинаете возвращать инвестиции, дорабатывая его на основе обратной связи с рынка.  На практике я часто встречал, что глубокий системный анализ и попытка все задокументировать занимает реально очень много времени. Так в одном проекте этап анализа занял 6 месяцев, так как был ориентирован на детальную проработку перед стартом проекта. При том, что сам проект рассчитан был на 1 год. После написания ТЗ разработка заняла 1.5 года. В итоге вместо предполагаемого года, вышло 2. Основной источник затрат по длительности — это написание детального ТЗ. При разработке по пользовательским историям, вместо того, чтобы писать большое ТЗ, сформулируйте основные пользовательские истории, далее уточните и напишите критерии приемки к ним. То есть те критерии, по которым эта пользовательская история будет приниматься. Далее, когда запустите процесс разработки, итеративно прорабатывайте каждую пользовательскую историю параллельно с разработкой, но не уходите в глубокий анализ, чтобы экономить время. Фокус на функциональности и решении порождает дорогие решения в отрыве от пользовательских потребностей. В таких условиях разработка становится более дорогой и менее эффективной. Чтобы перевести фокус на пользовательские потребности, формулируйте задачи в пользовательских историях, отражающие потребности пользователей. Пишите к пользовательским историям критерии приемки, которые дополнят историю деталями и позволят понять, как историю в итоге принимать. Вместо детального ТЗ используйте пользовательские истории как быстрый способ зафиксировать требования клиентов, далее по ходу разработки уточняйте их и детализируйте. Общение с пользователями — задача не только Владельца продукта, но и команды разработки, в которой могут состоять аналитики. Аналитик, переводя фокус на пользователей, создает более пользовательские требования, которые экономят бюджет и ускоряют процессы разработки. Всех желающих приглашаем на открытое занятие «Фиксация требований с помощью Use Case», на котором узнаем: как описать взаимодействие Актора и Системы; как отобразить все процессы и всех Акторов и не запутаться; кто в команде скажет "спасибо" за Use Case; как выбрать между Use Case и User Story. Регистрация доступна по ссылке. А если вам понравилась статья, жду в своем телеграмм канале и на сайте.   Переводчик, редактор