Блог

Всеволод Фролов
Начальник отдела управления проектами

Как писать требования

Одна из основных служебных обязанностей project-менеджера (PM) – это сбор требований и оформление их в задание на разработку. Заказчик приносит описание некой предметной области, для которой нужно запрограммировать реализацию. В нашем случае это, как правило, веб-проект. С чего начать? Как донести до разработчика, вернее, до команды разработчиков, суть задачи и что им требуется сделать? Упрощенно процесс выглядит так: сбор требований, их уточнение, написание техзадания, реализация. Поговорим про первую часть цепочки – сбор требований и их уточнение.

Идеал

В идеале, что хотелось бы получить PMу, – это документ, в котором заказчик описал все, что он знает о предметной области, то, как проект должен быть использован Пользователем, как бы заказчик хотел управлять проектом, показал дизайн, подумал о будущем развитии. Мечтать, как говорится, не вредно. Потому что так никогда не бывает.

Как обычно поступают требования

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

Заказчик – не программист, ТЗ писать не умеет, от него этого не требуется. Что требуется от заказчика, который пришел с заданием, – это знать свою предметную область и отвечать на вопросы для уточнения требований. Случается, что добиться ответа довольно проблематично.

Какие бывают затыки

Заказчик не в курсе или не до конца в курсе, что от него хочет работодатель/топ-менеджер, и, соответственно, не может сформулировать требования по задаче. В этом случае к разработчикам с заданием лучше не приходить, ничего хорошего в таком проекте не получится. Лучше идти в обратную сторону и получать информацию от первоисточника. Заказчик недостаточно компетентен в области разработки и стесняется излагать свои мысли простым языком. Такие сложности быстро решаются, так как задача PMа – разговорить собеседника, задать наводящие вопросы и выудить информацию. Кстати, описание требований на простом, «гражданском» языке – только приветствуется. Гораздо хуже, когда специальные термины применяются не по делу.

Почему мы не можем «сделать как-нибудь»

Если у заказчика возникают вышеописанные затыки, он предлагает сделать «как-нибудь», «на ваше усмотрение». Белые пятна в требованиях и предложения «сделать как-нибудь» – это зло. Алгоритм «как-нибудь» не напишешь, в нем все должно быть строго. Молодой разработчик, глядя на такое описание, сделает удивленные глаза, а опытный разработчик запрограммирует по-своему. В первом случае задача не будет выполнена, во втором – будет выполнена не так, как нужно бизнесу.

Как нам сделать, чтобы всем было хорошо

Первоначальные требования лучше описать самостоятельно и изложить в документе. В процессе изложения задачи «на бумаге» автор представляет себе будущий проект, моделирует его в своем сознании. Это приводит к тому, что всплывают новые особенности функционала, появляются новые идеи, описание обрастает подробностями. Требования, которые заказчик предварительно написал в виде документа, получаются более качественными и более полными.

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

Требования нужно детализировать до такой степени, пока у разработчиков не останется вопросов. Конечно, они появятся в процессе кодирования, но требования мы зафиксируем именно в том состоянии, когда разработчику в первый раз стало все по ним понятно. Детализация требований – это совместная работа PMа и заказчика. Пример из жизни: первоначальные требования, поступившие от заказчика на одной странице (с двумя картинками на ней же), после уточнения превратились в 19 страниц. То есть 18 страниц информации было вытянуто получено от заказчика в процессе утверждения требований, которые были доведены до той степени детализации, которая требовалась для начала разработки.

Не нужно в требованиях проектировать архитектуру. Есть прокачанные заказчики 80 уровня, которые углубляются в тему настолько, что в требованиях начинают проектировать приложение или строить схему базы данных. Это лишнее. На стороне группы разработки всегда есть человек, который придумает архитектуру и будет за нее отвечать. А вот отвечать за навязанную им со стороны архитектуру эти люди не любят.

Не нужно усложнять. Это прекрасно, когда заказчик – опытный интеллектуал с IT-бэкграундом. Когда он способен придумать и изложить сложную логику. Как приятно с ним общаться и формулировать требования! Однако в реальности с этой сложной логикой придется работать не только аналитикам и программистам (они, как правило, способны ее понять), но и контент-менеджерам, редакторам, саппортникам, наконец. Да и не будем забывать про Пользователя, всегда ли ему нужно вникать в сложную логику нашего проекта, в перегруженный интерфейс или понятную только избранным навигацию? Есть такое правило – Упрощай (за бугром это правило известно как KISS — keep it simple stupid).

Обязательно нужно фиксировать договоренности. Проверенный срок жизни информации в перегруженных разными проектами головах – две недели. После этого незафиксированная задача забывается, детали теряются или появляются новые фантазии, задача начинает звучать по-другому. Хороший инструмент для фиксирования требований – Google Docs, там всегда видна актуальная версия, можно настроить права, посмотреть историю изменений.

Приносите ваши требования, будем вместе их уточнять :)