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

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

Открытый анализ проектов

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

Расписание таких встреч публикуется в общедоступном календаре, на который может подписаться любой желающий. За два дня до встречи участники должны опубликовать документ о том, что именно они будут представлять. Каждый участник обязан ознакомиться с документом до начала заседания.

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

Цель подобной концепции состоит в устранении одного из недостатков «правила двух пицц». Дело в том, что при большом числе маленьких команд (у нас только над продуктами трудятся 150 команд) они начинают работать в тысяче разных направлений, и отдельной команде трудно понять, чем занимаются остальные. Однако в некоторых проектах над одним кодом работает целый ряд небольших команд. Каждая команда в такой группе зависит от других команд, поэтому все они должны следить друг за другом. Открытый анализ проектов позволяет командам быстро взаимодействовать друг с другом и оставаться в курсе происходящего.

Дополнительным достоинством этой концепции является то, что открытый анализ проектов становится своего рода учебной площадкой. Сотрудники со статусом «чтение/запись» учатся, потому что их работу проверяет лично Чи, который бывает довольно въедливым. Он так много знает о программном обеспечении, что становится страшновато, особенно тем командам, которые не достигают целевых показателей, или сотрудникам, которые плохо подготовились. Эти совещания могут быть не очень приятными, однако именно это и позволяет учиться. Цель конструктивной критики не устроить разнос, а помочь сотрудникам стать лучше. В действительности это форма внимания и обучения.

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

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

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

Сократический метод

Наш формат и стратегия открытого анализа проектов взяты из практики, которую уже давно используют в Amazon и называют «Еженедельный бизнес-обзор». Энди Джесси, возглавляющий AWS, проводил подобные обзоры уже в первые дни существования этой облачной платформы, и, на мой взгляд, именно ими объясняется большая часть нынешнего успеха компании.

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

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

Конечно, есть и прямо противоположные сценарии – моменты, когда руководитель не знает или не может объяснить, почему показатели удручающие. Это плохо. Каждый должен знать свое дело. Или, может быть, он знает, что именно идет не так, но у него нет действенного плана исправления ситуации. Это тоже плохо.

Энди не жалеет времени на то, чтобы вникнуть в ситуацию, помочь руководителям направлений – иногда, если честно, принудительно – понять, как лучше управлять бизнесом. Эти совещания – почти легендарное явление в AWS, потому что чем лучше вы подготовлены, тем лучше команды справляются с делами, а еще и потому, что это мастер-класс по искусству быть собственником. Именно такая открытая обучающая среда способствует инновациям и успеху.