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

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

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

Если вдуматься, масса иерархических компаний (т. е. большинство из них) строятся на предположении, что стоящие наверху знают все ответы (хотя нам известно, что это не так) и поэтому принимают решения. Это не открытый процесс, и он вселяет страх. Люди боятся принимать решения, поскольку могут сделать что-то не так, и стагнируют как специалисты. Или руководители боятся предоставить другим возможность принимать решения, поскольку те могут ошибаться. В конце концов, судьба руководителей зависит от результатов работы, и они не хотят доверять ее другим. Это справедливо, но в результате никто не делится проблемами, а вместо этого делегирует задачи. Но, на мой взгляд, методология «Спросите своего разработчика» – это лучший способ получить то, что вам нужно, т. е. результаты, а не командование и контроль.

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

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

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

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

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

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

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

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