Версия для печатиОтправить другу

Источник: Алексей Ким. Написание устава проекта.
Управление проектами - №1 (18) 2010 - с.23. Публикуется с разрешения редакции.
  
Как правило, на проектах внедрения информационных систем длительностью от полугода, где работы проходят в более-менее нормальном режиме, представители подрядчика (внедряющей компании) и заказчика успевают установить товарищеские отношения. Это не секрет, и происходит подобное по причине того, что представители заказчика и подрядчика на проекте решают совместные проблемы, идут на компромиссы, пытаются понять друг друга. Как правило, подобные отношения устанавливают руководители проектов, а также представители команды проекта, активно вовлеченные в проектную работу. Подобные товарищеские отношения полезны для проекта, они повышают мотивацию, эффективность, кроме того, общаясь между собой, члены команды получают знания и опыт друг друга, повышая уровень квалификации, но иногда, подобные отношения могут принести вред. Предлагаю рассмотреть подобную ситуацию.
 

В одной компании, скажем в многострадальной “Рога и Копыта” было принято решение о внедрении новой ERP системы. К вопросу подошли серьезно, был проведен анализ существующих систем, конкурс на выбор системы и внедряющей компании, GAP анализ и, наконец, проект оказался на стадии внедрения. Внедрение происходит в два этапа. Первый этап, собственно доработки ERP системы, его тестирование и отладка на стороне подрядчика, а второй этап заключается в тестировании на стороне заказчика и пользовательском приемочном тестировании. Во время тестирования системы заказчиком, представители подрядчика, разумеется, присутствуют в компании заказчика.
 
И вот, наконец, наступает момент технического тестирования заказчиком. В “Рогах и Копытах”, техническое тестирование проводят аналитики, хорошо знающие бизнес процессы компании. Написаны тестовые сценарии и началась прогонка сценариев в системе. В ходе тестирования, один из аналитиков выяснил, что тестируемая им часть хотя и работает в соответствии с техническим заданием, но работу можно сделать значительно более эффективной, если внести в систему небольшие изменения. Он подошел с этим вопросом к менеджеру проекта. Перед менеджером проекта встала проблема выбора. С одной стороны – улучшения очевидны, согласовать их с конечными пользователями можно, с другой – в связи с долгим процессом согласования запросов на изменения руководством, последующей оценкой запроса подрядчиком, регрессионным тестированием и т.п., произойдет затягивание сроков проекта, и увеличение бюджета. Он решил посовещаться с менеджером проекта со стороны подрядчика.
 
В результате совещания, менеджеры проекта со стороны заказчика и исполнителя пришли к выводу, что внести изменение стоит, а вот оформлять формально нет. Т.к. изменение системы было минимальным, разработчик подрядчика через пару часов прислал небольшой программный патч, вносящий эти изменения менеджеру проекта подрядчика, а тот передал его на диске заказчику. Патч был установлен на отдельную тестовую среду (ее удалось создать за пару дней) и проверен. Система работала так, как было необходимо. Во время пользовательского тестирования, пользователи очень обрадовались изменениям, т.к. они упрощали работу. Систему сдали (установив на боевую среду патч), проект успешно завершился, все счастливы. За одним исключением.
 
Через три месяца работы системы в промышленной эксплуатации были выявлены расхождения в отчетности и реальном положении дел. Потратив еще порядка недели на расследование инцидента, выяснилось, что благодаря внесенным изменениям, система все-таки работает неверно. Округления. Система выполняет округления не так, как было заявлено в техническом задании. Это не было заметно во время тестирования, т.к. тестирование проходило все-таки на небольшом объеме данных, но когда состоялся запуск системы в промышленную эксплуатацию, расхождения накопительным итогом, полученные в результате округлений, достигли значительных сумм. Восстановив из архивной копии тестовую систему, поставленную подрядчиком для тестирования, выяснилось, что в системе до установки патча, округления происходили верно. Ошибка была заявлена в техническую поддержку компании подрядчика, однако, вскоре был получен ответ, что согласно условиям договора, поддерживается поставленная в компанию версия системы, без доработок заказчика, а ошибка, заявленная в службу технической поддержки, возникла в результате изменения кода заказчиком. Подрядчик согласился исправить ошибку за дополнительную плату, но при этом терялась новая функциональность и, если требовалось исправить некорректные данные, то стоимость их исправления была высокой. Заказчику ничего не оставалось, как оплатить исправления.
 
“Экстра” функциональность легко может принести вред. Возникнуть она может множеством способов, отнюдь не только приведенным выше, начиная от разработчика, решившего внести изменения в код, чтобы что-то улучшить и заканчивая заказчиком, попросившим недокументированные изменения. Вред от нее также может быть разнообразным. От отказа в обслуживании по договору, как в приведенном примере, до срыва сроков и увеличения бюджетов. Хотя в примере и рассказывается про дополнительную (экстра) функциональность, вред может нанести и неавторизованная попытка превысить планируемый уровень качества, уложиться в меньшие сроки и многое другое. Разумеется, экстра может принести и пользу, но нужно ли рисковать получением запланированного результата проекта ради чего-то дополнительного? Думаю, не стоит.