Comments 12
Судя по вашей же таблице, оптимизация деплоя(если я правильно понимаю что такое выкатка) может сэкономить больше времени и денег, чем внедрение системы управления инцидентами.
Тоже самое касательно работы с бизнес требованием и консультациями.
Попробую прокомментировать, чтобы не нарушить nda.
Изначальной задачей выделения сервиса и внедрения и организации работы с потоком были:
-создание управляемой системы
-создание прозрачности в том, как работа движется.
С целью снизить количество проблем и негатива клиентов и внутренних заказчиков, участвующих в процессе.
Различные бонусы в виде того, что нам стало понятно, сколько времени на каком этапе работа залипает, где какие зависимости и задержки появились в том числе благодаря этому.
Выкатка - да, тут имеется ввиду деплой. Дело в том, что так массово статистику по деплою особо не собирали до того, как мы начали собирать статистику именно в этом сервисе. Если масштабировать всю ситуацию на компанию, то там может быть приличная экономия. В разрезе данного сервиса мы в итоге прилично сэкономили благодаря оптимизациям в деплое.
Система управления инцидентами позволила сделать практически безпроблемное взаимодействие между службами поддержки и разработкой. То есть временные затраты на взаимодействие свелись к ревью 1 раз в месяц по 1 часу, где мы собирали обратную связь и вносили изменения в систему.
Где именно удалось сэкономить больше, а где меньше мы считать не стали, так как не было в этом нужды. Обратная связь от внутренних заказчиков и других команд, участвующих в процессах показала, что количество неудовлетворенностей друг к другу снизилось практически до нуля. В этом плане цель была полностью достигнута.
В целом гипотезу того, что оптимизациями можно сэкономить больше денег и времени, чем внедрением систем управления я понимаю. Оспорить или, наоборот подтвердить именно в данном случае, не могу. Спасибо за комментарий.
В Райфайзине "оптимизировали" работу чата, правда отзывы клиентов скатились с 5 до 1.5 баллов по пятибальной шкале от внедрения виртуальной ИИ женщины, которая не способна ни на один вопрос ответить, но судя по всему айтишники довольны они уже полтора года за её обучение получают деньги и видимо не малые и похоже эта работа постоянная, как у психотеропевта - пока банк не лопнет.
Хороший коммент. Вот прям понимаю о чем вы))) Мы следили за NPS и контекстом отзывов от реальных клиентов по нашей части. Из общей массы обращений ежемесячно их было не так много, но мы трепетно относились к тому, чтобы не просадить показатели. Наша система отсева показала себя хорошо и падения пользовательских оценок не было. В общем мы даже заметили положительную динамику в росте оценок касательно обращений в поддержку.
Профессиональный новояз силён! Деньги вам платят не зря.
Но мне больше всего интересно, как в своей деятелности вы собираете и учитываете мнения конечных клиентов о результатах ваших нововведений. Тех, кому приходится с ними сталкиваться и страдать от этого процесса?
Я хотел сказать своим комментом следующее. На первом этапе совершенствование интерфейсов общения с банками вызывали исключительно положительные эмоции, особенно если сравнивать отечественные с западноевропейскими, которыми мне пришлось попользоваться.
Личные кабинеты, платежи, отчёты о потраченных средствах... Всё на высшем уровне. Чаты с банковским работником...
Но вот после того как людей, отвечавших на вопросы из чата начали менять на ИИ, предварительно сократив, видимо для того чтобы оплачивать недешёвый труд дополнительных айтишников, а сам интерфейс оптимизировали под смартфон видимо так, что с компа им стало пользоваться невозможно начался уже полный треш.
Отрицательные отзывы недовольных клиентов напрочь игнорируются и ситуация не меняется уже скоро как третий год... Ожидание в течение получаса когда железяка наконец перестанет выдавать тебе абсурдные ответы и подключит к чату сотрудника банка доводит до белого каления, особенно с учётом того, что чат нельзя оставлять без присмотра в период ожидания - через пару минут коннект разрывается, необходимо снова набирать пароль, входить в систему и начитать новый этап общения с шелезякой.
Но мне больше всего интересно, как в своей деятелности вы собираете и учитываете мнения конечных клиентов о результатах ваших нововведений. Тех, кому приходится с ними сталкиваться и страдать от этого процесса?
Могу сказать, как на тот момент своей деятельности мы это делали. Сейчас я давно перешел на другие проекты.
Напомню - контекст в данном случае касается только решения инцидентов. Вопросами учета мнений о доработках и прочих изменениях в продуктах - занимаются отдельные владельцы продуктов.
Когда только мы запустили сервис, мы задались вопросом о том, как мы проверим, что конечным клиентом стало лучше/хуже/все равно.
Мы поработали по трём основным направлениям:
1.Стали внимательно следить за ежемесячными отчетами NPS - внимательно читая контекст в поисках отзывов людей, которые относились именно к нашей работе. Как я уже писал - таких отзывов было очень много.
По этой части были видны незначительные изменения, которые косвенно можно связать с нашими нововведениями. Отзывов о долгих ожиданиях решений проблем стало меньше (незначительно)
2.Далее я применял инструменты из f4p, а именно fitness box score (специальные опросники) на разной выборке людей для того, чтобы снять более контекстные данные. Специфика такого опроса подразумевала меньше эмоций и больше конкретики.
Здесь ничего значительного накопать не удалось, в основном были достаточно высокие оценки работы служб поддержки (быстрое решение вопросов и т.д.) что-то порядка 80%. По итогу fbs бросили, потому что трудозатратно.
3.Пробовали так же копать в оценки работы служб поддержки, которые оставляли клиенты, чтобы посмотреть, что они пишут.
Там были видны улучшения. которые в основном касались того, что теперь инцидент, который явно должен быть взят в одну из первых очередей (много ожидающих клиентов, сложно достичь своей цели в процессе) - действительно брался и решался в одну из первых очередей.
На самом деле, пробовали много всякого, но в сухом остатке я могу сказать следующее. Офигенно сложно в чистом виде получить мнения клиентов, напрямую связанные с теми изменениями которые мы сделали. Честно говоря, практически нигде я такого прям в живую не видел. Поэтому, в основном это косвенные признаки.
P.S. По поводу "профессионального новояза" не до конца понял, что вы имели ввиду. С вашего позволения спрошу в личке.
Спасибо за пояснения. Было интересно пообщаться с человеком "по ту сторону барьера". Получить "обратную связь" c репрезентативной выборкой в короткое время думаю действительно очень сложно.
В моём случае в конце общения в чате можно было нажать на кнопку доволен/ недоволен, но проблема заключалась в том, что когда через пол часа удавалось таки достучаться сквозь эту мерзкую ИИ барышню до реального оператора - человека, проблема решалась быстро и хорошо. Отдельно оценки барышне ИИ и человеку поставить невозможно. Ставить плохую оценку оператору рука не поднимается, он то свою работу выполнил на отлично. В результате естественно никакого толку от подобных оценок нет. Люди крайне раздражены идиотизмом нововведений, но ставят плюсик за работу оператора...
Оххх, так это реально печально. По сути мы выдаем желаемое за действительное, при этом еще и клиента в неловкое положение ставим. Я такое встречал в компаниях. Как правило это из-за фокуса только на задачи/проекты/работу. Без взгляда на ценность. Я эту тему здесь разводить не буду, пожалуй) Об этом готов в личке общаться с теми, кому интересно)
Интересный пример из жизни, спасибо, хотя подача немного тенденциозная.
такие инструменты, как Kaiten, действительно экономят много времени
Основной момент, который помог ускорить решение запросов, это сортировка задач, поиск и отброс неактуального.
больше 50% были неактуальными
И уже дальше начинается приоритезация, классы сервисов, WIPы и т.п. Это как сказать, что у меня дома стало чище благодаря роботу-пылесосу, когда одновременно с эти я перестал ходить по квартире в уличной обуви.
Подчеркну, что это не умаляет того факта, что внедрённые практики принесли пользу и вообще являются шагами в правильном направлении. Вопрос в акцентах.
Ну и вот эти 56% неактуальных запросов - это же очевидно пользовательская боль. Может, где-то пользователи натыкаются на "не баг, а фичу", где-то просто путаются в UI, но тем не менее. На запросы в поддержку нужно смотреть не только с т.з. траты ресурсов саппорта на их разрешение, но и на потерянное время для пользователей. В общем, было бы здорово "в следующей серии" почитать про решение этой проблемы.
Спасибо за комментарий. По поводу инструментов я написал честный дисклеймер. Да и когда писал статью предполагая, что это так может быть воспринято.
Я тут по факту вижу два основных вопроса:
1. Инструмент или практики помогли сделать изменения и добиться результата?
2. 56% неактуальных запросов - вдруг там действительно что-то важное и не было ли такого, что важное для клиента мы считали неактуальным.
На первый вопрос отвечу однозначно так: именно практики, такие ,как приоритизация, классы обслуживания, изменения договоренностей с командами и службами поддержки помогли сделать хорошие изменения. Инструмент в данном случае - это удобство реализации этих практик. Я старался акцентировать внимание на кайтен специально в разрезах его фишек и удобстве. Например, в других инструментах невозможно нормально реализовать такие вещи, как кластеризщция блокировок, сквозные классы обслуживания, удобные лимиты, несколько досок под разные нужды. Несколько графиков, которые можно выгрузить достаточно быстро и посмотреть, не колдуя с ексель. В общем, мой акцент был в этом.
По второму вопросу: мы взяли для себя матрицу ZeroBugPolicy, основанную, на количестве клиентов, которых затронул инцидент и работоспособности бизнес процесса. То есть, если один клиент столкнулся с косметической проблемой и оповестил нас, то это будет считаться неактуальным. Так же в неактуальные попадают запросы, которые на момент создания были действительными, но в момент проверки стали уже неактуальными (починилось, показалось и т.д.). Там много различных кейсов. Все описывать не буду. Такая система не идеальна и действительно может в каких-то случаях упустить из вида важные нгеобходимые доработки типа путаницы с UI и т.д.. Для этого по ходу мы внедряли несколько решений, таких как кластеризация таких одиноких запросов при взаимодействии с самими службами поддержки. Ретроспективный анализ всего входящего потока для выявления кластеров таких запросов. Передавали часть в продуктовые команды. Кое-где даже зарядили большой рефакторинг одной из систем, которая вызывала по паре десятков инцидентов в месяц.
В общем, тут действительно можно отдельную статью писать. Спасибо вам за комментарий, всегда интересен взгляд на написанное со стороны.
Коллеги, я вот на какую фразу обратил внимание :"мы отказываемся от работы над ним из-за его неактуальности или незначительности". А как вы это регламентировали? Ведь для того, кто этот тикет создал (часто внутренний заказчик) для него это важно. Да лично для него или его блока. Вы, может и понимаете что в масштабах всей системы этот тикет незначительный и его отработка встанет в несоразмерную сумму или затраты времени. Как тут поступаете?
Как это делали мы: концептуально - мы создали совместную гибкую и эволюционирующую система договоренностей (набор правил), собственно это одна из практик Канбан метода. Она выглядит как матрица классов обслуживания и приоритетов, на которой видно, что и по каким критериям занимает большую емкость команды, что меньшую, что берется в первый приоритет, что во второй, что не берется. Так же она включала в себя правила, какой тикет у куда создавать ,что в нем писать. Она прозрачная и понятная. Лежит на виду у любого сотрудника. Тут важно, что это не регламент. На специальной встрече мы отработали возражение, внесли корректировки и согласовали эту матрицу между всеми участниками процесса: службы поддержки, менеджеры, другие команды. Сделали специальную систему тегирования, по которой сразу видно, как приоритет поступил к ни на входящую доску. То есть внутри нашей компании любой прилетающий инцидент из Upstream доски уже с тегом и понятно, куда его пихать. Далее мы эту систему корректировали в зависимости от возникающих кейсов в системе. Целью было автоматизировать большую часть потока, чтобы менеджер принимал решение действительно по важным кейсам, а не по основной массе задач.
Конечно, там множество различных кейсов. Когда система считает ,что это незначительно, а на самом деле кто-то очень громко говорит, что это очень важно. Мы просто шли и разбирались ,в чем суть кейса, почему это важно или неважно и по необходимости вносили корректировки в систему. Примерно 99% всех случаев наша система договоренностей автоматизировала. В среднем осталось меньше 1 случая в месяц в среднем, когда было непонятно, куда положить ту или иную задачу.
Тут вопрос именно гибкости. Мы , как менеджмент были полностью открыты к диалогу, явно и прозрачно оповещали всех участников об изменениях, пропагандировали это в команды разработки.
В дальнейшем было желание выйти с подобной системой на диалог с клиентами и попробовать откорректировать нашу матрицу на основании обратной связи от них. Но я ушел оттуда раньше.
P.S. Я понимаю, что это общие слова. Если где-то есть уточнения - спрашивайте. Можете зайти в личку, я прокомментирую.
Как мы организовали поток входящих запросов от клиентов и снизили время их обработки с 12 до 7 дней