Как Управлять Сложными Техническими Проектами, Не Нанимая Продакт-Менеджеров: Опыт Dataline

DataLine начинала с традиционного колокейшна и телекоммуникаций.

Затем к ним добавились облачные вычисления.

Теперь мы администрируем инфраструктуру, базы данных, сервисы информационной безопасности, приложения и целые веб-проекты.

Вместе с количеством услуг выросло и наше производство – так мы называем инженерные подразделения компании.

2009 2019
Сетевая группа Дежурные инженеры Департамент эксплуатации инфраструктуры Сетевая группа Группа виртуализации VMware Группа виртуализации Гипер-В Резервная группа Группа Майкрософт Группа мониторинга Группа Юникс Группа ДБА Центр киберзащиты Отдел управления внешним дата-центром Центр дизайна Отдел архитектурных решений Группа разработки программного обеспечения Департамент эксплуатации инфраструктуры Дежурные инженеры Служба технической поддержки
Небольшая ветка #10yearchallenge. Так выросла производственная дирекция.

Сегодня большинство клиентских дел затрагивают компетенции 2-3 производственных отделов.

Например, у клиента есть пул ресурсов в облаке.

Это уже два отдела — виртуализации и сетевого.



Как управлять сложными техническими проектами, не нанимая продакт-менеджеров: опыт DataLine

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

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

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



Как управлять сложными техническими проектами, не нанимая продакт-менеджеров: опыт DataLine

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

С такими проектами сложно справиться, используя только стандартные регламенты и процессы.

Когда речь идет о сложных изменениях на этапе эксплуатации, требуется дополнительная координация.

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

А также постоянно поддерживать связь с техническими специалистами клиента, и вообще следить за технической частью проекта.

При всем этом в компании появилась новая роль – Технический менеджер по работе с клиентами, или просто ТАМ.

Последнее время я курирую работу этих ребят и сегодня расскажу о них подробнее.



Как управлять сложными техническими проектами, не нанимая продакт-менеджеров: опыт DataLine



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

Когда к нам впервые приходит клиент, с ним работает архитектор.

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

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

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

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

  • Менеджеры службы: они отвечают за организационные вопросы, документы и общаются с лицами, принимающими решения.

  • Технические отделы: отвечают за техническую поддержку.

  • Технический менеджер по работе с клиентами: отвечает за все технические аспекты проекта.

    Его основная задача — координация крупных технических изменений в проекте.

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

    Еще одна функция ТАМ — контроль выполнения SLA.

Получается гибрид ПМ и PreSale, но при этом еще и практикующий инженер.

Теперь давайте подробнее рассмотрим каждый из компонентов роли технического менеджера по работе с клиентами.

Руководитель проекта.

Когда от клиента поступает запрос «подготовить технологический ландшафт для нового проекта (сеть + виртуальные ресурсы + ОС + nginx + php)», ТАМ выясняет детали и сроки.

Затем он разбирает общую проблему и распределяет ее фрагменты по необходимым инженерным отделам.

Нередки случаи, когда отделы должны решать проблему по цепочке: один отдел не может приступить к работе, пока другой не выполнит свою часть работы.

В таких случаях ТАМ отвечает за сроки и статусы.

Чтобы привнести что-то новое в проект, ТАМ должен быть в курсе того, что в нем происходит сейчас и что уже сделано.

Он агрегирует и обновляет при необходимости всю проектную документацию и в дальнейшем несет ответственность за ее актуальность.

Главный инженер.

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

Он также выслушает любые пожелания и планы и найдет решение.

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

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

Бывает, что у клиента вообще нет выполненной задачи.

Например, клиент пару раз в месяц подвергался DDoS-атакам высокого уровня.

Сам клиент этого пока совершенно не чувствует; это видит только инженер по увеличению трафика.

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

Следующая атака может оказаться сильной и положить конец всему.

Если время простоя критично для данного сервиса, то стоит подумать о его защите».

Кстати, мы не ограничились историей поддержки инициативы инженерами только ТАМами.

Любой инженер может предложить улучшение проекта клиента.

Если клиент реализует предложенные изменения, инженер получает бонус.

Менеджер по качеству.

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

Важнейшими контролируемыми показателями являются время реакции и разрешение инцидентов.

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

В случае возникновения аварии разбор полетов происходит сразу после устранения ее последствий.



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

Когда мы обсудили необходимость как-то согласовать проект на эксплуатационном этапе, напрашивался отдельный отдел со специалистами ПМ.

Но были опасения, что этот отдел тоже попадет в водоворот между техническими отделами, и мы хотели из него выбраться.

Кроме того, это пилотная тема, и мы решили не создавать сущности и реализовали эту идею внутри существующих отделов с помощью роли.

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

Тогда на собеседование мог прийти любой, кого заинтересовало мое предложение.

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

Если это сетевик, то он должен понимать, как работает виртуализация.

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

Из 15 человек выбрали 10. Сейчас там уже 13 ТАМов.

Еще 4 на подходе.

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

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

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

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



В чем еще преимущество ТАМ?

Мы надеемся, что с помощью ТАМ мы сможем:
  • Лучше понимать потребности клиента и активно действовать в проекте.

  • Наладить связи между техническими специалистами заказчика и нашими инженерами.

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

  • Снимите нагрузку с сервис-менеджеров.

    Они будут меньше заниматься техническими деталями проектов и смогут сконцентрироваться на своих основных задачах — удержании и развитии клиентов.

  • Усовершенствуйте внутренние производственные процессы.

Вся история с ТАМами началась в декабре и только набирает обороты.

Самое интересное — это отзывы клиентов, которые мы ожидаем получить в ближайшие месяцы.

Мы надеемся, что клиенты также оценят наши инновации.

Теги: #Карьера в IT-индустрии #Управление проектами #Управление персоналом #управление проектами #менеджер проектов #технический аккаунт-менеджер

Вместе с данным постом часто просматривают: