Представим, что продуктовая работа отлично выполнена: гипотезы проработаны, подтверждены, тесты проведены, решение принято – делаем фичу! Далее наступает очередной этап – нужно поставить задачу разработчикам, чтобы гипотетическая фича стала реальной. Как правило, разработке недостаточно описанной гипотезы и выводов по ее проверке, чтобы приступить к задаче. Для этого нужны детали и подробности: как фича должна работать в разных случаях, как она вписывается в текущую функциональность продукта, какие могут быть ограничения и противоречия.

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

Меня зовут Александра Хорошкова, я менеджер проектов по коммуникациям в SuperJob, и в этой статье я хочу поделиться своими способами подготовки требований. Если их описание — обязательная часть разработки, то и путь лежит через пять стадий принятия. Давайте рассмотрим их подробнее и разберемся, зачем нужны требования, какими они бывают, и как можно быстро и качественно их составить. 

Отрицание

«Зачем вообще нужны требования? Кто их читает-то?»

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

Однако все сэкономленное на требованиях время затем уходит на обсуждения деталей задачи с разработкой и ответы по уточняющим вопросам.

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

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

• свериться по объему и содержанию работ с планами других команд;

• освежить в памяти через некоторое время, как это все вообще должно работать;

• чтобы тестировщики или техподдержка могли быстро находить ответы на свои вопросы в реализованных задачах, а технические писатели могли на их основе создавать свою документацию;

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

Это далеко не все, случаев применения подробных требований очень много. Если кратко резюмировать: подробные требования сокращают неопределенность на любом этапе взаимодействия с фичей.

Гнев

«У меня и так куча дел! А тут еще целый документ надо составлять»

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

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

Торг

«А бывает качественно, но коротко?»

Очень часто словосочетание «подробные требования» вызывают ассоциацию многостраничных ТЗ, которые никто даже не открывает при виде масштабов. 

Я намеренно не использую в статье слова «техническое задание», чтобы не создавать таких ассоциаций. 

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

Итак, давайте представим, что вас интервьюирует специально обученный аналитик. Задает вам вопросы по задаче, а вы на них отвечаете. Быстро, полезно, удобно, и главное, по-максимуму учтены все аспекты задачи. 

Давайте тоже воспользуемся одним из инструментов аналитика – анкетированием, но только самих себя. 

Я подготовила список вопросов, которые мог бы задать вам аналитик, вам лишь остается для каждой задачи заполнять такой бриф и отдавать его вашей разработке. 

Главные вопросы, на которые должны отвечать наши требования: 

• Как это работает?

• Как это выглядит? 

Все остальное, это детали, специфичные для каждой задачи. 

Депрессия

«Список вопросов анкеты снова невероятно длинный и, наверняка, не полный…»

Да, но я тут привела наиболее универсальный перечень вопросов как раз для того, чтобы легче было адаптировать его под конкретные задачи. Этот перечень можно дополнять или удалять из него лишнее.

И да, заполнение этой анкеты займет какое-то время. Но это сильно меньше времени, потраченного на формулирование задачи «из головы на лету» без структуры. А вашим исполнителям читать и осознавать структурированный текст будет еще быстрее.

Для понимания приведу пример вопросов по одному из направлений наших задач:

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

Принятие

«Да, придется выделять время и на требования, но теперь понятно для чего».

Итак, вернемся к вопросам «зачем все это нужно и кто это читает?» Требования – это: 

• смысл проекта. Они снижают неопределенность и обосновывают необходимость задач и проекта в целом. Если мы в какой-то момент теряем фокус, то всегда можем вернуться, опираясь на них;

• контрактные обязательства. Исполнители не хотят быть «крайними», поэтому уточняющие вопросы будут всегда. Подробные и полные требования позволят их сократить и избежать повторений;

• это инвестиции в будущую поддержку проекта и в собственную уверенность. 

И не забывайте: наши завышенные требования жизнь все равно вернет на доработку.