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

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

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

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

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

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

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

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

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

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

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

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

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

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