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

    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?


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

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

    Вся история с ТАМами стартовала в декабре и только набирает обороты. Самое интересное – это фидбэк от клиентов, который мы ожидаем получить в ближайшие месяцы. Надеемся, что клиенты тоже оценят наше нововведение.
    DataLine
    142,00
    Экосистема на базе дата-центров TIER III
    Поделиться публикацией

    Комментарии 15

      0
      А СХД кто занимается? Бекапщики или Группа виртуализации?
        0
        Бэкапщики
        +1
        "… Получается такой гибрид PM и PreSale, но при этом еще и практикующий инженер." Где-то вы лукавите, так не бывает. И превратится хороший инженер в плохого :)
          0
          Ну почему же. Пока все получается) Мы даём возможность развивать инженеру свои soft skills, и расширять кругозор в других, непрофильных для него, технологических направлениях.
            0

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

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

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

                  0
                  Давайте все сначала).
                  Либо эта практика у вас совсем новая, либо мало клиентов.

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

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

                  ТАМ как раз подключается в тот момент, когда клиентский проект запускается в эксплуатацию. Взаимодействие и сопровождение клиента по всем техвопросам после внедрения — это и есть основной функционал ТАМ.

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

                  Самое трудозатратное для ТАМа — это первоначальное знакомство с клиентским проектом, когда нужно “въехать” в его технические нюансы, планы клиента и пр. Дальше, по нашим прогнозам, ведение клиента будет занимать меньше времени.
                  В любом случае, инженер уделяет роли ТАМа не более 30% всего своего времени.
                  ТАМ — дело исключительно добровольное и дополнительно поощряемое. Желающих много, у нас даже есть выбор на собеседованиях)
                    0

                    "Дальше, по нашим прогнозам, ведение клиента будет занимать меньше времени."


                    Это в теории так, а практика отличается

                      0
                      возможно наши практики отличаются.
              0

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

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

              0
              по-факту, TAM — это и есть PM. Просто назвали по-другому. У нас в банках он называется IT-PM, PM от IT. Поясню — в чем заключается задача обычного PM? Быть единым контактом, следить за соблюдением требований, следить за выполнением сроков, выбивать и планировать ресурсы. Чем занимается ваш TAM? Да тем же самым, просто у него есть некоторый технический бэкграунд и он часть вопросов может решить сам, например первичную архитектуру придумать или разбить задачу на под-задачи без участия архитектора. Так любой PM со временем этому учится. Так что, у вас есть отдел PMов и всё )

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

              Самое читаемое