DataLine начинала с традиционных colocation и телекома. Потом к ним добавились облачные вычисления. Сейчас мы администрируем инфраструктуру, базы данных, сервисы информационной безопасности, приложения и целые веб-проекты. Вместе с числом услуг выросло и наше производство – так мы называем инженерные отделы компании.

2009
2019
Группа сети
Дежурные инженеры
Отдел эксплуатации инфраструктуры

Группа сети
Группа виртуализации
VMware
Группа виртуализации
Hyper-V
Группа резервного копирования
Группа Microsoft
Группа мониторинга
Группа Unix
Группа DBA
Центр киберзащиты
Отдел управления внешними дата-центрами
Дизайн-центр
Отдел архитектурных решений
Группа разработки ПО
Отдел эксплуатации инфраструктуры
Дежурные инженеры
Служба технической поддержки
Небольшой филиал #10yearschallenge. Вот так выросла производственная дирекция.

Сегодня большинство клиентских кейсов задействуют компетенции 2-3 отделов производства. Например, у клиента пул ресурсов в облаке. Это уже два отдела – виртуализация и сеть.


Когда в проекте всего три отдела, скоординироваться не так сложно.

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


Когда в проекте участвует десяток технических отделов, координировать действия по проекту сложно.

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

Для всего этого в компании появилась новая роль – Technical Account Manager, или просто ТАМ.
С недавнего времени я курирую работу этих ребят и сегодня расскажу про них подробнее.



Что будет делать ТАМ?


Когда клиент к нам только приходит, с ним работает архитектор. Он переводит бизнес-задачи клиента на язык наших сервисов и разрабатывает решение.

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

Дальше клиента поддерживают:

  • Сервис-менеджеры: они отвечают за организационные моменты, документы, общаются с лицами, принимающими решения.
  • Технические отделы: отвечают за техподдержку.
  • Technical Account Manager: отвечает за всю техническую часть по проекту. Его основная задача – координация крупных технических изменений в проекте. Он будет взаимодействовать с клиентом по техническим вопросам, в том числе вносить предложения по оптимизации архитектуры клиента в соответствии с его задачами. Еще одна функция ТАМ – контроль выполнения SLA.

Получается такой гибрид PM и PreSale, но при этом еще и практикующий инженер. Теперь подробнее о каждой из составляющих роли Technical Account Manager.

Project manager. Когда от клиента приходит запрос “подготовить технологический ландшафт под новый проект (сеть+виртуальные ресурсы+ОС+nginx+php)”, ТАМ выясняет детали, сроки. Дальше он разбивает общую задачу и раздает ее кусочки нужным инженерным отделам. Нередки случаи, когда отделы должны решать задачу по цепочке: один отдел не может приступить к работе, пока другой не сделает свою часть. В таких случаях TAM рулит сроками и статусами.

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

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

Так как ТАМ досконально знает техническую часть проекта, он в курсе проблем и потенциальных точек для развития: клиенту вот-вот перестанет хватать ресурсов, инфраструктуру стало неудобно масштабировать. Бывает, что у клиента и вовсе не закрыта какая-то задача. Например, пару раз в месяц у клиента были высокоуровневые ddos-атаки. Сам клиент пока этого никак не ощущает, это видит только инженер по всплескам трафика. Он укажет на проблему, аргументированно объяснит риски и предложит решение: “Да, сейчас вы не замечаете этих атак, так как это лишь прощупывание, но они повторяются. Следующая атака может оказаться сильной, и все положит. Если для данного сервиса критичен простой, то стоит подумать о его защите”.

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

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

Если происходит авария, то разбор полетов происходит сразу же после устранения ее последствий.

Не должность, а роль


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

Я пообщался с каждым техническим отделом отдельно, рассказал, чем будет заниматься ТАМ и на каких условиях. Дальше на собеседование мог прийти любой, кого заинтересовало мое предложение. При отборе помимо уверенных знаний в своей области, мы хотели убедиться, что инженер также немного разбирается в смежных областях. Если это сетевик, то он должен понимать, как работает виртуализация. Оценивали, как инженер умеет общаться (доносить свою точку зрения, аргументировать ее), выступать лидом проекта и организовывать совместную работу специалистов из нескольких отделов.

Из 15 человек отобрали 10. Сейчас ТАМов уже 13. На подходе еще 4.

Инженер будет заниматься обязанностями ТАМа примерно 30% от своего рабочего времени и по результатам своей работы получать вознаграждение.

То, что ТАМы – это наши инженеры, а не специалисты с рынка, помогло нам убить сразу двух зайцев:

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

В чем еще профит от TAM?


Мы надеемся, что с помощью ТАМов мы сможем:

  • Лучше понять потребности клиента и действовать проактивно на проекте.
  • Наладить связи между техническими специалистами клиентов и нашими инженерами. В идеале мы хотим прийти к тому, что ТАМы общаются с технарями, а сервис-менеджеры – с лицами, принимающими решения.
  • Снять нагрузку с сервис-менеджеров. Они будут меньше заниматься техническими деталями проектов и смогут сконцентрироваться на своих первостепенных задачах – удержании и развитии клиентов.
  • Отточить внутренние производственные процессы.

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

Комментарии (11)


  1. KorP
    07.02.2019 10:42

    А СХД кто занимается? Бекапщики или Группа виртуализации?


    1. abagaev Автор
      07.02.2019 10:54

      Бэкапщики


  1. it2manager
    07.02.2019 11:11
    +1

    "… Получается такой гибрид PM и PreSale, но при этом еще и практикующий инженер." Где-то вы лукавите, так не бывает. И превратится хороший инженер в плохого :)


    1. abagaev Автор
      07.02.2019 11:40

      Ну почему же. Пока все получается) Мы даём возможность развивать инженеру свои soft skills, и расширять кругозор в других, непрофильных для него, технологических направлениях.


      1. Hardened
        07.02.2019 19:58

        Инженер, пресейл, проектник и ещё часть функций архитектора и сервис менеджера. ТАМ может ещё и продукт? А сервис менеджеры выродились в продавцов по действующей базе...


        1. abagaev Автор
          08.02.2019 09:45

          Не совсем так. ТАМ закрывает только техническую часть, и тратит на это не более 30% всего своего времени. Мы выбрали только самые сложные кейсы, и поэтому у каждого ТАМа пока по одному проекту.
          Даже если мы убираем техническую часть, то у сервис-менеджеров остается вагон и маленькая тележка задач: документы, финансы, переговоры, отчетность и т.д. Они обслуживают всех клиентов без исключения, а это десятки компаний на одного сервис-менеджера.


          1. Hardened
            10.02.2019 11:55

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


      1. pesh1983
        07.02.2019 23:31

        По опыту паттерн "и швец, и жнец, и на на дуде игрец" приводит к тому, что человек знает всего понемногу, но не особого глубого. Как правило, инженер из него со временем станет так себе, коллеги-инженеры уйдут далёко вперёд, потому что все время тратят на профильные задачи, а не часть, как такой ТАМ. Но, как я понимаю, это и есть основная задача на данной позиций: понимать немного в инженерии и все остальное — работа с клиентами.


        1. abagaev Автор
          08.02.2019 09:47

          Тут такой момент: ТАМу действительно нужно какое-то время, чтобы погрузиться в проект. Когда ТАМ разобрался и навел мосты с техническим персоналом клиента, то со временем трудозатрат будет уходить меньше.
          Повторюсь, в любой момент времени инженер отводит роли ТАМ не более 30% времени, и пока один ТАМ — один клиент. Это не такая большая загрузка, чтобы “выпасть” из рядов “чистых” инженеров.


  1. kartemk
    08.02.2019 09:47

    ТАМы закрепляются за всеми клиентами или по каким-то маркерам — от минимального платежа, за доплату или еще как-то?


    1. abagaev Автор
      08.02.2019 09:49

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