як тільки в Іраку вдалось уникнути близького провалу, бюрократична підтримка міжвідомчих команд почала знижуватись. До 2008 року управління й агенції, особливо одна розвідувальна агенція, яка залишилась неназваною, почали відкликати своїх людей і згортати спільну діяльність, вважаючи, що обмін інформацією та співпраця надто далеко зайшли[16].
Найпотужнішу зброю в арсеналі Америки, яку Боб Вудворд назвав не менш важливою, ніж винайдення танка чи літака, було відкладено вбік через містечкові перестороги керівників середньої ланки, які боялися за свої карєри. Я не раз бачив, як те саме відбувалося в одній великій фінансовій інституції в Бостоні. Кожного разу, коли вони мають проблему з важливим проектом, то в паніці кличуть мене на допомогу. Просять, щоб я навчив десятки їхніх людей Scrum та створив для них команди, здатні терміново впоратися з кризою. Вони направляють людей з усієї організації до багатофункціональних команд, щоб розвязати проблему. Вони її розвязують. Але, як тільки криза минає, вони розпускають команди по відповідних підрозділах під орудою звичайних менеджерів.
Річ у тім, що прозорість дій та обмін інформацією, прийняті в найкращих командах, попри всю ефективність, несуть у собі загрозу структурам, заснованим на таємничості та звичці все заплутувати. Менеджери часто не бажають, щоб інші менеджери, їхні власні команди або якісь інші люди всередині керівництва точно знали, чим вони займаються, чого досягли і як швидко. Вони вважають, що зберігання цього в таємниці надзвичайно важливе для їхньої влади. Замість того щоб діяти за спільними інтересами, вони діють за власними мотивами, які часто зводяться до жадібності та амбіцій. Саме такий спосіб мислення і призвів до масштабних управлінських провалів, що спричинили нещодавню світову економічну кризу. Дії багатьох компаній були засновані виключно на короткострокових перевагах для окремих осіб. Про загальну користь або обмеження шкоди для глобальної економіки ніхто не думав.
Розмір має значення, але не так, як ви гадаєте
Однак лише тому, що багатофункціональність може дати чудові результати, не слід гратися в Ноя та заганяти у свою команду кожної тварі по парі. Командна динаміка добре працює лише в малих командах. Згідно з класичною формулою, на високому рівні функціонують семеро людей плюс-мінус двоє (хоча я бачив команди навіть із трьох). Як не дивно, але досвід показує, що, якщо у вашій команді більш ніж девятеро людей, їхня швидкість насправді знижується. Саме так. Здавалося б, ресурсів більше, а команда сповільнюється.
У розробці програмного забезпечення є термін «закон Брукса», уперше виведений Фредом Бруксом ще в 1975 році у його новаторській книжці «Міфічна людина-місяць». Якщо стисло, закон Брукса каже: «Додавання людських ресурсів до простроченого проекту програмного забезпечення затримує його ще більше»[17]. Слушність цього підтверджено багатьма дослідженнями. Зокрема, вивченню того, скільки часу займає робота і чому, присвятив своє життя Лоренс Патнем легендарна фігура в розробці програмного забезпечення. Його праці незмінно демонструють, що проекти, в яких брали участь двадцять чи більше людей, потребували більших зусиль, ніж ті, де виконавців було пятеро чи менше. Причому не трохи, а набагато. Великій команді зазвичай потрібно в пять разів більше годин, ніж малій. Патнем спостерігав це знову й знову, а в середині 1990-х років вирішив спробувати провести широкомасштабне дослідження, щоб визначити ідеальну чисельність команди. Для цього він переглянув 491 проект середнього розміру сотень різних компаній. Усе це були проекти, що вимагали створення нових продуктів чи властивостей, а не перепризначення старих версій. Він розподілив ці проекти за розміром команди й одразу дещо помітив. Як тільки чисельність команд перевищувала вісім людей, виконання роботи починало займати в них значно більше часу. Групи, що нараховували від трьох до семи осіб, потребували для виконання однакового обсягу роботи приблизно 25 відсотків зусиль груп, де було від девяти до двадцятьох виконавців. Цей результат повторювався в сотнях проектів. Те, що дуже великі групи роблять менше, здається, є залізним правилом людської природи.
Але чому? Щоб відповісти на це запитання, слід розглянути обмеженість людського мозку. Ви, можливо, чули про класичне дослідження Джорджа Міллера, яке в 1956 році показало: максимальна кількість речей, що можуть зберігатися в короткотривалій памяті пересічної особи, становить сім. Ось тільки проблема з висновками Міллера в тому, що пізніше дослідження довело їхню помилковість.
У 2001 році Нельсон Ковен з Університету Міссурі вирішив перевірити правильність магічного правила семи та провів усебічне вивчення всіх нових досліджень на цю тему. Виявилося, що кількість елементів, які людина може зберігати у своїй короткотривалій памяті, не сім. Це чотири[18]. Люди часто думають, що можуть запамятати більше, використовуючи якісь спеціальні пристрої чи просто сильніше концентруючись. Але дослідження абсолютно чітко показують: ми здатні запамятати лише чотири «шматочки» даних. Класичним прикладом є дати комусь такий ряд із дванадцяти літер: дпанбумвфєцб. Як правило, люди можуть запамятати близько чотирьох із цих літер якщо тільки не помітять, що їх можна поділити на добре відомі абревіатури: ДПА (Державна податкова адміністрація), НБУ (Національний банк України), МВФ (Міжнародний валютний фонд), ЄЦБ (Європейський центральний банк). Якщо вам вдасться повязати речі у вашій короткотривалій памяті з асоціаціями довготривалої памяті, ви зможете утримати в голові більше. Але задіяна частина розуму свідома частина може утримати за раз лише приблизно чотири різні елементи.
Таким чином, існує глибоко вкорінене обмеження щодо того, скільки речей наш мозок може утримувати одночасно. Це відсилає нас знову до Брукса. Намагаючись визначити, чому додавання людей затримує виконання проекту, він відкрив дві причини. Першою є час, необхідний людям, щоб набрати потрібну робочу швидкість. Як ви, мабуть, розумієте, введення нового виконавця в курс справи затримує всіх інших. Друга причина повязана не лише з тим, як ми думаємо, але й, доволі буквально, з тим, про що наші мізки здатні думати. Зі збільшенням кількості людей значно збільшується кількість комунікаційних каналів, і наш розум просто не може із цим упоратись.
Якщо ви хочете розрахувати вплив розміру групи, візьміть кількість людей у команді, помножте її на цю саму кількість мінус один і поділіть на два. Кількість комунікаційних каналів = n (n1)/2. Таким чином, наприклад, якщо у вас є пятеро людей, ви маєте десять каналів. Шість людей пятнадцять каналів. Сім двадцять один. Вісім двадцять вісім. Девять тридцять шість. Десять сорок пять. Наші мізки просто не можуть дати раду зі стількома людьми за раз. Ми не знаємо, що вони всі роблять. І, намагаючись це визначити, ми сповільнюємось.
Як і в загоні спеціального призначення, у Scrum усі члени команди також мають знати, що роблять усі інші. Уся виконувана робота, нові виклики, досягнутий прогрес мають бути прозорими для решти виконавців. І, якщо команда стає надто великою, здатність кожного чітко спілкуватися з усіма іншими в будь-який час погіршується. Адже зявляється забагато перехресних звязків. Дуже часто команда соціально та функціонально розбивається на підкоманди, які починають працювати над досягненням невідповідних одна одній і навіть протилежних цілей. Багатофункціональність утрачається. Зустрічі, що раніше тривали хвилини, за таких умов розтягуються на години.
Не робіть цієї помилки. Команди мають залишатись невеликими.
Scrum-майстер
Працюючи зі своєю першою Scrum-командою, я регулярно показував їм відео про те, як готується до гри команда з регбі All Blacks. Ця легендарна збірна маленької Нової Зеландії є дійсно видатною командою. Перед кожною грою вони виконують ритуал народу маорі під назвою хака танець, що надихає воїнів на битву. Спостерігаючи за ним, ви просто-таки бачите, як енергія виходить із кожного гравця та зливається в одне велике ціле. На ваших очах синхронні притупування, плескання та ритуальні рухи уявного перерізання горлянки ворога перетворюють звичайних чоловіків на щось більше, щось величніше. Вони викликають бойовий дух, що не приймає ні поразки, ні страху.
Це відео довелось переглянути кілька разів, але врешті-решт моя команда компютерних програмістів, далеких від найкращої фізичної форми, сама захотіла досягти подібного стану. Вони виділили чотири моменти, варті наслідування. Перший полягає в чіткому концентруванні на меті, яке створюється та підживлюється наспівом маорі. Другим моментом є повна взаємодія сплетені руки гравців у прагненні єдиної мети. Третій справжній голод до бою: все, що постане на їхньому шляху, має бути усунене. Четвертий загальний захват, коли будь-який член команди проривається з мячем уперед. Байдуже хто. Приводом для святкування є сам цей факт.
Працюючи зі своєю першою Scrum-командою, я регулярно показував їм відео про те, як готується до гри команда з регбі All Blacks. Ця легендарна збірна маленької Нової Зеландії є дійсно видатною командою. Перед кожною грою вони виконують ритуал народу маорі під назвою хака танець, що надихає воїнів на битву. Спостерігаючи за ним, ви просто-таки бачите, як енергія виходить із кожного гравця та зливається в одне велике ціле. На ваших очах синхронні притупування, плескання та ритуальні рухи уявного перерізання горлянки ворога перетворюють звичайних чоловіків на щось більше, щось величніше. Вони викликають бойовий дух, що не приймає ні поразки, ні страху.
Це відео довелось переглянути кілька разів, але врешті-решт моя команда компютерних програмістів, далеких від найкращої фізичної форми, сама захотіла досягти подібного стану. Вони виділили чотири моменти, варті наслідування. Перший полягає в чіткому концентруванні на меті, яке створюється та підживлюється наспівом маорі. Другим моментом є повна взаємодія сплетені руки гравців у прагненні єдиної мети. Третій справжній голод до бою: все, що постане на їхньому шляху, має бути усунене. Четвертий загальний захват, коли будь-який член команди проривається з мячем уперед. Байдуже хто. Приводом для святкування є сам цей факт.
Отак ми й вибудували свою систему спринтів, щоденних коротких стендапів (зустрічей стоячи), оглядів та ретроспектив, після чого я усвідомив, що нам потрібен хтось, чиїм завданням буде слідкувати за ефективністю самого цього процесу. Не менеджер скоріше лідер-слуга, щось середнє між капітаном команди і тренером. Оскільки ми дивилися відео з All Blacks щодня, я спитав команду, як нам слід назвати цю людину. І вони зійшлися на «Scrum-майстер». Він чи вона забезпечуватиме всі зустрічі, стежитиме за прозорістю і, найважливіше, допомагатиме команді виявляти, що стоїть у неї на шляху. Ключовою частиною цього було усвідомлення, що часто перешкоди полягають не просто в проблемах із технікою або придуркуватості якогось бухгалтера Джима проблемою може бути процес як такий. Завданням Scrum-майстра було вести команду до безперервного покращення, регулярно шукаючи відповідь на питання: «Як нам виконувати свою роботу ще краще?»