Scrum - Джефф Сазерленд
Це була видатна зброя, але не якийсь новий електронний пристрій чи безпілотник. Генерал Стенлі Мак-Крістал, на той час начальник управління спеціальних операцій, назвав цю стратегію «спільним веденням війни». Вона передбачала виявлення та знешкодження мережі «Аль-Каїди» за участю багатофункціональних команд з усіх підрозділів, підпорядкованих уряду США. У статті від 6 вересня 2008 року газета Washington Post описала її так:
ЦРУ забезпечує аналітиків розвідки та шпигунську техніку з різними датчиками й камерами, здатними відстежувати цілі, транспортні засоби чи військову техніку впродовж 14 годин. ФБР надає експертів-криміналістів, які ретельно вивчають отримані дані – від інформації з мобільних телефонів до вмісту кишень та гаманців екстремістів. Співробітники міністерства фінансів відслідковують грошові потоки серед екстремістів та від урядів, які їх підтримують. Штатні працівники Агенції національної безпеки перехоплюють переговори та комп’ютерні файли, а фахівці Національної агенції геопросторової розвідки використовують високотехнологічне обладнання для точного визначення місця, де підозрювані екстремісти користуються телефонами чи комп’ютерами[14].
Разом вони створили багатофункціональну команду, що мала всі вміння й навички, необхідні для виконання роботи. Замість того щоб залишити всіх цих спеціалістів в окремих командах, які б рідко ділилися інформацією, вони всі працювали разом в одному приміщенні, об’єднавши свої знання та спільно плануючи відстеження й ліквідацію терористів «Аль-Каїди».
Раніше та чи інша розвідслужба визначала ціль, а потім передавала всі матеріали силам спеціального призначення, які й діяли далі. Після цього спецпризначенці, у свою чергу, передавали всю зібрану ними розвідінформацію іншій команді для аналізу. Ті, хто мав справу з такою моделлю, відчув на собі те саме, що й компанія Fuji-Xerox тоді, коли японці намагалися запровадити в себе систему поетапного планування NASA, і це стало однією з головних причин розроблення Scrum. Скрізь, де між командами відбуваються такі передачі справ, існує небезпека катастрофи. У статті в журналі міністерства оборони США Joint Force Quarterly під назвою «На службі розвідки, спостереження та рекогносцирування: найкращі практики спецназу» про це говориться так:
Міжвідомчі групи дозволили позбутись організаційних «швів» між різними силами коаліції в Іраку, приставивши до пріоритетних цілей «незмигне око»… Адже передача обов’язків між підрозділами та організаціями являла собою «мигання», під час якого сповільнювалась динаміка і ціль могла втекти[15].
Налагодити обмін інформацією та ресурсами, як у цьому випадку, нелегко за будь-яких обставин. Мені доводилося бачити менеджерів, яких буквально заціплювало, коли їхні ресурси переходили до команди поза межами їхнього прямого контролю. Відмовлятися від повсякденного мікроуправління та контролю взагалі непросто, але робити це в потайному світі розвідки та спеціальних операцій ще складніше – настільки, що, попри їхню ефективність, іракські команди були швидко розформовані одразу після визнання успіху стратегії «Великої хвилі». Крістофер Лемб та Еван Мансінг виклали це в своїй захопливій статті «Таємна зброя: групи пріоритетних цілей як організаційна інновація».
…як тільки в Іраку вдалось уникнути близького провалу, бюрократична підтримка міжвідомчих команд почала знижуватись. До 2008 року управління й агенції, особливо одна розвідувальна агенція, яка залишилась неназваною, почали відкликати своїх людей і згортати спільну діяльність, вважаючи, що обмін інформацією та співпраця надто далеко зайшли[16].
Найпотужнішу зброю в арсеналі Америки, яку Боб Вудворд назвав не менш важливою, ніж винайдення танка чи літака, було відкладено вбік через містечкові перестороги керівників середньої ланки, які боялися за свої кар’єри. Я не раз бачив, як те саме відбувалося в одній великій фінансовій інституції в Бостоні. Кожного разу, коли вони мають проблему з важливим проектом, то в паніці кличуть мене на допомогу. Просять, щоб я навчив десятки їхніх людей Scrum та створив для них команди, здатні терміново впоратися з кризою. Вони направляють людей з усієї організації до багатофункціональних команд, щоб розв’язати проблему. Вони її розв’язують. Але, як тільки криза минає, вони розпускають команди по відповідних підрозділах під орудою звичайних менеджерів.
Річ у тім, що прозорість дій та обмін інформацією, прийняті в найкращих командах, попри всю ефективність, несуть у собі загрозу структурам, заснованим на таємничості та звичці все заплутувати. Менеджери часто не бажають, щоб інші менеджери, їхні власні команди або якісь інші люди всередині керівництва точно знали, чим вони займаються, чого досягли і як швидко. Вони вважають, що зберігання цього в таємниці надзвичайно важливе для їхньої влади. Замість того щоб діяти за спільними інтересами, вони діють за власними мотивами, які часто зводяться до жадібності та амбіцій. Саме такий спосіб мислення і призвів до масштабних управлінських провалів, що спричинили нещодавню світову економічну кризу. Дії багатьох компаній були засновані виключно на короткострокових перевагах для окремих осіб. Про загальну користь або обмеження шкоди для глобальної економіки ніхто не думав.
Розмір має значення, але не так, як ви гадаєте
Однак лише тому, що багатофункціональність може дати чудові результати, не слід гратися в Ноя та заганяти у свою команду кожної тварі по парі. Командна динаміка добре працює лише в малих командах. Згідно з класичною формулою, на високому рівні функціонують семеро людей плюс-мінус двоє (хоча я бачив команди навіть із трьох). Як не дивно, але досвід показує, що, якщо у вашій команді більш ніж дев’ятеро людей, їхня швидкість насправді знижується. Саме так. Здавалося б, ресурсів більше, а команда сповільнюється.
У розробці програмного забезпечення є термін «закон Брукса», уперше виведений Фредом Бруксом ще в 1975 році у його новаторській книжці «Міфічна людина-місяць». Якщо стисло, закон Брукса каже: «Додавання людських ресурсів до простроченого проекту програмного забезпечення затримує його ще більше»[17]. Слушність цього підтверджено багатьма дослідженнями. Зокрема, вивченню того, скільки часу займає робота і чому, присвятив своє життя Лоренс Патнем – легендарна фігура в розробці програмного забезпечення. Його праці незмінно демонструють, що проекти, в яких брали участь двадцять чи більше людей, потребували більших зусиль, ніж ті, де виконавців було п’ятеро чи менше. Причому не трохи, а набагато. Великій команді зазвичай потрібно в п’ять разів більше годин, ніж малій. Патнем спостерігав це знову й знову, а в середині 1990-х років вирішив спробувати провести широкомасштабне дослідження, щоб визначити ідеальну чисельність команди. Для цього він переглянув 491 проект середнього розміру сотень різних компаній. Усе це були проекти,
