Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - rusandy

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

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

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

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

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

Страницы: 1