Что такое ФЗ
Бывает, что заказчик, рассказывая о своём видении продукта, упускает важные детали. Они очевидны для него, но увы, не для команды специалистов. Например, клиент хочет мобильное приложение с авторизацией пользователя по номеру телефона и паролю и с привязкой к социальным сетям, но говорит только про авторизацию, умолчав про то, как она должна быть сделана, и про соцсети. В итоге разработчик делает авторизацию по 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