Приводим список ключевых изменений, позволяющих эффективно сотрудничать командам, использующим подход «почувствовать и отреагировать»:

• Создание автономных команд под конкретные задачи;

• Использование многофункциональных команд;

• Создание специализированных групп;

• Поддержка новых рабочих направлений;

• Совместное размещение команды;

• Осторожность при дистанционной работе;

• Осторожность с аутсорсингом;

• Изучение опыта и использование минимально жизнеспособных процессов.

Считайте этот список отправной точной, а не инструкцией. Каждой организации, которая реализует эти идеи, придется подходить к ним творчески. Считайте эти идеи, скорее, принципами, чем жесткими правилами.

СОЗДАНИЕ АВТОНОМНЫХ КОМАНД С ЗАДАЧАМИ, ОСНОВАННЫМИ НА ЦЕЛИ

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

Используя эти возможности, они смогут предпринимать оперативные действия и вычислять оптимальный путь для продвижения вперед.

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

Таким образом, когда вы сталкиваетесь с неопределенностью, автономные команды, которые способны обучаться, – это именно те, кто создаст ценность для вашей организации.

СОЗДАНИЕ МНОГОФУНКЦИОНАЛЬНЫХ КОМАНД

Ранее в этой главе мы описывали возможности автономных команд: мониторинг и наблюдение за клиентами, проведение экспериментов, осмысление и интерпретация информации, принятие решений о том, как реагировать, и, собственно, ответ. Эти возможности формируют основу многофункциональных команд, к созданию которых мы стремимся. На практике это означает, что мы должны создавать команды из многофункциональных групп, убедившись, что основные функции команды (разработка, проектирование и управление продуктом) у них слажены.

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

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

СОЗДАНИЕ ПРОФИЛЬНЫХ КОМАНД

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

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

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

Гораздо эффективнее, если сотрудник работает в одной команде и над одной задачей.

ИЗМЕНЕНИЕ РАБОЧИХ ПОТОКОВ

Наверное, самое важное, что вам нужно сделать с точки зрения эффективности совместной деятельности, – это помочь команде переосмыслить свою работу. Такой вид сотрудничества обычно требует от членов команды изменить манеру, в которой они выполняют свою индивидуальную работу. Менеджеры по продукту могут иметь привычку создавать подробные планы и экономические модели: им нужно научиться ставить вопросы и экспериментировать. Дизайнеры обычно хорошо справляются с работой в Photoshop: скорее всего, во время обсуждений рабочего процесса им будет комфортно воспринимать информацию на электронной доске. Разработчики могут иметь привычку работать с подробными документами: они должны свыкнуться с отображением результатов в виде эскизов. И каждый должен смириться с тем, что внесение изменений и переработка уже сделанного являются ценными этапами процесса, а не затратами, которых следует избегать.

По мнению Билла Скотта из PayPal одна из причин успешности его команды у бывшего нанимателя, компании Netflix, состояла в том, что команда разделяла идею непрерывного улучшения: «Я понял, что, особенно в работе над пользовательским интерфейсом, мы отбросили 90 % кода, написанного в том году»[70]. И дело не в том, что команда написала плохой код, а в том, что она считала его всего лишь инструментом обучения. Это было частью постоянных усилий команды по поиску правильного решения.

СОВМЕСТНОЕ РАЗМЕЩЕНИЕ КОМАНД

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

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

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