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

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

07 февраля 2019  • 

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?

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

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

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

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

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

15 апреля
Сергей Жильцов

Главные вопросы при планировании инфраструктуры виртуальных рабочих столов.

08 апреля
Николай Продайвода

Как организовать гарантированный канал доставки трафика, даже если нет возможности подвести оптику и закупить дорогостоящее оборудование.

25 марта
Вячеслав Нечаев

Комментарии

Подпишитесь на нашу рассылку

Получайте свежие и полезные материалы и приглашения на наши мероприятия

randomness