Превратите каждую команду в небольшую бизнес-единицу, создающую ценность

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

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

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

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

Самое главное – чтобы функциональные и кросс-функциональные команды воспринимали себя в качестве бизнес-единиц, создающих ценность для своих клиентов независимо от того, внешние это клиенты или внутренние. Наша команда системных администраторов считала себя бизнес-подразделением, задача которого состоит в обслуживании клиентов и создании для них определенной ценности. Поэтому они нам так нравились. Они давали нам понять, что мы важны для них в качестве клиентов, независимо от того, сколько раз у нас падают операционные системы или серверы. Функциональные и кросс-функциональные команды должны управляться как небольшие бизнес-подразделения. Тогда они действительно становятся фрактальными группами, и их число в организации может быть неограниченным [Leffingwell 2007: 96].