Всем привет! Меня зовут Артём Харченков, я руководитель направления Java-разработки компании Crosstech Solutions Group. В этой статье хочу поделиться практическим опытом построения команды с нуля: от ситуации, когда вся экспертиза сосредоточена в одном человеке, до управления большой командой из пятидесяти специалистов, которые параллельно развивают несколько продуктов в различных классах решений информационной безопасности.
Пара слов о компании. Наши продукты помогают заказчикам снизить риски ИБ и защитить свои данные. Например, одним из ключевых продуктов, с которого во многом начался этот путь, стала Jay Data – решение для поиска, классификации и маскирования конфиденциальной информации в базах данных. Все наши решения внесены в реестр отечественного ПО и разрабатываются с учетом рекомендаций ФСТЭК.
Эта статья – текстовая версия моего доклада на конференции Team Lead Today, который можно посмотреть здесь. Она основана на реальном управленческом опыте, полученном за четыре года. За это время я и команда проходили через рост, ошибки найма, смену ролей, появление сложных процессов, реструктуризацию и итоговое масштабирование. Я сознательно опишу не только положительные решения, но и те места, где приходилось ошибаться, учиться, что-то переделывать и заново принимать решения.
Все описанное дальше – это не какая-то универсальная модель, а мой личный опыт. Я поделюсь им с вами через последовательный разбор этапов, возникающих вопросов и моментов озарения, которые могут быть полезны тем, кто строит или развивает команды разработки.
Маленькая vs большая команда
Прежде чем говорить о росте, важно понять, в чем состоят плюсы и минусы больших и маленьких команд.
Маленькие команды выигрывают за счет тесного личного взаимодействия. В них люди много общаются напрямую, быстрее принимают решения и лучше понимают контекст задач. Как правило, члены маленькой команды получают более разносторонний опыт: аналитик может выполнять функции менеджера, разработчик участвовать в тестировании или формировании требований. Для компании же такие команды дешевле в управлении и проще в перестройке.
В чане с плюсами отдельно хочу выделить минимальные затраты на коммуникации. Количество связей в команде с увеличением числа участников растет не линейно, а в геометрической прогрессии, поэтому даже добавление в цепочку нескольких человек резко усложняет обмен информацией.
Большие команды, в свою очередь, дают больше возможностей, позволяют реализовывать сложные и масштабные проекты, имея у себя в штате, в том числе, и узкоспециализированных экспертов. Также в маленьких командах больше bus-фактор, т.е. зависимостей от конкретных людей. Потеря одного сильного сотрудника в большом коллективе не так критична, как в маленьком.
Однако, цена таких преимуществ – рост коммуникационных издержек, сложности контроля и необходимость внедрения процессов.
Один в поле воин (~ 3 месяца)
Первый этап создания команды у меня начинался с точки, когда вся экспертиза и ответственность была сосредоточена в одном человеке – во мне самом. Изначально, когда я только приходил в компанию CTSG, здесь не было Java-направления как такового: эту экспертизу я принес с собой. Мы изначально договорились с руководителем, что первое время я буду работать один, а позже получу квоту и бюджет на найм сотрудников, чтобы реализовывать проекты посерьезнее.
Сначала я совмещал все роли: аналитик, разработчик, архитектор, тестировщик и менеджер. С одной стороны, это давало максимальную скорость из-за отсутствия «сетевых» потерь в коммуникациях и искажений информации. Когда все решения принимаются одним человеком, то все намного проще.
Главное на этом этапе – не словить раздвоение личности…
С другой стороны, быстро стало очевидно, что мои ресурсы сильно ограничены. Можно, конечно, тянуть направление в одиночку, но не очень-то долго. Кроме того, невозможно одинаково хорошо разбираться во всех областях, даже если у вас есть для этого какой-никакой бэкграунд
Поэтому ключевые инсайты, которые я вынес из этого этапа:
- можно все делать одному, но жизнь слишком коротка;
- невозможно быть экспертом во всем.
Три самурая (~ 9 месяцев)
«Многорукий» специалист в лице меня наконец-то получил квоту на двух сотрудников. Я очень тщательно подходил к подбору, потому что понимал, что ошибки на самом первом этапе найма могут вызвать вопросы у моего руководства и понизить мою уверенность в себе как у начинающего менеджера.
Спустя время считаю, что такой подход был оправдан: в итоге я нашел первых двух хороших программистов, с которыми мы начали наш увлекательный совместный путь.
По началу у нас в команде все делали всё, а из инструментов была лишь простая доска в Trello с двумя статусами: «to do» и «done». На ней я заводил любые задачи: по описанию требований, разработке, тестированию и принятию решений.
Помню, что на этом этапе, я столкнулся с типичным страхом начинающего руководителя – взять в команду человека сильнее тебя. Мне тогда казалось, что это может поставить под угрозу мою управленческую позицию в компании: ведь руководство может увидеть, что есть разработчик круче и назначить лидом его вместо меня. Позже, конечно, я понял, что этот страх скорее иррационален и если руководитель хорошо справляется со своей работой, то на практике такое случается крайне редко.
Инсайт, который я с собой забрал в следующий этап:
- когда в маленькой команде все занимаются всем – это норма. И это преимущество маленьких команд.
Боевое крещение (~ 6 месяцев)
«Три самурая» обросли мышцами. К нам присоединились еще два программиста, и нас отправили делать проект заказной разработки для крупного клиента. Это стало нашим первым стресс-тестом.
Я все еще пытался писать код, но у меня появлялось всё больше административных задач. С увеличением их количества, приходило осознание, что без изменения своей роли дальнейший рост невозможен. Пришло время переставать быть экспертом и начать становиться руководителем.
Людей на этом этапе я продолжал выбирать очень тщательно, понимая, что они станут моей будущей опорой при дальнейшем росте команды. Я осознанно сильно ограничил себе возможности по найму и выбирал программистов только из своего города, так как хотел периодически работать оффлайн. Мы выстраивали личный контакт: ездили в офис, ходили вместе на обед и иногда куда-нибудь после работы. Такая близкая коммуникация сыграла свою роль в будущем. Позже, кстати, эти программисты стали техническими лидами на продуктах при масштабировании команды.
Тогда же я начал готовить заместителя. На время своего отпуска делегировал ему задачи и функционал, а еще привлекал его и остальных ребят к собеседованиям. Другими словами, старался выстраивать культуру так, чтобы не только я формировал команду, но и другие тоже влияли на ее становление и чувствовали свою сопричастность к этому.
В это же время приходило осознание, что при таком размере команды разработчики уже не могут одинаково хорошо писать требования и тестировать, как это могли бы делать профильные специалисты.
Поэтому главный вывод из этого этапа, который я сделал:
- в команде 5+ сотрудников уже придется начать разделять роли. Все не могут делать всю работу одинаково хорошо.
Становление (~ 1 год)
На этапе становления у нас в команде появились первые специализированные роли: системный аналитик и тестировщик. Команда стала многофункциональной, а в нашей работе появились первые процессы.
Так как за каждый этап задачи теперь стали отвечать разные люди, то мы перешли к «взрослому» процессу работы в Jira Workflows. Появились первые элементы people-management – я стал проводить one-to-one, задумываться над индивидуальными планами развития сотрудников.
Но здесь произошли и первые кадровые ошибки. Я узнал, что хорошо пройденное собеседование еще не гарантирует качественной работы. Столкнулся с ситуациями, когда разработчик уверенно прошел middle-интервью, но не справлялся с базовыми джуновскими задачами, и даже не умел пользоваться дебаггером. Около двух месяцев нам пришлось с ним промучаться и в итоге, к сожалению, все равно попрощаться.
Чтобы не попадать в похожие ситуации, рекомендую начинающим специалистам посмотреть посты по стажировкам и повышению навыков в нашем телеграм-канале и попробовать себя в Учебном центре CTSG.
Еще на этом этапе появились первые дискоммуникации, непонимания зон ответственности и скрытые трения между членами команды. Не сказал бы, что это были конфликты, но несоответствия ожиданиям относительно работы других ролей возникали регулярно.
Итак, инсайт:
- в команде, где есть несколько ролей, нужно обязательно начинать строить процессы. Работать как на первых этапах, где каждый и так знает, что ему делать, уже не получится.
Модернизация (~ 1 год)
Дальнейший рост команды привел к первой серьезной реструктуризации. Мой отдел разработки преобразовался в управление, где появился второй уровень менеджмента и лиды направлений. На этом этапе у нас появились отделы разработки, аналитики, тестирования и автоматизации, у которых были назначены руководители. Какими-то отделами я управлял через лидов, а какими-то все еще напрямую.
Команда одновременно работала над несколькими продуктами, а специалисты каждого отдела распределялись по ним. Появилась необходимость делегировать функции управления на каждом продукте – так в нашей структуре возникла роль delivery-менеджера.
Получившуюся структуру часто называют «матричной». В ней у каждого сотрудника есть административный руководитель – лид отдела, и функциональный руководитель в лице delivery-менеджера.
Вместе с этим начали появляться первые регламенты: по найму, по зонам ответственности, по работе с продакт-менеджерами. Мы в команде также начали выстраивать собственную инфраструктуру разработки – купили свой первый физический сервер, на котором «нарезали» виртуальные машины с Jenkins и Nexus и настроили свой CI/CD.
Вроде со стороны все складывалось неплохо, но я вспоминаю этот этап, как наиболее перегруженный: из-за отсутствия полноценного опыта по найму delivery-менеджера, у меня не получилось полностью делегировать ему активности по управлению продуктовыми командами: проведение дейли, планирования, ретро и управление бэклогом. Из-за этого мне все равно приходилось ходить на все встречи и контролировать процессы, что вызывало жуткую нехватку времени.
Иногда случалось так, что назначенные или нанятые лиды не всегда ловили коннект со старыми сотрудниками, поэтому временами мои отделы сталкивались со сложными отношениями между руководителями и даже с увольнениями на этой почве.
Основной инсайт:
- если вы вводите второй уровень управления, то как можно раньше нанимайте лидов первого уровня, которые соберут свои команды под себя. В то время наш HR даже придумала подходящую фразу: «Сначала «голова», затем «руки». А может и не она это придумала…
Второстепенные выводы этапа «Модернизация», которые я сделал:
- Стоит внимательно выбирать, кому делегируете. Человек должен быть способен не только взять на себя ваши функции, но и хотеть этого.
- В прямом подчинении не должно быть больше 5-6 человек, иначе вам обеспечен перегруз.
Масштабирование (~ 1 год)
На последнем этапе команда превратилась в большую структуру, которая одновременно создавала 4 продукта компании. У меня появились лиды по каждому направлению, полный набор специалистов – от технических писателей до автотестеров, два delivery-менеджера. Первого я успешно заменил и все стало намного лучше.
Команда начала внедрять новые практики: нагрузочное тестирование, quality gates, тестирование документации, метрики по дефектам и производительности команды и много чего еще. Мы начали тщательнее подбирать методологии разработки, проверяли, в каких проектах лучше использовать спринты, канбан-доски и так далее.
Все нововведения в команде проходили через совет лидов, поэтому решения, как мне кажется, были взвешенными.
Еще наша компания взяла курс на безопасную разработку. Мы стали ориентироваться на получение сертификата ФСТЭК, внедрять статистические, динамические анализаторы, композиционный анализ и фаззинг. Об этом мы подробно рассказывали в нашем подкасте CrossCheck.
Конечно, этот этап тоже не обошелся без проблем, и главная из них – осложнившиеся коммуникации. С ростом команды информация часто перестала передаваться напрямую, а начала проходить через несколько участников и в результате могла теряться или искажаться – о чем я писал в самом начале статьи. Это приводило к появлению конфликтов, как накопленных со временем, так и возникающих, например, из-за разногласий на стыках зон ответственности.
Отдельной проблемой стали незафиксированные договоренности. Решения часто принимались на созвонах или в «личке» и нигде не документировались. В итоге, к примеру, могли возникать расхождения между спецификацией и фактической реализацией, причины которых было невозможно отследить.
Основной инструмент, который помог нам бороться с этим – внедрение обязательных протоколов встреч. Такое решение снижает количество совещаний и помогает лучше фиксировать договоренности. Когда мы ввели правило, что организатор встречи пишет протокол, то люди стали чаще задумываться: «А точно ли мне нужна эта встреча?». Вопросы сразу стали решаться в переписке.
Еще надо стараться максимально четко описывать зоны ответственности: это уменьшает число стычек между членами команды, а отражение прецедентов на бумаге позволяет со временем создать рабочие регламенты.
В конце добавлю, что очень важно выстраивать доверительные отношения с лидами нижестоящих уровней: только при наличии доверия можно получать достоверную информацию о ситуации в отделах и совместно принимать взвешенные решения. И лучше начинать это делать как можно раньше.
Глобальные выводы
Пройдя этот увлекательный путь длиной почти в 4 года, вот что я мог бы посоветовать тем, кто планирует построить большую команду:
- Процессы и практики должны соответствовать размеру команды. Не стоит в маленьком отделе внедрять много процессов. В то же время в больших подразделениях они становятся очень важны.
- Универсальность и принцип «все делают всё» нормально работают на ранних этапах, но чем более зрелой становится команда, тем больше появляется выделенных ролей.
- С ростом команды неизбежно увеличиваются управленческие издержки и сложность коммуникаций.
- Команду лучше растить постепенно – людям комфортнее привыкнуть к уже существующим правилам, чем переживать резкие изменения процессов.
- Четкие зоны ответственности и зафиксированные договоренности снижают конфликты и искажения/потери информации.
- Делегирование работает только тогда, когда для этого выбраны правильные люди.
- Доверие руководства и контакт с ключевыми вашими сотрудниками – критически важные факторы выживания и роста команды.
На этом пока все. Спас��бо, что дочитали статью до конца – увидимся в следующих публикациях. Подписывайтесь на мой telegram-канал «IT Инсайты», там я публикую много крутого контента и реальных историй для тимлидов и тех, кто только планирует им стать!
