Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [60]

Это как раз то, чего мы хотим видеть в своих компаниях. Мы хотим научить сотрудников тому, как учиться самостоятельно. В этом и заключается суть обучающей среды. Мы вырабатываем образ мышления, умение анализировать и решать проблемы. Сократический метод так же эффективен при решении деловых проблем, как и при рассмотрении сложных юридических вопросов.

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

Безупречное вскрытие

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

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

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

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

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

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