Почему функциональная специализация становится неэффективной в инновационных проектах?

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

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

Вернемся к нашему примеру. Передав все 30 рабочих чертежей инженерам, конструктор может перейти к следующему проекту. Однако, инженеры могут не знать, как должно работать то, что изображено на чертежах. Что если некоторые чертежи непонятны? Что, если возникнут какие-то проблемы, когда инженеры начнут с чертежами работать? Все эти имеет место.

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

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

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

РЕКОМЕНДАЦИЯ БЫЛА ПОЛЕЗНА? ОСТАВАЙТЕСЬ НА СВЯЗИ С НАМИ, ЗАРЕГИСТРИРОВАВШИСЬ НА САЙТЕ.