Версия для печати
Отправить другуСитуация:
Вы менеджер проекта со стороны подрядчика на проекте внедрения. Проект проходит успешно, и вы даже успеваете внедрить систему досрочно. В успехе проекта большая доля работы заказчика, который организовывал своевременные согласования документов и преодолевал все трудности, возникающие внутри организации. Вы знаете, что заказчик, в свое время, запрашивал у вас дополнительную функциональность в систему, но после оценки сроков и стоимости на управляющем комитете, согласно процедурам управления содержанием проекта, от данной функциональности отказались. У вас достаточно времени в запасе, и вы создаете этот функционал на тестовой среде, а затем, после тестирования, презентуете ее менеджеру проекта со стороны заказчика. Менеджер проекта очень доволен дополнительной функциональностью, как и конечные пользователи. Однако, через два месяца, техническая поддержка заказчика заявляет ошибку в вашу техническую поддержку, связанную с данным функционалом. Чтобы исправить некорректные данные в системе, которые создал дополнительный функционал необходимо приложить значительные усилия. Кроме того, необходимо исправить ошибку в функционале. Это дополнительные затраты. Кто будет их оплачивать?
Вывод:
Не делайте экстра функциональности. Выполняйте свои обязательства по контракту, это будет лучшим подарком для заказчика. Если будет возможность - сделаете скидку. Любая дополнительная функциональность может обернуться во зло, не сейчас, так позже.
- admin's блог
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
- Версия для печати
- Отправить другу
Если функциональность все-таки очень нужная для заказчика, и, особенно, полезная для вас - для будущих проектов, можно попробовать его убедить реализовать ее за дополнительную плату (сделать "допродажу" опций), таким образом получив бюджет на будущее сопровождение допфункционала. В чем-то может пересекаться с пунктами №№ 29 и 36 - только в этом случае инициатива исходит уже от вас. Или сделать ее условно бесплатно - с условием дополнительной оплаты на стадии сопровождения. Если заказчик не соглашается платить, но вам надо чем-то заполнить простой - то без гарантий, только для демо-целей (по принципу - "а шо вы хотели за такие деньги"), а по факту - для раскрутки-заманивания заказчика на доп. бюджет.
Вот только экстра функциональность - функциональность не входящая в рамки проекта, т.е. не описанная в задании и дополнениях (запросах на изменение). т.ч. никакого противоречия тут нет. Просто не нужно делать что-то не входящее в рамки проекта. Если есть что-то, что необходимо, но не входит в рамки проекта, нужно просто формально его включить в проект.
Тогда да, согласен. Просто в кейсе не сказано, что экстрафункционал не включен в проект. Я-то по умолчанию считал, что доработка влючена формально (для меня это само собой разумеющиееся), а проблема в финансировании - бюджет не расширен, доп. оплаты за нее нет, и потом из-за проблем с сопровождением начальство хмурит брови - типа зачем накликал проблемы, и без доработок бы все ок бы было.
Это отдельная тема, когда доработку включают, а бюджет и сроки не расширяют. Честно говоря, я помню такое было очень давно. Если у вас подобная ситуация свежа в памяти, можете оформить как очередной урок, если вам не трудно, я его опубликую (пока нет возможности публиковать в тот же блог другим пользователем).
Может быть, просто в данный урок вставить уточнение - доработка не оформляется, а делается "за просто так".
Насчет описания "своего" урока - мне надо подумать, как оформить. Вообще-то это было и бывает сплошь и рядом в случае фиксированного бюджета + размытое описание задач
(или обещание руководством заказчику "СИСТЕМА ДЕЛАЕТ ФСЁ!".
(а тема "продажников любой ценой" - это вообще отдельная песня). )))
Избегнуть фиксированного бюджета, увы, не всем и всегда удается ("политика продаж, панимашь" - см. выше), а круг задач как правило, может драматически расшириться, но идти на острый конфликт (а то и суд) - тоже не решение проблемы (опять "политика"). Чаще же всего неутвержденная, но ставшая нужной заказчкику доп. работа делается за счет отказа от уже утвержденной, не очень нужной задачи. Но если это не оформить, то получается такая же ситуация, как в текущем уроке, т.е. - как обычно в таких случаях - менеджер проекта виноват, и поделом.