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

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

Небольшой филиал #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?

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

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

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

Автор: abagaev

Источник