Все статьи Что такое функциональное задание и как его написать, фотография 1

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

15 мая 2018
Клиентам
Разработчикам
Наш опыт

Что такое ФЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда твоё ФЗ никто не читает
Когда твоё ФЗ никто не читает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестировщик пишет чек-лист
Слева: тестировщик пишет чек-лист без использования ФЗ. Справа: тестировщик пишет чек-лист, используя ФЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MyTech. Прототип для клиента

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

MyTech. Прототип для техника

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

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

Административная панель MyTech
Административная панель MyTech
Административная панель MyTech

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

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

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

Итоги

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

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

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

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

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

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

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

Прочитайте другие наши статьи
Как принимать чужой проект

Клиенты часто просят IT-студии взять их проект на поддержку и развитие. Что нужно сделать, чтобы обе стороны остались довольны и долго работали вместе?

Как заполнить бриф на разработку приложения

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

Как сделать свой Uber для X

Компания Uber навсегда изменила принцип поиска и вызова автомобиля. Нашли рынок, который тоже можно перевернуть? Делимся нашим опытом и рекомендациями

Роза Балджанова, фотография Роза Балджанова Аналитик Live Typing