Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Я правильно понял, что за бюджет на внедрение CRM, допустим, в 10млн, клиент через год получит удобный планировщик, интеграцию с каким-нибудь интранетом, хоть с чертом лысым, но не CRM. Это не проект, это бодишоп.
В таком случае мы, наверное, будем не очень хорошими исполнителями. Если клиент хотел CRM, то он должен получить CRM.
Весь вопрос в объеме реализованной функциональности, которая постоянно обсуждается нами и заказчиком в течение проекта, но свои основные функции как CRM система должна выполнять.
Иначе да, как в бодишопах, когда у исполнителей нет никакой ответственности за итоговый продукт — продается просто человек, а там будь что будет.
Весь вопрос в объеме реализованной функциональности, которая постоянно обсуждается нами и заказчиком в течение проекта, но свои основные функции как CRM система должна выполнять.
Иначе да, как в бодишопах, когда у исполнителей нет никакой ответственности за итоговый продукт — продается просто человек, а там будь что будет.
У вас же нет в договоре обязанности через год купить, внедрить, обучить. Вы как хорошие исполнители обещаете только оприходовать бюджет в срок, возможно, это не проектная деятельность.
Как я уже писал в комментарии выше, мы вместе с заказчиком делаем нужный ему продукт, с максимально возможным набором функций, в рамках бюджета проекта.
Если вы имеете ввиду полностью закрыть ответственность исполнителя договором — ну тут вариант только один, все четко прописать и получить контракт с зафиксированными бюджетом, сроком и скоупом.
Тогда заказчик точно получит то, что просил на старте проекта. Но не то, что ему по факту нужно. И обе стороны будут иметь те же проблемы, от которых хотели уйти :)
Если вы имеете ввиду полностью закрыть ответственность исполнителя договором — ну тут вариант только один, все четко прописать и получить контракт с зафиксированными бюджетом, сроком и скоупом.
Тогда заказчик точно получит то, что просил на старте проекта. Но не то, что ему по факту нужно. И обе стороны будут иметь те же проблемы, от которых хотели уйти :)
Разработчик софта, в котором я работал в 2000х, однажды попробовал такой подход, но быстро отказался. Причина — заказчик фокусируется на сырости продукта и недоработках (после неоднократного предупреждения, что это ИТЕРАЦИЯ и показываем ФИЧИ), его мотивация падала и он уходил к конкурентам. В лучшем случае, он говорил что в принципе нормально, давайте сделаем всё и до конца, и уже к финальному релизу предъявлял ту самую кучу новых требований.
Как вы справлялись с этой проблемой?
Как вы справлялись с этой проблемой?
«уже к финальному релизу предъявлял ту самую кучу новых требований» — у нас была несколько похожая ситуация, как раз в конце статьи я об этом упомянул. Только заказчик не предъявил кучу новых требований, а немного посетовал, что сделали не все, что было у него в голове. В принципе, если это возражение быстро и качественно с аргументами обработать, то получается ок и дальше запускается следующий этап проекта (релиз), уже в рамках нового бюджета.
По поводу сырости и недоработок, на моем опыте такое впечатление заказчика о промежуточных результатах сильно зависит от того, что мы ему показываем. Если показываем сырое, падающее, непонятно как сверстанное — тогда понятно, он будет недоволен. А если показывать небольшими инкрементами функциональности, но зато условно production качества — это уже другой разговор.
По поводу сырости и недоработок, на моем опыте такое впечатление заказчика о промежуточных результатах сильно зависит от того, что мы ему показываем. Если показываем сырое, падающее, непонятно как сверстанное — тогда понятно, он будет недоволен. А если показывать небольшими инкрементами функциональности, но зато условно production качества — это уже другой разговор.
Жду следующих статей. Особенно пример договора.
Это принцип «fix time, fix budget, flex scope» artgorbunov.ru/bureau/fff
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Agile с фиксированной стоимостью — это реально