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

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

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

Чаще всего начинают обвинять разработчика в том, что он допустил ошибку. Это совершенно инстинктивное побуждение, но оно в реальности ничего не дает. Когда работники, даже лучшие инженеры, совершают ошибки, они, поверьте мне, и без того чувствуют себя ужасно. Обвинения лишь подчеркивают, что они – люди, и отбивают охоту к созданию программ, как минимум для вашей компании. Допущенная ими ошибка – очевидная причина падения сайта, но истоки сбоя заключаются не в ней. Подлинная проблема лежит глубже – а именно в организации работы. Поэтому вместо предъявления обвинений нужно задавать вопрос: почему, когда всем известно, что люди неизбежно совершают ошибки, «система» допустила нанесение вреда клиентам? Ответ на этот вопрос приведет вас к первопричине или – что более вероятно – к множеству первопричин.

Чтобы добраться до истины, нужно постоянно спрашивать «почему?». Обычно мы начинаем с простого: «Почему произошел сбой клиентского сервиса?» Ответ очевиден: «Инженер включил в рабочую программу ошибочный код». Теперь поинтересуйтесь: «Почему ошибочный код в рабочей программе привел к падению сайта?» Возможно потому, что ПО не обладало достаточной степенью защиты – действительно надежное ПО могло обнаружить проблему и продолжить работать, пусть и усеченным образом. А может быть, потому, что даже надежное ПО не могло выжить, и тогда возникает вопрос: «Почему ошибочный код попал в рабочую программу?» Ответ может быть следующим: «Потому что код недостаточно тестировался». Было бы легко остановиться здесь и поднять на мачте вымпел «Задача выполнена», но дело еще не доведено до конца. Почему? Да потому, что это всего лишь хорошо замаскированная версия обвинения разработчика. Если бы он или, возможно, инженер по обеспечению качества написал более полные тесты, то проблемы можно было бы избежать. Итак, вы продолжаете: «Почему код пошел в рабочую программу, если было известно об отсутствии эффективного тестирования критического фрагмента кода?»

Ну вот, теперь кое-что понятно. Первопричина редко носит технический характер – она организационная. Как наша организация допустила, чтобы этот человек смог навредить клиенту и бизнесу? Представьте себе атомную электростанцию с большой кнопкой «Расплавление активной зоны реактора», расположенной прямо посередине панели управления. Техник случайно ставит чашку чая на эту кнопку, ну а дальше понятно, что происходит. Вы обвините техника? Скорее всего, вы спросите, почему эта кнопка вообще существовала! Вот и здесь то же самое. Почему «система» позволила встроить в рабочую программу плохо протестированный код? Возможно, это произошло потому, что ваша инфраструктура тестирования настолько несовершенна, что должное тестирование очень трудоемко и инженеры регулярно обходят его в интересах прогресса. Если это так, то создание хорошей инфраструктуры облегчит корректировку ПО и позволит инженерам удовлетворять запросы клиентов, причем с помощью хорошо протестированного кода. Или, может быть, организация не вкладывала деньги в повышение квалификации инженеров? В конце концов, вы доберетесь до истинной системной первопричины и сможете решить эту проблему.

Это важно, поскольку обращение к поверхностной причине позволяет устранить лишь ее. Возможно, с помощью какой-нибудь драконовской меры и удастся удержать конкретного разработчика от повторения ошибки. Однако другие инженеры ничему не научатся. Это сродни удалению одной из сотен кнопок «Расплавление активной зоны реактора» на панели управления. У вас, скорее всего, произойдет еще одна авария. Обращение к первопричине позволяет устранить предпосылки не только прошлого, но и следующего сбоя. Повторяя этот процесс, вы системно укрепляете свою организацию.

Я привел технический пример, потому что практика безупречного вскрытия чаще встречается в технологических организациях. Однако я видел, как этот метод применяется в разных частях нашей компании, и везде он работает одинаково.

В 2010 г. стартап в составе 10 человек под названием Uber (в то время – UberCab) стал клиентом Twilio. На протяжении нескольких лет он демонстрировал стремительный рост, и к тому времени, когда мы стали публичной компанией в 2016 г., приносил более 10 % нашей выручки и играл значительную роль в рекламной кампании нашего IPO. В 2016 г. Uber продолжал расти стремительными темпами и довел свои годовые расходы почти до $60 млн, что было неразумно, особенно с учетом смещения фокуса с «роста любой ценой» на снижение затрат. С точки зрения экономии мы были очевидной мишенью. В начале 2017 г. Uber заявил, что начнет сокращать свои расходы с нас. Во время телеконференции, посвященной финансовым результатам за первый квартал 2017 г., мы сообщили инвесторам, что крупнейший клиент, который стоял на первом месте в нашем проспекте эмиссии акций, решил сократить расходы на наши услуги. Это было плохо. Стоимость наших акций упала более чем на 30 % за один день. Наши сотрудники были ошеломлены. Оглядываясь назад, понимаешь, что это была кратковременная неприятность, поскольку у компании были и другие клиенты. В первом квартале 2020 г. наша выручка оказалась больше на 400 % с лишним при снижении концентрации крупных клиентов с 30 % в 2016 г. до 14 % в 2019 г. Это был явный промах для нашей новой, публичной компании, причем промах, который мы не хотели повторять.

Я попросил нашего тогдашнего финансового директора Ли Киркпатрика провести «безупречное вскрытие». Финансовая команда раньше не сталкивалась с такой задачей, поэтому мы обратились к Джейсону Худаку, нашему руководителю технической инфраструктуры (с которым вы познакомитесь в главе 11) с просьбой возглавить этот кросс-функциональный процесс. Мы начали не с вопроса «Почему у нас случился сбой в отношениях с клиентом?» – на этот раз вопрос звучал так: «Почему у нас произошла такая неприятность в отношениях с инвесторами?» Было бы легко обвинить торгового представителя, отвечающего за взаимодействие с Uber, но, как вы можете видеть, это не было первопричиной. «Наш крупнейший клиент решил сократить затраты, и мы раскрыли этот факт инвесторам». «Почему?» В конце концов все свелось к следующему. Прежде всего у нас было небольшое число клиентов, которые из-за нашей модели ценообразования, основанной на фактическом использовании продукта, стали слишком крупными и, следовательно, представляли для нас риск. Нам нужно лучше управлять «концентрацией клиентов», даже если это означает активное снижение цен. Другая первопричина заключалась в том, что у нас не было достаточного количества торговых представителей для взаимодействия со всеми клиентами. В то время у нас было всего около 15 торговых представителей с квотами по 36 000 существующих и потенциальных клиентов. Понятно, что наших торговых представителей не хватало на всех, в том числе и на крупнейшего клиента, тратившего более $60 млн в год. Итак, вторая первопричина нашей неудачи заключалась в недостаточном внимании к клиентам с нашей стороны. С той поры число наших торговых представителей выросло с 15 человек до многих сотен, а наша выручка увеличилась с $277 млн в 2016 г. до более чем $1,1 млрд в 2019 г., вклад крупнейших 10 клиентов при этом снизился вдвое.