Как писать требования, полезные для команды. Пошаговая схема для бизнес-аналитика
В статье не будет информации о методиках и способах написания требований. Я хочу сделать акцент на правилах, без соблюдения которых даже идеальные требования не будут прочитаны, а значит, и не будут полезными для вас и команды. Некоторые из правил будут очевидными, некоторые — будто советы из книг по личностному росту («Ну да, точно, я же так и думал, но не мог сформулировать»), а о некоторых, возможно, вы прочитаете впервые.
Я работаю бизнес-аналитиком 3,5 года. Весь свой опыт я получила в стенах продуктовых компаний. Первые два места работы — это банки. Это хороший способ получить опыт. Наверное... Тебя бросают в проект, который пишет уже не первое поколение разработчиков и столько же поколений тестирует и анализирует. Для того чтобы получить полезную, а главное — достоверную информацию, ты первым делом ищешь человека, который работает на проекте дольше всех и влияет на принятие решений. Потом налаживаешь с ним контакт. И так повторяешь в каждом из отделов, с которыми у вас смежные проекты. В общем, та еще школа жизни.
Сейчас я работаю в продуктовом отделе компании Unisender. Проблема поколений и поиска давно работающего сотрудника здесь не стоит, конечно, так остро, но задачи поиска и налаживания контакта все равно остались.
Иллюстрация Каталины Маевской
«Разработчики не читают требования»
Все началось с этой фразы, которую я услышала в первый рабочий день от коллег. Хотя нет, даже раньше — от более опытных студентов на курсах по бизнес-анализу. Думаю, с этой фразой согласны все и принимают сторону либо разработчиков, либо аналитиков.
Когда я впервые столкнулась с этой проблемой, как любой нормальный человек, я начала разбираться, что я делаю не так, а точнее — что не так с моими требованиями. Это был зацикленный процесс: я пробовала писать много текста (чтобы описать все, что только можно), я пробовала писать мало требований (чтобы было прочитано хоть что-то), пробовала разные способы написания требований.
Пока пробовала разные варианты и наблюдала за реакциями и результатами — сформулировала для себя правила полезных требований. Помимо написания требований, я участвую в анализе гипотез и саппорте процесса разработки по проекту, который я описывала. Поэтому правила, которыми хочу поделиться, разделила на три этапа:
- получение вводной информации по проекту;
- написание требований;
- саппорт команды разработки.
Первый этап: получение вводной информации
1. Разберитесь с целью проекта
Плохо, когда цель проекта звучит так: «Переделать процесс регистрации». Это не цель, а задача. Если приходится работать с такой «целью» — ты работаешь будто с закрытыми глазами: непонятно, что именно хочет получить бизнес.
В цели должны быть заложены:
- выгоды для бизнеса;
- количественный показатель изменений;
- задача, с помощью которой нужно это решить.
Например, так: «Увеличить конверсию на 10%, упростив регистрацию». Хорошо, если есть контекст появления этого решения и портрет пользователей, для которых делаем проект. Именно такие вводные помогают отвечать на вопросы, почему решили сделать именно так, а не иначе, и выбрать вариант реализации, не опираясь исключительно на свои догадки.
Пример. Вы хотите в отпуск. И пока вы просто туда собираетесь, вы никуда не полетите. Но как только вы определите даты, с кем полетите, бюджет, а самое главное — сформулируете, что хотите получить от отпуска, все тут же начнет складываться.
2. Узнайте и проверьте информацию
В период сбора и анализа информации важно помнить главные правила.
Не делайте работу, которую делали до вас
Плохо, когда так:
- Получаю проект в работу.
- Начинаю ресерч, он занимает у меня неделю, а может, и две.
- Случайно на кухне делюсь своей задачей с коллегой, а она:
- вариант 1: говорит, что как раз работает именно с такими исследованиями (которые кто-то делал до меня);
- вариант 2: говорит, что уже был такой проект, и он не принес желаемого результата;
- вариант 3: делится со мной информацией, которая или сокращает время анализа, или улучшает его качество.
Хорошо, когда так:
- Получаю проект в работу.
- Смотрю всю документацию и задачи, которые были написаны раньше.
- Задаю вопросы всем, кто имеет прямое или косвенное отношение к проекту, особенно тем, кто работает давно.
Пример. Конечно, вы можете собирать информацию о каждой стране/отеле/др. отдельно, но больше сведений вы сможете получить, посмотрев/прочитав чей-нибудь обзор. Чаще всего кто-то до вас уже сравнивал и выбирал, куда полететь, что посмотреть и др.
Проверьте полученную информацию
Плохо, когда так:
- Я получаю проект.
- Нахожу документ с исследованиями, которые, к счастью, мне теперь не нужно делать.
- На основе данных строю всю логику и расчеты.
- На этапе тестирования (это при лучшем раскладе) понимаю, что что-то не так.
- А оказывается данные устарели либо контекст вводной информации был другим.
Хорошо, когда так:
- Я получаю проект.
- Нахожу документ с исследованиями, которые, к счастью, мне теперь не нужно делать (возможно!).
- Перепроверяю хотя бы часть информации.
- Уточняю, какие данные брались для расчетов или анализа.
- Уточняю, для чего проводились исследования.
- На основе данных строю всю логику и расчеты.
Пример. Будет неплохо все же спросить мнение кого-то из близких по духу знакомых, которые бывали там, узнать о впечатлении о стране/отеле/др. Банально статья или видео, на которые вы опирались, могут быть составлены человеком, имеющим кардинально противоположные предпочтения. Еще хорошо бы проверить, куда вы собираетесь, не по фото, например, курорта, а с помощью Google-карт в режиме просмотра улиц.
3. Поинформируйте всех заинтересованных
Замечаю, что проекты более проработаны у тех, кто много коммуницирует с коллегами. Тут я дважды допускала ошибки: я не предупредила смежные отделы о «наших изменениях» и не позвала на общую встречу одного из стейкхолдеров, а, поговорив с ним позже, мы были вынуждены заново начинать проект.
Для общей синхронизации по проекту важно:
- понимать все процессы и сущности, связанные с проектом;
- понимать структуру всей компании и чем занимается каждый из отделов;
- проводить общие встречи со всеми стейкхолдерами.
Пример. Вы едете на отдых вдвоем, а детей оставляете с бабушками. Нужно не забыть заранее обсудить с ними ваши планы, чтобы в последний момент не оказалось, что детей оставить не на кого.
Что будет, если забыть об этих правилах? На следующих этапах вам все равно придется столкнуться с этими вопросами: какая цель проекта; кто еще занимался подобными исследованиями или имеет опыт, который вам интересен; кого мы не предупредили.
Второй этап: написание требований
1. Пишите достаточно и в лучшей для восприятия форме
Часто ловила себя на том, что получаю удовольствие, когда при написании требований начинаю писать детальнее, чем нужно. С одной стороны, это хорошо, так как я могу учесть все сценарии поведения пользователя и системы. Но с другой стороны, чрезмерная детализация отпугивает тех, кто будет их использовать. Из личных наблюдений: лучше воспринимаются требования с визуализацией процесса, например схемы, матрицы. Достаточность написания я определяю с помощью обратной связи от тех, для кого пишу требования. Обычно спрашиваю: достаточно ли описания; что еще нужно добавить; все ли понятно.
Исходя из ответов, лучше всего задача воспринимается с помощью дизайна и брифа команды + документ с описанием валидаций и пользовательские истории (если, конечно, это актуально для проекта, у меня в основном такие).
Пример. Составляя список задач, которые нужно сделать до того, как отправишься в отпуск, важно не забыть основные: купить билеты, забронировать отель и т.д. Но также важно не написать столько задач, что перехочется просто обращать внимание на этот список. Например: купить матрас, купить ласты, купить трубку для подводного плавания — все эти задачи можно объединить в один пункт «купить принадлежности для плавания в море».
2. Проговаривайте сценарии
Второе правило касается части требований, которые при их описании ставят меня в тупик. Например, описывая use case, обычно я последовательно в голове проигрываю сценарий взаимодействия и перехожу от действия к действию. Но тут последовательность прерывается, и у меня нет точного понимания, что первоочередно должна сделать «система». Или еще пример: рисую блок-схему, и тут стрелки, показывающие направление перехода к следующему этапу, пересекаются...
Обычно для меня это признак одного из двух: инструмент для описания или визуализации процесса выбран неправильно; данный кейс требует обсуждения. И если его не обсудить сейчас, он вас догонит на этапе разработки, тестирования.
Пример. Если вам что-то непонятно или вызывает сомнение в договоре о предоставлении услуг туроператором, лучше проговорить эти вопросы, как только они возникли. Если это не сделать сразу — как минимум, это грозит тем, что вы потратите время уже в отпуске, а в худшем случае отпуск будет испорчен.
3. Адаптируйте требования исходя из потребностей команды
Это правило индивидуального подхода к каждому члену команды. Когда я пишу требования, всегда думаю о том, как в прошлом команда работала с ними. Чаще всего подробное описание всех кейсов приветствуют тестировщики. Описание всех кейсов, позитивных и негативных, является рабочим инструментом для воспроизведения и тестирования.
Для разработки я обычно делаю сокращенный вариант требований (схемы, матрицы) со ссылками на более подробное описание. Но команды бывают разные, поэтому важно не забывать про обратную связь, полученную с прошлого проекта с этой командой.
Пример. Если всю подготовительную работу вы делаете вместе со второй половинкой, то хорошо бы сделать чек-лист задач, понятный не только вам. Например, писать без сокращений понятных только вам и др.
Что будет, если забыть об этих правилах? Требования будут написаны, но они останутся «лежать на полке и пылиться».
Третий этап: саппорт разработки
1. Ссылайтесь на требования
Чтобы требования были полезными, нужно ими пользоваться. Если у кого-нибудь из команды возникают вопросы, можно поделиться ссылкой на часть требований. Также это помогает увеличить доверие команды к требованиям и стремление чаще к ним обращаться самостоятельно, без запроса информации, например, у аналитика.
И также это помогает поддерживать требования в актуальном состоянии.
Во всех компаниях, в которых мне приходилось работать, было
Для требований я чаще использую Google Docs.
2. Визуализируйте прогресс проекта
Требования могут также стать инструментом для отслеживания прогресса по проекту. Одна из команд, с которыми я работала, использовала требования как чек-лист, отмечая:
- что было реализовано;
- что было реализовано, но не в точности как описано в требованиях;
- что не было реализовано и почему.
Мне это помогало реагировать на те части требований, которые были реализованы не так, и решить сразу, нужно вносить изменения или оставить как есть.
Пример. По мере решения всех подготовительных задач хорошо отмечать, что уже сделано (а иначе зачем было составлять этот список).
3. Общайтесь с командой
Правило актуально не только для последнего этапа, но важно о нем не забывать. Хорошо, если у вас есть возможность коммуницировать с командой вживую. Требования или задачи не заменят общения: это более быстрый канал для решения вопросов + чаще он исключает двоякое понимание ожидаемого результата.
Пример. Когда вы вместе готовитесь, вы, конечно же, обсуждаете все, что вы делаете (это всегда приятно).
Что будет, если забыть об этих правилах? Требования будут написаны, но они не станут рабочим инструментом.
Подводим итог
Требования будут прочитаны, а значит, будут полезны, если будет понятна цель проекта; они будут написаны для людей; они станут вашим рабочим инструментом.
Пример. Цель отпуска ясна. Вы хорошо подготовились: составили список задач и выполнили их. Как минимум, вы будете довольны собой, потому что любая успешно завершенная задача — это позитивные эмоции. Как максимум к ним прибавятся еще и впечатления от хорошо подготовленного отпуска.
P. S. Если вы разработчик или тестировщик, поделитесь своим опытом — читаете ли вы требования. Если нет — почему? Бывали ли проекты с требованиями, которые хотелось прочесть, то есть они вам помогали? Если вы аналитик, напишите, читают ли ваши требования. Что вы делаете для того, чтобы их прочитали?
