Формирование команды проекта в области информационных технологий

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

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

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

классическом варианте на старте речь идет о 4-6 участниках
Тимлид / архитектор (часто в одном лице);
Разработчик фронтенд / бэкенд (часто фулл стек);
Тестировщик (при регулярных обновлениях);
Специалист техподдержки (при частом взаимодействии с пользователями).

Критерии качества работы проектной ИТ-команды
Соблюдение дисциплины. Это самый быстрый тест для менеджера проекта. Действия сотрудников должны быть согласованы, информация – передаваться быстро, без искажений. Если один из участников постоянно опаздывает с выполнением работ, он может тянуть на дно всю команду IT-специалистов.
Единая цель. Все участники должны понимать цель проекта и ориентироваться на один результат.
Один лидер. Руководить должен только один член команды, признанный ею. «Перетягивание одеяла на себя» другими участниками ведет к рассогласованности действий, конфликтам, росту эмоциональной напряженности внутри коллектива.

Критерии качества работы проектной ИТ-команды
4. Ответственность каждого сотрудника. Каждый вносит свой вклад в проект. Каждый должен нести ответственность за свою работу, а не переваливать вину на другого.
5. Условия для мотивации.
Виды мотивации: повышение зарплаты, профессиональный и личностный рост, премии, карьерный рост. Невозможно достижение хороших результатов и качественная работа в принципе без мотивации работников.

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

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

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

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