Я хотела бы сосредоточиться на заданиях, которые формируются заказчиком для потенциальных исполнителей в начале их сотрудничества. Это может быть как техническое задание (ТЗ), так и функционально-технические требования (ФТТ), или любой другой документ, который предоставляет исполнителю необходимую информацию для подготовки коммерческого предложения, а заказчику — для качественной оценки предложений и выбора исполнителя.

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

Какое задание, я считаю идеальным: 1. Краткое –20-30 страниц, со всеми вспомогательными данными (глоссарий, оглавление и т.д.) это предел, уложиться в 5-10 идеально 2. Ориентированное на ключевые бизнес-требования – не менее 50% документа должны занимать бизнес-требования, около 30% — технические требования, а оставшиеся 20% — общие вводные данные, требования к составу предложения, исполнителю и порядку выполнения работ. 3. У каждого бизнес-требования должен быть владелец – идеально если он прямо указан в ТЗ. Если возникнут уточняющие вопросы по заданию, то однозначно будет ясно к кому их можно адресовать. 4. Каждое бизнес-требования должно описывать конечный результат, который нужен заказчику, а не процесс или способы исполнения.

Итак, в идеале задание должно максимально полно отвечать на вопрос «Что хочет заказчик». По сути, такой документ ближе к ФТТ, чем к ТЗ.

Казалось бы, чем тогда плохи таблицы требований, с которыми мне пришлось работать в рамках подготовки к тендеру? Попробую выделить основные моменты: 1. Объем: 300 требований – это очень много для любого проекта. 300 требований не могут быть ключевыми. Один бизнес-заказчик (если он персонифицирован) редко генерирует больше 5-10 требований. Таким образом в нашем проекте будет не мнее 30 ключевых бизнес-заказчиков, управлять ходом такого проекта будет крайне сложно, все процессы будут замедляться. Я бы рекомендовала такой проект декомпозировать, разделить на фазы/этапы, либо пересмотреть набор требований и выделить ключевые. 2. Неясность формулировок: Казалось бы документ ориентирован на бизнес-требования, но сами бизнес-требования не конкретизированы и выглядят примерно так: «Система должна позволять управлять движением материалов». Совершенно не ясно для чего? Какие задачи бизнеса это позволит решить. Гораздо проще было бы работать с таким требованием если бы оно описывало конкретный результат: «Система должна позволить сформировать отчет о движении материалов за произвольный период, в котором отражалось бы поступления материалов на склад из производства и других складов и списание со склада. Пользователь отчета - мастер склада. Цель отчета - поиск точек дисбаланса, идентификация мест возникновения брака»и далее еще 4-5 предложений осознанных бизнес-требований 3. Отсутствие общей картины: таблицы требований не дают понимания о том, как должен выглядеть результат проекта в целом, как должен выполняться проект. Как уже упоминалось, в документе не хватает 20% на общие вводные, требования к составу предложения и порядку выполнения работ.

Кто-то возможно скажет, что ТЗ и ФТТ остались в прошлом, у нас же есть Agile – обозначили основную цель проекта и начали итерационно к ней двигаться используя user story, например. Но к сожалению Agile пришел в крупные корпорации, а fix-price договора при этом остались. В следующем посте попробую высказать свою мысль о том, как совмещать работу по Agile и fix-price договор.