Проектная документация в ИТ важна, а еще важнее относится к ней не как к ненужной обузе, а как к незаменимой помощнице проектной деятельности.
С самого начала работы в проекте, а еще лучше с самого начала разработки продукта нужно определится с тем что такое проектная документация, зачем она нужна, из чего она состоит и как грамотно воплотить ее в жизнь.
Что ж, на этот счет бытует много мнений, у каждой компании подход по-своему уникален, у каждого сотрудника также, но я в этой статье попытаюсь не просто выразить свое, а сложить у читателя общее объективное понимание темы.
Итак, что такое и зачем нужна проектная документация в ИТ? По-сути это набор документов, необходимых для того чтобы проект был выполнен качественно и в срок, а значит не вызывал перерасходов у Клиента и снижения маржинальности у Интегратора.
Любой приличный Клиент будет требовать качественную документацию по проекту, ведь это одна из причин выполнения работ Интегратором, а не штатными сотрудниками или группой студентов от ИТ.
Для Интегратора проектная документация необходима для грамотного планирования ресурсов, ценообразования и качественного выполнения работ.
Заметьте, я не разделяю проектную и рабочую документацию, практика говорит что такое разделение во-первых искусственное, а во-вторых может нанести вред конечному качеству, что недопустимо.
Договор я не выношу отдельным пунктом, т.к. он является последствием и определить время его появления и закрепления затруднительно – уж больно индивидуально это происходит.
Ну а теперь самое интересное, что же входит в типовой набор? Я предлагаю остановится на таких документах:
1. Техническое задание. Документ, в котором Клиент описывает что он хочет увидеть в результате. На практике, Интегратор может и должен принимать участие в разработке ТЗ и помогать Клиенту разобраться в тонкостях продукта, ведь совсем не просто описать то, что еще не используется. Таким образом, работа и согласование ТЗ могут растянуться, но это не страшно, если с Клиентом ведется диалог
2. План и результаты аудита. Это вообщем-то два перекликающихся документа, но в Плане не всегда возможно учесть все тонкости, толковые инженеры привлеченные к аудиту всегда найдут что добавить. Несмотря на то что Результат аудита это документ ”для Интегратора”, я за то чтобы согласовывать его с Клиентом. Больше общения – лучше, и Клиент на первом этапе уже сможет понять что отношение к нему профессиональное. Иногда это называют Site Survey, это не ошибка, но специфика может отличатся.
3. High-Level Design. Я уже рассказывал о этом документе, добавлю лишь тот факт что HLD не всегда инструмент проекта, он может быть и инструментом продажи, т.е. появляться до проекта как такового.
4. Спецификации компонентов. Это понимается как КП, и совершенно верно, НО не лишним будет приложить datasheets к КП, если у Клиента возникнут вопросы, он может быстро найти на них ответы, что правильно.
5. Low-Level Design. Этот документ почему-то вызывает много споров относительно своего содержания, многие говорят о том что конфиги нужно описывать в NIP (Network Implementation Plan), я скажу так – зависит от проекта. Приводя в пример решения Microsoft, я за то чтобы LLD был исчерпывающим и самодостаточным. Этот документ составляют инженеры опираясь на ранее согласованный HLD и используя тестовую среду приближенную по характеристикам к Спецификации компонентов. Получив такой документ Клиент всегда сможет вернутся к изначальной конфигурации, а на самом деле даже выполнить работы самостоятельно, что иногда плохо, но иногда хорошо.
6. План выполнения работ. Не совсем документ, но важный этап. Составляет его обычно Project Manager, но по факту важный момент учесть мнение инженеров, т.к. это поможет избежать многих проектных рисков (о которых я обязательно расскажу в одной из ближайших статей).
7. План тестирования. В этом документе важнее всего соблюсти полное соответствие ТЗ. Результатом выполнения плана тестирования должен стать подписанный Клиентом и Интегратором документ (Протокол), в котором подтверждается соответствие результатов тестирования Техническому Заданию. Вы можете встретить название именование этого этапа как NRFU, но это уже специфика, а я говорю о более глобальных вещах в этой статье.
8. Эксплуатационная документация. Я за то чтобы делать один документ по эксплуатации продукта, где нужно описать согласованные сценарии эксплуатации. Этот документ будет крайне полезен если вы оказываете пост-стартовую поддержку проекта, а для сотрудников Клиента с-ма нова и работа с ней вызывает много однотипных вопросов.
В зависимости от продукта, эксплуатационная документация может быть ориентирована как на ИТ специалистов, так и на конечного пользователя. Впрочем, подход к составлению от этого не меняется – информация должна быть однозначной, понятной и применимой.
Вообще эксплуатационной документацией часто жертвуют – Клиент не всегда готов за нее заплатить, а Интегратор не всегда готов настоять и показать ее полезность. Выход из этой ситуации достаточно прост – если вы выполните проект за проектом, то единожды разработанная эксплуатационная документация будет с минимальными изменениями входить в каждый проект.
9. Disaster Recovery Plan (DRP) стоит выделить в отдельный документ т.к. тогда когда он будет нужен, не стоит тратить время на поиск соответствующего раздела в эксплуатационной документации. Ну а для Клиента это еще одно подтверждение правильности выбора подхода работы с интегратором.
10. Последний, но на самом деле не последний этап проекта, а просто то, о чем я хочу сказать в конце, дав пищу уму – это конфигурирование смежных систем.
ИТ должно быть единым, живым организмом, и интеграция должна быть учтена с самого начала и до конца проекта. Конкретные вещи по интеграции зависят от конкретной ситуации, и выделить эту тему в отдельный документ не получится в большинстве случаев.
Учитывайте интеграцию проекта с существующими системами везде где только это возможно – этим вы снизите риски и повысите конечную удовлетворенность Клиента.
Конечно в формате блога сложно покрыть весь объем, но мой основной посыл дать основу для дальнейшего роста, надеюсь эта информация будет полезна.
