Ситуация примерно следующая:
Есть проект с кучей производственных серверов, когда на сервере, что-нибудь случается заказчик, естественно звонит, так как своего нормального саппорта у него нету. Надо ему это как-то выставить в щет.
На данный момент схема примерно следующая:
Есть пул людей, которые готовы отвечать на звонки в любое время. Человек получает x за готовность это делать, независимо от наличия звонков + y за каждый звонок + время, потраченное на этот звонок, естественно, оплачивается как овертайм.
На данный момент схема довольно грубая, хотелось бы сделать шкалу прогрессивной, дабы заказчик задумался прежде чем будить людей по ночам.
Если у кого-то есть опыт подобной работы, либо какие-нибудь полезные ссылки буду крайне благодарен.
Здравствуйте, DLF, Вы писали:
DLF>На данный момент схема довольно грубая, хотелось бы сделать шкалу прогрессивной, дабы заказчик задумался прежде чем будить людей по ночам.
Тут так же стоит думать и со стороны заказчика. Если shit happens каждую неделю и по вине девелоперов, то почему заказчик должен ещё за это приплачивать. Так как цель "заставить заказчика десять раз подумать", то вероятно на то были причины "часто, звонит, народ подустал", что на самом деле только является следсвием, например, плохо поставленного процесса, недостаточного тестирования и т.д.
Поэтому для начала стоит найти первопричину и постаратся устранить. Я вот сейчас тоже на 24х7, но за пол года было всего пару звонков вечером проконсультироваться. Хотя люди, которые делали проект до меня, ездили ночами в офис довольно регулярно.
Второе что стоит сделать, это определится с приоритетами. По каким случаям заказчик может звонить, по каким он ждет утра.
Если, например, часть суппорта это объяснять юзверям по ночам где находится anykey, то стоит задуматся о создании суппорта в других часовых поясах. Собственно — нанять и натаскать индуса. Пусть дежурит пока вы спите.
Есть ещё такой момент как распределение проблем, на девелоперские, админиские и пр. Дабы изыскать способа уменьшения их количества.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, DLF, Вы писали:
DLF>>На данный момент схема довольно грубая, хотелось бы сделать шкалу прогрессивной, дабы заказчик задумался прежде чем будить людей по ночам. B>Тут так же стоит думать и со стороны заказчика. Если shit happens каждую неделю и по вине девелоперов, то почему заказчик должен ещё за это приплачивать. Так как цель "заставить заказчика десять раз подумать", то вероятно на то были причины "часто, звонит, народ подустал", что на самом деле только является следсвием, например, плохо поставленного процесса, недостаточного тестирования и т.д. B>Поэтому для начала стоит найти первопричину и постаратся устранить. Я вот сейчас тоже на 24х7, но за пол года было всего пару звонков вечером проконсультироваться. Хотя люди, которые делали проект до меня, ездили ночами в офис довольно регулярно.
B>Второе что стоит сделать, это определится с приоритетами. По каким случаям заказчик может звонить, по каким он ждет утра. B>Если, например, часть суппорта это объяснять юзверям по ночам где находится anykey, то стоит задуматся о создании суппорта в других часовых поясах. Собственно — нанять и натаскать индуса. Пусть дежурит пока вы спите.
B>Есть ещё такой момент как распределение проблем, на девелоперские, админиские и пр. Дабы изыскать способа уменьшения их количества.
Все это классно и понятно, процессы как раз я сейчас и настраиваю, но как показывает практика проекты бывают разные и при выходе на определенный уровень без сапорта не обойтись. Пример? Пожалуйста — сегодня накрылся "flash module" на одном из серваков а там хранятся некоторые настройки и т.д. в общем-то устранимо, но заказчик сам не сможет. На выходных — место на венике закончилась, оказалось, что при поставке сервака неправильно разбили веник, и вместо 500 G один partition оказался 50 G. [А разбивал harware supplier] В основном вопросы конечно админские, но легче от этого знания не становится... =)
А цель не только "заставить подумать", но еще и мотивировать людей. Кто же захочет, чтобы ему каждую ночь звонили а оплачивали как обычный overtime?
В кратце: Спасибо за ответ, но я спрашивал про другой аспект данной проблеммы.
Здравствуйте, DLF, Вы много оверквотили, что, собственно, запрещено правилами форума:
DLF>Все это классно и понятно, процессы как раз я сейчас и настраиваю, но как показывает практика проекты бывают разные и при выходе на определенный уровень без сапорта не обойтись. Пример? Пожалуйста — сегодня накрылся "flash module" на одном из серваков а там хранятся некоторые настройки и т.д. в общем-то устранимо, но заказчик сам не сможет. На выходных — место на венике закончилась, оказалось, что при поставке сервака неправильно разбили веник, и вместо 500 G один partition оказался 50 G. [А разбивал harware supplier] В основном вопросы конечно админские, но легче от этого знания не становится... =)
Как показывает практика пик подобных запросов приходится на некий период после выхода в production. Потом все более менее стабилизируется. Устанавливал софт на 50Gb тоже harware supplier? Соответственно вопрос к тому кто устанавливал.
DLF>А цель не только "заставить подумать", но еще и мотивировать людей. Кто же захочет, чтобы ему каждую ночь звонили а оплачивали как обычный overtime?
Ну, это уже сугубо задача переговоров с заказчиком о том сколько это денег нужно и какие есть варианты удобные для вас и приемлимые для него. Вам ведь никто не мешает поднять, например, цену. Тут не может быть никаких готовых рецептов.
DLF>В кратце: Спасибо за ответ, но я спрашивал про другой аспект данной проблеммы.
Какой тарифный план выставить заказчику? Могу сказать что у нас заказчик просто платит фиксированную сумму, за то чтобы по пол года нам не звонить.
Но у нас и ситуация другая. Есть и отдельный user support и отдельные админы которые решают админские задачи.
Здравствуйте, DLF, Вы писали:
DLF>На данный момент схема довольно грубая, хотелось бы сделать шкалу прогрессивной, дабы заказчик задумался прежде чем будить людей по ночам.
Оперделите некоторую базовую величину для первого вызова, а далее эмперическим( а также путём расчётов и переговоров) путём определяйте шкалу прогресса, так чтобы после некоторого количества вызовов заказчику было бы дешевле нанять сотрудников, занимаюшихся этим.
Врариант 1 шкалы:
Первые n вызовов( например 4 т.е. в неделю по разу) оцениваются по базовому тарифу.
Следующие n вызовов( цениваются по расценкам предыдущих * повышающий коэффициент, например 2 )
Вариант 2 шкалы:
Первый вызов оцениваются по базовому тарифу.
Следующий вызов( цениваются по расценкам предыдущий * повышающий коэффициент, болле менее нормально ставить его в диапазоне 1,1-1,25)
P.S. Готовых решений врялдли кто-то подскажет т.к. специфика работы различается, да и заказчики разные бывают.
Эмоции перехдестывают через край, у меня был один очень простой вопрос: Пожалуйста, поделитесь прогрессивными шкалами оплаты для супорта 24/7 [Конкретные ставки меня не инересовали, нужен пример].
P.S.: Blazkowicz, по постам чувствуется, что ты опытный человек, но не надо отвечать на вопрос кторого я не задавал, и тем более о нем спорить, пожалуйста.
Здравствуйте, DLF, Вы писали:
DLF>... у меня был один очень простой вопрос: Пожалуйста, поделитесь прогрессивными шкалами оплаты для супорта 24/7 [Конкретные ставки меня не инересовали, нужен пример].
До этой фразы я думал, что понимал, о чем ты спросил. После этой фразы, на фоне ответа nejest, я понял, что совсем ничего не понимаю
Что же касается сути — у монстров типа Майкрософта и Оракла это (если ЭТО — это то, о чем ты спрашиваешь ) организовано так, что заказчик саппорта изначально ограничен по количеству звонков в саппорт (в Оракле, насколько я помню договор нашей фирмы, это было 5 звонков в год для подробной консультации нашего админа с их экспертом по любому количеству вопросов; считается именно количество звонков). Больше оговоренного количества звонков он сделать не может. Таким образом, заказчик саппорта не звонит по мелочам, а собирает вопросы в достаточно большую кучу, прежде чем сделать драгоценный звонок.
Здравствуйте, DLF, Вы писали:
DLF>Эмоции перехдестывают через край, у меня был один очень простой вопрос: Пожалуйста, поделитесь прогрессивными шкалами оплаты для супорта 24/7 [Конкретные ставки меня не инересовали, нужен пример].
Вроде как поделился своей не прогрессивной шкалой.
DLF>P.S.: Blazkowicz, по постам чувствуется, что ты опытный человек, но не надо отвечать на вопрос кторого я не задавал, и тем более о нем спорить, пожалуйста.
Я ни с кем не спорю. Не хочешь общатся по теме — не комментируй мои посты. Всего-то делов.
Здравствуйте, nejest, Вы писали:
N>Врариант 1 шкалы: N>Первые n вызовов( например 4 т.е. в неделю по разу) оцениваются по базовому тарифу. N>Следующие n вызовов( цениваются по расценкам предыдущих * повышающий коэффициент, например 2 ) N>Вариант 2 шкалы: N>Первый вызов оцениваются по базовому тарифу. N>Следующий вызов( цениваются по расценкам предыдущий * повышающий коэффициент, болле менее нормально ставить его в диапазоне 1,1-1,25)
Можно пороть боков только для того чтобы выставить счет побольше.
N>P.S. Готовых решений врялдли кто-то подскажет т.к. специфика работы различается, да и заказчики разные бывают.
Я про это с самого начала говорил. Ситуации всегда уникальные. Вместо подобной шкалы, ИМХО, всегда лучше обсудить с заказчиком, и просто поднять цену.
Здравствуйте, Александр Каширин, Вы писали:
АК>Что же касается сути — у монстров типа Майкрософта и Оракла это (если ЭТО — это то, о чем ты спрашиваешь ) организовано так, что заказчик саппорта изначально ограничен по количеству звонков в саппорт (в Оракле, насколько я помню договор нашей фирмы, это было 5 звонков в год для подробной консультации нашего админа с их экспертом по любому количеству вопросов; считается именно количество звонков). Больше оговоренного количества звонков он сделать не может. Таким образом, заказчик саппорта не звонит по мелочам, а собирает вопросы в достаточно большую кучу, прежде чем сделать драгоценный звонок.
А, прошу прощения: только что понял, что пропустил кусочек формулировки вопроса То, о чем я говорил — не касается 24/7. В случае же 24/7 — всегда заранее оговариваются условия, а именно:
1. Ранжирование проблем по степени критичности (critical, high, medium, low, background) с четким указанием, по какому признаку проблема относится к той или иной категории. Например:
— critical — это недоступность сервера, или отсутствие обслуживания по одной из критических бизнес-функций (список четко оговаривается заранее), или задержка времени выполнения транзакции свыше 15 минут, или отказ обслуживания более 60% запросов.
— high — задержка времени выполнения транзакции свыше 10 минут, отсутствие обслуживание по одной из высокоприоритетных функций (список четко оговаривается заранее), или отказ от обслуживания более 40% запросов.
— и т.д.
2. В режиме 24/7 обслуживаются только запросы приоритета critical. И только для таких запросов разрешено тревожить горячую линию поддержки в нерабочее время. Остальные запросы обслуживаются в соответствии с другим регламентом. Например, high priority — в течение одного бизнес-дня, medium priority — в течение трех бизнес-дней, low priority — в течение двух недель и т.д.
3. Оговаривается процедура изменения приоритета запроса, если он ошибочно классифицирован с завышенным приоритетом. Т.е. на основании этой процедуры звонок ночью может быть легко отложен на утро, если заказчик позвонил просто спросить, сколько времени на сервере
Здравствуйте, Blazkowicz, Вы писали:
DLF>>P.S.: Blazkowicz, по постам чувствуется, что ты опытный человек, но не надо отвечать на вопрос кторого я не задавал, и тем более о нем спорить, пожалуйста. B>Я ни с кем не спорю. Не хочешь общатся по теме — не комментируй мои посты. Всего-то делов.
Зачем так резко?! Мы же не в Политике!
Проблема в том, что не всегда баги лезут сразу после выпуска в production, а потом почти тишина. Проблема в том, что есть различные категории клиентов:
1. Нормальные люди. Беспокоют суппорт только в случае проблем. Даннная категория имеет подкатегорию "супер". Эти способны подсказать классную новую фичу, выдать подробные обстоятельства возникновения бага и т.д.
2. Уроды. Эта категории самостоятельно задницу вытереть не может. Даже, если подобную(или точно такую же) задницу они вытирали вчера.
Задача автора состоит в том, чтобы отбится от 2-ой категории.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Зачем так резко?! Мы же не в Политике!
Вымораживают посты вида "вы не в теме, не пишите в мой топик"
LM>Задача автора состоит в том, чтобы отбится от 2-ой категории.
Ты тоже не в теме. Задача автора — найти другой вариант тарификации.
LM>ИМХО, очень грамотное решение предложено тута
Здравствуйте, Blazkowicz, Вы писали:
LM>>Зачем так резко?! Мы же не в Политике! B>Вымораживают посты вида "вы не в теме, не пишите в мой топик"
Тоже был не совсем корректный пост. Но у твоих постах слишком ярких контраст получился: профи vs пост в политике
LM>>Задача автора состоит в том, чтобы отбится от 2-ой категории. B>Ты тоже не в теме. Задача автора — найти другой вариант тарификации. Лично я увидел именно этот подтекст
LM>>ИМХО, очень грамотное решение предложено тута
Здравствуйте, LuciferMoscow, Вы писали:
LM>Тоже был не совсем корректный пост. Но у твоих постах слишком ярких контраст получился: профи vs пост в политике
Про политику же ты начал?
B>>Ты тоже не в теме. Задача автора — найти другой вариант тарификации. LM> Лично я увидел именно этот подтекст
Мне привидился другой подтекст в соответствии с которым я и поделился опытом.
B>>Собственно ранжировать запросы по приоритетам, я в первом посте и предлагал. LM>На этой части поста внимание не акцентируется.
ИМХО, кому надо — посты читает внимательно.
N>>Вариант 2 шкалы: N>>Первый вызов оцениваются по базовому тарифу. N>>Следующий вызов( цениваются по расценкам предыдущий * повышающий коэффициент, болле менее нормально ставить его в диапазоне 1,1-1,25) B>Можно пороть боков только для того чтобы выставить счет побольше.
Прибыль -конечно хорошо, но главное чтобы после определённого количества вызовов(например 3-х в неделю) было выгодней иметь своих специалистов, либо позволить фирме иметь для них выделенного специалиста. N>>P.S. Готовых решений врялдли кто-то подскажет т.к. специфика работы различается, да и заказчики разные бывают. B>Я про это с самого начала говорил. Ситуации всегда уникальные. Вместо подобной шкалы, ИМХО, всегда лучше обсудить с заказчиком, и просто поднять цену.
Но варианты лучше зеренее просчитать и определится относительно разумного маскимума вызовов( количества вызовов было выгодней иметь своих специалистов) а дальше только обсуждать жестокость наказания.
