Управление ИТ и гибкие методологии

Гибкие технологии очень быстро стали стандартом де факто в российской разработке. Сам бизнес тоже все больше использует гибкие подходы и начинает работать иначе. Для ИТ-службы переход на аджайл означает не только другую методологию управления. Это влечет очень серьезные изменения в оргструктуре, вступает в непростое взаимодействие с давно выстроенным процессом поддержки, влияет на взаимоотношения с подрядчиками и потребности в аутсорсинге. О том, как переход на аджайл сказывается на управлении ИТ, рассказывает Александр Огнивцев, руководитель управления сервисной поддержки ДИТ «Альфастрахование».

Кадровая проблема в ИТ остается острой многие годы. Что нового вы видите на фронте борьбы за кадры?

Традиционно рекрутинг персонала в ИТ-департаменте входит в служебные обязанности ИТ менеджеров, они очень много времени этому уделяют. Недавно мы начали переходить к парадигме «HR-бизнес-партнер». Это схема подразумевает, что сотрудники HR-службы выделяются для работы с каким-то одним подразделением компании, в нашем случае с ИТ-департаментом. Они понимают наши нужды, знают, что происходит внутри подразделения. Нельзя сказать, что мы полностью решили проблему подбора кадров, но в значительной степени эту работу удалось оптимизировать и наладить более продуктивное взаимодействие с HR службой. Этот подход хорошо себя зарекомендовал и для других подразделений, но в ИТ эффект появляется сильней, потому что айтишников сложней подбирать.

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

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

Много ли вы набираете и каких специалистов?

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

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

Поэтому мы берем много людей в разработку и в поддержку. Нам удалось выстроить систему, когда люди из поддержки растут внутри компании. На первую линию поддержки мы берем только с ИТ-образованием, даже без опыта, часто это первое место работы. Проработал год на первой линии – переводим на вторую, и так они могут двигаться дальше и дальше. Это позволяет нам решать кадровые вопросы, потому найти человека на первую линию легче, чем опытного сотрудника службы поддержки или специалиста по какой-то системе. Бывшие сотрудники первой линии вырастают в программистов, сотрудников службы информационной безопасности, могут двигаться куда угодно. Конечно, если сразу нужно 30 программистов, их приходится искать вовне, но частично кадровая проблема за счет поддержки решается.

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

ITSM и гибкая методология: как это делать одновременно?

У нас ITSM во всей его полноте реализован уже много лет. По управлению ИТ службой у нас есть сертификат ISO 20000, полученный в результате реального аудита. Все процессы этого стандарта у нас реализованы на практике. Есть приложение, которое поддерживает их, на базе OmniTracker, у нас было одно из первых масштабных внедрений этого продукта в России. В этой системе отражены все основные процессы, которые подразумевает ITIL. Общий контур поддержки не ограничивается сотрудниками поддержки, в него включены скрам-команды, бизнес подразделения, внешние подрядчики работают там же. Но у нас в этой системе поддерживаются только процессы поддержки, но не задачи разработки.

Мы оказались перед новым вызовом: нужно как–то скрестить ITIL с аджайлом. Работа команд принципиально отлична от работы поддержки. Команда работает до смерти продукта. Только с его исчезновением она распадется. При этом задачи поддержки команда зачастую выполняет с низким приоритетом, что создает проблемы в уже работающих бизнес-процессах. Поэтому у нас один из важных показателей работы команды – доступность сервиса, который она развивает. Команда заинтересована в том, чтобы сервис устойчиво работал.

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

Оценка эффективности труда программистов всегда была делом непростым. Как вы оцениваете труд сотрудников и результативность команд?

По оценке эффективности команд готового рецепта нет. Мы только ищем его. Для службы поддержки у нас есть давно отлаженная система оценки и мотивации, построенная по принципам ITIL. Там есть и SLA, и KPI, которые считаются по известным формулам. Работникам все это понятно, и за семь лет существования эта система показала свою эффективность.

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

Видно, что «удельная стоимость» ИТ у нас падает. Исчерпывающей модели эффективности ИТ еще нет, но можно посчитать стоимость обращения к сотруднику поддержки. Эта стоимость у нас снижается, а объем обращений растет. Это естественно: мы постоянно выводим в продуктив новые приложения.

Обучаете ли вы сотрудников за счет компании? Пытаетесь ли удержать их необходимостью выплатить стоимость обучения?

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

Как вы используете аутсорсинг?

Если компания готова человека загрузить на 100%, экономического смысла в аутсорсинге нет никакого. Через аутсорсинг мы получаем ресурсы худшие, чем у нас самих, и еще должны переплачивать. В разработке чаще всего это не работает. Есть исключения, но обычно это какое-то очень узкое направление. Сервисы – дело другое. У нас есть позитивный опыт аутсорсинга печати. Это вполне надежно работает, понятно, как этим управлять, но основную часть разработки мы можем делать только сами.

Роста рынка аутсорсинга нет, причин тому много. Одна из них – тот же кадровый голод. Куда быстрей пойдет человек: к аутсорсеру или в финансовую компанию? Лучшие люди в аутсорсинговые компании не идут. Исключение составляют трансграничные ситуации: российский аутсорсер продает в Москве труд своих сотрудников из Белоруссии или Украины по более низким ценам. Только очень низкие цены делают такую затею выгодной. Собственно, мировой опыт именно таков.

Есть и другая принципиальная сложность. Какой может быть аутсорсинг в аджайле? Команда или ваша, или не ваша. При применении водопадной модели аутсорсинг был логичен: ТЗ отдал, продукт принял. Мы делали так, заказывали аутсорсеру некий конечный продукт, и результат был вполне достойный. В гибкой разработке ничего подобного не получится. Так что переход к таким методологиям сам по себе ограничивает сферу применения аутсорсинга.

Какие организационные изменения влечет переход к аджайл?

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

Формально ИТ-сотрудник – член аджайл команды, подчиняется ИТ департаменту, но по факту – бизнесу. Его временем распоряжается владелец продукта, сотрудник бизнес-подразделения. Линейная подчиненность хорошо работает в службе поддержки. При командной работе нужны другие подходы. Жесткое администрирование не годиться. Мы работаем как раз сейчас над тем, чтобы адекватно изменить оргструктуру так, чтобы она поддерживала командный принцип работы. Причем, даже перейдя к плоской горизонтальной структуре, мы все равно должны обеспечить кадровое администрирование, табели, отпуска и подобные вещи. То есть нам нужно, чтобы по-прежнему работала административная часть и была командная организация работы.

Как вы применяете машинное обучение для снижения нагрузки на службу поддержки?

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

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

Разработанное приложение по тексту письма, написанного пользователем в свободной форме, понимает, что это такое. Пришедшее письмо регистрируется как обращение автоматически. Нужно его классифицировать и указать, к какому сервису это обращение относится. Вот это программа и делает, например ставит метку «SAP, высокий приоритет». После этого заявка начинает обрабатываться в соответствии с этой классификацией. Определен порог – вероятность распознавания. Если «выше чем» - заявка обрабатывается автоматически. Если ниже – это подсказка для оператора. Обращений по почте примерно треть общего объема обращений. Человека брать не стали. Стало ясно, что машинное обучение в поддержке – это правильный путь, и мы будем это направление развивать.

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

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

Нет задачи заменить им операторов. Ситуации бывают очень разные. Бывает так, что клиенту нужна только психологическая поддержка. Чат бот планируется как дополнительный ресурс. Им можно будет воспользоваться при желании, и это позволит снизить потребность в числе операторов, работающих по схеме 24х7. У нас есть ресурсная поддержка в таком режиме, но держать ее и для поддержки пользователей дорого и сложно. Чат бот может помочь. Для молодой аудитории чат бот – это очень приятное и естественное решение. Им иногда проще говорить с ботом, а не с оператором.

Как еще можно снизить нагрузку на службу поддержки?

Нам нравится концепция «поддержка сообщества» (community support). У нас действуют группы в соцсетях, в основном «ВКонтакте». В них выкладывается информация, наши сотрудники отвечают на вопросы. Не нужно никакого отдельного ресурса создавать, завести группу – минутное дело. Документы, выложенные в ней, видят все, и пользователи тоже помогают друг другу в решение общих проблем. Whatsapp, Viber, Telegram – везде есть наши группы. В мессенджерах идет обсуждение текущих проблем. Люди не звонят, а пишут сообщения.

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