• Главная
• Услуги
• Успешно внедряем автоматизацию бизнес-процессов
• Составление и ведение документации

Составление и ведение документации

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

Для чего нужно вести проектные документы в области ИТ

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

• Для того, чтобы держать под контролем объем проекта;
• А также его сроки реализации;
• Осуществлять контроль качества на каждом этапе работ;
• Управлять финансовой стороной дела и т.д.

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

Что обычно включает в себя проектная документация

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

• Техническое задание. Это специальный документ, где Заказчиком описывается как можно подробнее то, что ему нужно увидеть после исполнения работ. В идеале, Исполнитель также должен принимать участие в разработке техзадания. Это позволит и Заказчику, и Исполнителю вникнуть во все тонкости дела. Впрочем, это может несколько увеличить сроки разработки ТЗ. Однако верно и то, что в случае некорректной разработки ТЗ сроки еще больше затянутся, а качество по итогам исполнения проекта может оказаться далеким от идеала.
• Планы проверки по этапам проекта и результаты проведения проверки. Причем, результаты проверки могут повлиять в конечном итоге на составленный план исполнения проекта. В то же время, формировать план поверхностного характера также не следует. Это грозит снижением качества результатов.
• Высокоуровневый дизайн. Этот документ может быть и инструментом самого проекта, и инструментом продажи.
• Низкоуровневый дизайн. Порой относительно данной части документации спорят: что именно должно входить в него. Но в целом все зависит от каждого конкретного проекта.
• Спецификация компонентов. В данном случае, это коммерческое предложение. Для Заказчика не будет лишним дополнительно к спецификации приложить и datasheets. Если у того появятся какие-либо вопросы, то можно будет быстро отыскать ответы на них.
• План исполнения работы.
• План осуществления тестирования. Здесь важно соблюсти максимально полное соответствие техническому заданию. По итогам исполнения плана, должен быть подписан со стороны Заказчика протокол, где результаты проведенного тестирования подтверждаются на соответствие ТЗ.
• Эксплуатационная документация. Здесь нужно описывать согласованные сценарии по эксплуатации. Данный документ окажется полезным в случае оказания постподдержки проекта. Данная документация может зависеть от типа самого продукта. Ведь она может ориентироваться как на конечного пользователя, так и на специалистов ИТ. В любом случае, она должна быть однозначной и понятной.
• План по аварийному восстановлению.

Конфигурация смежных систем

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