На многофункциональной конференции TECH WEEK в ноябре на одном из докладов гости мероприятия узнали как можно снизить стоимость владения сложным IT-продуктом, используя для этого инцидентную техническую поддержку. Увлекательно и с обилием примеров рассказала об этом Галина Лазарева, СEO & co-founder компании STILT.
Инцидентная техническая поддержка
Компания STILT занимается инцидентной технической поддержкой и гордится тем, что умеет поддерживать системы, не занимаясь разработкой.
Что значит инцидент — это любое несанкционированное поведение программы, то есть это ошибка, неправильно завершенный процесс и так далее, который есть в конкретной системе. Сотрудники компании STILT как раз оказывают услуги поддержки для таких случаев:
— это операторы уровня L1, которые могут воспроизвести ошибку и по хорошо описанному сценарию ее убрать;
— специалисты, которые уже знают бизнес-процесс системы, понимают основные обмены и сущности этих обменов, могут пойти, перезапустить что-то вручную, достать логи, сходить в базу данных достать нужные списки заказов, посмотреть, все ли там с ними в порядке, и выполнить ряд инженерных действий.
При этом компания не работает с кодом и не занимается релизами.
Что значит инцидент — это любое несанкционированное поведение программы, то есть это ошибка, неправильно завершенный процесс и так далее, который есть в конкретной системе. Сотрудники компании STILT как раз оказывают услуги поддержки для таких случаев:
— это операторы уровня L1, которые могут воспроизвести ошибку и по хорошо описанному сценарию ее убрать;
— специалисты, которые уже знают бизнес-процесс системы, понимают основные обмены и сущности этих обменов, могут пойти, перезапустить что-то вручную, достать логи, сходить в базу данных достать нужные списки заказов, посмотреть, все ли там с ними в порядке, и выполнить ряд инженерных действий.
При этом компания не работает с кодом и не занимается релизами.
Как появилась идея инцидентной технической поддержки
Галина много лет работала на стыке продаж и IT. И у неё и её коллег родилась гипотеза, а потом и подтверждение, что есть колоссальные финансовые и временные потери на этапе ввода в эксплуатацию любого информационного продукта. В связи с этим появилась идея создания инцидентной поддержки.
Для того, чтобы понять важность внедрения такой технической поддержки, нужно посмотреть на корреляцию стоимости разработки и поддержки ПО на всем жизненном цикле.
Для того, чтобы понять важность внедрения такой технической поддержки, нужно посмотреть на корреляцию стоимости разработки и поддержки ПО на всем жизненном цикле.
Цифры могут отличаться.
Понятно, что у интернет-магазинов, у e-commerce цикл намного длинней, чем у простого продукта, потому что есть большое количество бэклога, запасы гипотез, которые в интернет-магазинах разрабатываются. Но суть остается одной и той же — в момент ввода в эксплуатацию система начинает работать, завели пользователей, и ошибки или какие-то изменения приходят достаточно неравномерно. Что это значит? Это значит, что между компанией-заказчиком разработки и компанией, которая осуществляет разработку, появляется разрыв ожидания в С-реальность.
Что хочет клиент, который заказал разработку? Он хочет:
— чтобы его система работала бесперебойно, нон-стоп;
— на любые вопросы был моментальный ответ или решение.
Что имеет компания разработчик-интегратор? У нее есть команда, но нет готового бэклога. Может ли она содержать команду из 6-8 человек, для того, чтобы когда-то раз в месяц прибежал клиент и сказал: «У нас не работает, у нас все упало»? Нет, не может.
Тут появляется инцидентная техническая поддержка и нивелирует коммуникационные, временные и финансовые издержки.
Каким образом?
1. Формат работы 24/7 — заявка будет принята, зафиксирована, ей присвоят номер.
2. Инцидентная техническая поддержка отвечает SLA за финансы, то есть нарушение времени реакции или нарушение времени решения для них штраф. Потому реакция здесь быстрая.
3. Бесперебойная работа.
Понятно, что у интернет-магазинов, у e-commerce цикл намного длинней, чем у простого продукта, потому что есть большое количество бэклога, запасы гипотез, которые в интернет-магазинах разрабатываются. Но суть остается одной и той же — в момент ввода в эксплуатацию система начинает работать, завели пользователей, и ошибки или какие-то изменения приходят достаточно неравномерно. Что это значит? Это значит, что между компанией-заказчиком разработки и компанией, которая осуществляет разработку, появляется разрыв ожидания в С-реальность.
Что хочет клиент, который заказал разработку? Он хочет:
— чтобы его система работала бесперебойно, нон-стоп;
— на любые вопросы был моментальный ответ или решение.
Что имеет компания разработчик-интегратор? У нее есть команда, но нет готового бэклога. Может ли она содержать команду из 6-8 человек, для того, чтобы когда-то раз в месяц прибежал клиент и сказал: «У нас не работает, у нас все упало»? Нет, не может.
Тут появляется инцидентная техническая поддержка и нивелирует коммуникационные, временные и финансовые издержки.
Каким образом?
1. Формат работы 24/7 — заявка будет принята, зафиксирована, ей присвоят номер.
2. Инцидентная техническая поддержка отвечает SLA за финансы, то есть нарушение времени реакции или нарушение времени решения для них штраф. Потому реакция здесь быстрая.
3. Бесперебойная работа.
Представьте ситуацию, разработчик занят своими непосредственными обязанностями. Тут прилетает претензия от пользователя: кнопка не работает, отчет не выгружается, что-то происходит. Что делает разработчик в этот момент? Он должен отключиться от задачи внедрения нового функционала, переключиться на поиск и устранение той проблемы, которая сейчас возникла. Но это же вроде как небольшая ошибка. Пять минут посмотреть, быстро устранить, и все будет хорошо. Но по факту уже, наверное, никто не верит, что многозадачность это круто.
Мы знаем, что отвлечение от задачи — это минимум 30 минут нужно будет потратить потом на то, чтобы перестроиться. Плюс процесс поддержки — это история рваная. Пришел запрос от пользователя. В нем, возможно, не хватает каких-то данных. Нужно запросить недостающие сущности, дождаться ответа. Тебе ответили. Потом поднять VPN, вспомнить логин-пароль, куда-то зайти, посмотреть, собрать логи, понять, в чем проблема. Написать пользователю, что мы все решили. И пользователь нам через 30 минут ответил, да, все решилось хорошо.
Вроде бы несложная задача, но это не работа разработчика. Она отвлекает его от основной работы и задач, поэтому такой функционал — работа с ошибками, непониманием пользователей и так далее логично отдать инцидентной технической поддержке.
Здесь не нужно бояться, что ТП не справится, ведь если вдруг что-то пойдет по незапланированному сценарию, специалисты техподдержки задачу эскалируют, если тут нужна помощь от разработчика.
Но только он получит уже эту задачу не в виде «у нас опять все не работает», а в понятном виде:
— будет проведенный алгоритм действий;
— собранные артефакты;
— вытащенные логи;
— скриншоты по задаче;
— список ошибок.
Естественно, разработчик, даже если он переключается на решение этой задачи в экстренном режиме, тратит меньше времени на аналитику и сбор информации.
Следующая история – это тоже про скорость, а ещё, про софт-скиллы, которые иногда разработчики не могут дать, к сожалению, пользователям. То есть, например, есть некая Ольга Анатольевна, ей 48 лет, она замечательный логист, на правовом уровне знает распределение веса внутри фуры по каждой оси в зависимости от сезона, но она не знает, как почистить кэш. И ей можно это простить, потому что она операционист не из IT-сферы.
Мы знаем, что отвлечение от задачи — это минимум 30 минут нужно будет потратить потом на то, чтобы перестроиться. Плюс процесс поддержки — это история рваная. Пришел запрос от пользователя. В нем, возможно, не хватает каких-то данных. Нужно запросить недостающие сущности, дождаться ответа. Тебе ответили. Потом поднять VPN, вспомнить логин-пароль, куда-то зайти, посмотреть, собрать логи, понять, в чем проблема. Написать пользователю, что мы все решили. И пользователь нам через 30 минут ответил, да, все решилось хорошо.
Вроде бы несложная задача, но это не работа разработчика. Она отвлекает его от основной работы и задач, поэтому такой функционал — работа с ошибками, непониманием пользователей и так далее логично отдать инцидентной технической поддержке.
Здесь не нужно бояться, что ТП не справится, ведь если вдруг что-то пойдет по незапланированному сценарию, специалисты техподдержки задачу эскалируют, если тут нужна помощь от разработчика.
Но только он получит уже эту задачу не в виде «у нас опять все не работает», а в понятном виде:
— будет проведенный алгоритм действий;
— собранные артефакты;
— вытащенные логи;
— скриншоты по задаче;
— список ошибок.
Естественно, разработчик, даже если он переключается на решение этой задачи в экстренном режиме, тратит меньше времени на аналитику и сбор информации.
Следующая история – это тоже про скорость, а ещё, про софт-скиллы, которые иногда разработчики не могут дать, к сожалению, пользователям. То есть, например, есть некая Ольга Анатольевна, ей 48 лет, она замечательный логист, на правовом уровне знает распределение веса внутри фуры по каждой оси в зависимости от сезона, но она не знает, как почистить кэш. И ей можно это простить, потому что она операционист не из IT-сферы.
Что происходит, когда разработка и проектные менеджеры напрямую коммуницируют с пользователями, которые работают с системой? Пользователь приходит с запросом, ему отвечают: «У вас все нормально, только кэш почистите». Но как это сделать? Непонятно.
А техническая поддержка понимает, что работает с клиентами не из IT-сферы, и, соответственно, она объясняет, что нужно сделать — почистите кэш, для этого вам необходимо:
— пойти в настройки;
— нажать сюда;
— потом сюда;
— дождаться результатов.
Это уровень коммуникации, который часто страдает.
Какие ещё встречаются сложности? Бывает такое, что внедряется новая система для того, чтобы собирать данные, чтобы автоматизировать рутинные процессы. Заходит команда операционистов и говорит, что в Excel лучше было, можно, пожалуйста, без нововведений. Это как раз про софт-скилы, стандарты общения и умение работать с такими, может быть, конфликтными пользователями, можно так их назвать. И если этап правильной коммуникации опускать, то конфликты и сопротивление будут неизбежны.
Далее актуальная документация.
Документация, написанная аналитиками, проектными менеджерами, техническими писателями принципиально отличается от документации, которую пишут в поддержках. Почему? Потому что в техподдержке есть ряд сменяющих друг друга людей. Если мы говорим про L1, это чаще всего софтовые люди, которые умеют работать по инструкции. И если инструкция не актуальна, он по ней работать не может. Если там написано «пойди, открой папку», но не написано какую, вполне возможно, что в потоке он этого решить не сможет. Соответственно, все эти инструкции декомпозированы до отсутствия таких очевидных историй. И эти инструкции прекрасно переиспользуются для конечных пользователей.
Инструкции уровня L2 у компании Stilt часто забирают сами продуктонеры, разработчики и так далее, для обучения своих сотрудников внутри.
Важно в документации и своевременное оповещение о релизах. У STILT такая система налажена, и, соответственно, команда говорит: «У нас есть релиз, вот список задач», оператор берет список изменившихся полей или логики поведения и дописывает документацию в моменте. Потому что он сегодня в 8 вечера уйдет, и ему на смену придет условный Вася. И Вася должен знать, что изменилось за время, пока его не было на смене. Тогда будет всё понятно, можно быстро внедрить и исправить.
И ещё важный момент про обесценивание. Что происходит, когда сама команда занимается поддержкой, и они 6 месяцев пилили очень крутой софт, автоматизировали кучу процессов, настроили отчеты,проделали колоссальную работу, и кто-то сейчас в моменте полностью их обесценивает, говорит, что продукт плохой и ничего не работает? Команда горит жестко от этого. Это неприятное обесценивание. Когда же есть такая прослойка из техподдержки, очень хорошо нивелируется негатив. Команда это в лучшем случае вообще не видит.
А техническая поддержка понимает, что работает с клиентами не из IT-сферы, и, соответственно, она объясняет, что нужно сделать — почистите кэш, для этого вам необходимо:
— пойти в настройки;
— нажать сюда;
— потом сюда;
— дождаться результатов.
Это уровень коммуникации, который часто страдает.
Какие ещё встречаются сложности? Бывает такое, что внедряется новая система для того, чтобы собирать данные, чтобы автоматизировать рутинные процессы. Заходит команда операционистов и говорит, что в Excel лучше было, можно, пожалуйста, без нововведений. Это как раз про софт-скилы, стандарты общения и умение работать с такими, может быть, конфликтными пользователями, можно так их назвать. И если этап правильной коммуникации опускать, то конфликты и сопротивление будут неизбежны.
Далее актуальная документация.
Документация, написанная аналитиками, проектными менеджерами, техническими писателями принципиально отличается от документации, которую пишут в поддержках. Почему? Потому что в техподдержке есть ряд сменяющих друг друга людей. Если мы говорим про L1, это чаще всего софтовые люди, которые умеют работать по инструкции. И если инструкция не актуальна, он по ней работать не может. Если там написано «пойди, открой папку», но не написано какую, вполне возможно, что в потоке он этого решить не сможет. Соответственно, все эти инструкции декомпозированы до отсутствия таких очевидных историй. И эти инструкции прекрасно переиспользуются для конечных пользователей.
Инструкции уровня L2 у компании Stilt часто забирают сами продуктонеры, разработчики и так далее, для обучения своих сотрудников внутри.
Важно в документации и своевременное оповещение о релизах. У STILT такая система налажена, и, соответственно, команда говорит: «У нас есть релиз, вот список задач», оператор берет список изменившихся полей или логики поведения и дописывает документацию в моменте. Потому что он сегодня в 8 вечера уйдет, и ему на смену придет условный Вася. И Вася должен знать, что изменилось за время, пока его не было на смене. Тогда будет всё понятно, можно быстро внедрить и исправить.
И ещё важный момент про обесценивание. Что происходит, когда сама команда занимается поддержкой, и они 6 месяцев пилили очень крутой софт, автоматизировали кучу процессов, настроили отчеты,проделали колоссальную работу, и кто-то сейчас в моменте полностью их обесценивает, говорит, что продукт плохой и ничего не работает? Команда горит жестко от этого. Это неприятное обесценивание. Когда же есть такая прослойка из техподдержки, очень хорошо нивелируется негатив. Команда это в лучшем случае вообще не видит.
При условии, что техподдержка всё всегда фиксирует, по итогу недели-двух месяцев в разрезе отчёта, можно понять, что там какой-нибудь товарищ Поликарпов обращался из 60 инцидентов 30 раз. И можно сделать выводы: либо его плохо обучили работе системы, нужно с ним созвониться, показать как и что устроено. Либо он какой-то может быть деструктивный, токсичный.
И когда у руководителя команды есть прозрачный отчет, он может делать управленческие решения на основании этого: провести хороший тет-а-тет с пользователем, отправить его на обучение и так далее. Обучение пользователей STILT, кстати, тоже проводит.
Обучение может понадобиться также, если это продукт, в котором много департаментов, и есть какая-то текучка, или дорабатывается функционал для нового департамента. Его можно проводить в формате вебинаров или индивидуальных занятий.
Следующая история тоже очень интересная. Она про потерю денег и времени и про прогнозы бюджета. То есть чаще всего в моменте ввода в эксплуатацию уже переходят на какой-то либо фиксированный платеж, а-ля там 40 часов в пакете для разработки и все, что сверху — ПТМ. Либо вообще это темная история. Более-менее стабильный продукт может выстрелить, может не выстрелить, но бюджет спрогнозировать сложно, особенно на самом старте ввода в эксплуатацию.
У техподдержки же фиксированный платеж, прогнозируемый бюджет вплоть до года с небольшой корреляцией на релизы. Здесь закладывается, что может быть по инцидентам просадка на какие-то пару дней, но это не бюджеты а-ля полмиллиона-миллион разницы. Это приблизительно 200 тысяч на год.
И когда у руководителя команды есть прозрачный отчет, он может делать управленческие решения на основании этого: провести хороший тет-а-тет с пользователем, отправить его на обучение и так далее. Обучение пользователей STILT, кстати, тоже проводит.
Обучение может понадобиться также, если это продукт, в котором много департаментов, и есть какая-то текучка, или дорабатывается функционал для нового департамента. Его можно проводить в формате вебинаров или индивидуальных занятий.
Следующая история тоже очень интересная. Она про потерю денег и времени и про прогнозы бюджета. То есть чаще всего в моменте ввода в эксплуатацию уже переходят на какой-то либо фиксированный платеж, а-ля там 40 часов в пакете для разработки и все, что сверху — ПТМ. Либо вообще это темная история. Более-менее стабильный продукт может выстрелить, может не выстрелить, но бюджет спрогнозировать сложно, особенно на самом старте ввода в эксплуатацию.
У техподдержки же фиксированный платеж, прогнозируемый бюджет вплоть до года с небольшой корреляцией на релизы. Здесь закладывается, что может быть по инцидентам просадка на какие-то пару дней, но это не бюджеты а-ля полмиллиона-миллион разницы. Это приблизительно 200 тысяч на год.
И ещё одна история про выгорание разработчиков. Они не любят саппорт на самом деле, потому что задачи примитивные, однотипные. В итоге разработчики не сильно вникают в проблему, перекладывают проблему с одного на другого. В итоге она не решается. Да и штрафа или наказания от руководства за все это нет никакого. Поэтому качество и измерение качества технической поддержки, которая находится внутри компании, очень сложная история.
Как меняется ситуация, когда техподдержка является твоим основным бизнесом, как в случае с инцидентной поддержкой от STILT? Есть SLA, есть деньги. Просрочили SLA, недополучили. 3, 10, 12, 150 тысяч в зависимости от того, насколько накосячили. И это очень сильно мотивирует не нарушать правила. Что положительно влияет и на бюджет, деньги заказчика.
И немного информации про отчеты, которые есть, когда есть техподдержка.
Первое – это зафиксированные инциденты, которые показывают, в каком именно месте системы есть проблема. Что происходит, зачастую, когда разработчики поддерживают систему без саппорта? Это приходит какой-то запрос. Нужно завести тикет. Разработчику или ответственному специалисту, допустим, в базе, файл поправить, одну букву дописать, это две минуты. И тикет заводить две минуты. Поэтому он этого сразу не делает, оставляет на потом. И по итогу месяца 30 таких случаев было или 100, да никто не знает, потому что это не зафиксировано и никогда не узнает. А если это 100, то, наверное, надо это системно решать, чтобы этого больше не возникало. И это тоже такая история совершенно непрозрачная, и прозрачная становится только тогда, когда есть детальный отчет.
Как меняется ситуация, когда техподдержка является твоим основным бизнесом, как в случае с инцидентной поддержкой от STILT? Есть SLA, есть деньги. Просрочили SLA, недополучили. 3, 10, 12, 150 тысяч в зависимости от того, насколько накосячили. И это очень сильно мотивирует не нарушать правила. Что положительно влияет и на бюджет, деньги заказчика.
И немного информации про отчеты, которые есть, когда есть техподдержка.
Первое – это зафиксированные инциденты, которые показывают, в каком именно месте системы есть проблема. Что происходит, зачастую, когда разработчики поддерживают систему без саппорта? Это приходит какой-то запрос. Нужно завести тикет. Разработчику или ответственному специалисту, допустим, в базе, файл поправить, одну букву дописать, это две минуты. И тикет заводить две минуты. Поэтому он этого сразу не делает, оставляет на потом. И по итогу месяца 30 таких случаев было или 100, да никто не знает, потому что это не зафиксировано и никогда не узнает. А если это 100, то, наверное, надо это системно решать, чтобы этого больше не возникало. И это тоже такая история совершенно непрозрачная, и прозрачная становится только тогда, когда есть детальный отчет.
Пример кейса
STILT поддерживает крупного логистического провайдера. Начинали с поддержки одного сервиса. Сейчас шесть сервисов. И результат по этому проекту, что у STILT нет эскалации на разработку вообще. То есть полностью автономная история стала. Команда довольна.
Бывает, кстати, что команда разработчиков на первых порах техподдержку воспринимает негативно — сейчас эти придут будут спрашивать все у меня. А потом они уже говорят, мы там запустили, вы, пожалуйста, проследите, чтобы все нормально было. Или там ночью мы сделали изменения, будет вот так и вот так. Если будет так, делайте так, если будет так. И это здорово, это про хорошее взаимодействие история. К нему и нужно стремиться.
То есть:
— снимать лишние задачи с разработчиков;
— если и обращаться к ним за помощью, то давать конкретный план и детальное описание проблемы;
— налаживать коммуникацию с пользователями;
— нивелировать негатив;
— работать с документами так, чтобы они были понятны любому человеку на любом этапе, это позволит избежать проблем в том случае, если специалист заболеет или уйдет в отпуск;
— доносить до разработчиков мысль, что внешний саппорт — это не проблема и не сложное нововведение, это экономия времени, сил.
То есть:
— снимать лишние задачи с разработчиков;
— если и обращаться к ним за помощью, то давать конкретный план и детальное описание проблемы;
— налаживать коммуникацию с пользователями;
— нивелировать негатив;
— работать с документами так, чтобы они были понятны любому человеку на любом этапе, это позволит избежать проблем в том случае, если специалист заболеет или уйдет в отпуск;
— доносить до разработчиков мысль, что внешний саппорт — это не проблема и не сложное нововведение, это экономия времени, сил.
ВЫВОД
Правильная работа с техподдержкой помогает не потерять деньги, избежать выгорания сотрудников, повысить качество обслуживания пользователей и повысить рентабельность услуги.
TECH WEEK — мультиформатная конференция о технологиях в бизнесе, проходящая дважды в год в Технопарке «Сколково». Лучшие эксперты рынка и представители технологический компаний. Нетворкинг, где каждый может собрать более 100 контактов, мастермайнды, практикумы с разбором кейсов, выставка компаний, менторинг и другое.
Станьте частью крупного бизнес-события: clck.ru/3A8fC2
