От заказчика поступила задача: переделать форму регистрации пользователей, чтобы сначала пользователь указал дату своего рождения.
Это нетипичная задача. Да и вопрос про дату рождения достаточно спорный (почему дату, а не возраст?). Поэтому мы идём к заказчику и спрашиваем, что он имел в виду. Поподробнее, желательно в письменном виде.
Получаем от заказчика примерно вот такую схему.
Из схемы понятно, что в голове у заказчика есть что-то: некая картинка, представление. Ему кажется, что всё просто, потому и на бумаге сложилось лаконично.
Мы расспрашиваем заказчика: кто будет регистрироваться, зачем, почему, и что будет дальше. И складывается, что есть два сценария регистрации пользователей сайта в зависимости от возраста. Возраст мы высчитываем на основе того, какую дату рождения укажет пользователь.
Получается, есть сценарий 1 и сценарий 2. Мы начинаем прорисовывать бизнес-процессы, моделировать поведение пользователей в зависимости от их роли. И один из сценариев тоже разделяется на три.
Получается такая картинка. Прорисовываем её вместе с заказчиком. И на этапе, где один из сценариев начинает расстраиваться (раскладываться на ещё три варианта), начинает расстраиваться и заказчик. Потому что картинка перестаёт быть простой. Она становится достаточно сложной: и весь набор вариаций в памяти не удержишь.
Для этого и нужен бизнес-аналитик в команде, который участвует в разработке техзадания.
Он выявляет и фиксирует сущности, роли пользователей, кто они, зачем им нужно регистрироваться, и зачем это нужно заказчику (сайту). Чтобы ничего не потерялось и не выпало из зоны внимания.
Мы берём время подумать. Бизнес-аналитик делает первую примерочную схему.
На схеме он прорисовывает экраны, которые будет отображать программа согласно оговоренным сценариям. В зависимости от действий пользователя, в зависимости от разных параметров будут разные экраны.
Схема упрощённая. Это «внешняя» схема: что видит пользователь, — потому что заказчику так «ближе». Здесь мы не указываем действия, триггеры, документы или типы информации, которые туда-сюда передаются. Здесь не указано даже, куда информация передаётся, и как её обрабатывает программа. В этой схеме нет «внутренней» информации для разработчиков. А там понадобилось встраивать таблицы в базу данных и корректировать внутреннюю логику приложений.
Тут обозначено, что видит пользователь. И вместе с заказчиком мы разыгрываем (моделируем) ситуации. Прорабатываем варианты (в маркетинге это называется «целевая аудитория», а здесь – виды пользователей, их роли): ходы, пути пользователей, для чего они пришли и как будут действовать.
На фото на схеме начёрканы правки, которые мы сделали в ходе обсуждения: что чем заменить, какие могут быть сложности, какие ещё шаги добавить.
Таким образом, за неделю, два созвона и две очных встречи с заказчиком мы сделали всего лишь схему бизнес-процессов всего лишь формы регистрации: от момента, когда человек попадает на страницу регистрации до момента, когда человек уже в своём личном кабинете. При этом учли интересы пользователей и интересы заказчика (те условия, из-за которых ему понадобилось усложнять форму регистрации).
После этого приступаем к формированию техзадания в письменном виде. Уже в словах и в требованиях, которые присущи техническим заданиям.
Вот так выглядит первый экран формы уже в реализованном виде.
Задача заняла порядка 40 часов разработки. Плюс работа по составлению и согласованию технического задания, встраивания разработки в существующую платформу заказчика, наладке исходных инструментов, составлению прочей документации.