Как вести сложные технические проекты, не нанимая PMщиков: опыт DataLine

В декабре в компании появилась новая роль - Technical Account Manager. Кто они такие и зачем понадобились, читайте в нашей статье.

07 февраля  •  Алексей Багаев

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?

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

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

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

Расскажите друзьям и коллегам о статье
  • Поделиться
  • Плюсануть
  • Поделиться

Подписка на новые статьи

Свежие статьи и анонсы семинаров по почте

Пишем редко и по делу

Последние статьи

Разбираем, как не допустить проблем с производительностью виртуальной машины из-за памяти.

13 июня
Алексей Дарченков

Заключительная большая часть про настройку VPN IPsec, L2 VPN, SSL VPN-Plus.

30 мая
Тимур Чухланцев

Рассказываем, что и почему "тормозит" и как сделать так, чтобы не "тормозило".

23 мая
Алексей Дарченков

Комментарии

randomness