Строим команды для проектов или используем существующие?

Тема данной статьи достаточно противоречивая и спорная. Это скорее идея, которая меня беспокоит последние пару лет, основанная на моем опыте работы и консалтинга в различных компаниях. У меня нет полного решения или продуманного на 100% плана трансформации к новой схеме, но мне кажется, что идея все равно заслуживает внимания. В большей части все сказанное ниже касается аутсорсинговых компаний, хотя достаточно справедливо и для больших продуктовых компаний, которые работают над линейкой продуктов.

High performance team

Итак, в большинстве компаний минимальной боевой единицей считается один сотрудник (которого все называют как только могут: ресурс, FTE и прочие лейбы). А это автоматически накладывает множество интересных шаблонов. Например, когда в компанию заходит новый проект, то пытаются собрать группу разрозненных сотрудников, отвечающих определенных требованиям, в команду. Или, в случае “схлопывания” проекта, раскидывают сотрудников из команды по другим командам на другие проекты. Ну и наконец, если кто-то в команде захотел развития или поработать с другими технологиями, то его пытаются перевести в другой проект.

Казалось бы, что тут плохого? Совершенно логичная оптимизация. Беда в том, что это локальная оптимизация, которая заточена на улучшение утилизации одного конкретного сотрудника (чтобы все были на 100% “утилизированы”), а не компании в целом. Что, как известно, чаще приносит больше проблем чем прибыли.

Надеюсь, всем известны этапы становления любой команды:

Team dynamics

На первых двух стадиях члены команды узнают друг о друге, пытаются начать работать вместе и взаимодействовать в рамках команды. Тут же происходит выдвижение неформальных лидеров, конфликты, притирка, выработка командных правил и принципов. На этих стадиях возможны “потери”, так как не все смогут работать вместе, а также ситуации полной неэффективности, когда конфликты не разрешаются вовремя или у команды нет лидера. На последних двух стадиях мы уже имеем более-менее слаженную команду, которая научилась работать как единое целое, работает над улучшениями и самосовершенствованием, показывает реальную эффективность. Стоит отметить, что до этих стадий доходят далеко не все команды.

И что мы делаем с такими командами когда проект завершается или начинает подходить к завершению? Правильно: расформировываем и делаем новые! Немного с другим набором технологий, немного другого состава, немного другого уровня… И все начинается заново. Вновь сформированные команды снова начинают проходить через те же стадии и испытывать те же проблемы. Компания не пользуется заработанным наследием предыдущего проекта в виде слаженной эффективной команды. Новые технологии? Хорошей сыгранной команде нужно ставить заранее цели по изучению новых востребованных технологий и она будет только рада развиваться. И нужно понять что дороже: доучить команду новым технологиям или строить новую команду с нуля? Заказчик хочет определенных людей, а не команду? Может пора изменить методику продаж и объяснить причины заказчику. Возможно, им также будет дешевле взять сыгранную команду вместо затрат на формирование и становление новой, даже если какие-то конкретные люди из команды им на первый взгляд не нужны.

Почему же компании так поступают? Есть несколько натуральных причин. Во-первых, часть компаний привыкла продавать людей. Больше продал – больше прибыли. Нет смысла задумываться над уровнем эффективности и структурами следующего порядка, ведь за все проблемы заплатит заказчик. Во-вторых, большая часть компаний не задумываются над потерями на этом уровне в принципе. Ведь на рынке все так работают, а это значит можно особо “не париться”. Ведь изменения – это всегда риски, затраты и выход из зоны комфорта. В-третьих, сами люди уже сильно привыкли к такой модели работы в компании и не особо мыслят командными парадигмами: сегодня в одной команде, завтра уже в другой и все нормально.

Кому больше всего выгодно задуматься об этой идее? Тем компаниям, которые хотят переходить от классической торговли людьми к полноценной продуктовой заказной разработке, где все внутренние затраты не влияют на конечную стоимость работ (либо ты оптимизируешь их и выходишь на прибыль, либо работаешь в убыток). И вот тут на сцену выходят много новых подходов, которые заменят существующие “плохо работаешь – не беда, заказчик заплатит”, “из любых людей сколотим команду и за это заплатит заказчик”, “проблемы с командой оплатит заказчик”. Изменения надвигаются, не так быстро, но они все ближе…

Обсуждение (0)

Leave a Reply

Your email address will not be published. Required fields are marked *