Аналитик · Организация работ · Требования

Формат требований, который вам необходим

Надоело писать ТЗ по шаблону? Я расскажу, как я избежала скучных требований, заинтересовала команду, и
предложила заказчику приятную “плюшку”.

Автор: Грицышина Динара

Кратко о себе: сертифицированный бизнес-аналитик (Certified Professional Requirements Engineering Foundation Level, Certified Professional in Requirements Writing) с опытом более 4-х лет. Вела русскоязычные и иностранные проекты, на последнем работала около 2-х лет. Вела документацию на английском языке. Общалась с иностранными коллегами.
В настоящий момент работаю в продуктовой компании, познаю новые прелести работы аналитика.
Задумываюсь иногда, чем я могла бы заниматься, и в голову не приходит ничего увлекательнее аналитики.

 

Моя история началась в тот день, когда я созвонилась с лидом QA команды и тот мне поведал, что конечные пользователи задают вопросы в саппорт, которые не должны задавать, т.е. чему проектные менеджеры должны были их обучить, но по каким-то причинам это не удалось сделать на 100%.

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

А вот над форматом мануалов надо было еще подумать.

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

Минимум сплошного текста, максимум исчерпывающих изображений.

Вот что такое скринфлоу, о котором я хочу вам рассказать.

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

Вот пример скринфлоу рандомной системы. Экраны идут один за другим в порядке последовательности. Элементы, которые добавляются или обновляются в рамках новой фичи выделяются и описываются комментариями (условия использования и ограничения). Если есть развилка, то это тоже указывается, с обязательным указанием условий для каждой из них.

 

Все легко и просто!

После сдачи первых скринфлоу, я приступила к разработке новых требований. И подумала, а почему бы не использовать этот формат и для команды тоже?

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

Текст

Так как некоторые фичи действительно объемные и сложные, я писала требования, используя макеты, таблицы, списки, отделяя все заголовками. Такой формат первое время пользовался у меня популярностью, так как требования постоянно изменялись и при помощи Ctrl+F было легко найти нужную строчку и что-то в ней поменять. К тому же по сравнению с другими форматами описания требований набор текста является наиболее быстрым.

Минусом такого формата является его объем, особенно если в требованиях есть макеты.

Use case

Если ожидалась более сложная и последовательная логика, то я использовала Use case. Главный плюс такого метода — удобство для команды QA. Но возвращаясь к проблеме непостоянства требований, надо отметить что очень сложно корректировать use case’ы. Проморгав один пункт, вся нумерация и шаги сценариев могли превратиться в кашу и можно было потратить больше времени на редактирование, чем на создание требований.

UML и Бизнес-Процессы

Да, все знают, что это очень наглядно, логично и последовательно, но! Редактирование может занять еще больше времени, чем на вычитку Use case’ов. Для описания новых фич нет потребности использовать какие-либо диаграммы. Тратить на них время стоит только в случае, когда описывается что-то фундаментальное, например основные процессы приложения, поток передачи данных или интеграция.

Тот самый Screenflow

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

Поэтому настал момент, когда потребовалось что-то поменять в требованиях.

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

  • Первый плюс Screenflow. Это просто способ описания требования, а не стандарт. Вы можете делать это в любой цветовой гамме, с любыми фигурами, добавлять текст, куда угодно. Главное правило — это должно быть легко читать и понимать. Лишнего текста все же добавлять не стоит. Если это новая фича, то надо описывать элементы и переходы, которые добавляются/изменяются в рамках этой самой фичи.
  • Второй плюс Screenflow. Вы описываете логику работы системы и показываете изменения интерфейса одновременно. Как же надоело читать описание интерфейса и то и дело пролистывать к макету, чтобы посмотреть, где уж там расположен этот элемент.
  • Третий плюс Screenflow. На нашем проекте мы использовали Screenflow в качестве инструкции для пользователей. Тот же самый документ, который читают разработчики читают и менеджеры проектов, которые уже доносят все до пользователей. То есть этот формат настолько удобен для восприятия, что его можно использовать совершенно в разных целях: для постановки задачи, для презентации, в качестве монуала.

Конечно, есть и минусы у такого подхода.

  • Если будут какие-то изменения в логике или интерфейсе, то придется сначала обновлять макет, а потом переписывать текст в Screenflow и менять эти макеты.
  • Второй минус. Прощай копипаст! Писать тест-кейсы или матрицы отслеживаемости придется вручную, если нет оригинала диаграммы, откуда можно скопировать.
  • К тому же некоторые команды ведут свою документацию в Confluence. И так как диаграммы вставляются изображением или документом, то возможность комментирования какого-то требования пропадает.

Не смотря на перечисленные минусы, Screenflow очень интересный формат. На проекте я провела опрос у всех разработчиков и QA-специалистов, какой формат описания требований кажется им самым удобным.

Больше половины команды ответило, что Screenflow — удобный, информативный, наглядный формат.

Так же команда отметила пользу Use case’ов. Поэтому для новых фич я использую комбинацию Screenflow и Use case’ов. Тут и подробное описание логики и последовательности вкупе с макетами. Иногда приходится дополнять чем-то, или наоборот обходится чем-то одним. Но Screenflow имеет место быть. Если не для постоянного использования, то хотя бы там, где можно облегчить жизнь себе и команде и не нагромождать огромные страницы с описанием.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *