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

Проблема

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

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

Моя команда использует Zendesk для отправки заявок в службу поддержки, и у нас уже есть приложение на этой платформе для сбора количества заявок, которые каждый человек выставлял одновременно. Это было полезно, но не давало целостной картины.

Введите очки истории.

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

Имея все это в виду, я собирался разобраться с улучшением этой метрики!

Работа

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

Для начала я обдумал варианты хостинга, не желая слишком усложнять ситуацию или полагаться на платформу хостинга, которая может нуждаться в собственном обслуживании. Я быстро решил использовать некоторые собственные функции моей компании Segment для написания кода для реализации этого проекта: Функции источника.

Исходные функции собирают данные через веб-перехватчик, а затем позволяют писать собственный код для изменения или анализа этих данных до того, как системы сегмента введут их в свой традиционный конвейер. Оттуда эти измененные данные могут быть отправлены вниз по течению подключенным адресатам. Хотя у Segment есть предварительно созданное подключение к Zendesk как уже установленному месту назначения, я не чувствовал, что это подходит для моего варианта использования. Подробнее об этом позже.

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

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

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

Насколько мне известно, в Zendesk нет поля, которое бы хорошо работало для хранения статических значений, поэтому я оставил примечание для своей команды, чтобы оно не редактировало это значение. Хотя с точки зрения того, как работает этот процесс, любое обновление на самом деле не имело бы значения и было бы просто программно изменено обратно по ходу дела. Я также поделился кодом, который определял значения баллов, с моей командой, чтобы они могли ссылаться на него, если число окажется выше или ниже, чем они ожидали, в зависимости от количества времени и усилий, которые они тратят на конкретный билет. Оттуда я также внедрил рабочий процесс Slack, чтобы помочь людям сообщать о заявках, где баллы не соответствовали фактической работе, которую они выполняли, чтобы помочь с калибровкой команды, чтобы система могла работать как можно более плавно.

Сам код состоит из объектов, содержащих все поля, доступные в Zendesk, и их значения в баллах (как определено командой) зависели от уровня сложности, как правило, связанного с ними:

Оттуда имеется логика для добавления баллов в зависимости от того, какие поля используются:

После этого делается запрос в пайплайн Segment с метаданными, чтобы результат процесса можно было просмотреть и проанализировать в нижестоящем хранилище:

Кроме того, в теле исходной функции создается исходящий запрос API для обновления Zendesk необходимыми данными. Эта функциональность выходит за рамки того, что предлагает Segment в своей готовой интеграции с Zendesk, поэтому потребовался специальный запрос к Tickets API Zendesk.

Со всем кодом и функциональностью API последняя часть этого проекта заключалась в том, чтобы собрать общее количество баллов в совокупности для каждого человека, что демонстрирует, сколько баллов у них есть за все их открытые, ожидающие и отложенные билеты вместе взятые:

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

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

Код

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

Что я выучил

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

Единственная часть этого, которую нельзя автоматизировать, — это добавление значений баллов для новых тем, которые появляются по мере роста конвейера Segment. Члену команды нужно будет решить, какое количество баллов добавить в зависимости от того, насколько легко или сложно та или иная тема. Таким образом, я недавно привлек новых членов команды, чтобы они проходили и вносили обновления там, где это имело смысл. Было здорово запустить этот проект, увидеть его ценность за последние пару лет, а затем найти других членов команды, которые были заинтересованы в поддержании и, надеюсь, развитии того, что я изначально заложил.