Проектные документы. Как снизить эту составляющую стоимости проекта?

27 августа 2014 г.

— Я не знаю, что вам нужно.

— Ну, что мне нужно, ну, что мне нужно? Мне нужно... Ой, ой... ой, ну, что мне нужно, Господи? А что у вас есть?

— Что вам нужно?

— Ну, что мне нужно?.. Ну, лекарства какие-нибудь.

— Какие?

— А какие у вас есть?

— А какие вам нужно?

© Жванецкий. На складе.

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

Как же снизить эту составляющую стоимости проекта? На поверхности лежит несколько ответов:

1. Снизить объем (количество) документации.

2. Оптимизировать процесс согласования.

Давайте рассмотрим каждый из вариантов.

Снизить объем (количество) документации. Звучит очень заманчиво, однако, если посмотреть на количество проектной документации не с точки зрения советской традиции «Мы заплатили много денег, нужно много результата» или вопроса постановки на учет НМА, то зачем же нужна документация? Что в проекте делает команда — разрабатывает некую функциональность (систему), которая посредством своих функций помогает клиенту достичь неких выгод и, как это не избито звучит, повысить эффективность. Но сама по себе система, какой бы эффективной она не была, для клиента представляет собой «черный ящик». На вход подаем то-то, на выходе то-то, все работает, но как — никто не знает. Более того — те самые разработчики через год точно также все забудут. Или не забудут но будут болезненно реагировать на отчуждение знаний.

Так что же покупает клиент? Систему, как результат интеллектуального труда, и поскольку это предмет не материальный — по сути клиент покупает описание системы, документацию. Это результаты труда проектной команды, которые дают ответ на вопрос «Что сделано в проекте? Какие действия необходимо предпринять, чтобы дойти до результата?».

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

Поэтому снизить объем документации в плане количества документов относительно устоявшихся «правил» вряд ли удастся, тем более, что этот состав достаточно выверен и отечественным, и зарубежным опытом. Правда иногда бывают исключения, но тут подход один — понять что клиент хочет видеть в этих дополнительных материалах и зачем. Без этого «Пойди туда — не знаю куда, принеси то — не знаю что», но это отдельный вопрос. Что остается в плане сокращения затрат на проект? Снижать наполнение каждого документа — и здесь мы плавно переходим ко второму ответу.

Оптимизировать процесс согласования. Вообще одной из целей проектной команды, помимо работающей функциональности (системы) и, качественной описывающей ее документации, является, конечно же, согласование этой документации с клиентом — без этого не будет актов сдачи-приемки, финансирования и, как следствие, заработной платы. А согласовывают документы с людьми. Мы уже обсуждали влияние количества участников проекта на сроки в статье про качество, касаясь вопросов понимания и интерпретации требований к системе, поэтому крайне важно их, этих самых согласовантов, уменьшить.

К примеру, я не так давно читал в одной статье сколько времени занимает установка светофора в Москве. Так вот поставить светофор — день (два-три максимум), а согласовать его установку — год. Много служб, вовлеченных в процесс согласования (столбы, колодцы, системы водоснабжения, коммуникации и т.д. — все имеют «хозяина» и с этим «хозяином» нужно согласовать — вам же наверное не понравится, если в середине вашего окна пройдет новая газовая труба?). В проектной документации — тоже самое.

Так как уменьшить количество людей? Только трезвым взглядом и ответами на вопросы вида «Кто с этим документом будет работать?», «Зачем человеку тратить время на этот документ?». Например, устав проекта, как определяющий порядок взаимодействия, и роли участников должны, конечно, согласовать все заинтересованные стороны, а вот описание настроек и разработок, наверное только проектно-эксплуатирующее подразделение (айтишники).

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

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

2. Определите, каким специалистам команды заказчика важна информация, которая содержится в том или ином документе. Кто понимает назначение этого документа. Отсюда и состав согласующих.

3. Определите зачем каждому согласующему необходимо что-то согласовывать. Каковы его интересы в его виде деятельности, какие его(!) задачи вы решаете данным проектом. Логично описание этих задач поместить в начало документа.

4. Соблюдайте принцип от общего к частному. Пространное вступление на пару страниц (например), без четкого понимания у читателя зачем ему это все читать, не способствует приятному чтению.

5. Согласовывать документ лучше итерационно — сначала необходимо определить разделы и что туда пишем, потом наполнение разделов. Человека всегда пугает монотонное чтение технического труда на 100+ страниц.

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

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

8. Если согласование не приносит результатов продолжительное время (несколько дней), меняйте подход. Дайджесты, очные встречи с пояснениями, больше картинок в документе, давайте не будем согласовывать сначала систему, покажем прототип и после все подпишем, наконец. Это не очень правильно с точки зрения рисков проекта, но явно лучше, чем стоять на месте и изводить представителей Заказчика просьбами о согласовании документов.

9. Цените результаты своего труда, которым и является документ. Мало кто любит писать проектную документацию, но это результат вашего труда. Одной работающей системы недостаточно. Проверьте документ на наличие нумерации страниц, ровные отступы, списки, идентичность шрифтов и орфографию с падежами. Такие «тяп-ляп» ошибки очень портят общее впечатление от документа, а с плохим настроением вероятность положительного восприятия вашего труда снижается в разы.

Другие статьи Андрея Шоханова: Как обеспечить качество в проекте?; У семи нянек дитя без глазу, или ошибки вида «несколько заказчиков в структурах управления проектом»; Почему затягиваются сроки внедренческих проектов? Внешние факторы; По щучьему велению, или Как сократить сроки внедренческих проектов

Источник: Андрей Шоханов, советник руководителя дирекции по работе с предприятиями нефтяной и энергетической отрасли ЛАНИТ