Все записи

Рецепты самопомощи аналитика: универсальная стратегия предотвращения ошибок

Оля — тимлид группы аналитики в Naumen Service Management Platform. Часто аналитики приходят к ней с разными вопросами. Например, как правильно работать с требованиями и общаться с разработчиками, почему не получается эффективно распределить время и приоритизировать задачи. Чтобы помочь команде решить сложности, Оля разработала стратегию самопомощи для аналитиков.

ОляГ.png

В статье она поделилась рецептами самопомощи и рассказала о некоторых ошибках и «красных флагах», которые помогают понять, что что‑то идет не так. 

1. Ошибка масштаба

Cитуация, в которой работа и сроки реализации проекта или продукта изменяются нелинейно и непредсказуемо из‑за масштаба их требований.

Как понять, что что-то делаем не так?

  • Чувствуем панику от задачи
  • Долго решаем проблему самостоятельно
  • Ощущаем перегруз

Рецепты самопомощи: как устранить ошибку масштаба

1. Декомпозировать — разбить сложный процесс, требования или задачи на управляемые шаги. Например, перед нами стоит задача на разработку решения. Заниматься будем следующим: проводить интервью, анализировать конкурентов, консультировать разработчиков и проектировать решения. Каждый из этих этапов можно разбить на небольшие шаги. Так увидим, что весь процесс может быть более управляемым и понятным.

2. Приоритизировать — ответить на вопрос, что сейчас важнее для бизнеса? Например, работаем с требованиями к продукту. Здесь можно обратить внимание на количество стейкхолдеров, проследить откуда больше всего проблем и к какой фиче много вопросов. Важно посмотреть на требования под разным углом и определить их приоритет.

3. Уточнить постановки задачи и своей зоны ответственности. Можно посмотреть регламенты, что делает аналитик, что разработчик, а что тестировщик. Спросить у наставника и руководителя. Если это наша зона ответственности, декомпозируем, приоритизируем и берем в работу. Если нет — отдаем тем, кто за это ответственный. 

4. Задать себе вопрос: «‎Чтобы что…?»‎. Всегда стоит задаваться универсальными вопросами: какую я достигну цель, выполнив это требование, или какую проблему решение этой задачи закроет. Это помогает сфокусироваться на приоритетных задачах и определить цель.

2. Ошибка заточения

Мы в своей работе всегда стремимся найти решение: прийти к определенному выводу, сделать прогнозы, составить требования к работе системы. Но иногда настолько сильно погружаемся во все эти процессы, что начинаем буквально жить поиском решения задачи. А когда находим — «‎влюбляемся»‎ в это решение. Так начинаем верить в свою правоту и отторгать альтернативные подходы. Это и есть ошибка заточения.

Как понять, что что-то делаем не так?

  • Ощущаем сверхуверенность в своей правоте
  • Сопротивляемся обратной связи
  • Игнорируем альтернативные решения

Рецепты самопомощи: как устранить ошибку заточения

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

2. Рассмотреть альтернативные решения. Даже если кажется, что правильное решение найдено, нужно рассмотреть другие подходы. Задать себе вопрос «А как еще можно достичь этих целей?». Я, например, сталкивалась с ситуацией, когда разрабатывать ничего не потребовалось, достаточно было просто поменять что‑то в процессах и таким образом решить проблему. Так мы нашли альтернативное решение, помогли достичь ценности заказчикам и сэкономили себе время. 

3. Расширить фокус. Стоит смотреть на свое решение с позиции наблюдателя — в этой ситуации мы не аналитик, а, например, заказчик. Получится подсветить детали, которые могут быть ключевыми. Сюда же я включаю постоянное обучение: митапы, лекции и общение с другими экспертами. Такие мероприятия расширяют наш кругозор и представление о возможных путях решений. 

4. Получать и принимать обратную связь. Не нужно бояться критики — коллеги могут заметить то, что мы пропустили. А еще всегда стоит задумываться над тем, откуда появилась такая привязанность и любовь к своему решению. Важно держать в голове, что наше решение — это не мы. Оно может быть правильным и неправильным, идеальным и не очень. Необходимо сохранять гибкость и активно собирать обратную связь.

3. Ошибка отсутствия зафиксированных договоренностей

К неверным заключениям и решениям мы можем прийти из‑за отсутствия договоренностей или недостаточного понимания всей картины.

Как понять, что что-то делаем не так?

  • Нет ни доказательств, ни аргументации, почему выбрали именно это решение 
  • Перекладываем ответственность
  • Откладываем подведение итогов на потом

Рецепты самопомощи: как устранить ошибку отсутствия зафиксированных договоренностей

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

2. Отдыхать и делать перерывы между встречами. Перерывы нужны для того, чтобы успевать фиксировать результаты созвона сразу же после встречи. Поэтому полезно закладывать 10–15 минут и за это время подготавливать информацию и рассылать ее участникам. 

3. Записывать встречи — это поможет освежить какие‑то моменты. Однако нужно время, чтобы пересмотреть запись, так что этот момент тоже необходимо учитывать. 

4. Применять «Правило двух минут» — если какая‑то задача занимает меньше двух минут, делаем ее прямо сейчас, прямо на встрече. Например, договариваемся вынести за рамки встречи какой‑то вопрос с заказчиком, лучше прямо на встрече открыть календарь и назначить встречу.

4. Ошибка неопределенности требований

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

Как понять, что что-то делаем не так?

  • Долго восстанавливаем контекст
  • Обращаемся к одним и тем же проблемам, но не получаем прогресс или решение
  • Не проверяем требования на противоречия, не налаживаем процесс управления ими

Рецепты самопомощи: как устранить ошибку неопределенности требований

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

2. Прототипировать — использовать техники раннего обнаружения проблем: обзор требований, моделирование и прототипирование. Это поможет нам выявить неопределенность и засинхронить контекст. 

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

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

5. Ошибка переполнения

Речь о перегрузе, когда у нас так много всего, что мы просто не понимаем, что с этим всем делать.

Как понять, что что-то делаем не так?

  • Берем в работу 15 пунктов, которые нужно выполнить за один день
  • Работаем над задачей только после определенного времени, чтобы никто не отвлекал
  • Чувствуем раздражение, любые вопросы от команды и участников проекта начинают триггерить

Рецепты самопомощи: как устранить ошибку переполнения

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

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

3. Сигнализировать руководителю и уточнять приоритеты. Не нужно пытаться решить все дела сразу и одновременно. В моей практике была ситуация, когда я занималась несколькими задачами и в какой‑то момент пришла к своему руководителю. Оказалось, что результат по одной из задач от меня ожидался только через месяц. Так я уточнила приоритеты и сроки, и мне стало спокойнее. А еще не стоит забывать о балансе работы и личной жизни. Планируйте не только работу, но и отдых. Добавляйте короткие перерывы и делайте разминку, это поможет поддерживать ум в легкости и спокойствии.

1290.png

Нет ничего страшного в том, чтобы совершать ошибки. Важнее то, как мы их исправляем. Нужно уметь смотреть в глаза своим промахам, знать «‎красные флаги» и вовремя использовать собственные рецепты устранения ошибок. 

Лучший универсальный рецепт для того, чтобы найти именно свои рецепты, «‎красные флаги» и решения, — рефлексия. Этот инструмент помогает проанализировать свое поведение, прошлый опыт, свои задачи. Полезно изучать свои подходы к решениям, ошибки и систематизировать знания в собственные рецепты и «‎красные флаги», на которые можно обращать внимание и предотвращать ошибки.

Похожие новости

Растем умом, а не числом

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

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

Frame 260л9109.jpg


Проблема: больше людей — больше хаоса

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

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

Почему так происходит?

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

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

Первая идея в такой ситуации кажется очевидной: «Давайте просто выделим каждому клиенту отдельного специалиста».

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

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


На чем строится культура обмена знаниями

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

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

Актуальность

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

Так в команде появилась роль куратора базы знаний. Его задача — не только проверять новые материалы, но и следить за тем, чтобы база знаний развивалась как единая система:

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

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

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

Доступность

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

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

image3.png

Признание

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

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

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

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

Ответственность

Сегодня в базе знаний около 500 статей. Проверять каждую самостоятельно уже невозможно. Поэтому ответственность за актуальность материалов постепенно стала общей задачей команды.

Если коллеги замечают устаревший скриншот, неработающую ссылку или неточное описание, они сообщают об этом мне. В зависимости от объема изменений я обновляю материал сама или передаю его одному из авторов.

Сейчас у нас 15 активных авторов, заместитель куратора базы знаний, а статьи обновляются по мере необходимости: в среднем по две-три в неделю.


Что помогает нам переиспользовать знания

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

Многие из этих решений довольно простые. Именно поэтому они и работают: сотрудникам не нужно менять привычный процесс или помнить о каком‑то дополнительном инструменте — знания становятся частью ежедневной работы.

База знаний

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

Поэтому мы разделили базу знаний на две части:

  1. Закрытый раздел для сотрудников — внутренние инструкции, документацию по порталу поддержки, регламенты, скрипты, технические настройки.
  2. Открытый раздел для клиентов — инструкции по работе с продуктами, ответы на популярные вопросы, лучшие практики.

Кроме разделения на открытую и закрытую части, система учитывает, какие продукты использует клиент. Благодаря этому пользователь видит только релевантные статьи.

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

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

Шаблоны комментариев

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

Так появились шаблоны комментариев. Они помогают уже в первые 10–15 минут дать клиенту подробный ответ, проверить базовые сценарии и собрать необходимую информацию до подключения инженеров.

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

image1.png

ML

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

  • Анализ эмоционального фона

ML анализирует комментарии в заявке и определяет общий эмоциональный фон общения — позитивный, нейтральный или негативный.

Если система видит потенциально конфликтную ситуацию, отдел Customer Success может подключиться к работе раньше и помочь не доводить разговор до эскалации.

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

  • Краткое содержание обсуждений

Еще один сценарий — подготовка краткого содержания длинных обсуждений.

Для этого в карточке заявки есть отдельная кнопка: специалист может обратиться к ИИ‑ассистенту, выбрать готовый промт и получить результат прямо в заявке. Раньше на это могло уходить около получаса. Сейчас — в среднем 3–5 минут.

  • Поиск похожих кейсов

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

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

  • Комментарии по клиентам

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

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

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

  • Система рекомендаций

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

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


Какую пользу мы в итоге получили

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

Быстрее решаем типовые вопросы

Раньше на вопрос вроде «Как добавить новую колонку в список заявок?» специалист в среднем тратил около 25 минут, а стажер — почти час. Причем значительная часть времени уходила не на решение самой задачи.

Сейчас достаточно открыть готовую статью из базы знаний — и такой вопрос обычно закрывается примерно за минуту.

Клиенты чаще находят ответы самостоятельно

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

Удается сохранять качество поддержки

Количество обращений продолжает расти, но средняя оценка работы с клиентами остается на уровне 4,9+.

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

Новички быстрее начинают работать самостоятельно

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

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


Вместо заключения

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

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

Главное — сделать так, чтобы знания не оставались в голове одного человека. Со временем даже небольшие решения начинают складываться в единую систему. Именно так произошло и у нас.

Claude Code: ИИ-помощник

Claude Code — ИИ-агент от Anthropic, который устанавливается на ваш компьютер. Он работает с файлами напрямую: видит папки, открывает документы, редактирует код. В браузерной версии ИИ такого нет, поэтому Claude Code может решать много оперативных задач. В статье собрали инструкцию: как установить и чему можно научиться.

Почему хорошие вопросы ценятся не меньше хороших ответов

Вопрос может направить работу в нужную сторону, а может растянуть обсуждение на несколько кругов уточнений. Часто все упирается не в сложность задачи, а в то, насколько понятно сформулирован запрос.

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

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

Все новости