Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

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

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

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

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

При таком режиме обучения студенты приходят в аудиторию, надо думать, подготовившись к теме, а преподаватель вызывает их и устраивает быструю дискуссию. Сократический метод нацелен на выработку умения критически мыслить и с ходу приводить аргументы. Мои сокурсники называли это «прокачкой перед группой». Напряжение было очень высоким, но этот процесс помогал нам научиться задавать сложные вопросы и отвечать на них перед всей группой. Почему сократический метод не теряет актуальности вот уже 2500 лет? В фильме «В погоне за корочкой» великий актер Джон Хаусман в роли профессора Гарвардской школы права Чарльза Кингсфилда объясняет: «Мы используем здесь сократический метод. Я вызываю вас, задаю вопрос, и вы отвечаете на него. Почему я просто не читаю вам лекцию? Потому что мои вопросы приучают вас учиться самостоятельно».

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

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

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

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

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

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

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

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