В чем разница техподдержки и сопровождения заказного ПО? Есть ли где-то формальная граница?

A>В чем разница техподдержки и сопровождения заказного ПО? Есть ли где-то формальная граница?

ну в моем понимании:

техподдержка — это ответы на разные вопросы, которые могут быть неточно или вообще не описаны в документации, разьяснение каких-нть хитростей использования, прием багов (если это специально не оговорено, то без гарантий и сроков их исправления)

сопровождение — это фикс багов с различной скоростью в зависимости от критичности, мелкие изменения и доработки, возможно даже добавление новой функциональности

Здравствуйте, Banch, Вы писали:

B>сопровождение — это фикс багов с различной скоростью в зависимости от критичности, мелкие изменения и доработки, возможно даже добавление новой функциональности

Интересен аспект добавления новой функциональности...
1. Если это в рамках ТЗ первоначальной системы, то сущестует опасность, что заказчик через время намекнет! на недоработанность первоначального релиза.
2. Как только "добавление новой функциональности" выходит за рамки ТЗ первоначальной системы, как формально определить границу: это мы делаем в сопровождении, а это уже новая работа?
3. (расширение п.2)Усовершенствование добавленных новых функций может вырасти...

естестьвенно в большом проекте всегда найдеться что доделывать, переделывать, создавать новое и т.д.
но все это должно быть описано в договоре — в каком объеме осуществляется сопровождение, сколько времени и за какие деньги

Здравствуйте, Banch, Вы писали:

B>сопровождение — это фикс багов с различной скоростью в зависимости от критичности, мелкие изменения и доработки, возможно даже добавление новой функциональности

Не совсем.
Сопровождение обычно применимо к системам, изменения в которых делаются не от прихоти заказчика, а, скорее, от прихоти государства. Пример — бухгалтерские, таможенные, налоговые системы, базы законов типа К+.
Также иногда под сопровождением имеется ввиду договор о внесении доработок в систему с какими-то условиями (спец. цены, объем в ч/ч). То есть разрабатывается система — написано ТЗ, но в последствии всплывает, что еще-бы "nice to have" иметь какой-то функционал, либо известно, что какой-то алгоритм будет в будущем меняться/добавляться, т.к. "наверху" еще не решили, а делать надо уже. Вот в этом случае после сдачи системы и подписывается договор о сопровождении, который обязует исполнителя доработать по требованию заказчика функционал системы. Заказчик-же обязуется не привлекать на эту работу 3-е лицо без согласия непосредственного исполнителя. Вот так вот

Здравствуйте, Pavel_Lechenko, Вы писали:

P_L>Также иногда под сопровождением имеется ввиду договор о внесении доработок в систему с какими-то условиями (спец. цены, объем в ч/ч). То есть разрабатывается система — написано ТЗ, но в последствии всплывает, что еще-бы "nice to have" иметь какой-то функционал, либо известно, что какой-то алгоритм будет в будущем меняться/добавляться, т.к. "наверху" еще не решили, а делать надо уже. Вот в этом случае после сдачи системы и подписывается договор о сопровождении, который обязует исполнителя доработать по требованию заказчика функционал системы. Заказчик-же обязуется не привлекать на эту работу 3-е лицо без согласия непосредственного исполнителя. Вот так вот
Вопрос в объемах доработок. Вы имеете в виду договор с нефиксированным объемом работ, типа договора о намерениях? В словах "обязуется по требованию" не фригурирует временной параметр. Если в стандартном договоре фиксируются цена, объемы и сроки, то в сопровождении цена фиксированы, а объемы не фиксированы.

Здравствуйте, amenhatep, Вы писали:

A>Здравствуйте, Pavel_Lechenko, Вы писали:

P_L>>Также иногда под сопровождением имеется ввиду договор о внесении доработок в систему с какими-то условиями (спец. цены, объем в ч/ч). То есть разрабатывается система — написано ТЗ, но в последствии всплывает, что еще-бы "nice to have" иметь какой-то функционал, либо известно, что какой-то алгоритм будет в будущем меняться/добавляться, т.к. "наверху" еще не решили, а делать надо уже. Вот в этом случае после сдачи системы и подписывается договор о сопровождении, который обязует исполнителя доработать по требованию заказчика функционал системы. Заказчик-же обязуется не привлекать на эту работу 3-е лицо без согласия непосредственного исполнителя. Вот так вот
A>Вопрос в объемах доработок. Вы имеете в виду договор с нефиксированным объемом работ, типа договора о намерениях? В словах "обязуется по требованию" не фригурирует временной параметр. Если в стандартном договоре фиксируются цена, объемы и сроки, то

Имеем типичный SLA (Service Level Agreement) договор, т.е. договор о предоставлении сервиса. Временной параметр в нем тоже фигурирует. Это временной интервал на протяжении которого предоставляется сервис, время реакции на запросы заказчика (анализа сложности и исправления ошибок/добавления функционала) и допустимый бюжет на выполнение запроса.
В нем обязательно фиксируются след вещи:
Время действия договора — от dd/mm/yy1 до dd/mm/yy2.
Стоимось сервиса — XX$/человеко-час.
Обьем услуг — от XXX часов (мин обьем услуг, которые должен заказать заказчик) до YYY часов (максимальное к-во ресурсов, которое должен предоставить исполнитель).
Условия сервиса:

Тип(сложность): время анализа / время исполнения / бюджет на исполнение 1 запроса
Косметические исправления: 1 день / 2 дня / 1 час
Изменения/новый фуккционал без изменения существующих алгоритмов: 1 день / 3 дня / 4 часа
--//-- с изменением(реализацией новых) алгоритмов: 3 дня / 1 неделя / 20 часов
....
--//-- требующие существенных изменений архитектуры: 1 неделя / в рамках отдельного договора

(цыфры, естественно, почти от фонаря)

A>в сопровождении цена фиксированы, а объемы не фиксированы.

Хотелось бы получить оценку анализа разницы subj.
После некоторых размышлений и анализа сообщений, пришел к следующему выводу:
Критерием разницы subj является наличие в результате (обязательных) модификаций в системе.
Например, Microsoft берет на себя обязательства техподдержки, но это не связано с модификацией системы. Модификация системы происходит по их доброму желанию и определяется их стратегией на рынке.

Объем работ по техподдержке (спасибо, Banch):
консультации и ответы на вопросы, которые могут быть не полно или вообще не описаны в документации или касаются "особенностей использования системы". Прием замечаний и предложений.

Из сообщения Pavel_Lechenko следует, что по источнику объема сопровождения может быть два варианта:
1)Заказчик или потребитель.
2)Третьей стороной, например, государством.

Минимальный размер рабочей группы исполнителя определяется:
1) в случае техподдержки — потребностями заказчика или потребителей.
2) в случае сопровождение — размерами системы, т.е. минимальным размером рабочей группы по разработке.

Техподдержка может базироваться на SLA (Service Level Agreement) договоре, спасибо Candle645, т.к. может быть легко оценена обоими сторонами по соответствующим артефактам внешней деятельности, т.е. вся работа осуществляется в контакте исполнитель-заказчик или разработчик-потребитель.

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

Поэтому в сопровождении возможно Service Level Agreement (было бы не плохо посмотреть пример русской реализации подобного договора) или итеративно: 1)собрали замечания и предложения; 2)спроектировали, реализовали, протестировали; 3)сдали, внедрили.

Здравствуйте, amenhatep, Вы писали:

A>Хотелось бы получить оценку анализа разницы subj.

В общем Banch уже все достаточно четко описал.

A>После некоторых размышлений и анализа сообщений, пришел к следующему выводу:
A> Критерием разницы subj является наличие в результате (обязательных) модификаций в системе.

A>Объем работ по техподдержке (спасибо, Banch):
A>консультации и ответы на вопросы, которые могут быть не полно или вообще не описаны в документации или касаются "особенностей использования системы". Прием замечаний и предложений.

Поддержка (Support) это:
— регистрация проблем, о которых сообщает клиент (скорее end-user, чем заказчик)
— помощь в решении уже известных проблем (напр. из FAQ).
— в случае необходимости — анализ того что поддерживается с целью рекоммендовать walkarounds, которые решат проблеммы клиента
Если в двух словах, то Поддержка — это решение тех проблем клиента, которые решаются без изменений в уже существующем решении (в часности софте).

Сопровождение (maintenance) — это изменение уже существующего решения для его соответствия новым пожеланиям заказчика.

A>Минимальный размер рабочей группы исполнителя определяется:
A>1) в случае техподдержки — потребностями заказчика или потребителей.

Да, если подразумевать потребностями заказчика в самом широком смысле.
A>2) в случае сопровождение — размерами системы, т.е. минимальным размером рабочей группы по разработке.

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

A>Техподдержка может базироваться на SLA (Service Level Agreement) договоре, спасибо Candle645, т.к. может быть легко оценена обоими сторонами по соответствующим артефактам внешней деятельности, т.е. вся работа осуществляется в контакте исполнитель-заказчик или разработчик-потребитель.

Как правило — НЕТ
Пример — некоторые ведущие Internet Providers оутсорцят службу Castomer Care на внешние Call Centers и платят отнюдь не за количество звонков на которые поступили в Call Center а за то, что в течении определенного промежутка времени их клиентам помогают решать некоторые из их проблем.

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

Трудозатраты всегда являются внутренним делом фирмы-разработчика. И он решает, какие запросы заказчика исполнябтся в нормальном режиме (XXX часоа на запрос), а какие попадают в категорию "требующие существенных изменений архитектуры: 1 неделя / в рамках отдельного договора"

A>Поэтому в сопровождении возможно Service Level Agreement (было бы не плохо посмотреть пример русской реализации подобного договора) или итеративно: 1)собрали замечания и предложения; 2)спроектировали, реализовали, протестировали; 3)сдали, внедрили.

Здравствуйте, Candle645, Вы писали:

C>Здравствуйте, amenhatep, Вы писали:

C>Поддержка (Support) это:
C>- регистрация проблем, о которых сообщает клиент (скорее end-user, чем заказчик)
C>- помощь в решении уже известных проблем (напр. из FAQ).
C>- в случае необходимости — анализ того, что поддерживается с целью рекомендовать walkarounds, которые решат проблемы клиента
C>Если в двух словах, то Поддержка — это решение тех проблем клиента, которые решаются без изменений в уже существующем решении (в частности софте).


C>Сопровождение (maintenance) — это изменение уже существующего решения для его соответствия новым пожеланиям заказчика.

Лаконичное определение. Правда, определение не включает описание того, входит ли в это исправление неполадок и где граница перехода сопровождения в разработку новой системы (типа, в рамках существующей архитектуры системы).

A>>Минимальный размер рабочей группы исполнителя определяется:
A>>1) в случае техподдержки — потребностями заказчика или потребителей.

C>Да, если подразумевать потребностями заказчика в самом широком смысле.
Какое здесь возможно исключение?
A>>2) в случае сопровождение — размерами системы, т.е. минимальным размером рабочей группы по разработке.

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

Безусловно — объемом изменений. Однако, если изменяемая часть системы имеет зависимости с другими частями, то это потребует общее тестирование или расширенную модификацию. Таким утверждением нет, Вы исключаете критерий разницы между сопровождением и поддержкой. Критерий основан на том, что для комплексной системы может быть минимально один консультант, а при минимальной модификации: менеджер, архитектор, программист, тестер и т.п., пусть даже они не будут полностью заняты этой задачей.

A>>Техподдержка может базироваться на SLA (Service Level Agreement) договоре, спасибо Candle645, т.к. может быть легко оценена обеими сторонами по соответствующим артефактам внешней деятельности, т.е. вся работа осуществляется в контакте исполнитель-заказчик или разработчик-потребитель.

C>Как правило — НЕТ
C>Пример — некоторые ведущие Internet Providers оутсорcят службу Castomer Care на внешние Call Centers и платят отнюдь не за количество звонков на которые поступили в Call Center а за то, что в течении определенного промежутка времени их клиентам помогают решать некоторые из их проблем.

Время не достаточный критерий для оценки капиталоемкости на поддержку. Я удивлен, узнав, что оплата Call Centers осуществляется повременная. Полагаю, что оценка идет усредненная на базе уже сформированной статистики самого центра или на момент передачи сервиса от Заказчика. Т.е. сама оценка сервиса произошла завуалировано.
Кроме этого, Соглашение об уровне обслуживания оценивается, в основном, как соглашение о качестве предоставляемого сервиса.