Структурируем документацию проекта. Часть 1

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

Новичкам для ознакомления с основами ведения документации.
Для тех, кто готовит документацию с нуля или расширяет текущую.
Для тех, кто хочет сравнить и проанализировать разные подходы к документированию продуктов.

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

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

Итак, рассмотрим какая же структура предпочтительна для документации.

Этот раздел описывает внутренних и внешних участников продукта, дорожную карту проекта, проблемные вопросы и другую общую информацию продукта.

Этот раздел описывает внутренних участников продукта.

Структурируем документацию проекта. Часть 1

Этот раздел описывает внешних участников продукта.

Тут приводится подробная дорожная карта реализации. Не забудьте указать ответственного за контроль и актуальность плана работ.

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

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

Пример:

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

Этот раздел включает в себя основные аспекты продукта/разработки. Здесь приводится описание, цель, ограничения продукта, функциональные требования.

Краткое изложение сути продукта/разработки. В этот подраздел можно также включить предысторию продукта.

Пример:

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

Здесь необходимо описать назначение продукта/разработки для определения направления работы и критериев оценки результатов. Цель можно сформировать по SMART.

Пример:

Необходимо разработать функционал электронной записи в личном кабинете школьника.

Пример по SMART:

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

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

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

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