Проектная документация в ИТ

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

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

Зачем нужна проектная документация в ИТ?

По-сути для снижения рисков Заказчика и Исполнителя.

Исполнителю проектная документация необходима для ведения проекта – управления объемами, сроками, финансами, качеством.

Заказчику наличие проектной документации поможет оценить качество работ и ощутимо улучшит дальнейшую эксплуатацию решения.

Ну а теперь самое интересное, что же входит в “джентельменский набор” документации?

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

Фактически ТЗ, это фиксация цели проекта, а цель должна соответствовать определенным критериям, например, общепринятым SMART

2. План и результаты аудита (Site Survey). Это вообщем-то два “зеркальных” документа, но на практике в Плане вы не сможете учесть 100% объем, поэтому полученные результаты могут изменить изначальный план.

Но делать поверхностный план не стоит – это снижает качество результатов, а значит генерирует дальнейшие риски.

3. Высокоуровневый дизайн (High-Level Design). Я уже рассказывал о этом документе, добавлю лишь тот факт что HLD не всегда инструмент проекта, он может быть и инструментом продажи, т.е. появляться до проекта как такового.

4. Спецификации компонентов. Это понимается как коммерческое предложение, и совершенно верно, НО не лишним будет приложить datasheets к КП, если у Клиента возникнут вопросы, он может быстро найти на них ответы, что хорошо.

5. Низкоуровневый дизайн (Low-Level Design). Этот документ почему-то вызывает много споров относительно своего содержания, многие говорят о том что конфиги нужно описывать в Implementation Plan, я скажу так – зависит от проекта.

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

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

6. План выполнения работ (Project Plan). Не совсем документ, скорее этап. Подробнее об этом можете узнать из моего цикла статей IT Project Management.

7. План тестирования (NRFU). В этом документе важнее всего соблюсти полное соответствие ТЗ. Результатом выполнения плана тестирования должен стать подписанный Заказчиком Протокол, в котором подтверждается соответствие результатов тестирования Техническому Заданию.

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

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

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

9. План аварийного восстановления (Disaster Recovery Plan) стоит выделить из эксплуатационной документации в отдельный документ т.к. тогда, когда он будет нужен, не стоит тратить время на поиск соответствующего раздела в эксплуатационной документации.

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

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

Учитывайте интеграцию проекта с существующими системами везде где только это возможно – этим вы снизите риски и повысите конечную удовлетворенность Заказчика.

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