Что такое функциональное задание и как его написать

Что такое ФЗ

Бывает, что заказчик, рассказывая о своём видении продукта, упускает важные детали. Они очевидны для него, но увы, не для команды специалистов. Например, клиент хочет мобильное приложение с авторизацией пользователя по номеру телефона и паролю и с привязкой к социальным сетям, но говорит только про авторизацию, умолчав про то, как она должна быть сделана, и про соцсети. В итоге разработчик делает авторизацию по email и паролю, клиент недоволен, а разработчик не понимает, почему.

Чтобы подобных ситуаций не происходило, все члены команды должны понимать, какого результата необходимо достичь. Для этого в компании Лайв Тайпинг, где я работаю аналитиком, формируется функциональное задание (ФЗ) — документ, который описывает все возможности продукта. ФЗ нужно для:

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

На этапе проектирования за составление ФЗ отвечают аналитик и менеджер. Оно может быть написано как ими обоими, так и только менеджером, а после дополнено деталями от аналитика. Параллельно с доработкой ФЗ создаётся дизайн, поэтому одна из задач специалистов — проследить, чтобы дизайн и ФЗ не расходились, а дополняли друг друга.

Чего мы ждём от ФЗ

Документирование возможностей продукта в виде функционального задания призвано дать команде ясное представление о нём. Для разработчика задачи точно сформулированы и подчинены порядку, что оптимизирует процесс разработки веб-сервиса или приложения. Тестировщик с помощью ФЗ может составить чек-лист — детализированный список функций, которые необходимо протестировать и либо убедиться, что они работают так, как написано в документе, либо обнаружить ошибки. В дальнейшем при разработке и поддержке продукта тестировщик добавляет все изменения в ФЗ, актуализируя документ.

Если клиент вдруг решил обратиться в другую студию, то передать проект новой команде будет проще и быстрее, когда есть ФЗ.

Так как общепринятых стандартов нет, требования к ФЗ диктуются здравым смыслом. Оно должно быть ёмким, ведь никто не захочет читать огромную простыню. При этом у команды не должно быть вопросов к документу, описание должно быть понятным и однозначным. 

И конечно же, ФЗ должно приносить пользу команде, иначе зачем создавать документ, который никому не нужен.

А как выглядит документ, который никому не нужен?

Обычно в ФЗ возможности продукта расписываются по экранам в свободном стиле. Такой подход чреват тем, что в итоге все будут иметь дело с громадным документом, который получился таким из-за желания описать всё до мелких подробностей. Тот же свободный стиль делает каждое новое ФЗ непохожим на предыдущее. Единой структуры — нет, как вообще начинать писать такой документ и на что опираться — непонятно.

Дел с таким документом команда иметь не хочет: специалистам проще пообщаться с аналитиком или менеджером, а тестировщики пишут свои чек-листы с нуля, потому что время тестирования по ФЗ увеличивается в разы.

Продукт с течением времени развивается и обрастает новыми функциями. Соответственно, документацию к продукту нужно обновлять. Но желание обновлять окончательно пропадает после понимания, что документом всё равно никто не пользуется. Процесс написания ФЗ превращается в ненужную трату времени. Документ покрывается мхом и вскоре забывается.

Как нужно: эпики, пользовательские истории и критерии приёмки

Для решения проблемы мы попробовали изменить формат ФЗ, расписав возможности не поэкранно, а отталкиваясь от функциональной структуры приложения с помощью epic, user story и acceptance criteria.

Вначале мы определяемся с главными составляющими нашего проекта — эпик (epic). Это большая пользовательская история, которую можно разделить на группу идейно объединённых историй поменьше. Отличительная особенность эпика в том, что он показывает главные цели конечного пользователя.

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

Если же это мобильное приложение для оплаты услуг ЖКХ, то для такого проекта можно выделить такие эпики как доступ в приложение, профиль пользователя, счётчики, оплата услуг.

Эпик задаёт самые общие границы разделов приложения, поэтому следующим шагом будет разделение эпика на более мелкие части — пользовательские истории (user story).

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

Обычно для написания историй предлагается воспользоваться шаблоном:

«Как <роль пользователя>, я <что-то хочу получить> <с такой-то целью>»

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

Для все того же интернет-магазина пользовательские истории могут быть такими:

• «Как клиент я могу воспользоваться поиском по каталогу, чтобы быстро найти нужный мне товар»;
• «Как клиент я могу добавить товар в вишлист, так что я смогу быстро вернуться к понравившимся товарам».

Ниже представлены примеры историй для услуг ЖКХ без указания цели:

• «Как клиент я могу авторизоваться в приложении»;
• «Как клиент я могу передать показания счётчика»;
• «Как клиент я могу перейти к архиву квитанций».

Эпики и пользовательские истории составляют «скелет» ФЗ, и на ранней стадии проекта такой структуры вполне достаточно. А на этапе дизайна документ дописывается полностью и появляются критерии приёмки (acceptance criteria) — короткие инструкции к пользовательским историям, описывающие функциональность более детально. Критерии приёмки — это шаги пользователя для достижения какой-то цели.

Вот несколько критериев приёмки к пользовательским историям:

• как клиент я могу воспользоваться поиском по каталогу, чтобы быстро найти нужный мне товар:
• я могу найти товар по названию;
• я могу найти товар по штрихкоду;
• я могу видеть экран-заглушку, если искомого товара нет в каталоге.

• как клиент я могу передавать показания счётчика:
  • я могу видеть номер счётчика и его тип (счётчик электроэнергии, горячей воды и т. п.);
  • я могу ввести показания счётчика;
  • я могу видеть показания счётчика и расход за предыдущий месяц;
  • я могу сохранить/не сохранять введенные показания.

• как клиент я могу посмотреть историю показаний счетчиков:
  • я могу видеть список счётчиков и их номера;
  • я могу открыть историю показаний по конкретному счётчику;
  • я могу открыть историю показаний по конкретному счётчику;
  • я могу видеть отправленные показания и расход за каждый месяц по конкретному счётчику.

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

Такое ФЗ очень просто и быстро писать, ведь оно пишется по шаблону. Команде легко понять требования из-за отсутствия расплывчатости — краткие, простые предложения легче воспринимаются людьми. Работа тестировщиков по новому ФЗ упрощается: добавив обработку ошибок, они получат основу для тестирования продукта. Клиенты же, в свою очередь, экономят время и деньги на составлении простого для понимания ФЗ.

Какие проблемы могут возникнуть при написании ФЗ

Нет обсуждения с командой

Работа над проектом — это командная согласованная работа, поэтому не стоит пренебрегать вопросами от членов команды. Функциональное задание не должно создаваться в одиночку, оно всегда открыто для обсуждений, иначе недопониманий не избежать.

Размер документа

Когда пользовательская история охватывает слишком большую функциональность, работать с ней становится неудобно, оптимальнее разбить её на несколько историй. Если же в ней содержится небольшая часть функций, то удобнее объединить такую историю с другими. Не нужно чрезмерно детализировать ФЗ, чтобы не создавать переизбытка информации, но и слишком обобщать тоже не стоит, иначе команда станет задавать много вопросов и документ перестанет быть понятным.

Как не надо делать:

Как клиент я могу работать с корзиной, чтобы контролировать список товаров, которые в ней лежат:

• я могу видеть список товаров и их количество;
• я могу изменить количество товара в корзине (от 1 до 5);
• я могу добавить товар в вишлист;
• я могу удалить товар из вишлиста;
• я могу удалить товар из корзины;
• я могу открыть экран с товаром.

Необходимо добавить описание ситуации, когда корзина окажется пуста.

Как клиент я могу работать с корзиной, чтобы контролировать список товаров, которые в ней лежат:

• я могу видеть экран-заглушку, если корзина пуста;
• я могу перейти в каталог, если корзина пуста;
• я могу видеть список товаров и их количество;
• я могу изменить количество товара в корзине (от 1 до 5);
• я могу добавить товар в вишлист;
• я могу удалить товар из вишлиста;
• я могу удалить товар из корзины;
• я могу открыть экран с товаром.

Как ещё не надо делать:

Авторизация пользователя. Как пользователь я могу:

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

Лучше разбить юзерстори на две:

Авторизация пользователя. Как пользователь я могу:

• войти в приложение при помощи e-mail и пароля;
• видеть попап с сообщением об ошибке, если я ввел неверный email или пароль;
• восстановить свой пароль

Восстановление пароля. Как пользователь я могу:

• ввести email для получения кода;
• ввести код, который придет по почте, для подтверждения email;
• ввести новый пароль и его подтверждение.

Выносить в ФЗ техническую информацию

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

Разбор на примере ФЗ к проекту MyTech

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

Пользователи приложения разбиты на три группы: клиенты, техникаи и администраторы.

Клиент — создаёт заявки и выбирает исполнителей для них.

Техник — предлагает себя в качестве исполнителя заявки и может согласиться или отказаться от выполнения работы.

Детали касаемо заявки клиент и техник обсуждают в чате. Клиент может отслеживать местоположение назначенного техника по карте.

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

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

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

В этом документе вы увидите, как выглядит ФЗ с эпиками, пользовательскими историями и критериями приёмки для проекта MyTech.

Итоги

Новый формат ФЗ оказался удобнее и для менеджера, который следит за проектом, и для разработчика, оценивающего и планирующего работы, и для тестировщика, составляющего чек-листы. Шаблонная структура документа позволила новым членам команды быстрее влиться в проект и быстро вносить изменения в ходе работы над проектом. У клиентов появились задокументированные требования, с помощью которых легко отслеживать работу команды.

Что ещё почитать

User Story: план действий для разработчика

Пять признаков хороших пользовательских историй

История пользователя — User Story

Как и зачем писать пользовательские истории — user stories

Как написать функциональное техническое задание?