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

Поддержка оговаривается в рамках контракта на внедрение. И если поддержка не лимитирована (то есть должен чинить все и всегда), то вполне реальна ситуация, когда клиент говорит что "ваша левая" фича падает и ее нужно починить и допилить. А это ресурсы. А деньги те же что и без нее, так как согласовывались до ее появления. В итоге - убытки.

что тут скажешь? улучшайте процесс продаж, обучайте продажников - не должно быть такой ситуации: ни когда "поддержка не лимитирована", ни когда "деньги согласовывались до ее появления". неправильно закладывать бюджет имея только слабое представление о будущих рисках, либо не имея его вовсе. в этом случае убытки - вполне закономерный исход недостаточно квалифицированного управления...

Я немного другое имел ввиду.
Допустим мы провели предпроектное исследование и т.д. Формируем требования и т.д. В итоге получаем систему в набором функ-ий (например 10).

Согласовываем и получаем что наши 10 фун-ий стоят 100 т р. Там же оговариваем поддержку, есть круглосуточный сапорт 24/7, которая обойдется в 200 т р. клиенту. И примерно знаем что будет 50 обращений в месяц для которых хватит ресурсов 2 х сотрудников.

А по факту выходит что у нас не 10, а 12 фун-ий. И если мы их оставляем - мы должны их поддерживать. В итоге будет на 50, а 60 обращений и 2х сотрудников саппорта не хватит. В итоге мы несем затраты.

еще раз.
контракт на поддержку непринятой в эксплуатацию системы, т.е. системы с неопределенным набором функций, ЗАКЛЮЧАТЬСЯ НЕ ДОЛЖЕН. Иначе Вы не сможете его выполнить.
При этом действительно ресурсы поддержки оцениваются из опыта, статистики и т.п. Количество обращений тоже.
Однако дальше все зависит от организации процессов поддержки. В принципе я могу и в эту тему погрузиться, но она не для этого форума - читайте ITIL/ITSM и itsmforum.ru

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

Почему система не принятая в эксплуатацию - с неопределенным набором функций ? Мне казалось что они как раз описываются до разработки и уже указаны в контракте, иначе как проводить приемку ?

Я еще раз напоминаю, что не нужно углубляться в те или иные процессы.

Речь идет не о том как правильно организовать поддержку, а о том стоит ли такой функционал включать в ТЗ и описывать (тем самым беря на себя ответственность за него) или его стоит искоренить (даже если это затратно). И если стоит оставить, то почему и какие профиты с этого можно поиметь.

Вообще говоря, все зависит от организации Вашего процесса разработки: если он подразумевает согласуемое с заказчиком ТЗ и последующую его неизменность (некий вариант водопадной модели). Вы можете рискнуть и сразу подписать контракт на поддержку. Но я бы этого делать не стал, так как риски изменений очень велики.
Однако, когда заказчик подписывает контракт на разработку, он понимает, что систему нужно будет поддерживать и стремится снизить свои издержки в отношении поддержки. НО! на самом деле издержки, связанные с поддержкой будут минимальны, когда снята неопределенность в отношении состава поддерживаемой системы. как минимум это означает, что контракт на поддержку должен подписываться в районе подписания акта приемки. да и для разработчика это выгоднее.
а представьте бывают ситуации, когда поддержка гарантировано будет осуществляться не разработчиком, а компанией, выбираемой на конкурсной основе. как тогда работала бы Ваша схема?

P.S. ну что ж раз Вы не хотите обсуждать организацию поддержки, то и я не буду на этом настаивать...

1. Сопровождение "левых" фич - это в любом случае дополнительные расходы ресурсов.
2. Вопрос не в его ценности, а в рисках попасть на доп расходы по его поддержки и доработки.

Дальше я тоже читал, прежде чем ответить...

Во-первых, вопрос в величине расходов. Сопровождать 100 фич или 102 - безразлично. Если заказывали 3, а сделали 10 - да, это беда. Но если эти 10 уложились в бюджет 3, то и сопровождение 10 уложится в бюджет 3 - это же чистая статистика, сопровождение везде тоже считают как проценты от разработки. Кроме того, дополнительные фичи можно не сопровождать и, особенно. не дорабатывать. Так что не понимаю опасений.

Речь идет не о том как правильно организовать поддержку, а о том стоит ли такой функционал включать в ТЗ и описывать (тем самым беря на себя ответственность за него) или его стоит искоренить (даже если это затратно). И если стоит оставить, то почему и какие профиты с этого можно поиметь.

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

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

Так же если функционал оставить но не включить в ТЗ, то как потом отслеживать "откуда оно появилось" ?

Ну, если при нажатии на кнопку система падает, то это не фича (в смысле - она не работает, то есть не сделана). Если падать стало в результате доработок системы, про фичу забыли - можно кнопку убрать.

А что касается как отслеживать - по-моему всегда есть внутренние, а не внешние доки на систему. Там и написать кратко "случайно сделали такую-то фичу, в ТЗ ее нет.

Ну предположим "фича" может падать когда параллельно с ней открыты одноклассники. А такую ситуацию не оттестируешь сразу (это утрированный пример). А всплывет это после внедрения и нужно будет потратить время, что бы эту ошибку локализовать.

Так может кнопку сразу убрать и не показывать заказчику вообще ?

Как правило эти внутренние инструкции очень плохо систематизированы. И найти в них что то непросто.

Вот! Не показывать! Этот вариант я привёл ещё на первой странице обсуждений

Вот! Не показывать! Этот вариант я привёл ещё на первой странице обсуждений

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

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

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

А прибивание спонтанного творчества - оно плохо сказывается на мотивации и моральном состоянии авторов этого творчества. Они же старались. Так что тут в обе стороны проблемы быть могут...

А прибивание спонтанного творчества - оно плохо сказывается на мотивации и моральном состоянии авторов этого творчества. Они же старались. Так что тут в обе стороны проблемы быть могут...

Ну да, творческая личность развлеклась от нечего делать, а остальные участники процесса (тестеры, документаторы, сопровождение) негры что-ли? А если так развлекся аналитик/архитектор/проектировщик, то вообще по башке надо давать - неграми становятся уже программеры. Если у кого-то избыток времени, то это не значит, что его избыток и у всех остальных. Так что с точки зрения внутрикомандной мотивации мотивации и морали это палка обоюдоострая.
Но воообще-то для полностью заказных продуктов мне кажется это все-таки надуманная ситуация. Для тиражных, полутиражных-полузаказных, внутренней автоматизации - да, такое бывает, но там не так страшно.