Как построить команду под ИТ-проект, которая даст результат

Сильная команда — важная часть проектной работы, определяющая результат. Рассказываем, как это происходит в Lodoss Team: делимся реальными историями и опытом.

Как отбирать людей на проект

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

Команду мы начинаем формировать, когда дело подходит к подписанию контракта с заказчиком — в Lodoss Team этим занимаются ИТ-директор и начальник отдела управления проектами. Первый знает, каким инструментарием и на каком уровне владеет конкретный человек. У второго есть информация о загруженности кадров текущей работой, понимание личностных и профессиональных качеств каждого сотрудника. Он всегда может сказать, кто хорошо сработается, а также кто из менеджеров проектов сможет возглавить разработку нового продукта.

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Идеально, если можно подключить к проекту уже сработавшуюся команду, внося в её состав минимальные изменения. Строить же коллектив под проект с нуля — непросто и сопряжено с рисками. Особое внимание нужно уделить, если вы подбираете исполнителей извне. Токсичный новый коллега может разрушить гармонию даже в сплочённом дружном коллективе. Поэтому мы стараемся прибегать к такому как можно реже, и для этого у нас есть проверенный кадровый резерв.

Как распределить обязанности в команде

Роли каждого специалиста в проекте распределяются в зависимости от двух главных факторов:

• квалификации и занятости сотрудника,
• его психологической и эмоциональной совместимости с участниками проекта.

После того как вы сформировали команду и закрепили роли за сотрудниками, важно чётко обозначить, кто и за что отвечает на проекте. Нужно распределить не только обязанности в разрезе «Это Петя и Вася — они фронтендеры, а это Дима — он тимлид». Важно добиться общего понимания у всех участников команды: к кому обращаться в случае затруднений, кто отвечает за принятие решений в конкретных ситуациях. Для этого можно собрать стартовый митинг со всеми членами команды, озвучить ответственных и ответить на их вопросы. В идеале записать эти договорённости.

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

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

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

Есть ещё хорошая практика — каждую неделю назначать мердж-мастера. Это оправдывает себя на проектах, где работает больше трёх человек. Мердж-мастер — это главный ревьюер, человек, который отвечает за качество кода. Он является конечным рецензентом, определяющим, можно ли заливать код в master-ветку проекта. Он же следит за своевременной заливкой кода.

Мы работаем по такой схеме: ребята разрабатывают код в рамках своих веток в гите. Есть ревьюеры кода, которые отвечают за его качество и исправление ошибок. Они просматривают все запросы на мерж, и если есть замечания — отправляют код на доработку. Каждый запрос должен получить одобрение двух ревьюеров, только после этого код может выйти в свет.

Ошибки, которые делают чаще всего при формировании и управлении командой в проекте

Ошибка при выборе руководителя проекта

На проекте должен быть человек, отвечающий за принятие технических решений, назовём его «старшим на проекте». Даже если в команде всего два разработчика, кто-то из них должен быть назначен главным, иначе конфликты в проекте вам обеспечены. Излишние споры будут возникать вокруг любого вопроса: какой инструмент выбрать, как строить архитектуру, кто какую задачу будет делать. В принципе дискуссии — это не плохо, главное, чтобы менеджер на их основе мог бы принять грамотное финальное решение и закончить этим дебаты.

Пример из жизни. Над небольшим проектом по мобильной разработке у нас работала пара разработчиков. Старшего мы не назначали. Один из программистов занимался визуальной частью, а второй — работой с сервером, обработкой и хранением данных. Чуть позже выяснилось, что оба имеют свой взгляд на работу с data layer. Одному из разработчиков пришлось брать на себя роль старшего, но без формальной власти решение некоторых задач сильно затягивалось. Он не мог сказать коллеге: «Я тебя выслушал, понял твою точку зрения, но делать будем по моему плану». Руководить напрямую этот сотрудник не мог: поэтому ему приходилось проявлять чудеса дипломатии и идти на компромиссы. Всё это не шло на пользу проекту. Когда руководство случайно услышало один из таких споров, человека наделили полномочиями старшего на проекте, после чего дальнейшая работа заметно ускорилась.

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

Неграмотное управление конфликтами

Необходимо следить за эмоциональным настроем команды. Если упустить момент возникновения конфликта в коллективе, то участники проекта могут сильно поссориться и их работа не будет плодотворной. Даже если люди тихо не любят друг друга, но при этом делают свою работу, это подрывает общий моральный дух команды, снижает эффективность работы. Поэтому важно выявлять и вовремя устранять такие моменты: примирять участников конфронтации, а если это невозможно — то выводить одну или обе стороны из проектной команды.

Однажды мы проглядели на проекте конфликт дизайнера и Android-разработчика. Суть разногласий на первый взгляд кажется смешной: дизайнер тщательно прорабатывал мелкие детали интерфейса, а разработчик решил, что они не нужны, и пилил интерфейс без них. Когда дизайнер увидел промежуточный результат, то очень расстроился, что его работа пропала впустую. Он наотрез отказался дальше работать с этим программистом и даже хотел уволиться. При этом своими переживаниями он ни с кем не делился — думал, что рассказывать об этом бесполезно, так как руководитель разработчика по умолчанию будет на его стороне. Молчаливый конфликт зрел, эффективность работы команды понижалась. В один момент дизайнер всё же не выдержал и заявил о своём недовольстве. После этого мы быстро решили проблему, но целый месяц команда работала в состоянии стресса.

Отсутствие «громоотвода»

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

Игнорирование проблем в коллективе

Большая ошибка держать человека-проблему в проекте, потому что кажется, что его нельзя заменить. Начинающие и неопытные менеджеры считают, что главное, чтобы разработчик писал код. Их не волнует, что проблемы вокруг сотрудника растут, как снежный ком. Они думают, что это не критично и до конца проекта как-нибудь можно доработать с этим коллегой. Это в корне не верно — если человек не идёт на диалог и отказывается исправляться или только формально соглашается и обещает, но делает всё по-старому, то его нужно исключать из команды. В противном случае этот сотрудник может подорвать работоспособность всего коллектива и успешная реализация проекта будет под угрозой.

Как мотивировать и повышать эффективность работы

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

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

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

Руководитель проекта должен избегать двойных стандартов и максимально объективно подходить к работе каждого члена команды. Недопустимо, чтобы кто-то работал на проекте спустя рукава, в таком случае — это сигнал расслабиться для всех остальных. Если же вы открыто кого-то хвалите, то нужно следить и за успехами других людей. Не заметить чьих-то стараний — значит дать понять, что усердие и стремление человека не ценятся, а следовательно, не нужны компании.

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.