Comments 13
Добрый день, хотелось бы задать несколько вопросов:
Спасибо
- Можете описать, что включалось в обучение T2 и какие требование стали предъявляться к людям в T2 ?
- Как работает вот этот пункт: «6. В команде поддержки появился еще один вектор для карьерного роста.»? Люди переходят по эффективности работы, по рекомендации или после каких-то тестов?
- Если смотреть по вот по этой ссылке (Техническая_поддержка), то куда относятся ваши специалисты Т2 — к Уровень/Линия 2, Уровень/Линия 3 или где-то посередине?
Спасибо
Михаил, добрый день!
1. Обучение Т2 проходило постепенно, по ходу работы: некоторое время мы провели в изучении правил эскалаций, знакомстве с основными инструментами и рабочими ситуациями (т.е. изучали сам процесс); параллельно с этим запускали обучающие сессии по конкретным техническим темам (несколько итераций, от простого к сложному) — обучние работе с API, плагинам, интеграциям Wrike.
Что касается общего «траблшутинга», никакого особого тренинга наши агенты не получали — здесь, скорее, многое родилось само в процессе контактов с QA и dev и из опыта решения разного рода проблемных ситуаций. Мы также запустили свою внутреннию документацию для саппорта на основе этих знаний.
Насчет требований: во главу угла для Tier 2 агентов мы поставили навыки локализации и анализа проблемы (аналитические способности, умение отделить важное от второстепенного, умение грамотно и четко донести суть). Отдельно выделили важность коммуникативной составляющей — умение наладить общение как с людьми инженерного скалада ума, так и с клиентами. Ко всему прочему Т2 агент должен был стать опорой для товарищей из поддержки — здесь пригодится наличие менторских качеств, а также стремление помогать и объяснять (такой 'support for support' прицнип практикуется в поддержке Wrike и на уровне менеджмента).
2. Нашему Т2 процессу чуть больше года на данный момент, за это время мы расширили состав Т2 только единожды (+2 человека для прикрытия ночной смены, т.к. поддержка у нас 24/7) — никаких специальных тестов не проводили, но, безусловно, был важен опыт на первом уровне, интерес к технчиеским знаниям и аналитический склад ума. Я бы еще сравнил отбор в Т2 с собеседованием на роль помощника Шерлока Холмса — есть в процессе исследований клиентских проблем и багов что-то детективное :) И требования соответствующие.
3. Спасибо за ссылку, по этой статье Т2 относится скорее к Уровню-Линии 2 («аналитические методы решения», «оказание помощи первой линии» говорят прямо в его пользу).
В то же время в характеристике Уровня 3 указна ответственность «за исследования и развитие решений для новых, появляющихся, неизвестных ранее проблем» — все-таки в нашем случае Т2 иногда может взять на себя и эту функцию. Часто бывает, что Т2 агент сам находит проблему, выявляет ее источник, стабильный способ воспроизведения и передает напрямую разработчикам для фикса (QA остается только лишь официально подтрведить баг). В общем и целом, наши инженеры квалифицируются как Tier 3 в общей системе эскалаций, т.к. за ними всегда фикс любых багов, что, к сожалению, не в компетенции Tier 2 спецов.
1. Обучение Т2 проходило постепенно, по ходу работы: некоторое время мы провели в изучении правил эскалаций, знакомстве с основными инструментами и рабочими ситуациями (т.е. изучали сам процесс); параллельно с этим запускали обучающие сессии по конкретным техническим темам (несколько итераций, от простого к сложному) — обучние работе с API, плагинам, интеграциям Wrike.
Что касается общего «траблшутинга», никакого особого тренинга наши агенты не получали — здесь, скорее, многое родилось само в процессе контактов с QA и dev и из опыта решения разного рода проблемных ситуаций. Мы также запустили свою внутреннию документацию для саппорта на основе этих знаний.
Насчет требований: во главу угла для Tier 2 агентов мы поставили навыки локализации и анализа проблемы (аналитические способности, умение отделить важное от второстепенного, умение грамотно и четко донести суть). Отдельно выделили важность коммуникативной составляющей — умение наладить общение как с людьми инженерного скалада ума, так и с клиентами. Ко всему прочему Т2 агент должен был стать опорой для товарищей из поддержки — здесь пригодится наличие менторских качеств, а также стремление помогать и объяснять (такой 'support for support' прицнип практикуется в поддержке Wrike и на уровне менеджмента).
2. Нашему Т2 процессу чуть больше года на данный момент, за это время мы расширили состав Т2 только единожды (+2 человека для прикрытия ночной смены, т.к. поддержка у нас 24/7) — никаких специальных тестов не проводили, но, безусловно, был важен опыт на первом уровне, интерес к технчиеским знаниям и аналитический склад ума. Я бы еще сравнил отбор в Т2 с собеседованием на роль помощника Шерлока Холмса — есть в процессе исследований клиентских проблем и багов что-то детективное :) И требования соответствующие.
3. Спасибо за ссылку, по этой статье Т2 относится скорее к Уровню-Линии 2 («аналитические методы решения», «оказание помощи первой линии» говорят прямо в его пользу).
В то же время в характеристике Уровня 3 указна ответственность «за исследования и развитие решений для новых, появляющихся, неизвестных ранее проблем» — все-таки в нашем случае Т2 иногда может взять на себя и эту функцию. Часто бывает, что Т2 агент сам находит проблему, выявляет ее источник, стабильный способ воспроизведения и передает напрямую разработчикам для фикса (QA остается только лишь официально подтрведить баг). В общем и целом, наши инженеры квалифицируются как Tier 3 в общей системе эскалаций, т.к. за ними всегда фикс любых багов, что, к сожалению, не в компетенции Tier 2 спецов.
Замечу кое-что в порядке философского отступления. Почему-то когда люди сами пытаются сделать какую-то полезную работу, они очень быстро приходят к тому, что управляемая многоуровневая иерархия, место в которой определяется опытом и предшествующими заслугами, лучше неуправляемого хаоса демократии, в котором все равны… равны в своей неэффективности. Однако когда те же самые люди взаимодействуют с государственной властью (являясь, по сути, клиентами) они крайне возмущены тем, что у них нет возможности прямой коммуникации с теми, кто реально принимает решения. А если вдруг такая возможность есть — например, прямо в твиттер губернатору можно написать о новой яме на дороге, — то это воспринимается с восторгом… якобы это офигенный прогресс, а вовсе не регресс.
Мы в своей фирме сделали почти так же — ввели должности разработчиков отдела поддержки, то есть разделили отдел разработки и отдали его часть в управление отдела поддержки. Правда эта возможность связана со структурой продукта, который состоит из множества модулей, каждый из которых имеет свои настройки, БД и скрипты для каждого клиента. В итоге резко снизилось количество и увеличилось качество проработки задач для основных разработчиков, что позволило сосредоточиться на выпуске новых версий. Плюс увеличилась скорость обработки запросов клиентов на мелкие изменения, которые можно осуществить «на лету», и исправление или купирование ошибок. Престижность этого отдела невысокая, но он является отличной «кузницей кадров», человек переходит в основной отдел разработки с хорошим багажом знаний продукта и знанием реальных проблем клиентов
Спасибо за комментарий — интересный опыт! В вашей ситуации отдел «разработчиков поддержки» действительно видится хорошей разгонной площадкой для новых разработчиков. Быть может, такой отдел на самом деле видится престижным для определенной категории сотрудников с интересом к техническим темам и разработке, не имеющих большого опыта в этой среде. К тому же взращенные у себя кадры всегда ценнее в плане уникальных знаний и приспособленности под конкретную работу. Еще главный плюс в таком подходе в том, что порой инженерам как раз не хватает понимания проблем и чаяний клиентов — а так выходит, что человек уже и с этой стороны подготовлен.
Спасибо за статью, Павел – было очень интересно узнать о вашем опыте, так как уже давно занят в данной области — мы правда продаем и обслуживаем инструменты/компоненты для других разработчиков бизнес приложений. Хотел бы задать несколько вопросов:
1. Расскажите, сколько в среднем инцидентов (всего, простых L1 и сложных L2) отвечает рядовой сотрудник супорта и Т2 агент, если это не секретная информация?
2. Как у вас распределяются задачи в работу из очередей (новые и реактивированные инциденты)? В частности, имеет ли каждый супортер всегда в разработке в любой момент времени только одну задачу, которую потом оставляет на себе (AssignedTo)? Берет ли он следующую из общего пула только когда закончит с предыдущей или возможна ситуация, когда на одного сотрудника приходится несколько задач сразу, так как он с ними уже сильно и много разбирался до последней реактивации (ну т.е. личная ответственность vs групповая)?
3. Интересно, возможно ли в вашей системе прогнозирование доступности ресурсов «на будущее», т.е. предсказание ждущим клиентам в очередях типа «При текущей загрузке специалистов вам ответят примерно через 1ч.30», если в вашем бизнесе такое вообще требуется.
4. Как у вас происходит передача запросов и проблем клиентов к разработчикам и другим членам команды? В частности, нет ли с таким T2 подходом проблем с утаиванием/потерей важной информации до тех, кто написал исходный код продукта?
5. Расскажите, пожалуйста, какой еще проактивной работой помимо улучшения качества базы знаний, документации, самого продукта занимаются ваши сотрудники техподдержки.
В заключение, хотелось бы поделиться опытом нашей компании (live chat я брать не буду, пока только расскажу кратко про online help desk с тикетами или почтой). У нас в 2016 году есть те же L1 и L2, но на них практически работают одни и те же сотрудники техподдержки (aka support developers), которые находятся физически рядом с ответственными разработчиками и др. членами команды. Например, мой текущий трайб XAF и в нем есть сквады WinForms, ASP.NET, Mobile, Core, Security, Analytics, которые имеют разработчиков, супортеров, техписателей, дизайнеров (последние два шарятся на трайб ввиду дефицита данных ресурсов). Отдельных тестеров или отдела QA у нас нет — автоматическое юнит, функциональное и ручное тестирование производится силами всей команды. Специалист супорта в трайбе у нас универсален и может ответить на любой вопрос по продукту/направлению, но в то же время он также старается больше фокусироваться на теме своего сквада, например, Core (эта специализация касается как поддержки так и разработки/тестирования новых фич). В тоже время есть небольшое число очень опытных и мега универсальных спецов. Ответы стараемся давать в течение бизнес дня или в большинстве случаев раньше (<24ч), основной язык общения — английский (по-русски тоже можно пообщаться в приватных тикетах при большой необходимости), есть вторая смена (15.00-00.00) для охвата западного побережья, priority line для некоторых подписок типа Universal, эскалация на руководство. Как и думаю везде, стараемся чтобы на L1 не залеживалось тикетов старше нескольких часов (1-2 в идеальном мире), на L2 попадают сложные кейсы, которые нельзя/быстро сразу ответить (например, какой-то сложный проект для долгой отладки) либо с полной инфой после всех уточнений, чтобы любому можно было сразу взять без усилий и начать разбираться. Например, если прислали проект, надо убедиться, что он собирается и запускается, есть шаги и др. необходимые данные. Супорт должен хорошо разбираться в поддерживаемом продукте с технической стороны, отлаживать проекты клиентов, грамотно и вежливо передавать им решения и др. информацию, искать и оформлять баги со всеми шагами (все баги должны предварительно заверяться вместе с разработчиками), анализировать код и запросы клиентов, быть передатчиком клиентской боли и запросов в команду, взаимодействовать со всеми коллегами, чтобы планировать будущие релизы и улучшать сам продукт, базу знаний и онлайн документацию. «Идеальный» супортер у нас — эдакий чтец, жнец и на дуде игрец, разве что баги сам не фиксит и фичи с тестами не пишет (хотя есть и такие исключения). Конечно, создание такого «швейцарского ножа» требует долгой и серьезной подготовки, но плюсы очевидны и также легче сохранять мотивацию таких специалистов на высоком уровне за счет большого разнообразия задач. Конечно, это все было бы невозможно или сложно, если бы под боком не было друзей-разработчиков, которые вместе с нами слушают customer pain/suggestions (мы стараемся следовать принципу Put everyone on the front lines как в Rework от 37 signals и доводить эту инфу до авторов напрямую), планируют изменения и помогают в сложных случаях или делятся знаниями. Иногда, в случае больших завалов или на праздники, сами разработчики напрямую привлекаются для ответов на тикеты (конечно, каждый предварительно проходит тренинг, чтобы соответствовать стандартам техподдержки компании по вежливости, грамотности, стилю и др.). Вкратце вроде все описал:-)
P.S.
Пользуемся вашим продуктом для некоторых marketing задач, спасибо!
1. Расскажите, сколько в среднем инцидентов (всего, простых L1 и сложных L2) отвечает рядовой сотрудник супорта и Т2 агент, если это не секретная информация?
2. Как у вас распределяются задачи в работу из очередей (новые и реактивированные инциденты)? В частности, имеет ли каждый супортер всегда в разработке в любой момент времени только одну задачу, которую потом оставляет на себе (AssignedTo)? Берет ли он следующую из общего пула только когда закончит с предыдущей или возможна ситуация, когда на одного сотрудника приходится несколько задач сразу, так как он с ними уже сильно и много разбирался до последней реактивации (ну т.е. личная ответственность vs групповая)?
3. Интересно, возможно ли в вашей системе прогнозирование доступности ресурсов «на будущее», т.е. предсказание ждущим клиентам в очередях типа «При текущей загрузке специалистов вам ответят примерно через 1ч.30», если в вашем бизнесе такое вообще требуется.
4. Как у вас происходит передача запросов и проблем клиентов к разработчикам и другим членам команды? В частности, нет ли с таким T2 подходом проблем с утаиванием/потерей важной информации до тех, кто написал исходный код продукта?
5. Расскажите, пожалуйста, какой еще проактивной работой помимо улучшения качества базы знаний, документации, самого продукта занимаются ваши сотрудники техподдержки.
В заключение, хотелось бы поделиться опытом нашей компании (live chat я брать не буду, пока только расскажу кратко про online help desk с тикетами или почтой). У нас в 2016 году есть те же L1 и L2, но на них практически работают одни и те же сотрудники техподдержки (aka support developers), которые находятся физически рядом с ответственными разработчиками и др. членами команды. Например, мой текущий трайб XAF и в нем есть сквады WinForms, ASP.NET, Mobile, Core, Security, Analytics, которые имеют разработчиков, супортеров, техписателей, дизайнеров (последние два шарятся на трайб ввиду дефицита данных ресурсов). Отдельных тестеров или отдела QA у нас нет — автоматическое юнит, функциональное и ручное тестирование производится силами всей команды. Специалист супорта в трайбе у нас универсален и может ответить на любой вопрос по продукту/направлению, но в то же время он также старается больше фокусироваться на теме своего сквада, например, Core (эта специализация касается как поддержки так и разработки/тестирования новых фич). В тоже время есть небольшое число очень опытных и мега универсальных спецов. Ответы стараемся давать в течение бизнес дня или в большинстве случаев раньше (<24ч), основной язык общения — английский (по-русски тоже можно пообщаться в приватных тикетах при большой необходимости), есть вторая смена (15.00-00.00) для охвата западного побережья, priority line для некоторых подписок типа Universal, эскалация на руководство. Как и думаю везде, стараемся чтобы на L1 не залеживалось тикетов старше нескольких часов (1-2 в идеальном мире), на L2 попадают сложные кейсы, которые нельзя/быстро сразу ответить (например, какой-то сложный проект для долгой отладки) либо с полной инфой после всех уточнений, чтобы любому можно было сразу взять без усилий и начать разбираться. Например, если прислали проект, надо убедиться, что он собирается и запускается, есть шаги и др. необходимые данные. Супорт должен хорошо разбираться в поддерживаемом продукте с технической стороны, отлаживать проекты клиентов, грамотно и вежливо передавать им решения и др. информацию, искать и оформлять баги со всеми шагами (все баги должны предварительно заверяться вместе с разработчиками), анализировать код и запросы клиентов, быть передатчиком клиентской боли и запросов в команду, взаимодействовать со всеми коллегами, чтобы планировать будущие релизы и улучшать сам продукт, базу знаний и онлайн документацию. «Идеальный» супортер у нас — эдакий чтец, жнец и на дуде игрец, разве что баги сам не фиксит и фичи с тестами не пишет (хотя есть и такие исключения). Конечно, создание такого «швейцарского ножа» требует долгой и серьезной подготовки, но плюсы очевидны и также легче сохранять мотивацию таких специалистов на высоком уровне за счет большого разнообразия задач. Конечно, это все было бы невозможно или сложно, если бы под боком не было друзей-разработчиков, которые вместе с нами слушают customer pain/suggestions (мы стараемся следовать принципу Put everyone on the front lines как в Rework от 37 signals и доводить эту инфу до авторов напрямую), планируют изменения и помогают в сложных случаях или делятся знаниями. Иногда, в случае больших завалов или на праздники, сами разработчики напрямую привлекаются для ответов на тикеты (конечно, каждый предварительно проходит тренинг, чтобы соответствовать стандартам техподдержки компании по вежливости, грамотности, стилю и др.). Вкратце вроде все описал:-)
P.S.
Пользуемся вашим продуктом для некоторых marketing задач, спасибо!
Денис, спасибо за вопросы и за то, что поделились собственным опытом! Также рады услышать, что пользуетесь Wrike :)
Постараюсь ответить на всё так же максимально развернуто:
1. Если я правильно понял ваш вопрос, интересно количество «простых» инцидентов и «сложных». Мы не ведем отдельный подсчет для каждого агента, но чтобы вы получили представление о масштабах:
— в среднем в неделю нагрузка по всем каналам на всех агентов > 2k тикетов
— как правило 10% процентов от общего числа тикетов составляют различного рода проблемные инциденты (категория product issue, по вашей классификации можем назвать их L2 инцидентами)
— большинство вопросов по продукту невольно затрагивают некую «проблему», которую клиент не может решить (в нашей статистике такие вопросы обозначаются как product question). Их доля ок. 40% от общего числа запросов.
В Т2 эскалируется в среднем 40-50 проблем в неделю, равномерно распределенная нагрузка на каждого агента при этом получается 6-7 проблем, хотя, конечно все работаю по-разному. Интересно, что с нашей новой системой все эти проблемы уже как правило валидные случаи для дальнейшей эскалации или же вопросы, на которые только Т2 сможет ответить (API, интеграции), т.к. Т2 работает напрямую с агентами первого уровня и консультирует уже «на подходе».
2. Каждый суппортер обязан разбирать новые тикеты из очереди по мере поступления, при этом ответ на них приоритетнее работы над «реактивированными», открытыми тикетами. Плюс в нагрузку даются чаты и звонки (в зависимости от роли агента). У нас действует «ассайн» новых тикетов, соотв. каждый имеет некое портфолио открытых, с которыми он ведет переписку. В итоге, по «реактивированным» тикетам ответственность личная, а по новым запросам – групповая.
3. У нас на самом деле по live каналам (чат, телефон) нет очередей, поэтому такое прогнозирование не ведется :) Вообще мы пользуемся эффективной SLA метрикой, которая устанавливает следующие целевые показатели: 90% чатов должны быть взяты за 30 секунд, 90% звонков за 20 с, 90% email тикетов получить первый ответ в течение часа.
4. Интересно, что вы имеете в виду под «утаиванием»? Передача проблем осуществляется через задачу в Wrike, в ней же хранятся технические записи для dev (в кач-ве подзадачи). Т2 агент составляет подробное и четкое описание, прилагает скриншоты, видео, логи и т.д. К тому же у нас прямая коммуникация ведется, всегда можно что-то уточнить лично.
5. Т2 выполняет функцию мостика между саппортом и другими отделами, не только инженерами. Мы пытаемся доводить до команды любые новости по развитию продукта и изменениям в нем, часто работаем с PM-ами (предоставляем фидбэк), присутствуем на митингах различных команд разработки. Knowledge-sharing через личный контакт также неотъемлемая часть работы – мы проводим тренинги, обучаем новичков процессам напрямую.
P.S. У нас есть свежее видео с выступления менеджеров, где рассказывается о базовых организационных вещах по работе Саппорта в целом, если вам интересно, можете глянуть: https://www.youtube.com/watch?v=YY5Bm3kDw-M
К вам также возникли вопросы:
1. Как в вашем случае все-таки различаются L1 и L2 уровни саппорта? Если работают одни и те же сотрудники, это лишь формальное деление по сложности задач?
2. Очень интересен опыт ответов разработчиков на тикеты, вовлечения их в «customer-facing» роль – насколько сложно это было воплотить в жизнь и есть ли какие-то хитрости в «приобщении»? Все-таки тяжело «технических» людей привлечь к клиентской работе.
Постараюсь ответить на всё так же максимально развернуто:
1. Если я правильно понял ваш вопрос, интересно количество «простых» инцидентов и «сложных». Мы не ведем отдельный подсчет для каждого агента, но чтобы вы получили представление о масштабах:
— в среднем в неделю нагрузка по всем каналам на всех агентов > 2k тикетов
— как правило 10% процентов от общего числа тикетов составляют различного рода проблемные инциденты (категория product issue, по вашей классификации можем назвать их L2 инцидентами)
— большинство вопросов по продукту невольно затрагивают некую «проблему», которую клиент не может решить (в нашей статистике такие вопросы обозначаются как product question). Их доля ок. 40% от общего числа запросов.
В Т2 эскалируется в среднем 40-50 проблем в неделю, равномерно распределенная нагрузка на каждого агента при этом получается 6-7 проблем, хотя, конечно все работаю по-разному. Интересно, что с нашей новой системой все эти проблемы уже как правило валидные случаи для дальнейшей эскалации или же вопросы, на которые только Т2 сможет ответить (API, интеграции), т.к. Т2 работает напрямую с агентами первого уровня и консультирует уже «на подходе».
2. Каждый суппортер обязан разбирать новые тикеты из очереди по мере поступления, при этом ответ на них приоритетнее работы над «реактивированными», открытыми тикетами. Плюс в нагрузку даются чаты и звонки (в зависимости от роли агента). У нас действует «ассайн» новых тикетов, соотв. каждый имеет некое портфолио открытых, с которыми он ведет переписку. В итоге, по «реактивированным» тикетам ответственность личная, а по новым запросам – групповая.
3. У нас на самом деле по live каналам (чат, телефон) нет очередей, поэтому такое прогнозирование не ведется :) Вообще мы пользуемся эффективной SLA метрикой, которая устанавливает следующие целевые показатели: 90% чатов должны быть взяты за 30 секунд, 90% звонков за 20 с, 90% email тикетов получить первый ответ в течение часа.
4. Интересно, что вы имеете в виду под «утаиванием»? Передача проблем осуществляется через задачу в Wrike, в ней же хранятся технические записи для dev (в кач-ве подзадачи). Т2 агент составляет подробное и четкое описание, прилагает скриншоты, видео, логи и т.д. К тому же у нас прямая коммуникация ведется, всегда можно что-то уточнить лично.
5. Т2 выполняет функцию мостика между саппортом и другими отделами, не только инженерами. Мы пытаемся доводить до команды любые новости по развитию продукта и изменениям в нем, часто работаем с PM-ами (предоставляем фидбэк), присутствуем на митингах различных команд разработки. Knowledge-sharing через личный контакт также неотъемлемая часть работы – мы проводим тренинги, обучаем новичков процессам напрямую.
P.S. У нас есть свежее видео с выступления менеджеров, где рассказывается о базовых организационных вещах по работе Саппорта в целом, если вам интересно, можете глянуть: https://www.youtube.com/watch?v=YY5Bm3kDw-M
К вам также возникли вопросы:
1. Как в вашем случае все-таки различаются L1 и L2 уровни саппорта? Если работают одни и те же сотрудники, это лишь формальное деление по сложности задач?
2. Очень интересен опыт ответов разработчиков на тикеты, вовлечения их в «customer-facing» роль – насколько сложно это было воплотить в жизнь и есть ли какие-то хитрости в «приобщении»? Все-таки тяжело «технических» людей привлечь к клиентской работе.
Спасибо за развернутые ответы, Павел!
По п.4 смотрю у меня там опечатки, простите. Имел ввиду возможные потери пользовательского фидбека (как хорошего, так и плохого) или недонесение его до разработчиков за счет прослойки между клиентов. Уточнял это отдельно, так как мы с этим сталкивались в некоторых командах и эта проблема также описывается в сообществе. Хорошо, что у вас все хорошо:-) и п.5 лишний раз это подтверждает.
Мои ответы на ваши вопросы:
1. Да, линии по сути просто сортируют работу на день: все что можно простое — отвечаем сразу, сложные кейсы просто требуют доп. исследований и времени.
2. Да, сложностей куча, начиная от элементарного владения деловым английским языком и заканчивая чисто мотивационными «не барское это дело» или «я пишу код, а донести у вас все равно лучше получится», а также желанием соблюсти баланс между супортом и разработкой (фичи писать и тесты поднимать тоже ведь надо). В компании у нас огромное внимание уделяется сервису клиентов, и поэтому одним из принципов является «поддержка клиентов — это ответственность ВСЕЙ команды». Поэтому считаю немаловажным, чтобы разработчики и остальные понимали эту ценность на уровне подкорки. Когда будет понимание, тогда и не будет отношения к процессу поддержки как к повинности. Конечно, как писал выше, также необходим базовый тренинг aka «неделя в супорте», который длится у все по разному в зависимости от исходных данных. Во время него разработчик работает в паре с опытным супортистом и делает обычный разбор линий, пишет сам ответы, получает корректировки по ходу дела и знакомится со всеми остальными секретами данного дела. Дальше плотный контроль потихоньку ослабевает. Если все хорошо, то разработчик идет уже сам в бой и со временем присмотр вообще становится не нужен. Некоторым ребятам вообще очень нравится отвечать тикеты так как приятно все таки общаться с живыми пользователями твоей фичи, получать благодарности, что даже просят иногда «подкиньте посупортить, а то давно не было»:-) — так что это вполне может быть дополнительной мотивацией к работе, тем более полезно менять сферу деятельности. Есть также вообще уникальные команды, где поддержку оказывают целиком дежурные разработчики (как писали выше в коментах), но это скорее исключение. В среднем по больнице, привлекать разработчиков мы стараемся только по реальной необходимости, такой как перегрузы или праздники (по договоренности/желанию разработчики могут выйти в праздники вместо коллег супортистов). Для этого координатор группы супорта продукта в начале дня (чтобы ребята могли лучше спланировать свой день и не переключаться лишний раз) выделяет тикеты на спец линию Developers Queue или «девку» — сей процесс мы даже шутливо называем «разогрев девки»:-)
Так как английский язык очень важен для нашего бизнеса (не только для супорта, но и тупо метод в классе нормально назвать, сделать ревию новой статьи в документации или понять о чем говорили на вебинаре с маркетингом), компания всячески мотивирует сотрудников на улучшение этого навыка (это даже упоминается в оценке уровней) и создает условия для его изучения (компенсации или курсы на базе офиса, причем супорту курсы вообще бесплатно и за счет рабочего времени). В своей команде я лично всегда ставлю поднятие уровня языка на ревию уровней молодым или проблемным ребятам. И это вроде действует — после осознания многие стали ходить на курсы/наняли репетиторов и прокачивают этот навык сами. Дай бог скоро совсем не будет переменных «needRepit» и шуток про «Минаков-стайл»:-)
Конечно, для ответов на тикеты для всех в компании есть специально обученные знатоки языка aka «корректоры» (местные и нативные), которые помогают с грамматикой, стилями и правильными коннотациями, перед тем как ответ уйдет клиенту.
Вроде все из основного — почти на статью получилось… Спрашивайте, если что интересует еще!
По п.4 смотрю у меня там опечатки, простите. Имел ввиду возможные потери пользовательского фидбека (как хорошего, так и плохого) или недонесение его до разработчиков за счет прослойки между клиентов. Уточнял это отдельно, так как мы с этим сталкивались в некоторых командах и эта проблема также описывается в сообществе. Хорошо, что у вас все хорошо:-) и п.5 лишний раз это подтверждает.
Мои ответы на ваши вопросы:
1. Да, линии по сути просто сортируют работу на день: все что можно простое — отвечаем сразу, сложные кейсы просто требуют доп. исследований и времени.
2. Да, сложностей куча, начиная от элементарного владения деловым английским языком и заканчивая чисто мотивационными «не барское это дело» или «я пишу код, а донести у вас все равно лучше получится», а также желанием соблюсти баланс между супортом и разработкой (фичи писать и тесты поднимать тоже ведь надо). В компании у нас огромное внимание уделяется сервису клиентов, и поэтому одним из принципов является «поддержка клиентов — это ответственность ВСЕЙ команды». Поэтому считаю немаловажным, чтобы разработчики и остальные понимали эту ценность на уровне подкорки. Когда будет понимание, тогда и не будет отношения к процессу поддержки как к повинности. Конечно, как писал выше, также необходим базовый тренинг aka «неделя в супорте», который длится у все по разному в зависимости от исходных данных. Во время него разработчик работает в паре с опытным супортистом и делает обычный разбор линий, пишет сам ответы, получает корректировки по ходу дела и знакомится со всеми остальными секретами данного дела. Дальше плотный контроль потихоньку ослабевает. Если все хорошо, то разработчик идет уже сам в бой и со временем присмотр вообще становится не нужен. Некоторым ребятам вообще очень нравится отвечать тикеты так как приятно все таки общаться с живыми пользователями твоей фичи, получать благодарности, что даже просят иногда «подкиньте посупортить, а то давно не было»:-) — так что это вполне может быть дополнительной мотивацией к работе, тем более полезно менять сферу деятельности. Есть также вообще уникальные команды, где поддержку оказывают целиком дежурные разработчики (как писали выше в коментах), но это скорее исключение. В среднем по больнице, привлекать разработчиков мы стараемся только по реальной необходимости, такой как перегрузы или праздники (по договоренности/желанию разработчики могут выйти в праздники вместо коллег супортистов). Для этого координатор группы супорта продукта в начале дня (чтобы ребята могли лучше спланировать свой день и не переключаться лишний раз) выделяет тикеты на спец линию Developers Queue или «девку» — сей процесс мы даже шутливо называем «разогрев девки»:-)
Так как английский язык очень важен для нашего бизнеса (не только для супорта, но и тупо метод в классе нормально назвать, сделать ревию новой статьи в документации или понять о чем говорили на вебинаре с маркетингом), компания всячески мотивирует сотрудников на улучшение этого навыка (это даже упоминается в оценке уровней) и создает условия для его изучения (компенсации или курсы на базе офиса, причем супорту курсы вообще бесплатно и за счет рабочего времени). В своей команде я лично всегда ставлю поднятие уровня языка на ревию уровней молодым или проблемным ребятам. И это вроде действует — после осознания многие стали ходить на курсы/наняли репетиторов и прокачивают этот навык сами. Дай бог скоро совсем не будет переменных «needRepit» и шуток про «Минаков-стайл»:-)
Конечно, для ответов на тикеты для всех в компании есть специально обученные знатоки языка aka «корректоры» (местные и нативные), которые помогают с грамматикой, стилями и правильными коннотациями, перед тем как ответ уйдет клиенту.
Вроде все из основного — почти на статью получилось… Спрашивайте, если что интересует еще!
Действительно интересно, спасибо за то, что поделились ценным опытом привлечения dev к процессу контактов с клиентом — нам крайне интересна такая тема, т.к. иногда чувствуется необходимость «сблизить» клиентскую и инженерную стороны сервиса. Идея с «разогревом девки» и привлечением к работе в саппорте разработчиков очень понравилась :)
Ваши действительно достойны отдельной статьи, тема это всегда актуальна для ориентированных на клиента IT компаний, на мой взгляд.
Наверное, если разработка и саппорт у вас в компании так близки, не возникает особых сложностей в понимании нужд клиента и их адаптации в продукте. Всегда интересовал вопрос, каким образом лучше донести клиентские жалобы до ушей разработки — любой фидбэк из саппорта все же обычно воспринимается не слишком «близко к сердцу», но когда сам творец оказывается на передовой, то наверное и ответственность ощущается лучше.
Ваши действительно достойны отдельной статьи, тема это всегда актуальна для ориентированных на клиента IT компаний, на мой взгляд.
Наверное, если разработка и саппорт у вас в компании так близки, не возникает особых сложностей в понимании нужд клиента и их адаптации в продукте. Всегда интересовал вопрос, каким образом лучше донести клиентские жалобы до ушей разработки — любой фидбэк из саппорта все же обычно воспринимается не слишком «близко к сердцу», но когда сам творец оказывается на передовой, то наверное и ответственность ощущается лучше.
Павел, сложности есть всегда, и многое зависит от самих людей. По мне основной секрет успеха — это прививка ценности на уровне компании — люди должны понимать где и для чего они работают (опять же в «Put everyone on the front lines» главе из Rework от 37 signals неплохо расписано). Помимо передачи «кастомер-боли»/сценариев использования разработчикам, у нас само руководство, например, читает каждый отзыв в «Uninstall Feedback» письмах, налажена передача информации напрямую либо через мыл-листы и др. каналы, чтобы все были в курсе интересных вещей/серьезных проблем и могли формировать понимание, принимать решения. OKR опять же — тоже неплохой фреймворк в помощь для лучшего следования ценностям компании/трайба.
К разработчикам опять, есть такое неплохое летучее выражение: «Пиши код так, как будто в дальнейшем его будет поддерживать сумасшедший психопат-убийца, который знает, где ты живешь». На практике его пробовали реализовывать для некоторых особо важных новых фич даже путем технической поддержки самими разработчиками на протяжении нескольких месяцев после релиза. Так авторы еще лучше могут «прочувствовать» слабые места и оперативно выпускать обновления.
Удачи!
К разработчикам опять, есть такое неплохое летучее выражение: «Пиши код так, как будто в дальнейшем его будет поддерживать сумасшедший психопат-убийца, который знает, где ты живешь». На практике его пробовали реализовывать для некоторых особо важных новых фич даже путем технической поддержки самими разработчиками на протяжении нескольких месяцев после релиза. Так авторы еще лучше могут «прочувствовать» слабые места и оперативно выпускать обновления.
Удачи!
Спасибо, Денис, за обмен опытом, вам тоже удачи и успешной реализации планов! :)
Sign up to leave a comment.
На второй линии фронта: наш опыт развития технического отдела поддержки