Представим, что продуктовая работа отлично выполнена: гипотезы проработаны, подтверждены, тесты проведены, решение принято – делаем фичу! Далее наступает очередной этап – нужно поставить задачу разработчикам, чтобы гипотетическая фича стала реальной. Как правило, разработке недостаточно описанной гипотезы и выводов по ее проверке, чтобы приступить к задаче. Для этого нужны детали и подробности: как фича должна работать в разных случаях, как она вписывается в текущую функциональность продукта, какие могут быть ограничения и противоречия.
Не всегда в командах есть специально-обученный человек для формулирования требований, в этом случае писать их будет продакт, проджект, маркетолог или любой другой причастный к гипотезе сотрудник. Достаточно ли времени и навыков у этого человека? Понимает ли он все нюансы постановки задач? Если нет, разработка рискует столкнуться с некоторыми трудностями.
Меня зовут Александра Хорошкова, я менеджер проектов по коммуникациям в SuperJob, и в этой статье я хочу поделиться своими способами подготовки требований. Если их описание — обязательная часть разработки, то и путь лежит через пять стадий принятия. Давайте рассмотрим их подробнее и разберемся, зачем нужны требования, какими они бывают, и как можно быстро и качественно их составить.
Отрицание
«Зачем вообще нужны требования? Кто их читает-то?»
Это довольно часто встречающийся вопрос про необходимость требований. Кажется, что достаточно написать условие задачи, а разработчики все поймут, они же профессионалы.
Однако все сэкономленное на требованиях время затем уходит на обсуждения деталей задачи с разработкой и ответы по уточняющим вопросам.
В других случаях разработчики, также желая сэкономить время заказчика, не задают вопросы и делают по своему разумению. И здесь мы можем прийти к ситуации, когда сделали не так, как планировали. Выяснить, что пошло не так, переделать или откатить – куда более затратно, чем составить подробное описание.
Ну не будем о плохом. Требования также нужны и вам самим, вот для чего:
свериться по объему и содержанию работ с планами других команд;
освежить в памяти через некоторое время, как это все вообще должно работать;
чтобы тестировщики или техподдержка могли быстро находить ответы на свои вопросы в реализованных задачах, а технические писатели могли на их основе создавать свою документацию;
если в процессе разработки потребуется передать задачу другому исполнителю, подробные требования сократят срок этой передачи.
Это далеко не все, случаев применения подробных требований очень много. Если кратко резюмировать: подробные требования сокращают неопределенность на любом этапе взаимодействия с фичей.
Гнев
«У меня и так куча дел! А тут еще целый документ надо составлять»
Фреймворков по написанию требований много, но чтобы не сделать из их использования карго-культ, нужны специальные навыки и опыт, а на это, опять же, необходимо время.
Кроме того, как понять качество уже изложенных требований? Даже если на описание будет выделено достаточное количество времени, как проверить требования на полноту, непротиворечивость и т.д.? Особенно, если описано все подробно и объем уже получился внушительным.
Торг
«А бывает качественно, но коротко?»
Очень часто словосочетание «подробные требования» вызывают ассоциацию многостраничных ТЗ, которые никто даже не открывает при виде масштабов.
Я намеренно не использую в статье слова «техническое задание», чтобы не создавать таких ассоциаций.
Наши требования должны быть понятными и лаконичными. Их легко написать, трудно не понять и невозможно забыть.
Итак, давайте представим, что вас интервьюирует специально обученный аналитик. Задает вам вопросы по задаче, а вы на них отвечаете. Быстро, полезно, удобно, и главное, по-максимуму учтены все аспекты задачи.
Давайте тоже воспользуемся одним из инструментов аналитика – анкетированием, но только самих себя.
Я подготовила список вопросов, которые мог бы задать вам аналитик, вам лишь остается для каждой задачи заполнять такой бриф и отдавать его вашей разработке.
Главные вопросы, на которые должны отвечать наши требования:
Как это работает?
Как это выглядит?
Все остальное, это детали, специфичные для каждой задачи.
Как это работает? | Описываем основной сценарий работы фичи Например так: Нажимаю кнопку «регистрация», ввожу почту и пароль, нажимаю ОК, регистрация состоялась. Если пользователь с такими данными уже есть, авторизуем его после нажатия ОК. |
Как это выглядит? | Круто, если тут есть макеты. Прикладываем их. Либо, если внешний вид не важен, стоит об этом прямо написать вашим исполнителям, чтобы они смело делали задачу под руководством здравого смысла и гайдов, и не ждали согласований. |
Платформы: десктоп, мобильная версия, приложения? | Кроме сайта, у нас есть мобильное приложение? Эта фича должна быть и там? Отлично! Пишем об этом нашим исполнителям. У нашего сайта есть мобильная версия? Наша фича ведет себя там так же? |
Наличие CRUD-операций? | CRUD (сокр. от англ. create, read, update, delete — «создать, прочесть, обновить, удалить») Допустим, пользователь должен создавать в нашей системе какие-то записи, а может ли он потом их редактировать или удалять? Есть ли на это ограничения? |
Отображение фичи для разных ролей? | Если в вашем проекте есть разные роли для пользователей, необходимо описать, как ведет себя фича для этих ролей. Например, в нашем продукте есть роли работодателя, соискателя и гостя, поэтому отображение вакансии или резюме для каждого будут разными: какие-то поля или кнопки будут скрыты. |
Админка(CRM)/Клиентский отдел/Модерация? | Если у нас есть какие-то обеспечивающие инструменты? Нужно понять, требует ли наша фича изменений в них, и описать это.
|
Письма/пуши/смс? | Должны ли мы писать нашему пользователю? Например, письма с подтверждением заказа. Тут стоит описать хотя бы просто необходимость в отправке какого-либо сообщения пользователю. Тексты и прочие креативы можно отложить, пока до этого не дойдет разработка. |
Баннеры/информеры/онбординг? | Насколько крупная и заметная у нас фича? Может стоит сделать пользователю небольшой онбординг? Тут также необходимо хотя бы упоминание об этом, чтобы разработка заложила время или спланировала проектировочное решение, а подробности и креативы можно выдать позже. |
Аналитика? | Требуется ли нам собирать какую-то специфическую статистику? Например, нажатие определенных кнопок пользователем. |
Требуется согласование или доработка у сторонних подразделений? | Если наш проект делает не одна команда, стоит ли остальным знать о нашей новой фиче? Есть ли у нас бухгалтерия или юристы? Возможно, они тоже должны быть в курсе новой фичи, особенно, если мы собираемся брать оплату с клиента или менять условия пользовательского соглашения. |
Будем ли мы отслеживать метрики фичи после запуска? | Если мы хотим оценить эффект от фичи через какое-то время, лучше зафиксировать в требованиях необходимость такой оценки через отведенный период. В потоке задач мы можем забыть вернуться к реализованной задаче для оценки, а так об этом будет знать и помнить большее количество людей. Если по итогам будет принято решение о неуспехе, сразу стоит запланировать мероприятия и задачи для выпиливания фичи. |
Депрессия
«Список вопросов анкеты снова невероятно длинный и, наверняка, не полный…»
Да, но я тут привела наиболее универсальный перечень вопросов как раз для того, чтобы легче было адаптировать его под конкретные задачи. Этот перечень можно дополнять или удалять из него лишнее.
И да, заполнение этой анкеты займет какое-то время. Но это сильно меньше времени, потраченного на формулирование задачи «из головы на лету» без структуры. А вашим исполнителям читать и осознавать структурированный текст будет еще быстрее.
Для понимания приведу пример вопросов по одному из направлений наших задач:
Здесь не так много вопросов, но на все нужно знать ответы. Плюс приведен план релиза, чтобы эти пункты не забывали ни разработчики, ни менеджеры.
Принятие
«Да, придется выделять время и на требования, но теперь понятно для чего».
Итак, вернемся к вопросам «зачем все это нужно и кто это читает?» Требования – это:
смысл проекта. Они снижают неопределенность и обосновывают необходимость задач и проекта в целом. Если мы в какой-то момент теряем фокус, то всегда можем вернуться, опираясь на них;
контрактные обязательства. Исполнители не хотят быть «крайними», поэтому уточняющие вопросы будут всегда. Подробные и полные требования позволят их сократить и избежать повторений;
это инвестиции в будущую поддержку проекта и в собственную уверенность.
И не забывайте: наши завышенные требования жизнь все равно вернет на доработку.
