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

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

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

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Здравствуйте, pogopogo, Вы писали:

P>>как организованы механизмы работы саппортеров у вас на предприятии?
P>>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

СШ>Как человек, который занимался этим два года, могу сказать только одно слово: ужас. Люди такое не выносят. Ищите наиболее стрессоустойчивого человека. В остальных случаях люди будут увольняться каждые пол года (это моя статистика).

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

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

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

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

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

Судя по фразе "у вас на предприятии", разговор идёт о непрерывном цикле разработка/экплуатация/поддержка, правильно? Это я к тому, что стандартная роль "саппортера" не выделена и размазана по всем, кто есть... Из этого предположения и буду исходить.

Думаю, можно попробовать порегулировать как минимум две составляющие:
1) Минимизировать затраты на саппорт, отсеивая часть запросов на поддержку на ранних стадиях;
2) Минимизировать время на оргвопросы, возникающие при оказании техподдержки;
3) Cократить время, тратящееся на переключение деятельности с саппорта к "созидательному труду" и в обратную сторону.

Предложения следующие:

Пустить ВСЕ запросы пользователей через некую (даже самую простую) систему, в которой все запросы на саппорт документируются. Причём пользователями! Очень очень желательно (не говорю обязательно, поскольку не всегда возможно). Сделайте им простую систему или внедрите существующую — пусть записывают. Причём вполне проходит подход типа: "Я с вами поговорю, но у нас тут всё строго — не опишите — не сделаем. Порядок такой." Впрочем, если можно выделит специального человека, коьторый будет записывать — тоже неплохо. Но у вас, насколько я понял, такой возможности нет.

Но всё равно, должен быть человек, ответственный за обработку саппортных запросов (Requests for change — RFC). Пусть он тратит больше всех времени на саппорт — всё равно это интегрально ресурсные затраты сократит. Данный человек рассматривает каждый запрос и принимает решение относительно данного запроса: это ошибка или предлагаемое улучшение, каков приоритет данного запроса, не является ли этот запрос дублем другого запроса или дополнением другого запроса. Далее все ошибки передаются на исправление конкретным разработчикам, а все дополнения, улучшения, изменения обязательно согласуются и вставляются в план разработки, который в дальнейшем должен быть кем-нибудь утверждён.

Ошибки должны разделяться по критичности. Например, есть ошибки business critical, наличие которых не позволяет выполнять основную бизнес-функцию приложения и неисправление которых немедленно может привести к существенным затратам. В таком случае уже ничего не поделаешь — нужно испралять немедленно. Все остальные ошибки могут подождать. Поэтому можно эти ошибки накапливать и выдавать разработчику порциями (например, выделить 1 день в неделю на исправление ошибок, или начинать с этого рабочий день). Главное, чтобы не было "бешенной зебры" — исправление, разработка, исправление, разработка... "Зебра", помимо того, что она просто сильно раздражает, ещё и весьма затратная проблема. Каждый переход от разработки к исправлению и обратно, это, как минимум затяжной перекур, а в среднем 15-30 минут на переключение.

Т.е., резюмируя:
— документировать все ошибки;
— человек — первичный анализ, ранжирование и распределение;
— выделенное время (не конкретно — 3 часа с утра, а, например, не более 3 часов с утра, если есть ошибки);

Данный подход может дать следующие преимущества:
1) Разработчики ограждаются от первичного самостоятельного анализа RFC — экономится время и нервы;
2) Отбрасывается часть несущественных RFC и нормально планируются изменения (не ошибки);
3) Разработчики меньше переключаются между задачами, снижается эффект "зебры";
4) Упрощается планирование изменений;
5) Упрощается планирование рабочего времени и учёт рабочего времени;
6) Упрощается контроль за изменениями (документирование RFC);
...

А главное, нервы успокаиваются.

P.S. Хочу заметить, что данные меры первичные. Дальше ИМХО надо будет решать следующую проблему — как вообще разделить саппорт (исправление ошибок, мелкие улучшения и т.п.) и создание новой функциональности.

P.P.S. Можно почитать что-нибудь вроде Microsoft Operations Framework (MOF) и, в особенности, "The MOF Supporting Quadrant". Кое-какие организационные идеи оттуда можно для себя почерпнуть (на всё ресурсов скорее всего не хватит).

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

S>P.P.S. Можно почитать что-нибудь вроде Microsoft Operations Framework (MOF) и, в особенности, "The MOF Supporting Quadrant". Кое-какие организационные идеи оттуда можно для себя почерпнуть (на всё ресурсов скорее всего не хватит).

По поводу почерпнуть идеи, еще посмотри ITIL (IT Infrastructure Library, устоявшийся "перевод" – Библиотека Передового опыта ИТ) — рекомендации по организации Service Desk (раннее называлось Help Desk). Имено на основе ITIL были разработаны методики MOF и ITSM.

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

Ниже коллеги хорошо описали теорию. Добавить практически нечего, кроме голой практики (на примере своей компании, но не знаю насколько это подходит вам).

Как устроен саппорт:
1. Есть выделенный департамент эксплуатации. Именно это структурное подразделение отвечает за поддержку.
2. Поддержка сделана двухуровневой:
— все звонок попадают на "первый уровень", если проблема стандартная или простая то и решаются там же;
— если оператор первого уровня не может помочь, он переключает на экспертов "второго уровня". Их меньше, их квалификация выше и стоят они дороже...
3. Для вип-клиентов есть индивидуальный саппорт — закрепляется один человек (т.н. "куратор"), который решает все вопросы клиента (как правило его квалификация еще выше чем у специалиста поддержки второго уровня).

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

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

P.S. Замечу, что поступления денег от клиентов за сопровождение является весьма существенной статьей дохода фирмы, сравнимой с поступлениями от новых продаж. Так что советую развивать саппорт, это выгодно и разработчикам и клиентам…

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

A>Если это "дежурный саппорт" когда все работает, просто юзеры тупят, то делить его нужно поровну. Если взвалите на одного программиста тот будет сильно демотивирован.
А в этом случае поставьте на саппорт одного из юзеров. Глазом моргнуть не успеете, как обращений поуменьшится.

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

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

G> А в этом случае поставьте на саппорт одного из юзеров. Глазом моргнуть не успеете, как обращений поуменьшится.

Вместе с потоком денег от этих юзеров

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

Организуйте дежурство. Каждый программер должен периодически тратить день-несколько на выполнение работы главного по саппорту. Он должен консультировать и открывать дефекты и переводить их на авторов для исправления, и что может, правит сам.

Дефектам присваивают приоритеты — 1 (исправить немедленно), 2 (исправить в очередном релизе), 3 (исправить при случае). Надо ввести расписание выхода сервис релизов.

Все, собственно. Чтобы народ не расстраивался, можно ввести систему премий и бонусов за сапорт.

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

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

G>> А в этом случае поставьте на саппорт одного из юзеров. Глазом моргнуть не успеете, как обращений поуменьшится.

A>Вместе с потоком денег от этих юзеров
Эээээ, я про внутренний саппорт.

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.
Раскажу немного о своем опыте. Был как раз в роли такого программера\суппортера. В некоторый момент суппорт(при большой загрузке) убивает весь программинг(после общения с дебилами).
Лучший хит от админа MS SQL Servera:
Я: запустите Enterprise Manager
Админ: Что запутить ?

Лучшей в Вашем случае будет наем хотя бы одного работника, который сажается на поддержку. Далее тут уже расказывали про двух уровневую поддержку. Reazon: При хорошей загрузке суппорта у Вас может начать бегство прогграммеров, а это будет стоить дороже, чем оплата еще одного человека

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

G>Организуйте дежурство. Каждый программер должен периодически тратить день-несколько на выполнение работы главного по саппорту. Он должен консультировать и открывать дефекты и переводить их на авторов для исправления, и что может, правит сам.

Может не получиться, если проект крупный и все всё не знают. Соответственно, придётся саппортить тому, в чьём (предположительно) модуле проблема.

G>Дефектам присваивают приоритеты — 1 (исправить немедленно), 2 (исправить в очередном релизе), 3 (исправить при случае). Надо ввести расписание выхода сервис релизов.
+1

G>Все, собственно. Чтобы народ не расстраивался, можно ввести систему премий и бонусов за сапорт.
+1

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

Какой именно вид деятельности вы понимаете под саппортом?

У нас, например, работа организована приблизительно следующим образом:
1. Есть CSR'ы -- посредики между клиентами и девелоперами, они общаются с клиентами, уточняют их требования, документируют их, и дают задачи девелоперам на саппорте.
2. Есть девелоперы на саппорте; они, в случае возникновения проблем у клиента, получают задачу от CSR'ов вникают в суть проблемы и, если ее возможно решить сразу, решают. Как правило, кто-то что-то неправильно проинсталировал, поэтому большинство проблем решаются исправлением конфигурационных параметров. Если проблема серьезная и требует изменений в исходных кодах, то она регистрируется и оценивается. Если проблема серьезная и срочная, возможно делается hotfix.
3. Есть просто девелоперы; они решают текущие задачи (фиксят баги и добавляют новую функциональность) и с клиентами никак не пересекаются.

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

P>как организованы механизмы работы саппортеров у вас на предприятии?
P>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

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

Есть специальный team, распределенный по миру на три больших части (Asia & Africa, America, Europe) , который занимается поддержкой. Саппорт включает в себя примерно следующее:


7 days a week, 24 hours a day unlimited technical support assistance, for two
contacts per 25 licenses purchased, via phone, e-mail or fax.

All product updates, including bug corrections, extensions, and other changes or
upgrades made by Telelogic to the standard software

Proactive shipment of product updates and patches for all installed licenses

Access to the Telelogic customer-only support web site where customers can
obtain patches and other product specific technical information

Access to the customer support knowledge base on the support web site

Case tracking on the support web site

Access to a dedicated Telelogic Support Representative during normal
regional hours

Annual review meeting on the customer's site with Telelogic's Vice President for
Global Support

On-site support assistance offered at a reduced rate.

On-site installation assistance offered at reduced rate.

Periodical installation 'health checks' offered at reduced rate

Preferential rates for certification of customer experts who want
to set up in-house first-line support centers

Membership of Telelogic Support User Group, which includes an invitation to the
annual Support User Group conference, normally hosted during the Telelogic User
Group Conferences, to influence the support offerings

Invitation to maintain a direct dialogue with Telelogic's product
development organization

A>Как практика показала в гомеопатических дозах саппорт для
A>девелоперов не только полезен, но и необходим.
A>Сразу становится понятна кривость кривореализованных решений.

Что толку с того, что он это поймёт? Те решения, кривость которых видит юзер, принимает не программист, а архитектор и интерфейсник. А кривость тех решений, которые принимает девелопер, конечный юзер заметить не может (ну, кроме банального "программа что-то несколько медленно работает, так и должно быть?").

S>Но всё равно, должен быть человек, ответственный за обработку
S>саппортных запросов (Requests for change — RFC). Пусть он тратит
S>больше всех времени на саппорт — всё равно это интегрально ресурсные
S>затраты сократит. Данный человек рассматривает каждый запрос и
S>принимает решение относительно данного запроса: это ошибка или
S>предлагаемое улучшение, каков приоритет данного запроса,
S>не является ли этот запрос дублем другого запроса или
S>дополнением другого запроса.

Постой-постой! Ты путаешь "саппортный запрос" и баг-репорт. Это же совершенно разные вещи.

Саппортный запрос — это когда юзверь пишет в майкрософт "а как у вас в Word`е цвет фона под текстом поменять, — я слышал, так можно сделать, да и у джейн из соседнего отдела на распечатке видел, правда, не знаю, может это она в пауэр-поинте пририсовала?" или "я в экселе нажимаю кнопку "выделить границы", но никаких линий вокруг выделенных ячеек не появляется. что сделать, чтобы они появились?" или же "возникает ошибка "неостаточно прав для данной операции либо файл защищён от записи". что делать?" или даже "можно ли с помощью встроенных средств IIS реализовать следующую функциональнось: всем программам, работающим по портам 123, 234 и 345 по будням с 18:00 до 21:00 отводиттся канал не больше 5 Кбит, с 9::00 до 18:00 их работа полностью рапрещена, а с 21:00 до 9:00 и круглосуточно в выходные они могут потреблять сколько угодно трафика".

А баг-репорт — это когда юзер пишет "как только я набираю в Word`е фразу "правоспособность-способность лица иметь гражданские права и нести обязанности", он крэшится — и так каждый раз!"

>P.S. Хочу заметить, что данные меры первичные. Дальше ИМХО надо будет
>решать следующую проблему — как вообще разделить саппорт (исправление ошибок,
>мелкие улучшения и т.п.) и создание новой функциональности.

Так мы говорим о разных вещах — поддержку программы (которая на самом деле не поддержка, а сопровождение) и поддержку пользователей ака поддержку продукта. Но судя по некоторым фразам ("Если это "дежурный саппорт" когда все работает, просто юзеры тупят, то делить его нужно поровну", "запросы пользователей") эта путаница есть у многих. В любом случае, запросы пользователей с сопровождением и развитием программы связаны мало.

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

S>>Но всё равно, должен быть человек, ответственный за обработку
S>>саппортных запросов (Requests for change — RFC). Пусть он тратит
S>>больше всех времени на саппорт — всё равно это интегрально ресурсные
S>>затраты сократит. Данный человек рассматривает каждый запрос и
S>>принимает решение относительно данного запроса: это ошибка или
S>>предлагаемое улучшение, каков приоритет данного запроса,
S>>не является ли этот запрос дублем другого запроса или
S>>дополнением другого запроса.

C>Постой-постой! Ты путаешь "саппортный запрос" и баг-репорт. Это же совершенно разные вещи.

Это для понимающего разниуцу — разные. А для подавляющего большинства пользователей это одно и тоже. Научить пользователя писать "правильные" фидбеки практически не возможно. Мало того есть ещё такой класс сообщений, как вопросы. А человек, о котором я говорил — это как раз та личность, которая понимает, что пришло от пользователя — вопрос, предложение или ошибка. Другими словами — классифицирует.

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

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

S>>P.P.S. Можно почитать что-нибудь вроде Microsoft Operations Framework (MOF) и, в особенности, "The MOF Supporting Quadrant". Кое-какие организационные идеи оттуда можно для себя почерпнуть (на всё ресурсов скорее всего не хватит).

B>По поводу почерпнуть идеи, еще посмотри ITIL (IT Infrastructure Library, устоявшийся "перевод" – Библиотека Передового опыта ИТ) — рекомендации по организации Service Desk (раннее называлось Help Desk). Имено на основе ITIL были разработаны методики MOF и ITSM.

С ITIL — согласен отчасти. MOF имхо доступнее и проще для восприятия (такое мнение предположительно, поскольку я не читал рекомендации по организации Help Desk, из ITIL). Так сказать — адаптация.

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Здравствуйте, pogopogo, Вы писали:

P>>как организованы механизмы работы саппортеров у вас на предприятии?
P>>у нас в команде нет специально выделенных для этого людей, а поддерживать надо несколько проектов. Нужно создать какое-то решение для того, чтобы программист мог заниматься саппортингом параллельно программингу и делал это наиболее эффективно. Саппортера в штат принять пока не представилась возможность.

Как человек, который занимался этим два года...

Ищите наиболее стрессоустойчивого человека. В остальных случаях люди будут увольняться каждые пол года (это моя статистика).

По Собственным меркам — выходит, что Вы человек исключительной стрессоустойчивости, с

4 / 0.5 = 8 кратным запасом прочности

Прикольно, но как-то не согласуется с:

могу сказать только одно слово: ужас

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

S>

S>Как человек, который занимался этим два года...

S>

Ищите наиболее стрессоустойчивого человека. В остальных случаях люди будут увольняться каждые пол года (это моя статистика).

S>По Собственным меркам — выходит, что Вы человек исключительной стрессоустойчивости, с

S> 4 / 0.5 = 8 кратным запасом прочности

S>Прикольно, но как-то не согласуется с:

S>

S>могу сказать только одно слово: ужас

Запас кончился