Компьютерра - Журнал «Компьютерра» № 8 от 28 февраля 2006 года

6. Бизнес-процессы могут измениться к моменту начала внедрения.

Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.

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

2.2. Техническое задание на проект

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

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

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

2.3. Настройка системы, описание доработок

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

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

Но у Заказчика нет специалистов, способных оценить качество этих документов, следовательно, никаких проблем с приемкой этапа не возникает.

2.4. Доработка системы

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

2.5. Обучение (свет в конце тоннеля)

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

Пользователи начинают бунтовать. У пользователя много причин для бунта. Его устраивала та система, в которой он работал раньше. Новая система кажется ему сложной, и у него есть шанс обратить внимание разработчиков на недостатки (как ему кажется) интерфейсов и необходимость оптимизации каких-либо функций.

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

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

2.6. Зачем такой длительный предпроект?

"Позвольте, мамаша! На станции,

Согласно багажной квитанции,

От вас был получен багаж:

Диван, чемодан, саквояж,

Корзина, картина, картонка

И маленькая собачонка.

Однако во время пути

Собака могла подрасти!"

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

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

Когда будет выполнено все, кроме последнего этапа, нет гарантий, что полученная система сможет быть внедрена. Для Исполнителя важно, что почти все деньги получены. Если последний этап выполнить не удается, то для Исполнителя в этом нет ничего страшного. Риски незначительны. Он рискует: