Как сделать спецификацию проекта за 5 шагов: инструкция

Русалина Ожго

ведущий менеджер проектов EMAILMATRIX

Ксения Ерастова

ведущий менеджер проектов EMAILMATRIX

Впервые опубликовано 22.11.2022. Обновили статью 14 августа 2025: дополнили новыми разделами и примерами спецификаций.

Представим, что вы планируете разработать большой проект: сайт, блог или приложение. Чего вы боитесь как заказчик? Что подрядчик пообещает золотые горы, возьмёт деньги, но не сделает, что вы хотели. А как подрядчик? Что в начале работы вас попросят сделать одно, а в процессе — всё переделать (причём раз десять), в итоге вы потратите кучу времени и уйдёте в минус.

Проект большой, поэтому надо принять меры. И поможет в этом спецификация (в простонародье — спека). В этой статье расскажем, как готовить спецификацию к масштабному проекту, на примере нашей недавней работы с крупным клиентом.

Что такое спецификация?

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

Спека похожа на список продуктов перед походом в магазин. В неё вносится всё, что нужно не забыть. Это, по сути, договор между вами и заказчиком, который регулирует объём будущих выполненных работ.

Для чего нужна спецификация

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

Какие функции выполняет спецификация:

• 

  Как правильно оценить эффективность работы CRM-агентства: почему мы не гарантируем продажи и даже Open Rate

  Сверка целей и ресурсов. Спецификация наглядно показывает, насколько цели соответствуют средствам и получится ли результат таким, каким его видит заказчик, или потребуются дополнительные вложения. Чётко расписанный план действий поможет объективно оценить текущую ситуацию.

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

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

Виды спецификаций

В зависимости от проекта могут быть разные виды спецификаций. В работе с клиентами используем такие:

• Спецификация к договору. В ней уточняются требования к работе и конечному результату. Здесь прописаны конкретные услуги, которые предоставляет исполнитель, их стоимость и объём трудозатрат.

• Техническая спецификация. Фиксирует требования к инструментам разработки и реализации проекта.

• Спецификация к счёту. Это отчёт о проделанных работах, за которые выставляется счёт. Он может быть оформлен как акт или приложение к счёту-фактуре. Вид документа обычно согласовывается с клиентом. Это может быть текстовое описание со ссылками или скриншотами.

Расскажем, как сделать техническую спецификацию, которая упростит жизнь и менеджерам, и разработчикам. Её подготовку можно разделить на пять этапов.

Шаг 1. Закрытая или открытая?

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

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

Есть и средний вариант: полузакрытая спека (обычно заказчики и исполнители договариваются именно на такой компромисс). Вы описываете инструменты разработки только там, где их можно определить заранее, до начала работ.

Шаг 2. Содержание

По структуре спецификация похожа на дипломную работу: элементы вроде содержания, введения или списка источников точно напомнят о студенческих временах.

С содержанием всё довольно просто: в него можно перенести примерный план задач от заказчика — то, что вам надо сделать. А чтобы понять, как это сделать, созвонитесь со специалистами и добавьте их комментарии к плану.

Ну и какая дипломная работа спецификация без титульного листа! Добавьте на него заголовок и дату публикации.

Шаг 3. Разделы

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

1. Введение
   1. Обзор: цель спецификации.
   2. Объём проекта: краткое описание проекта.
   3. Глоссарий: расшифровка терминов.
   4. Ссылки: список источников.
   5. Обзор продукта: краткое описание каждого раздела.
2. Общее описание
   1. Системная среда: общее описание, при помощи каких инструментов будет реализован функционал продукта. Также она включает операционную систему, серверную архитектуру, стек технологий, систему управления версиями, хостинг и окружение разработки.
   2. Объём проекта: краткое описание проекта.
   3. Спецификация функциональных требований: подробное описание, из чего состоит продукт. Если вы создаёте сайт, здесь будет подробное описание всех его страниц, хедера, футера и так далее.
3. Технические требования
   1. Требования к интерфейсу: общее описание требований к возможностям интерфейса проекта. Для сайта в этом разделе можно указать:
      • адаптивность и отзывчивость дизайна;
      • корректность отображения интерфейса во всех разрешениях;
      • кроссбраузерность — отображение и поведение элементов интерфейса единообразно в актуальных версиях браузеров;
      • навигация и UX — всё, что связано с удобством использования интерфейса и качественного отображения его элементов.
   2. Функциональные требования: описание того, как должна работать система со стороны пользователя и администратора. Например:
      • наличие конкретных страниц: главная, услуги, контакты, блог, каталог, отзывы и т. д.;
      • интеграция карт, видео, фотогалерей, слайдеров;
      • структура меню и вложенность страниц;
      • пользовательские функции;
      • управление контентом: создание, редактирование, удаление страниц, блоков, изображений;
      • интеграции с внешними сервисами и другие требования, которые определяют, что нужно реализовать.
   3. Нефункциональные требования: описание того, что нужно сделать, чтобы реализовать функциональные требования. То есть это требования к качеству работы сайта. Сюда же относятся:
      • безопасность;
      • производительность;
      • масштабируемость;
      • удобство использования;
      • поддержка и сопровождение (опция внесения изменений через CMS без помощи разработчика, возможность обновления модулей и т. д.).
4. Критерии приёмки

   Спецификация должна содержать чёткие критерии приёмки: что считается выполненным, какие параметры допустимы и как будет проводиться проверка. Без этого ожидания клиента могут не соответствовать реальности.

Шаг 4. Функциональные и нефункциональные требования

Это основная и самая подробная часть спецификации, поэтому расскажу о ней более подробно. Ей нужно уделить особое внимание, но сначала давайте разберёмся, в чём разница между этими требованиями.

Функциональные требования — то, как должна вести себя система, чтобы удовлетворить ожидания пользователя. В нашем проекте одной из функций была строка поиска. В её поведение закладывалось ранжирование результатов в хронологическом порядке. А если ничего не найдено, то пользователь получает рекомендацию изменить запрос.

Ещё один пример: описание работы с комментариями на сайте

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

Другой пример нефункционального требования — безопасность

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

Шаг 5. Согласование

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

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

Как только спека согласована, остаётся подписать её вместе с заказчиком и приступать к работе.

Как сделать спецификацию проекта: короткая пошаговая инструкция

Информации было много, давайте закрепим:

1. Открытая или закрытая спека? Первая даёт больше свободы подрядчику, вторая понятнее заказчику, но возможен и компромиссный полузакрытый вариант.
2. Титульный лист и содержание. Готовим драфт, чтобы было куда накидать «мясо».
3. Описание всех разделов. Заполняем каждый раздел из содержания.
4. Требования клиента. Делятся на функциональные (что система должна делать) и нефункциональные (как она должна это делать).
5. Согласование. Перед отправкой заказчику прочитайте спецификацию его глазами: всё ли понятно?

Спецификация может показаться сложным документом, но без неё будет намного сложнее в самой разработке. А чтобы вам было полегче, скачайте через форму ниже готовый шаблон 🙂