Приветствую всех аналитиков!
Возникла следующая ситуация - пишем ТЗ на разработку, в котором есть раздел и про гарантийное сопровождение. И в рамках гарантии хочется как-то умерить аппетит заказчика в части возможных будущих доработок Системы (крупная централизованная АС для работы филиалов заказчика). Был ли у кого-то подобный опыт и что можете посоветовать для выбора в качестве количественных ограничений для таких доработок?? Потребность в ограничениях продиктована прежде всего небольшой командой которая будет потом заниматься техподдержкой и они просто физически не смогут переписать всю систему (если вдруг такая хотелка возникнет).

Сопровождение и переписать — это разные вещи.

В гарантию обычно входят любые необходимые работы по обеспечению работоспособности в том виде, в котором она была заказана и принята.

Крутая у вас техподдержка, что ещё умеет и систему переписывать (как я понял, ей для этого не хватает только времени, но не квалификации).


Давайте различать работы:
1. По гарантийному сопровождению, чтобы система продолжала работать — тут можно оговорить по запросам/инцидентам:
а) время реакции — например, не позднее суток
б) время исправления проблемы — например, не позднее 3-х дней
в) количество часов на поддержку — например, 10 часов в месяц
Эта работа может входить в договор на разработку, внедрение и поддержку системы.

2. Доработке и развитию системы — это лучше делать отдельным договором, услугой, что там меряем:
а) количество часов в месяц, которое вы можете выделить на доработки — например, 40.
б) стоимость этих доработок в час, например, 30$

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

Также важный момент — классификация инцидентов по сложности.

Браться разрешать любые инциденты за 3 дня — это слишком рискованно.
Лучше ввести 3-5 уровней критичности инцидентов и для них дать разные сроки.
А ещё лучше — добавить проценты.
Например, «Инциденты уровня 3 должны исправляться в течение 7 дней в 95% случаев». Это означает, что если один из 20 инцидентов такого типа окажется очень заковыристым, вы сможете его исправлять и дольше и формально выполнить условия соглашения, без штрафов.

Разумного CIO такой подход должен устроить.

А лучше нанять нормального спеца, который может организовать сопровождение и утрясти все проблемы как внутри команды, так и с Заказчиком. Слишком много  подводных камней, что бы "удовлетворять". Каждый участник будет тянуть одеяло на себя и надо быть жестким переговорщиком, что понять где можно уступить, а где нельзя.

Денис, спасибо большое за развернутый ответ и Ваши советы!
Да, скорее всего, все что не уложиться в определение гарантии (в т.ч. большие трудоемкие доработки), менеджмент постарается вынести в отдельный контракт.
Получается, что меня как раз интересуют возможные виды "классификации инцидентов" (в вашей формулировке), т.е. по каким критериям можно как раз разграничить эти 3-5 уровней их критичности.
Например, что пришло мне на ум:
1) Как раз разграничить по трудоемкости работ, разумеется по оценке исполнителя, а не заказчика (в вашей формулировке = стоимости доработок).
2) Приоритетности доработок для заказчика, например, высокоприоритетные и высокотрудоемкие не более Х, высокоприоритетные и низкотрудоемкие не более У, низкоприоритетные и высокотрудоемкие не более К и т.д.
3) Трудоемкость доработки определять исходя из количества дорабатываемых подсистем.

Может есть еще какие-то критерии?

Elf боюсь, что когда заказчик выкатит список и скажет все срочное и все важное, то уже никакой переговорщик не сможет помочь, а так хоть будут какие-то контрактные условия/ограничения. В целом же согласен, подводных камней очень много и предусмотреть все заранее практически невозможно, но тех камней о которых мы уже знаем, все-таки хочется заранее избежать

Получается, что меня как раз интересуют возможные виды "классификации инцидентов" (в вашей формулировке), т.е. по каким критериям можно как раз разграничить эти 3-5 уровней их критичности.
Например, что пришло мне на ум:
1) Как раз разграничить по трудоемкости работ, разумеется по оценке исполнителя, а не заказчика (в вашей формулировке = стоимости доработок).
2) Приоритетности доработок для заказчика, например, высокоприоритетные и высокотрудоемкие не более Х, высокоприоритетные и низкотрудоемкие не более У, низкоприоритетные и высокотрудоемкие не более К и т.д.
3) Трудоемкость доработки определять исходя из количества дорабатываемых подсистем.

Может есть еще какие-то критерии?

Вы с самого начала говорите о рамках гарантии. На гарантийное сопровождение нужен один контракт (у вас же гарантия не бессрочная?), на послегарантийное обслуживание (поддержку) - другой.

Гарантия обычно даётся на то, что система будет работать в рамках, заданных ТЗ, а если не работает, то исполнитель обязуется сделать так, что она заработает.
Изменения нужно делить на ошибки (неправильно работающая функциональность) и доработки (новая функциональность). Новые функции - новые деньги.

Есть ещё такое волшебное слово - SLA
Вот здесь (последний пост) есть типичная классификация проблем по сложности, а также примеры времени реакции на проблемы:
http://www.itsmonline.ru/community/viewtopic.php?t=37

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

Есть ещё такое волшебное слово - SLA
Вот здесь (последний пост) есть типичная классификация проблем по сложности, а также примеры времени реакции на проблемы:
http://www.itsmonline.ru/community/viewtopic.php?t=37

Григорий, спасибо за наводку

Да, должно пригодится.

Вы с самого начала говорите о рамках гарантии. На гарантийное сопровождение нужен один контракт (у вас же гарантия не бессрочная?), на послегарантийное обслуживание (поддержку) - другой.

Гарантия обычно даётся на то, что система будет работать в рамках, заданных ТЗ, а если не работает, то исполнитель обязуется сделать так, что она заработает.
Изменения нужно делить на ошибки (неправильно работающая функциональность) и доработки (новая функциональность). Новые функции - новые деньги.

Есть ещё такое волшебное слово - SLA
Вот здесь (последний пост) есть типичная классификация проблем по сложности, а также примеры времени реакции на проблемы:
http://www.itsmonline.ru/community/viewtopic.php?t=37

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

что то не открывается страница с классификацией....

что то не открывается страница с классификацией....

Странно, у меня открывается. Вот цитата оттуда:

Уровни сложности
Сложность запроса определеяет, насколько серьезна проблема и как данный инцидент должен быть приоритезирован. Сложность инцидентов будет классифицированна в соответствии с следующими определениями:

Сложность 1 “Критичная”
Когда данный инцидент останавливает критически важные бизнес процессы заказчика и обходной путь не доступен, то такой кейс должен быть приоритезирован выше остальных и работы должны начаться немедленно.
Например: База данных недоступна, не работают алгоритмы закрытия периодов в финансовых системах и т.д.

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

Сложность 3 “Средняя ”
Когда приложение вызывает ошибку, которая уменьшает, но не запрещает доступ пользователям. Т.е. пользователи могут работать, но нуждаются в поддержке и помощи.
Например: Небольшие ошибки, которые имеют небольшое влияние на пользователей.

Сложность 4 “Низкая”
Когда инцидент по сути является заявкой на изменение. Т.е. запрашиваемой функциональности в системе раньше не было. Такой кейс должен быть занесен в систему с низким приоритетом.