Проекты без проектной документации

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

Подготовка проектной документации может занимать до 30% трудозатрат проекта. Эти затраты будут складываться как из непосредственной подготовки проектных решений, технический проектов и прочего, так и из трудоемкости, затраченной на их согласование с заказчиком. При согласовании проектная команда тратит огромное количество времени на стилистическую редактуру казалось бы технического документа. Например, одному участнику рабочей группы от заказчика не нравится слово «Работники», и он просит заменить их на «Сотрудники», другому не нравится слово «Согласующие» и он требует заменить его во всем документе на «Согласовывающие». Иногда кажется, что такое согласование будет длиться бесконечно.

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

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

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

Но, как обычно, дьявол кроется в деталях. Уже на этапе тестовой эксплуатации, после того как исполнитель закончит разработку и будет демонстрировать решение заказчику, начнутся претензии в стиле «мы рассчитывали, что это будет реализовано несколько иначе», «мы думали, это будет работать по-другому», «почему вы не сказали, что оно работает именно так, мы бы ни за что на это не пошли». Всех этих вопросов можно было бы избежать, если бы проектные решения или технический проект подробно описывал реализацию того или иного функционального блока. В итоге, экономия на документировании может вылиться в серьезные модификации (вплоть до 100% выполненных ранее модификаций) на этапе тестовой эксплуатации. За чей счет они будут выполняться станет одним из сложнейших вопросов, которые придется решать руководителям проекта со стороны заказчика и исполнителя.

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

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

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

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

3.     На бизнес-пользователей ни в коем случае не выносятся документы описывающие технические детали и настройки.

4.     Из проектной документации исключаются все «стандартные разделы», например, «техника безопасности» и тому подобные формальности.

5.     Формат всей проектной документации согласуется на старте проекта.

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

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