Зачем нужна кроссфункциональная команда вместо функциональных отделов?

Вообще такое преобразование кажется неверным с точки зрения регулярного менеджмента. Ведь, начиная от Адама Смита «все знают», что повышение производительности достигается за счет разделения труда. В книге «О богатстве народов» он приводит знаменитый пример с изготовлением булавок: разделение изготовление на 18 операций, каждую из которых делают отдельно, приводит к тому, что 10 рабочих изготавливают в день 48 тысяч булавок, в то время как при индивидуальном изготовлении рабочий их делал не более 20 в день: увеличение производительности труда в 240 раз. В эту сторону идет и конвейер Форда, который принципиально повысил скорость изготовления автомобилей – до одного в минуту.

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

Собственно, когда в IT возникла необходимость массовой разработки с появлением персоналок, вызывавшем взрывной рост потребности в программах автоматизации для множества конкретных фирм, то попробовали пойти по такому же пути. Конечно, в отличие от булавок или автомобилей программы – изделия индивидуальные, однако для этого были наработаны методики индивидуализированного производства, применявшиеся, например, в строительстве зданий или других аналогичных отраслях. Конструкторы-проектировщики разрабатывали технический проект, который потом отдавали в производство и получали готовое изделие с более-менее гарантированными стоимостью, сроками и качеством. Аналогичную конструкцию попробовали сделать в IT, и так появился Rational Unify Process (RUP). Не получилось. Для этого есть системные причины, подробнее я рассказывал о них в главе «Развитие и провал регулярного менеджмента в IT» и не буду повторяться.

А здесь хочу отметить, что автоматизация бизнеса имеет еще одну важную особенность: окружение, в котором работает система, динамично изменяется во времени. Конечно, при строительстве индивидуальных домов или ремонте квартир это тоже имеет место: у заказчика могут непрерывно возникать новые пожелания, но если они касаются уже построенного, то ему можно предложить голосовать деньгами. Однако, есть опасность что при бесконечных переделках дом никогда не будет закончен, такие примеры известны. В IT задача успеть за изменениями бизнеса при его автоматизации гораздо более актуальна, речь идет не о произвольных желаниях, а о следовании за изменениями процессов, которые компании продиктовал рынок.

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

Цепочки создания ценности.

Кроссфункциональные команды вместо функциональных отделов изменяют и сам характер производства. Рассмотрим это подробнее. Для этого нам понадобиться обобщенная структура компании. Я буду работать на той схеме, которую