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