Необходимо мне заключить договор на поддержку с одной софтверной конторой, которая для нас написала софт. Хочу вставить в договор немного от SLA... Понимаю, что ни один разработчик не подпишется под требованием решить критичный вопрос в срок один-два-три часа, т.к. задача может оказаться труднорешаемой. Но и вы меня поймите, заключая договор на поддержку не хочется, чтобы компания откровенно клала на нас, когда у нас будут проблемы (а в итоге виноват буду я).
Так вот, как можно решить эту неразрешимость? Ведь наверняка заключали похожие договора. Мне желательно именно договора, где ответственность разработчика больше прописана, т.к. здесь я выступаю со стороны пользователей.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Коллеги, приветствую!
N_C>Необходимо мне заключить договор на поддержку с одной софтверной конторой, которая для нас написала софт. Хочу вставить в договор немного от SLA... Понимаю, что ни один разработчик не подпишется под требованием решить критичный вопрос в срок один-два-три часа, т.к. задача может оказаться труднорешаемой. Но и вы меня поймите, заключая договор на поддержку не хочется, чтобы компания откровенно клала на нас, когда у нас будут проблемы (а в итоге виноват буду я).
N_C>Так вот, как можно решить эту неразрешимость? Ведь наверняка заключали похожие договора. Мне желательно именно договора, где ответственность разработчика больше прописана, т.к. здесь я выступаю со стороны пользователей.
N_C>С уважением, N_C> Николай
Обычно требуют образец стандартного SLA от компании, оказывающей поддержку. Поймите, если в компании не установлены и не работают процессы, обеспечивающие ваши требования, то в случае проблем на вашей стороне, их сторона измениться в один день физически не сможет. И как со своим уставом нет нужды лезть в чужой монастырь, ваш текст договора — только повод для будущих ссор и судебных разборок. А оно вам надо?
Короче, вам нужно не красивую фразу где-то выкрать, и зашить в договор мелким текстом, а сесть за стол переговоров, и по душам обсудить этот вопрос с вашим вендором. При чем, порядок дня этого митинга предложите свой, а слово дайте им первым.
Вы и ваша компания безусловно останетесь в выигрыше при таком подходе.
Удачи Вам!
Д>Обычно требуют образец стандартного SLA от компании, оказывающей поддержку.
Не... Там есть SLA. Они нам его прислали. Но он стандартный — время реакции на проблему. А время реакции — это время регистрации проблемы. И все. Мне нужно быть уверенным, что если у нас система встала, то люди работают над проблемой, а не филонят. А подозрения такие есть. Вот я и думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать контрагента на решение проблемы. Может пеню за каждый час простоя? Как обычно решают эту задачку?
Nikolay_Ch пишет: > Не... Там есть SLA. Они нам его прислали. Но он стандартный — время > реакции на проблему. А время реакции — это время регистрации проблемы. И > все. Мне нужно быть уверенным, что если у нас система встала, то люди > работают над проблемой, а не филонят. А подозрения такие есть. Вот я и > думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать > контрагента на решение проблемы. Может пеню за каждый час простоя? Как > обычно решают эту задачку?
Эту задачу обычно решают надеждой вашего поставщика на долговременное и
прибыльное для него сотрудничество (не обязательно только с вами,
возможно он рассчитывает на референс). Если они подпишут договор с
"пеней за каждый час простоя" (простоя чего, кстати?) — это практически
на 100% указание на то, что они не придают договору никакого значения
вообще.
Если есть подозрения — озвучьте их своему начальству, поищите альтернативы.
Здравствуйте, Nikolay_Ch, Вы писали:
Д>>Обычно требуют образец стандартного SLA от компании, оказывающей поддержку. N_C>Не... Там есть SLA. Они нам его прислали. Но он стандартный — время реакции на проблему. А время реакции — это время регистрации проблемы. И все. Мне нужно быть уверенным, что если у нас система встала, то люди работают над проблемой, а не филонят. А подозрения такие есть. Вот я и думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать контрагента на решение проблемы. Может пеню за каждый час простоя? Как обычно решают эту задачку?
1) присваиваете _приоритет_ вопросу.
2) его можно изменить с обоих сторон. бывают конфликты.
3) в зависимости от приоритера — время реакции и фикса.
4) в зависимости от времени фикса (или просрочки!) — деньги.
2.1) приоритет может быть изменен любой стороной. вы считаете, что проблема важная, и должна быть решена сейчас. мы считаем, что проблема яйца выеденного не стоит, и может быть решена через неделю. ставьте свое время, и спрашивайте. мы поставим свое, и ответим.
если через неделю(!) проблема не будет решена, вы штрафуете нас по _нашим_ оценкам.
если вы напряжетесь, и позвоните пм-у, и он _с_нашей_ стороны подтвердит, что приоритет высокий — будете штрафовать завтра.
а есть еще градация сложности.
типа:
приоритет — высокий, сложность — высокая. время на фикс — 3 дня.
приоритет — высокий, сложность — низкая. время на фикс — 3 часа.
приоритет — средний, сложность — высокая. время на фикс — неделя.
приоритет — низкий, сложность — высокая. время на фикс — не определено!
в таком раскладе приоритет ставите вы, а сложность — мы. у нас все будут — суперсложные изначально.
как решать — ...ну я знаю путь, но как разработчик — не скажу.
Здравствуйте, hrensgory, Вы писали:
H>... Если они подпишут договор с H>"пеней за каждый час простоя" (простоя чего, кстати?) — это практически H>на 100% указание на то, что они не придают договору никакого значения вообще.
Простоя системы... Т.е. время, пока система не работает — но это аварийная ситуация и она самая критичная. А почему не придают? Ведь это живые деньги уходят от них?
H>Если есть подозрения — озвучьте их своему начальству, поищите альтернативы.
Позиция руководства — ответственность твоя, тебе и решать.
Nikolay_Ch пишет:
> Простоя системы... Т.е. время, пока система не работает — но это > аварийная ситуация и она самая критичная. А почему не придают? Ведь это > живые деньги уходят от них?
Я имел в виду что они не заплатят при любом развитии событий. По крайней
мере никогда не слышал о компании, которая бы выполнила подобные
обязательства. Почитайте EULA на любой софт — предоставляется as is,
производитель ответственности не несёт.
К тому же, возможно я не до конца понимаю вашу ситуацию, но что значит
"система не работает"? Вообще не работает, BSOD? Кто это зафиксирует,
ведь в этом случае видимо потребуется видимо и согласие разработчика с
этим суждением.
> H>Если есть подозрения — озвучьте их своему начальству, поищите > альтернативы. > Позиция руководства — ответственность твоя, тебе и решать.
А альтернатив никаких нету? В смысле в другом месте саппорт заказать.
Здравствуйте, hrensgory, Вы писали:
H>А альтернатив никаких нету? В смысле в другом месте саппорт заказать.
вот-вот... вот... ВОТ!!!! вот она, золотая идея.
call-цент + скользящий график для толпы студентов.
и все. мировое доминирование индии на рынке саппорта будет сломлено.
бизнес-схему и образец договора обсудили выше. во
bastrakov пишет: > Здравствуйте, hrensgory, Вы писали: > > H>А альтернатив никаких нету? В смысле в другом месте саппорт заказать. > > вот-вот... вот... ВОТ!!!! вот она, золотая идея. > call-цент + скользящий график для толпы студентов.
В форуме про работу недавно было какое-то предложение в саппорт за 3000
руб./мес сутки через двое. Так что похоже индусы уже трепещут.
Здравствуйте, hrensgory, Вы писали:
H>Я имел в виду что они не заплатят при любом развитии событий. По крайней H>мере никогда не слышал о компании, которая бы выполнила подобные H>обязательства. Почитайте EULA на любой софт — предоставляется as is, H>производитель ответственности не несёт.
Речь идет о разработке заказного софта, от которого зависят наши БП. Никто не собирается возмещать убытки, понесенные бизнесом, но должно быть какое-то условие, которое заставит разработчика бегать в случае, когда его софт банально лежит.
H>К тому же, возможно я не до конца понимаю вашу ситуацию, но что значит H>"система не работает"? Вообще не работает, BSOD? Кто это зафиксирует, H>ведь в этом случае видимо потребуется видимо и согласие разработчика с H>этим суждением.
Да, вообще не работает. Т.е. мы, например иконку щелкаем, а в ответ — "пошел нафих"...
>> H>Если есть подозрения — озвучьте их своему начальству, поищите >> альтернативы. >> Позиция руководства — ответственность твоя, тебе и решать. H>А альтернатив никаких нету? В смысле в другом месте саппорт заказать.
Альтернативы всегда есть. Меня в этом плане больше интересует именно какое условие заложить в договор. Бить то в случае простоя будут меня в первую очередь.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>.... но должно быть какое-то условие, которое заставит разработчика бегать в случае, когда его софт банально лежит. N_C>Да, вообще не работает. Т.е. мы, например иконку щелкаем, а в ответ — "пошел нафих"... N_C>Меня в этом плане больше интересует именно какое условие заложить в договор. Бить то в случае простоя будут меня в первую очередь.
Хочешь изобрести велосипед? Ей-ей, не стоит..... ГОСТы не зря писаны.
Здесь не "условие в договор" надо закладывать, а — адекватно организовать процесс разработки со стороны заказчика. Например:
1. разбить работу на этапы. Один из этапов — предварительные испытания этого самого заказного софта, причем с обязательным участием представителя заказчика (не путать с ПЗ ). Программу и методику разрабатывает исполнитель, согласовывает заказчик (то бишь вы). Протокол этих испытаний утверждается с двух сторон.
2. при удовлетворительных результатах испытаний начинается следующий этап — тестовая эксплуатация на вашей площадке, например, в течение месяца (ну или сколько там надо из разумных соображений). Если при этом выявляются блокирующие работу баги, то переходим к п.1, если некритичные — исполнитель их исправляет в рабочем порядке.
3. при удовлетворительных результатах тестовой эксплуатации и закрытых некритичных багах — актируете (с двух сторон) результаты тестовой эксплуатации и переходите к приемосдаточным испытаниям. Программа и методика ПСИ — тоже разрабатываются исполнителем и согласовываются вами.
4. по результатам ПСИ принимаете решение.... Если все более-менее удовлетворительно — принимаете ПО в боевую эксплуатацию.
Такая методика в некоторой степени гарантирует от варианта, "когда его софт банально лежит". Где-то так.
По удовлетворительному результату п.1 платите исполнителю аванс — в размере порядка 30%. А окончательный расчет — только по результату п.4.
Nikolay_Ch пишет: > > H>К тому же, возможно я не до конца понимаю вашу ситуацию, но что значит > H>"система не работает"? Вообще не работает, BSOD? Кто это зафиксирует, > H>ведь в этом случае видимо потребуется видимо и согласие разработчика с > H>этим суждением. > Да, вообще не работает. Т.е. мы, например иконку щелкаем, а в ответ — > "пошел нафих"...
Абстрагируемся от того факта, что "пошёл..." может вызываться не
обязательно ПО, а к примеру недоступностью БД, сетевыми проблемами или
(если это декстопное приложение) совместимостью с многочисленными
версиями Windows, Office и т.п.
Интересно другое — а с БП вашими при этом что будет, стоять будут?
Допустим разработчик "забегал", но ПО по-прежнему не работает. Ваша
физическая безопасность, как наиболее досягаемого, может оказаться под
угрозой
Тут уже посоветовали — проведите тестовую эксплуатацию, приёмо-сдаточные
испытания. По итогам решайте.
--
WBR,
Serge.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Коллеги, приветствую!
N_C>Необходимо мне заключить договор на поддержку с одной софтверной конторой, которая для нас написала софт. Хочу вставить в договор немного от SLA... Понимаю, что ни один разработчик не подпишется под требованием решить критичный вопрос в срок один-два-три часа, т.к. задача может оказаться труднорешаемой. Но и вы меня поймите, заключая договор на поддержку не хочется, чтобы компания откровенно клала на нас, когда у нас будут проблемы (а в итоге виноват буду я).
N_C>Так вот, как можно решить эту неразрешимость? Ведь наверняка заключали похожие договора. Мне желательно именно договора, где ответственность разработчика больше прописана, т.к. здесь я выступаю со стороны пользователей.
Оговаривается только гарантированное время реакции на проблему в зависимости от критичности (обычно 24 часа для критических проблем), что вы выделяете специалиста на нее, но не то, что она обязательно будет решена. Плюс, конечно, даются точные определения критичных и прочих проблем.
Это максимум, что можно требовать. Да, кроме того, такое условие вообще-то принято отдельно оплачивать по фиксированному тарифу, не зависящему от объема работы и деФектов. Это примерно как страховая медицина.
V_S>Хочешь изобрести велосипед? Ей-ей, не стоит..... ГОСТы не зря писаны.
ГОСТ на сопровождение? Это какой? У меня фаза разработки и приемки закончилась — теперь поддержка.
H>Абстрагируемся от того факта, что "пошёл..." может вызываться не H>обязательно ПО, а к примеру недоступностью БД, сетевыми проблемами или H>(если это декстопное приложение) совместимостью с многочисленными H>версиями Windows, Office и т.п.
Нам поставщик поставил сервер и ПО — вот пусть он и решает эти проблемы.
H>Тут уже посоветовали — проведите тестовую эксплуатацию, приёмо-сдаточные H>испытания. По итогам решайте.
это поддержка — все, что Вы описали уже в прошлом.
G>Это максимум, что можно требовать. Да, кроме того, такое условие вообще-то принято отдельно оплачивать по фиксированному тарифу, не зависящему от объема работы и деФектов. Это примерно как страховая медицина.
Не вопрос — оплатим. Просто мне надо быть уверенным, что поставщик не начнет динамить с исправлением ошибки. Сейчас у него эта тенденция наблюдается. Думаю, что вставим в договор пеню за реализацию задач (от момента постановки, до момента передачи (или до момента приемки) исправления заказчику) и на этом завершим.
Здравствуйте, Nikolay_Ch, Вы писали:
G>>Это максимум, что можно требовать. Да, кроме того, такое условие вообще-то принято отдельно оплачивать по фиксированному тарифу, не зависящему от объема работы и деФектов. Это примерно как страховая медицина. N_C>Не вопрос — оплатим. Просто мне надо быть уверенным, что поставщик не начнет динамить с исправлением ошибки. Сейчас у него эта тенденция наблюдается. Думаю, что вставим в договор пеню за реализацию задач (от момента постановки, до момента передачи (или до момента приемки) исправления заказчику) и на этом завершим.
Пеня за превышение сроков не очень хороша на мой взгляд, так как штрафует также за чрезмерно оптимистические оценки сроков (если их дает Исполнитель, и они утверждаются Заказчиком), или за ошибку оценки сроков Заказчиком (если их делает Заказчик — на такое ни один исполнитель не пойдет в здравом уме, кстати), или за возникшие по ходу работ непредвиденные обстоятельства (риски).
Если речь идет о дефектах — то и само их появление, и проблемы их исправления (сроки которого непредсказуемы по природе), — сплошные непредвиденный обстоятельства. Я не понимаю, как можно требовать сроков их разрешения, и брать за их превышения пени. Можно требовать _реакции_ на проблемы, но _гарантий_ их исправления в детерминированный срок вам никто не даст (разве что идиот, который ничего не соображает).
Я, как Заказчик, вообще не пользуюсь пенями за срыв сроков (сейчас я выступаю также со стороны Заказчика, мы активно субподрядим), ибо считаю их скорее вредными, чем полезными, в силу выше перечисленного, плюс — еще и социальный аспект этих пень — люди не начинают быстрее думать когда их наказывают, зато стремятся избежать наказания и вас обмануть. Возможно, это имело бы смысл, если есть жесткий внешний дедлайн для Заказчика, перейдя который он сам начнет терять деньги и штрафоваться. Но все равно, пени — не решение проблемы, это лекарство симптома. Решение проблемы — нормальный Исполнитель, и нормальные отношения с ним, чему пени не способствуют.
V_S>1. разбить работу на этапы. Один из этапов — предварительные испытания этого самого заказного софта, причем с обязательным участием представителя заказчика (не путать с ПЗ ).
Это почему же "не путать"? Великие и страшные ПЗ именно для этого и существуют
H>>Тут уже посоветовали — проведите тестовую эксплуатацию, приёмо-сдаточные H>>испытания. По итогам решайте. N_C>это поддержка — все, что Вы описали уже в прошлом.
А подозрения такие есть. Вот я и думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать контрагента на решение проблемы. Может пеню за каждый час простоя? Как обычно решают эту задачку?
вот она, золотая идея. 
во
