Альпінізм

На початку 1970-х, коли я жив і працював у Швейцарії, я вступив до Швейцарського альпійського клубу і провів кілька чудових літніх сезонів, пройшовши шлях від початківця до альпініста середнього рівня. Виявилося, що альпінізм мені більше до смаку, ніж скелелазіння; можливо, це тому, що в альпінізмі було більше різноманітності, а скелелазіння, зрештою, є його підгрупою. Або, можливо, тому, що в альпінізмі більше уваги приділяється витривалості, а не гірським спортивним показникам. У будь-якому випадку, я зрозумів, що для досягнення успіху в цій діяльності потрібно поєднувати базові технічні навички з навичками спілкування з людьми та здоровим глуздом. Я виявив, що було багато альпіністів, але мало дійсно хороших лідерів альпіністських груп. Тож я спробував з’ясувати, що робить хороших лідерів справді хорошими.

Усі люди, яких я прагнув наслідувати, досягли успіху в той момент, коли вони вже точно пройшли пік своєї фізичної досконалості, але здобули неймовірну розсудливість та навички роботи з людьми. Хоча вони все ще були достатньо технічно сильними, щоб “підніматися першими”, тобто бути першими на мотузці, були й інші лідерські якості, які відрізняли їх.

Пізніше, коли частина моєї роботи полягала в оцінці менеджерів з розробки програмного забезпечення, я помітив, що існує величезна схожість між хорошими менеджерами і тими провідними альпіністами, з якими я працював на вершинах. Можливо, міркував я, це тому, що ці два види діяльності мали багато спільного. Це наштовхнуло на думку про альпіністську експедицію як метафору для проєкту з розробки програмного забезпечення. Опрацьовуючи деталі цієї метафори, я все більше і більше приймав її, хоча, як і з усіма метафорами, потрібно бути обережним, щоб не завести її занадто далеко.

Про сходження на великі гори

Створення великої програмної системи дуже схоже на сходження на велику гору. Обидва види діяльності мають чітко визначену мету і вимагають скоординованих зусиль команди висококваліфікованих людей, які перебувають в обставинах, які вони можуть передбачити і спланувати, але не можуть контролювати. Успіх в обох випадках – це ймовірнісний розрахунок, оскільки ризик відіграє певну роль. Хоча я детально розгляну деякі з цих питань у наступних розділах, тут я розглядаю проєкт як цілеспрямовану командну діяльність і приділяю особливу увагу деяким ключовим елементам, які виникають знову і знову.

Розглянемо докладніше.

Розуміння обсягу як прелюдія до планування

Для обох видів діяльності гарне планування збільшує шанси на успіх. Першим кроком у правильному плануванні є
зрозуміти обсяг завдання. Для альпіністської експедиції це означає розуміння висоти гори, відносної складності місцевості, особливих погодних умов тощо. Важко уявити собі команду альпіністів, які на запитання про висоту гори, на яку вони збираються піднятися, відповідають: “Ми дізнаємося, коли піднімемося на вершину!” Аналогічно, я очікую, що команда розробників програмного забезпечення розуміє обсяг роботи, яку вони збираються виконати: наскільки велика ця гора? Скільки рядків коду, скільки спеціальних драйверів пристроїв, які вигадливі користувацькі інтерфейси, які характеристики продуктивності і т.д. будуть потрібні? У жодному разі команда або її лідери не можуть передбачити всі можливі “підводні камені”, але основні риси проблеми мають бути визначені та записані, щоб їх можна було врахувати в подальшому плануванні.

Другим кроком у плануванні є аналіз обсягу проєкту та основних перешкод на шляху до успіху, а також визначення чисельності та набору навичок команди, необхідних для досягнення поставленої мети. Мій досвід в обох сферах підказує мені, що найкраще працювати в якомога меншій команді. Всі учасники повинні мати мінімальний рівень навичок, щоб не тягнути команду вниз. Наприклад, якщо експедиція вимагає, щоб у складі команди був лікар, він повинен бути хорошим альпіністом, а не тягарем на шляху до вершини. В обох сферах учасники, які можуть грати кілька ролей, цінніші за спеціалістів; коли виникають труднощі, гнучкість є неймовірною перевагою в середовищі невеликої команди.

Вибір команди

Коли ви визначаєте потенційних членів команди, важливо оцінювати кандидатів за кількома параметрами. Зрозуміло, що ви будете наймати спеціалістів за потребою: якщо вам потрібно перетнути складний, порізаний тріщинами льодовик, вам знадобиться хороший льодолаз. Аналогічно, якщо ви створюєте продукт з вимогами до роботи в режимі реального часу, вам знадобиться експерт з часу виконання програми. Крім того, як згадувалося раніше, слід докласти значних зусиль, щоб вибрати компетентних альпіністів та інженерів; у професійному спорті це філософія відбору найкращих спортсменів, на відміну від відбору позиційних гравців. Нарешті, вам потрібно оцінити характер: крім оцінки навичок, вам потрібно оцінити, як кожна людина буде працювати в команді, і як кожна людина буде витримувати стрес і негаразди. Важливо, щоб майбутній член команди був хорошим альпіністом і партнером як у погану погоду, так і в гарну. Оскільки несприятливі погодні умови неминучі в той чи інший час на більшості сходжень, можна навіть стверджувати, що виступ за таких умов є найважливішим критерієм.

Один фактор, перш за все, допомагає оцінити ризик: досвід. Чим більше людей ви зможете додати до команди, які вже піднімалися на подібні гори, тим краще. Альпіністи, які піднялися на багато-багато гір, безсумнівно, мають кращу розсудливість, засновану виключно на дарвінівських міркуваннях! Це відомо як “Алгоритм вибору пілота на Алясці”: Обираючи з-поміж альтернатив, обирайте пілота, який найдовше працює в бізнесі. У досвідчених моряків є приказка: “Відмінні моряки використовують свою відмінну розсудливість, щоб не потрапляти в ситуації, які вимагають застосування їхніх відмінних навичок”. Те саме стосується альпіністів та менеджерів програмного забезпечення. Краще уникнути проблем завдяки кмітливості, ніж вирішувати їх героїчними зусиллями. Найпростішою ознакою наявності розсудливості – є досвід. Шукайте людей, які робили це раніше і досягли успіху. За інших рівних умов, візьміть тих людей, які пережили сходження на важку гору, а не тих, хто не піднімався на неї взагалі.

Чи можете ви уявити собі спробу піднятися на Еверест без шерпів?

Організація команди

Зібравши потенційний пул альпіністів/інженерів, керівник команди повинен подумати про те, як зібрати підкоманди. У скелелазінні це означає розподіл двох, трьох або чотирьох людей на кожну мотузку.

Зрозуміло, що ніхто не піднімається без мотузки на будь-яку важливу гору. На додаток до великої небезпеки, яку це може становити для будь-якого альпініста, який буде достатньо дурним, щоб спробувати, це також становить ризик для решти учасників групи. Їм доведеться вжити надзвичайних заходів, щоб врятувати свого колегу навіть від найменшої помилки. Аналогічно, у великих проєктах програмування поведінка вовка-одинака дуже ризикована. Щонайменше двоє на мотузці має бути правилом.

Для команд, в яких повинні співпрацювати три або більше інженерів, зверніть увагу на правильний мікс. Завжди потрібен сильний провідний альпініст, а поєднання навичок та індивідуальних особливостей має бути розподілене так, щоб одна мотузка не виявилася набагато слабшою за інші. Основним принципом є баланс: Жодна мотузка не повинна бути незбалансованою, і сукупність команд також повинна бути збалансованою. Якщо ви не можете створити задовільні підкоманди з пулу, вам потрібно проаналізувати, чому, і – або додати, або зменшити пул, поки не вдасться створити підкоманди.

Метою завжди має бути найменша кількість малих груп. Чотири команди по три-чотири гравці в кожній можуть досягти великих успіхів.

Пам’ятайте, що в програмній інженерії, як і в альпінізмі, тихо працює підступна логістична піраміда: чим більше людей ви намагаєтесь поставити на вершину, тим більше людей вам потрібно, щоб підтримати зусилля організаційно. Зростання має тенденцію до експоненціального зростання з висотою гори.

Складання розкладу

Іншим аспектом планування є складання розкладу. Після того, як ви накидаєте ескіз команди, можна починати з’ясовувати, скільки їжі і якого альпіністського спорядження вам знадобиться. Програмний еквівалент – це з’ясування того, скільки апаратного та програмного забезпечення для розробки вам знадобиться і в який час. Для того, щоб правильно розподілити ресурси, вам потрібно мати уявлення про те, як команда буде просуватися в гору. Пам’ятайте, що є три можливі шляхи помилок:

• Недостатньо ресурсів
• Забагато ресурсів
• Неправильний тип ресурсів, що перетворюється на марну вагу, яку потрібно нести

Якщо в сходженні беруть участь 10 осіб на чотири дні, це один набір ресурсів; якщо 15 осіб на два тижні, це зовсім інша справа.

Тепер найцікавіше те, що для того, щоб виконати цю роботу, вам потрібно знати:

• Яким маршрутом ви збираєтеся підніматись
• Де будуть проміжні зупинки
• Про те, коли ви плануєте дістатися до кожної проміжної точки із заданою кількістю людей

Це все, що вам потрібно для того, щоб скласти розклад і розрахувати, що вам потрібно для виконання роботи. Вам не потрібно знати кожну деталь про те, як ви збираєтеся дістатися до кожного пункту зупинки. Це добре, тому що будь-який план, який залежить від цієї інформації, дуже ризикований: більшість цих деталей не можна знати з упевненістю до того, як ви підніметеся на гору. Навіть якщо ви розплануєте їх до останньої краплинки, вони будуть змінюватися в міру того, як ви будете просуватись вперед. За винятком непередбачуваних обставин, які змушують змінити маршрут, загальні пункти зупинок, або віхи, не повинні суттєво змінюватися.

Етапи корисні для двох речей: щоб отримати загальне уявлення про те, як ви збираєтеся виконувати роботу і які ресурси вам знадобляться; і щоб відстежувати важливий прогрес. Якщо ви думали, що вам знадобиться два дні, щоб дістатися до першого базового табору, а вийшло шість, то вам краще сісти і подумати про решту шляху. Те, що моральний дух команди все ще чудовий, а базовий табір – найкраще спроєктований з усіх, які ви коли-небудь бачили, не має значення, враховуючи, що весь проєкт, швидше за все, займе (як мінімум) втричі більше часу, ніж заплановано.

Віхи чи кілочки?

Тому я виступаю за грубе, висхідне планування з консенсусом у команді щодо того, скільки часу знадобиться для досягнення важливих віх. І я вважаю, що потрібно дуже серйозно ставитися до часу, який потрібен для того, щоб туди потрапити. Для того, щоб це було корисно, віхи не можуть бути занадто близько одна до одної або занадто далеко одна від одної. Під час одноденного або дводенного сходження віхи, як правило, розташовані з інтервалом у кілька годин. Для сходження в Гімалаях, яке триває тижнями, я вважаю, що значущі віхі проходять з інтервалом у кілька днів. Для програмного проєкту тривалістю від 18 до 24 місяців, десь три-чотири місяці між проміжними віхами здаються правильними. Це означає приблизно шість важливих віх проєкту, плюс-мінус кілька. Якщо ви використовуєте ітеративний підхід до розробки, мається на увазі, що приблизно шість основних “контрольних точок” мають бути в порядку речей, навіть якщо ітерацій буде більше. Наприклад, дворічний проєкт може мати 10 ітерацій, але лише шість з них вимагатимуть найвищого рівня управлінського контролю після завершення.

Немає нічого поганого в тому, що кожна підкоманда може мати більш деталізовані завдання, якщо це допоможе. Кожен керівник команди повинен організувати свою мотузку, щоб переконатися, що його команда прибуває синхронно з іншими.

Моніторинг та облік

Більшість досвідчених лідерів команд, яких я знаю, постійно ведуть свої записи. У альпіністів на привалах зазвичай з’являється невеликий кишеньковий блокнот і олівець, в який занотовуються деякі нотатки. Коли я переглядаю ці нотатки після сходження, я бачу, що хоча я не записав багато інформації, вона завжди дуже доречна. Типові примітки стосуються часу прибуття, відхилень від запланованого часу прибуття та незвичних умов. Іноді з’являються неформальні нотатки про те, як працюють окремі учасники та команди. Коли ви плануєте сходження, подібні нотатки про схожі гори можуть виявитися корисними для коригування початкових оцінок. Для програмних проєктів подібні нотації можуть бути корисними для отримання уявлення про фактичну продуктивність проєкту.

Керування ризиками

Плани проєктів також повинні враховувати непередбачувані обставини. У скелелазінні двома змінними, які представляють форс-мажорні обставини, є несподіванки на обраному маршруті та погода.

Якщо обраний заздалегідь маршрут виявляється занадто ризикованим, необхідно обрати альтернативний. Зазвичай це відбувається через те, що лід або скеля не в тому стані, в якому вони були під час останнього дослідження цього маршруту. Хороший план використовує природні зупинки під час підйому, щоб оцінити можливості і вибрати один з альтернативних маршрутів. Аналогія з розробкою програмного забезпечення полягає в тому, щоб постійно оцінювати технічний напрямок, а потім, на основі результатів, досягнутих на кожній ітерації, дещо змінювати маршрут для наступної ітерації. Зверніть увагу, що мета, вершина гори, є константою. Однак мінливі умови можуть вплинути на наше судження щодо найкращого способу дістатися туди. Рідко буває так, що існує лише один шлях, і кращій альпініст вирізняється тим, що знаходить правильний шлях перед обличчям нових даних.

Погода – це зовсім інша річ. Коли погода різко погіршується, все ваше підприємство докорінно змінюється. Зараз це вже не питання потрапляння на вершину, а питання виживання. Навіть якщо учасники вирішять, що подальший негайний прогрес неможливий і що правильна стратегія – “залягти на дно”, поки шторм не вщухне, все одно всі можуть загинути, якщо їжа закінчиться до того, як погода вщухне. Оскільки ви абсолютно не можете контролювати погоду, ви повинні ставитися до неї з особливою обережністю; сила вашої команди може стати недоречною. Більше людей гине в горах через егоїзм, ніж через будь-яку іншу причину; нездатність вчасно повернути назад може бути фатальною.

Аналогія з програмуванням – це коли ви виявляєте, що залежите від речей, які не можете контролювати безпосередньо. Це стосується нових, неперевірених технологій, запланованих чудес, необхідних порушень відомих законів фізики, а також внутрішніх і зовнішніх постачальників і субпідрядників. Ігнорування змін погоди в цих районах може призвести до смерті – миттєвої або болісної і тривалої.

Рішучість

Я ніколи не зустрічав хорошого альпініста, який був би нерішучим. Я знав альпіністів, які плутали нерозсудливість з рішучістю. Є різниця. (Можу також додати, що я знав старих альпіністів, і я знав зухвалих альпіністів. Я не знав жодного старого, зухвалого альпініста).

Головне, чого я навчився в альпінізмі, – це те, що у вас немає часу на муки прийняття рішень. Це не означає, що ви можете дозволити собі стрілянину “від стегна”. Часто доводиться розглядати складні альтернативи, ситуації, в яких одна невірна гілка може означати різницю між успіхом і невдачею або, в крайньому випадку, між життям і смертю. Іноді вибір не є очевидним.

Однак чого ви не можете собі дозволити, так це стати паралізованим і продовжувати відкладати прийняття рішень – так званий синдром “паралічу від аналізу”. Ви повинні витратити деякий час, розглянути варіанти, зібрати дані, а потім прийняти рішення. Прийнявши рішення, ви йдете вперед і не сумніваєтесь у своїх діях.

Це може означати ходіння по по крихкому льоду з точки зору командної динаміки. Дуже важливо досягти консенсусу щодо важливих рішень. Однак досягнення консенсусу саме по собі може призвести до паралічу. У певний момент лідер повинен прийняти рішення, якщо ситуація зайшла в глухий кут. Якщо команда зібрана правильно, вона буде виконувати, розуміючи, що це “найкраще” рішення краще, ніж ніякого рішення взагалі.

Одного разу я сидів на скелі, намагаючись вирішити, яким із двох потворних шляхів піти. Мій напарник трохи потішив мене, а потім сказав: “Ну, ти можеш прийняти рішення або сидіти тут і замерзнути до смерті”. Те ж саме відбувається і в розробці програмного забезпечення.

Загальна мета та фокус

На хорошому сходженні всі домовляються про мету. Зазвичай, це означає потрапляння на вершину. Все, що не сприяє досягненню мети, безжально уникається: жодних побічних поїздок, ніхто не відходить за квітами, ніхто не зупиняється на півгодини, щоб сфотографуватися, і так далі. Команда може заздалегідь домовитися про те, що деякі з цих дій є частиною сходження і, таким чином, санкціоновані; однак, дуже важливо, щоб не було плутанини щодо головної мети і того, як її досягти.

Аналогом розробки програмного забезпечення є зосередження на меті, яка зазвичай полягає у створенні програмної системи. Цікаві програмні побічні подорожі можуть саботувати всі зусилля, особливо якщо одна з підкоманд потрапляє в розколину. До речі, не хвилюйтеся про бали за артистизм. Альпіністів не нагороджують ними. “Потворне” досягнення вершини завжди перевершує естетичний відступ. Це не особиста думка, це спосіб, яким більшість країн світу веде підрахунок балів.

Довгострокова перспектива

Говорячи про сходження на гору, часто роблять помилку, зосереджуючись на тому, щоб дістатися до вершини, ніби це є єдиною метою. Дістатися до вершини, а потім спустити всю команду з гори цілою і неушкодженою – ось справжнє завдання. (Аналогічно, метою космічної програми в шістдесятих роках було не висадити людину на Місяць, а висадити людину на Місяць і повернути її назад живою).

Програмною аналогією цієї помилки, але з невеличким перебільшенням, є зосередження всіх зусиль на розробці, необхідній для відправки початкової версії продукту. Це дозволяє так би мовити “встановити прапор”. (Іноді ми оголошуємо про перемогу ще раніше, наприклад, після відправлення першої бета-версії). Я стверджую, що моральним еквівалентом сходження на гору і безпечного спуску з неї є доставка програмного продукту, який ви можете підтримувати і супроводжувати. Це означає створення продукту, програмне забезпечення якого надійне, документація повна і зрозуміла, а тягар підтримки не вбиває решту організації. Тому, коли команда планує програмний проєкт, вона повинна планувати виконати всю роботу, а не просто встановити прапор на вершині.

Конкуренція може спричинити ірраціональну поведінку

Наші два сини, Девід і Марк, були ще зовсім маленькими, коли ми приїхали до Швейцарії. Пізніше їм довелося розділити мій ентузіазм щодо альпінізму. Дейв вказав мені на те, що “чистота” альпінізму частково випливає з романтичного уявлення про ізольовану команду, яка бореться зі стихією заради досягнення благородної мети. Він також зауважив, що в реальному світі цей ідеал часто порушується конкуренцією між командами. На одну вершину можуть претендувати дві або більше груп, кожна з яких прагне першою “встановити прапор на вершині”. (Деякі сфери наукових досліджень страждають від подібного розриву між романтичним ідеалом і реальним світом). У розробці програмного забезпечення, звичайно, конкурентний тиск ще більш інтенсивний, оскільки продукт, що розробляється, є конкурентною зброєю, яку решта організації хоче мати у своєму арсеналі негайно. Наслідки такого тиску можуть бути катастрофічними; часто зміни планів на маршруті у відповідь на змагання змушують команду йти на надмірні ризики, що призводять до невдачі або ще гіршого.

Найпоширеніші причини провалів

Вказавши на схожість між альпіністською експедицією та проєктом з розробки програмного забезпечення, я стверджую, що програмні проєкти зазнають невдачі з тих самих причин, що й альпіністські експедиції. Багато з цих питань знову і знову з’являтимуться в наступних розділах. Давайте візьмемо альпіністські “режими відмов” і знайдемо їхні аналоги в розробці програмного забезпечення:

• Намагання дістатися до вершини занадто швидко.
  Аналог: Нереальний розклад від самого початку.
• Намагання потрапити на вершину з явно недостатніми ресурсами.
  Аналог: Не вистачає хороших людей або інструментів.
• Сходження із занадто великою командою; логістичний та комунікаційний тягар перевантажує команду.
  Аналог: Занадто багато посередніх розробників по відношенню до першокласних розробників.
• Затягування експедиції: команди, які занадто довго перебувають на горі, втрачають бадьорість, енергію, і втома бере своє. Крім того, у них можуть просто закінчитися ресурси.
  Аналог: Програмні проєкти, які тягнуться вічно, настільки довго, що вимоги до них змінюються, іноді кілька разів.
• Дотримуватися неправильного маршруту незважаючи на нову інформацію.
  Аналог: Ігнорування даних ранніх ітерацій; нездатність скоригувати план під час виконання проєкту.
• Бути знищеним через обставини, які не залежать від альпіністів.
  Аналог: Відмова постачальника або субпідрядника; відмова ключового компонента, який насправді був науково-дослідницькою діяльністю, а не готовим продуктом.
• Відсутність розумного плану, який всі розуміють, вірять в його успіх і повністю віддані йому.
  Коментар: Зазвичай це результат плану, що спускається зверху вниз, ієрархічно санкціонованого.
• Неможливість, в межах допусків, виконання за планом.
  Коментар: Іноді це є наслідком накопичення багатьох дрібних промахів, а не однієї ефектної невдачі.
• Втрата бадьорості духу, коли стає важко; нерозуміння того, що негаразди – це частина роботи.
  Коментар: В офісі так само погано, як і в горах.
• Відсутність резерву на випадок надзвичайних ситуацій.
  Коментар: Зазвичай досвід досвідчених гравців може забезпечити частину цього резерву; вони знають, що робити, коли трапляється несподіванка.

Інгредієнти успіху

Аналогічно, я повинен бути в змозі вивести ознаки успішних команд, дивлячись на інші аспекти метафори. Ось кілька з них:

• Успішні команди добре планують, але вони не зациклені на цьому.
  Коментар: Невелика кількість хорошого планування завжди перемагає велику кількість деталей.
• Здатність швидко пересуватися невеликими групами; виходити на гору і сходити з неї до того, як матінка-природа передумає і вирішить не дозволити вам піднятися на гору в цей день.
  Аналог: Зробіть все до того, як вимоги занадто сильно зміняться.
• Талант оцінювати вхідні дані в режимі реального часу та вчасно вносити відповідні зміни до плану.
  Аналог: Використовуйте ітеративну розробку, інтегруйте та тестуйте на ранніх стадіях і часто, а також використовуйте отриману інформацію для коригування плану.
• Гарний баланс між окремими першокласними учасниками та хорошими командними гравцями і лідерами; ключовим фактором тут зазвичай є дуже широка пропускна здатність комунікацій.
  Коментар: Потрібно мати баланс і спільне мислення.
• Відстеження виконання плану з відповідною деталізацією.
  Коментар: Потрібно відчувати, коли у вас виникають проблеми, і що з ними робити.
• Лідери демонструють зрілість і розсудливість.
  Коментар: Важливо знати, коли посилювати, а коли послаблювати.
• Витривалість: розумійте, що загальна тривала продуктивність набагато важливіша за продуктивність в режимі пікового навантаження. Не дивно, що більшість лідерів альпінізму приходять до своєї вершини в сорок років, не раніше.
  Аналог: Цікаво було б побачити статистику лідерів з програмного забезпечення.
• Міцність: Здатність витримати, коли справи йдуть погано.
  Аналог: Важливо, наприклад, для відстеження дуже складних помилок.
• Зосередженість: Команда зосереджена на чітко визначеній меті.
  Коментар: Всі учасники знають, що, чому, коли і як.
• Креативність: Готовність експериментувати та відчувати справжню радість від того, що вони роблять.
  Коментар: Як і все життя.

Людський фактор

Ну, в деякому сенсі це зводиться до того, що люди – це все. Для програмних проєктів, як і для майже всього іншого, що варто робити, я б хотів перефразувати письменника Ірвінга Стоуна: “Дайте мені чоловіків (і жінок), які б відповідали моїм горам”. Людський фактор настільки важливий, що я присвячую йому цілий розділ пізніше.

Підсумок

Багато менеджерів програмного забезпечення, з якими я говорив про цю метафору сходження на гору, зазначали, що я упустив важливий момент: масштабування. Це не каламбур; вони мають на увазі, що загальні принципи залишаються незмінними незалежно від розміру гори чи масштабу проєкту. Звичайно, все змінюється в деталях: сходження на вихідних на 4000-метрову вершину командою з 10 осіб відрізняється від штурму Евересту. З іншого боку, порушення загальних принципів призведе до провалу будь-якої експедиції. Хоча дуже великі програмні проєкти потребують дещо іншої організації, виникає питання, чи не були б вони більш успішними, якби їх моделювали за принципом малих команд, тільки з більшою кількістю команд. Цікавим питанням в обох випадках є компроміс між збільшенням накладних витрат на зв’язок з більшою кількістю команд та внутрішніми режимами збоїв, які, здається, виникають, коли команди стають занадто великими. У будь-якому випадку, ця метафора з альпінізмом стимулювала багато дійсно цікавих дискусій про справжню природу проєкту з розробки програмного забезпечення.

Я все ще є членом Швейцарського альпійського клубу, але більшість моїх альпіністських подвигів сьогодні пов’язані з витягуванням себе з особливо глибоких піщаних пасток на різних полях для гольфу по всьому світу.

Наступний розділ присвячений деяким іншим ідеям щодо загального менеджменту, які я накопичив протягом багатьох років.