User stories: как писать задачи, которые команда действительно понимает
Когда команда растёт быстро, у каждого нового человека своё представление о том, как должна выглядеть задача. Один привык к подробным техническим спецификациям, другой работал в стартапе, где задачи обсуждали устно за кофе, третий вообще впервые слышит про user stories. И вот все они смотрят на одну карточку в Jira и видят разное.
У нас эта ситуация встречается особенно часто. Компании растут, набирают людей из разных сфер, формируют новые продуктовые команды. Людям нужно быстро научиться понимать друг друга, и user stories могут в этом помочь. Если, конечно, использовать их правильно.
Когда все понимают по-разному
В одной финтех-команде в Алматы случилась показательная история. Product owner написал story: «Как пользователь я хочу получать уведомления о транзакциях, чтобы контролировать расходы». Всё по шаблону. На планировании бэкенд-разработчик понял это как push-уведомления, фронтендер начал проектировать экран с историей, а аналитик имел в виду SMS. Три человека, три картины мира, одна расплывчатая формулировка.
Дело было совсем не в шаблоне. Проблема в том, что story использовали как готовое требование, хотя её роль - начать разговор. Модель трёх C (Card, Conversation, Confirmation), которую описал Ron Jeffries, как раз про это. Карточка - только повод поговорить. Confirmation - это те самые acceptance criteria, в которых команда фиксирует, о чём договорились.
Как наладить понимание в формирующейся команде
Когда люди ещё притираются друг к другу, нужны более явные практики. Со временем общий контекст нарастёт и многое станет очевидным, но на старте полезно быть чуть более формальными, чем кажется нужным.
Совместное написание критериев приёмки. Вместо того чтобы product owner приносил готовые acceptance criteria, стоит формулировать их втроём - продакт, разработчик, тестировщик. Каждый задаёт вопросы со своей стороны, и в результате критерии получаются конкретнее. «Пользователь получает push-уведомление в течение 30 секунд после списания» гораздо полезнее, чем «уведомления работают корректно».
Пятиминутный разговор до backlog. Прежде чем story попадёт в бэклог, имеет смысл обсудить её хотя бы с одним человеком из команды. Это помогает поймать неоднозначности на ранней стадии, когда исправить их просто.
Примеры вместо абстракций. В формирующихся командах конкретные примеры работают лучше обобщённых формулировок. «Марат переводит 5000 тенге другу, оба получают уведомление» понятнее, чем «система уведомляет участников транзакции».
Размер историй в условиях быстрого роста
Когда бизнес давит на скорость, появляется соблазн писать крупные истории - чтобы «не мелочиться». Но в растущей команде большие story работают плохо. Новые люди не могут охватить контекст целиком, оценки расходятся в разы, а product owner теряет возможность гибко управлять приоритетами.
Лучше разбивать по пользовательским сценариям. Каждый кусок должен нести самостоятельную ценность и быть достаточно компактным, чтобы обсудить за десять минут. Если обсуждение затягивается, внутри наверняка спрятано несколько разных историй.
Story как инструмент адаптации
Есть побочный эффект, о котором редко говорят. Хорошо написанные user stories помогают новым членам команды быстрее войти в контекст продукта. Читая backlog, человек понимает, кто пользователи, какие у них задачи, что для них важно. Это работает лучше любой документации по онбордингу, потому что отражает живой, актуальный контекст.
В быстрорастущих командах у нас это особенно ценно. Когда каждый квартал приходят новые люди, хорошо структурированный backlog становится общей картой, по которой можно ориентироваться.
Если хотите разобраться в продуктовом управлении бэклогом, приоритизации и работе с данными, посмотрите программу Advanced Product Ownership. А для системного погружения в agile-практики подойдёт Certified Agile Professional.