Строим сильную команду: от 0 до 100
[Дмитрий Зиновьев — Software Engineering Manager в EPAM, 11 лет в IT]
Всем привет! В этой статье я хочу поделиться практиками по построению сильных команд, которые я собрал за 12 лет работы в этой сфере. Мой рассказ будет в контексте компаний, которые наследуют сервисную модель с возможностью расширения зоны ответственности до уровня консалтинга.
История моей команды
Четыре года назад мы начинали работу командой в 20 ребят. Был только потенциал и безудержное желание растить экспертизу, чтобы иметь возможность работать с проектами любой сложности и технологических стеков. Цель была работать на перспективу, не утопая в текущей реальности. Шаг за шагом, квартал за кварталом мы построили эти процессы. Спустя два года повторили эту стратегию с двумя новыми дисциплинами в нашей команде. Сейчас у меня в команде более 170 замечательных и компетентных специалистов. 80% команды продолжает развивать и инвестировать в практику на регулярной основе.
Какие трудности возникают
Каждая уважающая себя software engineering компания хочет делать вклад в продукт, который она реализует. И каждый уважающий себя software engineer тоже хочет видеть результаты своего труда. Следовательно, вектор стратегии развития компании должен лежать в плоскости роста экспертизы.
Пока это проект на пару месяцев с универсальной командой в
Умение эффективно расти в столь динамических условиях жизненно необходимо. IT-индустрия имеет высокий уровень конкуренции, и ситуация будет лишь усугубляться. От партнера требуется всё большая экспертиза и предсказуемость результата.
В таких условиях самая главная инвестиция любого управляющего — команда. И задача не состоит в том, чтобы набрать сильных и самостоятельных людей с рынка. Цель — непрерывная инвестиция в лидеров (Continuous Leadership Growth). Это непростой подход, так как окупаемость инвестиций местами измеряется годами.
Зачем нужна непрерывная инвестиция в лидеров?
Рассмотрим стандартный процесс старта нового проекта, не вдаваясь в детали. Мы получили Request for Proposal (RFP). Путём длительного анализа и общения с клиентом мы подготовили прагматичный вариант с нашим решением, заложенными рисками, планом и прочими артефактами. Опустим pre-sale фазу и предположим, что путём сложных переговоров мы выигрываем тендер на условиях команды из 20 человек и сроком на год. Для систематического достижения результата нам нужна команда ключевых специалистов в размере
Что если у нас одновременно стартуют несколько проектов? Что если у нас нет свободных специалистов такого уровня сейчас? Набор молодых специалистов лишь даст иллюзию движения на старте. Как показывает статистика последних лет, найти ключевых людей крайне сложно, тем более в таком количестве и в сжатые сроки.
Мы оказываемся на пороге времени, когда просто «потреблять» IT-рынок специалистов уже недостаточно. Мы должны сами инвестировать в его развитие.
Непрерывная инвестиция в лидеров
Для роста любой организации и команды важны лидеры, способные достигать совместного результата независимо от обстоятельств и событий. В большинстве случаев это не найм звёздных игроков на рынке, а инвестиция в собственные кадры. Расширение зон ответственностей, прозрачность в отношениях с компанией, понимание путей собственного профессионального развития, вклад в общий результат и помощь в самореализации. Перейдем к практикам.
Особенность CIS-рынка
На пространстве СНГ IT-специалисты растут в основном эмпирическим путём, не имея профильных учреждений для подготовки production ready software engineers. Плюсы — люди весьма мотивированы, так как пришли в IT в большей степени на своём энтузиазме. Минусы — у людей часто нет чётко структурированного вектора профессионального роста. В среднем при таком подходе люди выходят на уровень ключевых специалистов спустя
Такая ситуация на рынке усугубляет прогнозирование возможностей компании брать новые проекты и доводить их до финального результата. Для таких задач нужны компетентные Software Engineers, которые помимо технического опыта могут построить сбалансированное архитектурное решение и эффективно работать в команде.
Я хочу поделиться практиками, которые активно использую последние 7 лет. Именно они помогли мне построить сильную команду.
Профиль специалиста
Лет 7 назад повальное число кандидатов с рынка говорили, что у них в компаниях нет градаций по уровням специалистов, ссылаясь на то, что это лишь усугубляет эффективный процесс разработки. Я готов согласиться с этим утверждением лишь в том случае, если компания готова уволить молодых специалистов и оставить на должности Software Engineer лишь ключевых людей, способных самостоятельно вести проекты. В противном случае у них есть градация, пусть и неформальная.
Для чего нужны градации по уровням и понимание их корреляций относительно специалистов в компании?
Берём стандартное распределение на junior, middle и senior. Каждый профессиональный уровень состоит не только из набора технических навыков. Цель каждой должности — это роль и связанные с этой ролью уровни ответственности, которые специалист может на себя взять и успешно выполнить поставленную задачу. То есть по данной шкале специалист уровня senior, помимо хорошего технического опыта, должен быть самостоятельным, иметь навыки выстраивания отношений с командой и клиентом, работать с конфликтами, эффективно интегрировать новые тренды, брать на себя ответственность за результат, тем более, если тот был построен на базе его предложения, и так далее. Заметим, что требования к персональным навыкам (soft skills) столь же высоки, как и к техническим.
Объективно, каждый ключевой специалист в компании, которому поставят цель нанять другого ключевого специалиста, будет иметь ясную картинку в голове, что последний должен из себя представлять и с какими задачами должен уметь справляться. Формализовать первую версию профиля специалиста — дело пары дней. Тем более, если в компании уже есть экспертная группа.
Это дает прозрачную картину в первую очередь для молодых специалистов, к чему нужно стремиться в рамках данной организации.
Прозрачность роста для специалиста и компании
Имея профиль по уровням и специализациям, компания легко может построить индивидуальный план для каждого специалиста. Построить план не составляет труда — практически каждая компания это так или иначе делает. Например: «Прочти книгу по управлению командами и будешь Team Lead». Но сложности не связаны с качеством этого плана. Есть два подводных камня.
Что если специалист выполнит поставленные перед ним задачи? Компания, скорее всего, должна будет пойти на два шага: пересмотреть финансовую сторону вопроса и перевести человека на новую роль. Допустим, в финансовом вопросе обе стороны пришли к компромиссу. Что касается новой роли, это не должна быть лишь громкая должность: «Все, теперь ты Team Lead, продолжай педалить». С новой должностью должны раскрываться новые зоны ответственности и задач. К сожалению, в некоторых компаниях люди могут формально пройти путь Software Engineer, Team Lead, Business Analyst, Product Owner, но при этом неформально оставаться Software Engineer, не получая новых знаний в смежных областях.
Компания предоставила план роста, но как она готова его поддерживать? «Вот план, вот проекты — будущее в твоих руках!», — далеко не всегда рабочая схема для эффективного роста специалистов.
Существует три заблуждения касательно эффективного роста посредством смены проектов.
Первое заблуждение. Проекты ограничивают технологический стек специалиста на определённый период времени. Это может расходиться с планами профессионального роста. Для того чтобы следовать трендам в индустрии, кто-то занимается собственными проектами, которые растягиваются на годы, кто-то планирует заложить себе время между проектами или мажорными версиями продукта и разобраться с данным вопросом, что тоже крайне редко заканчивается успешно.
Второе заблуждение. Проекты вызывают чувство полной занятости, но не всегда являются таковыми. Не будем брать в расчёт проекты с систематической переработкой. В большинстве случаев мы осознанно тратим больше 8 часов рабочего дня на старте и в конце проекта. Это обусловлено необходимостью разобраться с особенностями проекта, настроить процессы и отношения с клиентом на старте и ответственностью за реализуемый продукт в конце.
Но как только специалист начинает свой день с чёткого понимания последовательности действий (например, митинг с клиентом в определённое время, список задач на итерацию, какие задачи на кого стоит распределить, порядок операционных активностей и с чего начать выполнение собственных задач), в этот момент мозг начинает всячески оправдывать заслуженный отдых после сложного старта. Что приводит к фоновой прокрастинации: чуть дольше пил чай, заговорился с коллегой, читал непрофильную литературу и так далее. Сам отдых — это прекрасно, но он никак не коррелирует с профессиональным ростом.
Кто имел опыт работы на freelance с моделью оплаты за часы работы с кодом, тот знает статистику, когда на разработку в среднем уходит 3 часа, плюс 3 часа на прочтение документации и размышления, как этот код написать. Потеря двух часов в день ведет к потере одной недели в месяц. Это очень много и определенно может быть использовано для профессионального развития и получения новых навыков.
Третье заблуждение. Между проектами редко меняется сложность. Смена предметной области привносит новые тонкости, но для Software Engineer абстрактно задачи имеют общие черты: сущности, коллекции, межсетевые взаимодействия, формы, валидация, API и так далее. По сути, для молодого специалиста все проекты можно обличить в один домен, например Healthcare или CMS. Если роль специалиста остается прежней, то со временем он лишь набивает руку для более эффективного выполнения однотипных задач.
Учитывая эти подводные камни, фактического роста у специалиста, который 5 лет подряд сидел в рутине, может и не быть. Для выхода на новые горизонты каждый из предыдущих проектов должен привнести новый навык. Например:
- Первый проект: я научился работать в команде.
- Второй проект: я научился делать сложные части системы самостоятельно с качественным результатом на выходе.
- Третий проект: я научился делать проект с нуля.
- Четвертый проект: я научился работать в сложных условиях.
- Пятый проект: я получил опыт миграции сложной системы. В таком случае я как Software Engineer, скорее всего, могу претендовать на более высокую должность и заработную плату, так как компания с большей вероятностью может рассчитывать на меня в достижении цели. Подобные достижения минимизируют риски в будущем.
К сожалению, не каждый проект позволяет раскрыть весь потенциал специалиста. Особенно если у последнего есть амбициозный план роста и огромный ресурс для его воплощения. В таком случае компания должна предоставить возможности раскрыть этот потенциал:
- участие в технических интервью, чтобы научиться подбирать себе надежную команду;
- управление внутренними активностями и проектами, чтобы получить опыт управления командами и достижения результата;
- привлечение к pre-sale новых проектов, чтобы научиться строить релевантные планы, предложения и так далее.
Подготовка молодых кадров
В условиях острого роста спроса на IT-специалистов мы сталкиваемся с нехваткой компетентных кадров. С большой долей вероятности подобная ситуация будет лишь усугубляться, так как у нас все еще недостаточно профильных учебных учреждений, которые готовят новых IT-специалистов. А главное — способных буквально завтра приступить к работе на реальных проектах.
Что нам мешает инвестировать в рост молодого поколения? Имея на руках профиль специалистов, мы довольно легко можем обрисовать тот фундамент, который должен пройти каждый в данной области. Имея сильную профильную команду, мы легко можем построить процесс обучения с привлечением реального производственного опыта и практик. Это обеспечивает абсолютно новый, более профильный уровень подготовки специалистов.
Сложность данной инвестиции в больших сроках её окупаемости. Требуется
Тренинги и наставничество
Обучение — процесс перманентный. Сервисная или консалтинговая компания, которая ориентируется на результат, должна инвестировать в рост своих сотрудников на регулярной основе. Кто-то скажет: «Что если мы обучим сотрудника, а он уйдет из компании?». А стоит спросить: «Что если мы не обучим этого сотрудника и он останется?». Тренинг-программы должны иметь место как для молодых кадров, так и для состоявшихся ключевых специалистов, архитекторов и менеджеров.
В чем суть тренингов? Тренинг наряду с хорошей книгой систематизирует собранный опыт специалиста. В условиях динамично развивающейся индустрии мы можем встретить ситуации, когда молодой разработчик или менеджер попадает в сложный и качественно организованный проект. Для интеграции и адаптации в проектные практики и процессы ему, возможно, будет достаточно ознакомиться поверхностно с этой темой. Скорее всего, прочитать пару-тройку статей. Спустя неделю-две он уже активно вовлечен в процесс разработки. Это хорошо с точки зрения проекта и производительности труда. Но подобные ситуации вызывают ложные чувства компетентности у специалиста. Ему может показаться, что он в состоянии построить подобные практики и процессы собственноручно в любом другом проекте. От этого осознания, по его мнению, растет и его стоимость на рынке.
Если же дать такому специалисту возможность реализовать себя в условиях нового проекта, то ситуация может выйти из-под контроля. Почему-то клиент не готов использовать автоматизированное тестирование, проектная команда не согласна со стратегией работы в системе контроля версий, команда разработчиков не верит в TDD и всячески саботирует этот процесс и так далее. Каждый процесс имеет свои корни возникновения, сильные и слабые стороны. Уметь найти баланс и поставить процесс на рельсы, тем более в уже существующем проекте, весьма сложно.
Тренинг в совокупности с наставничеством систематизирует знания и помогает применить часть из них на практике, преодолевая возможные неблагоприятные обстоятельства. В добавок ко всему, подобные инициативы чаще всего не имеют привязки к существующим проектам. Что снижает их приоритет в пользу производственных задач. А значит и эта инициатива требует сильных лидеров на местах.
R&D, инвестиции в новые тренды
Предположим, предыдущие шаги мы прошли как по маслу и решили все возникающие сложности. На горизонте появляются новые обстоятельства, усложняющие все вышеперечисленные процессы. IT-индустрия не стоит на месте и каждый день IT-специалистов становится больше. Они пишут новые решения. Выпускают новые продукты. Просыпаясь утром, мы читаем новости про новую технологию. Обедая, мы читаем новости про выход второй версии этого решения, а за ужином неожиданно узнаем о том, что эта технология уже устарела. Я утрирую ситуацию, но динамику видят все.
Будет спрос — найдем людей, в чем сложности? Проблема в том, что на рынке не будет компетентных специалистов с
Какие шаги можно предпринимать? Внепроизводственная инвестиция в анализ нового технологического решения и реализация внутреннего проекта, который включает в себя создание решения с нуля и миграцию из существующих технологий. Очевидные вещи. Сложность в качестве результата.
Рассмотрим оба шага в отдельности.
Анализ включает в себя погружение в тему, основываясь на бизнес-контексте, с которым мы работаем. Например:
- кто создатель этого решения?
- есть ли у этого решения поддержка сообщества или платная поддержка 24/7 (что особенно критично для большого бизнеса)?
- удовлетворяет ли данное решение всем требованиям бизнес-процессов?
- есть ли прозрачные планы по стабилизации и модернизации этого решения с запланированными датами релиза?
- какие сильные и слабые стороны, риски и перспективы (SWOT-анализ)?
- как данное решение будет интегрироваться в уже существующую среду компаний?
Порой отрицательное решение понятно уже в первые дни анализа, основываясь на жизненно важных требованиях. Результатом анализа должен стать отчет или презентация. Скорее всего, эти документы понадобятся не для одного клиента.
Внутренний проект. Здесь главное не заиграться. Иллюзия развязанных рук может довести до слишком сложных решений. Таких себе универсальных конструкторов или платформ. Подобные инициативы должны следовать только после утвердительного результата анализа, что данное решение имеет право на жизнь и требует более детального углубления в предметную область. Результатом должно стать MVP максимально релевантное бизнес-задачам, с которыми сталкивается компания в проектах. По статистике подобные результаты можно продемонстрировать уже через один-три месяца. Работающее решение наглядно демонстрирует потенциальные сильные или слабые стороны и может служить фундаментом конструктивных переговоров.
Сообщество и глобальный опыт
В большинстве компаний есть преобладающие специализации, которые встречаются на каждом проекте. Каждый специалист несет уникальный опыт. К сожалению, в большинстве случаев люди не пересекаются друг с другом за пределами своих проектов. Тем более если компания разделена на несколько офисов, городов или стран. Это приводит к однотипным ошибкам, которые ранее, возможно, были совершены другой командой и которых можно было бы избежать.
Объединение компетенции в сообщество — пожалуй, один из важнейших шагов роста экспертизы в организации. Такие сообщества нуждаются в ключевых людях в каждой локальной группе и выделенной централизованной команде для системной работы:
- менеджмент-команда, координирующая все процессы внутри практики;
- прозрачные процессы и возможности, каждый должен иметь возможность присоединиться и поддерживать систему;
- новости в компании и индустрии;
- работа со входящими запросами со стороны бизнеса (консультация, аудит, помощь с pre-sale и т. д.);
- разработка общего вектора развития дисциплины;
- доступность информации;
- offline-мероприятия.
Оценка
Если люди имеют прозрачный персональный план роста и возможности для его реализации, нужно уметь делать оценку перехода специалиста на новый уровень и связанный с ним круг обязанностей.
В моей практике формат формального check list и принятие решения на основании мнения руководителя работали малоэффективно и лишь порождали больше вопросов.
В первую очередь желания человека расти профессионально и выходить на новые горизонты своего потенциала должны строиться на уже достигнутых результатах. Повышение как инвестиция работает плохо. Я склоняюсь к повышению как констатации, что специалист уже соответствует новой роли.
Во-вторых, достигнутые результаты должны иметь обратную связь со стороны старших коллег. Таким образом мы избежим простого красноречия кандидата в свой адрес. И если человек сделал положительный вклад в какое-либо дело, всегда найдутся люди, готовые это подтвердить.
И как финальный шаг — оценка потенциала. Церемония оценивания должна отличаться от типовых собеседований. Представьте себе, что вы являетесь лидером команды из пяти человек. В вашем проекте три таких команды. От результата работы всех команд зависит успешность проекта. Успешно закончим проект — получим хорошие бонусы. Завалим проект — вся проектная команда окажется без работы. В процессе работы вы получили новую зону ответственности и должны собрать четвертую команду. Как вы будете собеседовать нового лидера четвертой команды? Вам менее важны доскональные теоретические знания. Куда важнее, как будет рассуждать человек в разрезе тех реальных ситуаций, которые он может встретить на проекте.
Подводя итоги
Все эти процессы и мои мысли не являются последней инстанцией. Каждый из процессов мы меняли со временем, какие-то вовсе исключали из практики и добавляли новые. Цель: планировать наперёд и нивелировать риски обстоятельств, которые существуют на рынке.
Все эти инициативы направлены на планомерные инвестиции в новых лидеров, платформы для приобретения нового опыта, помощь в самореализации. Важна их системность, регулярность и вовлечение людей, имеющих потенциал, а не свободных от проектов.
