Система инцидент менеджмент что это такое
«Инцидент менеджмент»: как власти следят за негативом в соцсетях
Программа в тестовом режиме действует с октября 2017 года.
По сообщению «РБК», Кремль запустил программу мониторинга реакции региональных властей на жалобы россиян в соцсетях. К 2019 году разработанную ООО «Медиалогия» систему распространят по всей стране.
«Инцидент менеджмент» будет следить за инфоповодами в соцсетях (например, во «ВКонтакте», Facebook, Instagram, Twitter, «Одноклассниках») и за тем, насколько позитивно будут восприниматься сообществами действия местных властей. О тестировании программы изданию сообщили источники в двух регионах и подтвердили три неназванных ньюсмейкера, близких к Кремлю.
Региональный чиновник рассказал, что на презентации автоматизированной системы «управления реакцией на негативные мнения» (и инфоповоды в соцсетях) рассказали о том, что это браузерная программа, то есть тот, кто ей пользуется, на компьютер не устанавливает дополнительное программное обеспечение.
Мониторинг осуществляется по ключевым запросам. Программа нацелена на поиск негативных сообщений, жалоб, вопросов, отзывов, благодарностей. Результаты поступают к региональному администратору (как правило, это сотрудник информационного управления правительства региона), который фильтрует необходимую для реагирования властей выдачу.
В зависимости от масштаба проблем информация далее сортируется по профилям министерств или муниципалитетов, чиновники должны отвечать в соцсетях, «Инцидент менеджмент» агрегирует их ответы через администратора.
Несколько постов с одной темой администраторы смогут объединять в кейсы, называемые «инцидентами». По отработанным или проигнорированным «инцидентам» статистику смогут наблюдать в администрации президента, а также на уровне муниципальных и региональных администраций. Отрабатывать «инциденты» чиновникам придется не позднее 24 часов с момента их возникновения.
В администрации президента этим направлением заведует управление по общественным проектам, которое курирует первый замруководителя администрации Кремля Сергей Кириенко.
PR-директор «Медиалогии» Надежда Жуковская уточнила, что Кремль не является клиентом компании, региональные министерства и ведомства заказывают систему напрямую. «Медиалогия» подтвердила, что разработала данное ПО и ведет поставку в регионы. Изначально система делалась под бренды, которым необходимо управлять репутацией в соцсетях. Ранее «Инцидент» использовался, например, ПАО «Ростелеком», стоимость годового контракта тогда составила 8,5 миллионов рублей.
Необходимость уделять больше внимания негативным сообщениям в соцсетях появилась после трагедии в кемеровской «Зимней вишне». В Кремле хотят локализовать негатив и контролировать повестку именно в соцсетях, по словам неназванного собеседника издания.
Пилотную версию «Инцидента» сперва опробовали в Подмосковье в октябре 2017 года, а уже в марте 2018-го начали внедрять по регионам, в первую очередь там, где в сентябре пройдут выборы губернаторов. Издание напомнило, что в единый день голосования 9 сентября 2018 года пройдут дополнительные выборы семи депутатов в Госдуму и прямые выборы глав в 22 регионах, в том числе в Москве и Подмосковье. Еще в 4 субъектах глав регионов выберут парламентарии. В 17 субъектах выберут региональные законодательные органы.
Министр правительства Московской области по информационной политике Анастасия Звягина рассказала, что в пилотном проекте мониторингу подверглись все вышеназванные соцсети плюс YouTube – отработка составила более 3 тысяч эффективных публичных групп 7 дней в неделю.
«К процессу отработки негатива в социальных сетях на сегодняшний день привлечены все министерства, ведомства и муниципальные образования региона. От каждого муниципалитета и ведомства закреплены ответственные по работе с социальными сетями и конкретно в системе «Инцидент», – отметила министр. Она подтвердила, что еженедельно анализируется статистика запросов и ответов участников системы, формируется карта «горячих точек».
Оказалось, жителей области больше всего интересуют вопросы по благоустройству территорий, ЖКХ и ремонту дорог, затем идут проблемы строительства и экологии.
Внедрение «Инцидент менеджмента» приведет к росту нагрузки на чиновников, их ответы будут однотипными, считает директор Центра экономических и политических реформ Николай Миронов. По его словам, многие проблемы не могут быть решены на региональном уровне из-за нехватки средств или отсутствия компетенции – это почти весь блок, связанный с бедностью, недостатками социальной инфраструктуры, тарифами.
«К тому же неясно, как региональные власти ответят на жалобы в связи с федеральными инициативами повышения НДС и пенсионного возраста», – резюмировал политолог.
Вселенная советов
Система «Инцидент менеджмент»: как сообщить о своей проблеме
Решать возникающие проблемы в городах и сельской местности в наши дни надо оперативно. А для этого необходимо, чтобы жители проблему «озвучили», то есть разместили о ней сообщение в социальных сетях. После этого в работу включается система «Инцидент менеджмент», которая и проследит за тем, чтобы проблема была решена местными властями.
«Инцидент Менеджмент» — система мониторинга, разработанная компанией «Медиалогия». Её основная цель — быстрое реагирование на темы, которые поднимают пользователи соцсетей. Система выявляет и собирает значимые сообщения: негативные оценки, жалобы, вопросы, отзывы, благодарности. Программа в основном мониторит пять популярных в России площадок: «ВКонтакте», Instagram, Facebook, Twitter и «Одноклассники».
Система «Инцидент менеджмент»: как сообщить о своей проблеме
Как работает система «Инцидент Менеджмент»
Система анализирует ключевые слова в пяти соцсетях. Результаты отправляются региональному администратору. Он решает, какие проблемы наиболее острые и требуют реакции представителя власти.
Если по одной теме появляются посты в нескольких соцсетях, то их объединяют в один кейс или «инцидент».
А вот кому его передадут (местным депутатам или министрам), определяет масштаб проблемы. Публично ответить на запрос нужно в течение суток. Проигнорировать проблему местным депутатам или министрам не удастся, поскольку у сотрудников Администрации Президента РФ тоже есть доступ к системе.
Эксперты отмечают, что система не фиксирует негатив вообще, а фокусируется на конкретных вещах. Поэтому её нельзя отнести к политическим системам мониторинга. Она больше административная: отмечает «конкретные претензии конкретного гражданина к конкретной проблеме». «Инцидент Менеджмент» — проект многообещающий. В итоге система должна создать условия для прямой коммуникации местной власти и общества, повысить уровень контроля над чиновниками, сделать управление в регионах более эффективным.
Источник — Проект SFERA Live
Как сообщить о своей проблеме
Сейчас мониторинг ведется в Instagram, Вконтакте, Одноклассники, Facebook и Twitter. Запросы в зависимости от тематики распределяются по районам и региональным министерствам.
«Озвучить» свою проблему можно на интернет-страничках глав муниципалитетов, руководителей местных организаций в социальных сетях.
Не обязательно писать первому лицу региона, чтобы добиться результата. Главное, попасть в «Инцидент», а дальше система уже приведет к нужному итогу.
Если вы хотите, чтобы ваше обращение гарантированно попало в систему «Инцидент менеджмент», необходимо указать конкретный адрес, свои контакты и четко обозначить проблему.
В течение суток ответ на комментарий, в котором была обозначена проблема, рассмотренная системой «Инцидент Менеджмент», публикуется в соцсетях.
«Как близнецы»: 3 пары похожих терминов ITIL
Библиотека ITIL — подробный набор методов управления ИТ-услугами, который применяют с восьмидесятых годов. Но путаница в используемых терминах и их значении до сих пор преследует тех, кто только начинает внедряет у себя соответствующие методологии.
В этой статье мы попытаемся разграничить три пары похожих терминов:
Инцидент и проблема
IT-специалист и автор тренингов по ITIL Майкл Скарборо (Michael Scarborough) подчёркивает, что между терминами установлена следующая зависимость: проблема — причина, инцидент — следствие.
Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. Когда мы говорим «разрешили инцидент», это значит, что временно восстановили какую-то услугу (на 10 лет или всего на 1 минуту). То есть очень вероятно, что подобная ситуация повторится в будущем.
Проблема же, это причина возникновения инцидентов. Эксперт в области ITSM профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему», который вы задаёте себе.
Посмотрим на примеры, которые приводит директор по маркетингу компании Hornbill Питер Саммерс (Peter Summers).
Инцидент: пользователь звонит в службу поддержки и сообщает, что не может распечатать документ. Специалист, который принимает вызов, обнаруживает, что указанный файл вызвал ошибку в очереди печати. Чтобы можно было продолжить работу, специалист предлагает пользователю временно воспользоваться принтером в соседнем офисе.
Проблема: инцидент с принтером — признак глобальной проблемы. Этот пользователь — первый из многих, кто позвонит сегодня в службу поддержки. Допустим, удалось установить, что причиной инцидентов является обновление офисного ПО прошлой ночью. Если исправить баги апдейта, проблема будет решена и отказов в печати по этой причине больше не будет.
Для наглядности возьмём более приземлённый пример. Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.
Другой пример: вы едете на лысой резине — это проблема. Если вы продолжите её игнорировать, вероятность возникновения инцидента будет расти, покрышка, вероятно, лопнет.
Чтобы упростить вопрос с разграничением значений этих двух терминов, Филип Юсон (Philip Yuson), генеральный директор Concept Solutions Corporation, рекомендует задавать следующие вопросы:
Incident Management и Problem Management
Мы уже выяснили, чем отличаются инцидент и проблема, поэтому разграничить эти два процесса будет проще. ITIL определяет эти два термина следующим образом:
Управление инцидентами — управляет жизненным циклом всех инцидентов. Цель: скорейшее восстановление ИТ-услуги для пользователей.
Управление проблемами — управляет жизненным циклом всех проблем. Цель: предотвращение инцидентов в будущем.
Посмотрим на примеры от специалистов Microsoft. Представим сценарий: к специалисту техподдержки обратился пользователь, который не может просмотреть электронное письмо из-за ограничений. Саппорт создаёт новый инцидент с помощью шаблона e-mail incident, чтобы быстро разрешить ситуацию и обрабатывать похожие случаи в будущем.
В сценарии управления проблемами специалист техподдержки создаёт запрос на внесение изменений в код. Когда команда найдёт и устранит причину проблемы, это разрешит проблему и автоматически устранит инциденты с ней связанные.
Для большей ясности приведём пару примеров из жизни. Управление инцидентами похоже на работу пожарных. Они приходят на место происшествия и стараются максимально эффективно погасить огонь. То же самое происходит при управлении инцидентами. Возобновить работу инфраструктуры нужно быстро.
Далее начинается управление проблемами и детальное расследование происшествия. Этот процесс похож на работу эксперта или следователя. Он не был на месте, когда тушили пожар, но может определить причину возгорания и дать рекомендации, которые позволят избежать таких ситуаций в будущем.
Service desk и Helpdesk
Для начала вновь заглянем в официальную терминологию ITIL.
Service Desk — единая точка контакта (SPOC) между поставщиком услуг и клиентами. Функции: управляет инцидентами, запросами на обслуживание.
Help desk — точка контакта для пользователей. Функции: регистрирует инциденты.
Термин «служба поддержки» часто употребляется как синоним службы Service Desk, что является главной причиной путаницы в терминах. Крис Коффи (Cris Coffey), менеджер по маркетингу компании BMC Software, который работает на рыке Help Desk уже 20 лет, выделяет следующие различия между двумя этими службами.
Service Desk: полностью интегрируется с другими ITSM-процессами, помогает организации соответствовать соглашениям об управлении уровнем услуг, интегрируется с базой данных управления конфигурациями и процессом управления активами.
Help Desk: отслеживает все входящие инциденты, автоматически отслеживает уведомления по электронной почте, предлагает ограниченную интеграцию с другими ITSM-процессами, предоставляет услуги самообслуживания для конечных пользователей.
Посмотрим, как это выглядит на практике. Пример работы Help Desk: драйвер для принтера Джо сломался, а ему нужно распечатать копии документов до 10 часов. Help Desk поможет Джо восстановить работу принтера или найдёт другой способ получить распечатки вовремя. Задача службы — сделать так, чтобы распечатки были в руках у Джо до 10 часов.
В той же ситуации Service Desk заметит, что за прошедшую неделю несколько человек с этого этажа обратились в службу с той же проблемой. Это значит, что проблема — глубже, чем кажется. Service Desk отправляет специалиста, чтобы установить корень проблемы с принтером. Задача службы — устранить первопричину.
Напоследок кратко обобщим все разобранные моменты:
Кремль мониторит соцсети: Зачем нужна новая система «Инцидент»
На базе «Медиалогии» разработан и уже тестируется новый сервис отслеживания контента в социальных сетях «Инцидент». Он будет мониторить жалобы сограждан. Внедрение по всей стране рассчитывают сделать на следующий год. Как это будет устроено процедурно и технически?
Полное название системы — «Инцидент менеджмент». Работать она будет в пяти социальных сетях: ВКонтакте, Facebook, Instagram, Twitter и Одноклассники. Сам мониторинг будет устроен наподобие «медиалогического» — по ключевым словам. Работать это всё будет прямо из браузера, то есть полный доступ к данным будет только у «Медиалогии».
После того как проведут мониторинг, его результаты попадут к региональному администратору. Обычно это коллеги из информационного управления правительства того или иного региона. Именно этот человек будет решать, нужно ли отвечать на жалобу. Дальше, если принято положительное решение об ответе, жалобы сортируют по уровням ответственности: от региональных министерств до муниципалитетов. Ответственные должны будут отреагировать на сообщение в социальной сети. И результат будет автоматически приходить региональному администратору в рамках этой системы.
Конечно же, будет и статистика. И достаточно подробная. Сколько приняли вопросов, сколько из них обработали, в какой срок. Предполагается, что на региональном уровне ответ должен быть дан в течение суток. Вся, кстати, статистика по каждому региону будет видна в администрации президента. А одни и те же темы в разных социальных сетях будут объединены в рамках системы в кластер и названы «Инцидент». Ответ будет рассылаться от госструктур автоматически во все сети.
Занятно, что изначально цель системы — работа на коммерческие компании. Например, в декабре 2017 г. Ростелеком заплатил 8,5 млн рублей за годовой контракт на эту систему. Что, кстати, вполне логично для оператора, так как недовольство сервисом провайдера — достаточно частая жалоба в Сети. И их принято отрабатывать сегодня отделами SMM, но осложняется всё тем, что пользователи далеко не всегда отмечают провайдера хештегами или цитированием в своих сообщениях.
На сегодняшний день есть три категории бизнеса, которые наиболее успешно работают именно в социальных сетях — это банки, сотовые операторы и интернет-провайдеры. Для всех трёх категорий это возможность сократить затраты на call-центр и дать пользователям инструмент писать в компанию в удобной для них среде. Кроме того, это асинхронность ответа, что даёт возможность обслужить большее количество клиентов.
В случае работы «Инцидента» на государственные структуры логика совершенно другая. Во-первых, сегодня, по слухам, внедрение такой системы дано на откуп конкретным регионам. Будет учтена региональная специфика. Во-вторых, тут логика внедрения — не столько сокращение затрат, сколько получение наиболее полной картины происходящего в регионах и протестные настроения. То есть предотвращение социального взрыва.
Если говорить о стоимости разработки подобной системы, несколько системных архитекторов на условии анонимности рассказали Царьграду, что сумма кратно меньше стоимости разработки самой «Медиалогии» как головного бизнеса. На основе этих разработок и стартовал «Инцидент». По разным оценкам стоимость создания «Медиалогии» — 10 млн долларов и три года работы. Исходя из этих цифр, комментаторы указывают на то, что это мог быть год работы и кратно меньшая сумма, где-то до миллиона долларов.
Но основная техническая проблема — это даже не поиск ключевых слов или обработка текста иным способом. Это выводы, которые можно сделать из сообщения. Это тональность выступления, технические данные, наиболее полный поиск в условиях того, что пользователи склонны писать с ошибками, без знаков препинания, иногда они вообще получают искажённые данные.
Также это необходимость определять информационные атаки и правильно на них реагировать. Ведь одной из причин внедрения как раз стала трагедия в «Зимней вишне» в Кемерове. Когда украинский пранкер под псевдонимом Евгений Вольнов (настоящее имя Кувиков Никита Андреевич) распространял фейк о том, что число погибших идёт на сотни. Это всколыхнуло местные социальные сети так, что некоторые до сих пор не доверяют официальным данным. Такая техническая возможность отличить информационную атаку от настоящей жалобы — одна из самых сложных задач системы.
Другой вопрос, если мы говорим о социальных сетях, у пользователя есть возможность удалить свой пост. Например, под давлением местных чиновников. Если это были отечественные социальные сети, да, доступ у правоохранительных органов в упрощённом порядке, можно будет легко восстановить картину. А если это будет Facebook, Twitter или Instagram? Американские социальные проекты крайне неохотно, скажем так, реагируют на попытки регулирования и мониторинга из России.
И ещё один момент. Важно, станет ли процедурно и документально обязывающей история реагирования на социальные сети. Сегодня законный механизм «электронного» волеизъявления в Рунете — это проект «Российской общественной инициативы», roi.ru. Он работает как с федеральными, так и с региональными проблемами. Есть ГИС ЖКХ, которая собирает проблемы домового фонда граждан в электронном виде. Есть «Госуслуги». Но во всех этих проектах нужно логиниться через ЕСИА, чтобы подтвердить свою личность. Это создавало как возможности, так и ограничения.
Инцидент-менеджмент для самых маленьких: как мы учили поддержку и разработку работать сообща
Привет, хабр! Меня зовут Полина. Я несколько лет занималась настройкой и развитием инцидент-менеджмента для eLama.
Благодаря работе нашей команды управление инцидентами с уровня «сообщения техдиру в мессенджере» поднялось до регламентированного и прозрачного процесса, который учитывает особенности поддерживаемого продукта и отвечает потребностям бизнеса.
В этой статье я размышляю над некоторыми вопросами, которые занимали меня саму на разных этапах работы над процессом. Например, могло ли введение регламента [работы с инцидентами] быть менее болезненным для всех сторон? О чем можно было позаботиться раньше? Возможно, кому-то будут полезны выводы, к которым я пришла.
Приоритет – всему голова
На мой взгляд, приоритет – одна из самых важных категорий в контексте работы с инцидентами. Пожалуй, даже самая важная.
В нашем случае приоритизация начала зарождаться на стороне поддержки. Менеджеры отдела стали разделять проблемы на срочные и несрочные. Это учитывалось специалистом, который передавал информацию о некорректной работе системы в разработку – срочные репорты обрабатывались в первую очередь. Но что с ними происходило на стороне разработки, для саппорта оставалось загадкой.
На этом этапе не были учтены, как мне кажется, наиболее важные аспекты работы с приоритетами. Во-первых, определение приоритета не должно выполняться «на глаз». Во-вторых, в приоритетах должны мыслить все участвующие стороны, как минимум, разработка и поддержка.
О критериях
Критерии определения приоритета проблемы в каком-то смысле первичнее списка возможных приоритетов. На начальном этапе работать можно даже с двумя приоритетами. Например, критичным и нормальным. Гораздо важнее прописать, как определить, к какому из них отнести конкретный инцидент.
В части критериев, как мне кажется, нет универсальных решений, потому что должны быть учтены особенности продукта и потребности бизнеса. Вот два простейших примера.
У вас B2C-сервис, которым пользуется множество небольших клиентов. В этом случае показательным может быть количество заафекченных пользователей.
Совсем другое дело, если вы разрабатываете узкоспециализированную платформу для бизнеса. Возможно, у вас не много клиентов, и каждый составляет значительную долю в конечной прибыли компании. В такой ситуации проблема, которая затронула даже одного клиента, может иметь наивысший приоритет.
С течением времени и список приоритетов, и их критерии могут меняться. Например, в первой итерации процесса у нас было 5 приоритетов – highest, high, medium, low и lowest. Последний отпал в ходе эволюции, потому что для него не нашлось применения на практике.
Приоритет конкретной проблемы тоже изменчив. Он может стать выше или ниже по мере наблюдения за количеством ошибок, обращений от пользователей, потенциальным риском и так далее.
Главный профит работы с четко прописанными приоритетами для нас был в том, что как минимум серьезные проблемы не оставались без внимания. Когда все обращения льются в одном потоке, критичную для бизнеса ситуацию можно упустить.
Второй важный плюс такого подхода – мы перестали отвлекать своих разработчиков на каждую мелочь. Если проблема не критичная, значит, ее обсуждение можно отложить до ближайшей планерки, PBR или передать на проработку продакт-менеджеру.
О синхронности
Таблица приоритетов, с которой мы работаем сейчас, является общей для всех отделов, при этом в регламенте есть четко описанный флоу для каждого уровня критичности. Поэтому когда инциденту присваивается определенный приоритет, все стороны знают, что будет происходить дальше и какие есть ожидания относительно их работы.
До введения таблицы приоритетов в моей практике был кейс, когда реакция на крайне серьезную проблему со стороны программистов была долгой. Это случилось потому, что изначально разработка не поняла, насколько критична ситуация. Поддержка в то же время была уверена, что всё под контролем и из-за загруженности входящими обращениями не запрашивала апдейта по текущему статусу. Если работать в рамках понятных для всех сторон приоритетов, такого недопонимания не возникнет.
Я думаю, что попробовать работу по четко прописанным приоритетам можно и нужно, даже если вы еще не работаете с багтрекинговыми системами и даже не регистрируете инциденты. Да, у вас не будет наглядной иконки на тикете, но настройка бизнес-процессов — это, в первую очередь, про мышление и коммуникацию. Инструментальные решения на этом этапе могут быть самыми разнообразными в зависимости от ваших вводных.
Программистский для начинающих
В идеальном мире все инциденты предупреждаются до того, как о них узнали внешние пользователи: системы мониторинга и алертов работают бесперебойно, а дежурные разработчики реагируют молниеносно. Безусловно, это то, к чему стоит стремиться. Но, к сожалению, в действительности так работает далеко не всегда, и бывает, что команды узнают о проблемах от поддержки, а те, в свою очередь, от пользователей.
Здесь важно отметить, что наши продукты поддерживает клиентская служба, которая помимо обработки обращений о багах и проблемах в работе сервиса, решает еще огромное количество различных вопросов. Работа с инцидентами составляет лишь часть их текущих задач. Подобный формат – особый, но не редкий случай.
Изначально вся коммуникация между саппортом и разработкой велась через чат. Как я уже упоминала выше, за передачу информации о проблемах, отрепорченных пользователями, отвечал один конкретный сотрудник поддержки. Его основная суперсила была в том, что он мог сформулировать проблему на понятном для разработчиков языке и перевести менеджерам обратную связь от команды. А еще, в допандемийные времена, добежать до отдела разработки, если на проде возникла серьезная проблема, чтобы обсудить детали голосом.
Такой подход имеет право на существование, но, на мой взгляд, только как временное решение. Во-первых, чат, хоть и сохраняет историческую информацию, не может рассматриваться как способ регистрации проблем. Но об этом мы поговорим в другой части статьи. Во-вторых, наличие отдельного человека на такой роли создает серьезный bus-фактор.
О поиске общего языка
На начальном этапе ввода процесса я много времени посвятила тому, чтобы научить коллег из поддержки описывать проблемы и предоставлять полный набор необходимой разработчикам информации.
Вместе с ребятами из технического отдела мы определилили, какие данные нужны для первичной диагностики. На основе этой информации и личного опыта общения с разработчиками я составила программу и провела очные встречи для сотрудников саппорта. Такая же встреча есть в онбординге всех новичков.
Чтобы держать ребят в форме, у нас есть подробная инструкция, к которой можно обратиться, чтобы освежить знания, а также дополнительная встреча для более опытных сотрудников. На ней мы разбираем конкретные примеры тикетов, составленных саппортом, и отмечаем, что было описано хорошо, а что можно улучшить.
Анализируя свой опыт, я поняла, что изначально, до внедрения процесса, подходила к этому не совсем правильно. Когда ко мне обращались с проблемой, я предлагала объяснить «как умеешь», а еще лучше просто показать проблему в интерфейсе и после уже сама переводила информацию в нужный формат для разработчиков. Это рабочий, но недальновидный способ решения проблемы.
Позже мы перешли к формату, где поддержка составляла тикет, а я его корректировала и давала автору обратную связь. Благодаря этому, ребята постепенно освоилили азы языка разработчиков и начали не только лучше формулировать проблемы, но и сами понимать программистов.
Безусловно, это не избавило нас от bus-фактора. Процесс работы с инцидентами по-прежнему координируется и, если честно, я не могу с уверенность сказать, может ли быть иначе. Но процент времени, которое затрачивает инцидент-менеджер непосредственно на переписывание тикетов, значительно сократился.
Опять же – здорово, если у вас уже есть инструменты для упрощения и автоматизации процесса. Например, мы, пользуясь возможностями багтрекинговой системы, кастомизировали форму создания инцидента и для наглядности добавили разные типы тикетов в зависимости от содержания проблемы. Однако это произошло далеко не в первую итерацию процесса. Даже сообщения в чат с разработкой можно и нужно составлять по уму.
Тестировщик в беде не бросит
Выше я уже писала о том, что на некоторых этапах работа с инцидентами замыкается на том, кто ее координирует, в нашем случае – на инцидент-менеджере. Это плохо для компании, потому что важнейший бизнес-процесс завязан, по сути, на одном конкретном человеке. Да и сам сотрудник быстро понимает, насколько такая «незаменимость» может быть неудобна.
О скрытых ресурсах
В самом начале предполагалось, что проблема bus-фактора будет решена назначением второго инцидент-менеджера. Позже стало понятно, что в нашем случае два человека на этой роли – решение не совсем целесообразное.
В какой-то момент ребята из команды тестирования сами предложили свою помощь. И это было хорошей идеей по многим причинам.
Во-первых, работа с инцидентами тесно связана с отлавливанием некорректного поведения систем, локализацией проблем и написанием багрепортов. Никто не знает об этом больше, чем QA-специалисты.
Во-вторых, находясь на периферии обращений о некорректной работе продукта, тестировщики могут быстрее узнавать об ошибках на бою.
Ну и в-третьих, тестеры в курсе многих багов, которые уже были обнаружены в функционале, но еще не исправлены, и могут фильтровать входящие обращения, чтобы избежать дублирования и лишней работы.
О форматах взаимодействия
Традиционно в нашей команде тестировщиков есть специалист, который полностью берет на себя координацию процесса на случай отсутствия инцидент-менеджера. Этот тестировщик обладает не только специальными знаниями, но и глубоко погружен в сам процесс. Кроме этого, на обычной неделе выделяется день, когда он дежурит в роли инцидент-менеджера, что позволяет оставаться в контексте и высвобождает для основного координатора процесса немного времени на работу по другим задачам.
Остальные тестировщики тоже участвуют в процессе – подхватывают часть входящих обращений по своей функциональности и снимают таким образом некоторую нагрузку с дежурного инцидент-менеджера.
Безусловно, работа с инцидентами не является основным фокусом команды QA, да и не всем подошел такой формат. Но даже то участие, которое по мере своих возможностей принимают в процессе заинтересованные тестировщики, в нашем случае обеспечивает достаточную поддержку процесса и ослабляет bus-фактор.
С чего начинается инцидент-менеджмент
Ранее я упоминала, что какое-то время коммуникация между представителями поддержки и разработкой велась только через чат. В самом общении в чате нет ничего плохого, зачастую при помощи него удается решить вопрос быстрее, чем, например, через комментарии в тикете.
Но мой опыт подсказывает, что именно с систематической регистрации инцидентов начинается настройка полноценного бизнес-процесса. Того, что с регламентами, автоматизацией и агрегированными статистическими данными, на которые бизнес сможет опираться при принятии решений. Можно, конечно, регистрировать инциденты, имея совершенно не налаженный процесс. Но наладить процесс, не фиксируя инциденты хоть в каком-то виде, представляется мне сложно выполнимой задачей.
До того, как мы стали решать этот вопрос на уровне всей команды, я предложила решение для поддержки – не писать о проблемах мне напрямую, а заносить их в таблицу. Даже это, возможно, не самое изящное решение причинило много добра.
Во-первых, занесение проблемы в табличку означало, что оно не потеряется, в отличие от личного сообщения.
Во-вторых, у таблицы была шапка и названия столбцов подсказывали заполняющему, какие данные нужны, чтобы репорт можно было взять в работу для первичной диагностики. Именно тогда у проблем впервые появился такой атрибут, как приоритет.
При этом, на тот момент мы воспользовались теми ресурсами, которые уже были в команде, то есть не потратили никаких дополнительных средств.
Спустя достаточно продолжительное время данные, которые сохранились в табличке, понадобились нескольким отделам. Мы не предполагали, что такая необходимость появится, но оказались к ней готовы.
Признаюсь честно, что это произошло непреднамеренно, но та табличка, в том числе, подготовила почву для перехода на автоматизированный процесс работы с инцидентами через багтрекинговую систему. Менеджеры на личном опыте узнали, насколько удобно видеть в одном месте все отрепорченные инциденты и как упрощает жизнь наличие полей-подсказок. Поэтому когда я пришла к ребятам из саппорта с очередными, более радикальными нововведениями, у меня уже был некоторый кредит доверия.
Заключение
Ретроспективно оценивая свой опыт работы над incident management process, я сформулировала для себя, на каких трех слонах и черепахе он базируется. Для меня это:
общий язык для обмена информацией между командами;
люди, готовые поддерживать процесс;
регистрация инцидентов в любом виде.
Позже мы с командой проделали много работы в других направлениях. Это и автоматизация операций, и категоризация проблем, и составление различных отчетов для разработки и бизнеса и многое другое. Но всё это – сюжеты для совсем других статей.
Первый шаг традиционно является самым сложным. Поэтому я считаю важным понимать, как расставить приоритеты, чтобы было проще вводить изменения и делать это поступательно. Ведь настройка любого бизнес-процесса — это работа с людьми, а многие тяжело переносит введение новых регламентов и правил. Особенно, если «и до этого как-то справлялись».
Ну и последнее, о чем я хочу сказать. Мне кажется важным не относиться к регламенту как к чему-то железобетонному. Регламент – это инструмент, который должен работать во благо компании, а не существовать где-то в параллельной вселенной. Если в процессе появились узкие места или какие-то договоренности стали приносить больше вреда, чем пользы, нужно это подсвечивать и пытаться найти решение.
Для поддержания актуальности регламента мы применяем итеративный подход. Вводим небольшие изменения и оцениваем их эффективность. И только после этого принимаем решение о дальнейших шагах.