Компьютерра, 2006 № 08 (628) - [36]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Самуил Маршак, «Багаж»

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

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

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

< Неполученным остатком денег из бюджета проекта.

< Своей репутацией.

< Невыполнением обязательств по договору.

Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно. Риск потери репутации отсутствует — мы ввели такое допущение (почему, объясняется в разделе «Итоги не для всех»). Невыполнение обязательств по договору — тоже риск несущественный. Договор готовил Исполнитель и заранее продумал наличие в договоре лазеек для сложившейся ситуации.

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

2.7. Внедрение

Последний этап обычно очень сложен. Прежде всего из-за низкого качества выполнения задач предпроекта. Но есть и другая причина.

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

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

Дальше сценарии бывают разные. Если Заказчик располагает ресурсами или инструментами давления на Исполнителя, то конфликт улаживается. Проект удается внедрить — пусть с большим опозданием и зачастую с увеличением бюджета.