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

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

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

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

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

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

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

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

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

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

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