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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть]. И дело не в том, что команда написала плохой код, а в том, что она считала его всего лишь инструментом обучения. Это было частью постоянных усилий команды по поиску правильного решения.

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

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

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

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

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

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

УПРАВЛЕНИЕ ДИСТАНЦИОННЫМ СОТРУДНИЧЕСТВОМ

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

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

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

УПРАВЛЕНИЕ АУТСОРСИНГОВЫМИ И ОФШОРНЫМИ КОМАНДАМИ

Начиная с конца 1980-х годов мы наблюдаем рост использования аутсорсинговых и оффшорных ИТ-услуг. Аутсорсинговые компании выступают с, казалось бы, привлекательным предложением: используя их недорогие услуги в области ИТ и разработке программного обеспечения, компании получают возможность избежать необходимости самостоятельного управления этими нестратегическими бизнес-функциями, передав их высококлассным экспертам и сосредоточившись на своих основных компетенциях.

Как мы надеемся, мы уже совершенно ясно дали понять, что ИТ и разработка программного обеспечения теперь должны рассматриваться в качестве основной бизнес-функции, а также стать основной компетенцией для каждой фирмы любого размера. В проектах и программах, в которых неопределенность играет существенную роль, компании все больше уходят от ИТ-аутсорсинга. С недавних пор мы заметили нарастающую тенденцию развития ИТ-услуг внутри организации[71]71
  Eric Savitz, “The Death of Outsourcing, and Other IT Management Trends,” Forbes.com, December 28, 2012, http://www.forbes.com/sites/ciocentral/2012/12/28/ the– death– ofoutsourcing-and-other-it-management-trends/#12657a6775c7; and Stephanie Overby, “Goodbye Outsourcing, Hello Insourcing: A Trend Rises,” CIO.com,February 17, 2011, http://www.cio.com/article/2411036/outsourcing/ goodbyeoutsourcing – hello-insourcing – a-trend-rises.html.


[Закрыть].

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

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

Конечно, существуют технологические проекты, для которых подходит аутсорсинг. Проекты с низким уровнем неопределенности (что строить и что будет работать) отлично подойдут для аутсорсинговых и офшорных команд. Один из методов такого типа работы – использование двухкомпонентного agile-подхода.

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

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

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

РЕТРОСПЕКТИВНЫЕ ОЦЕНКИ

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

Другими словами, члены команды рассматривают свой рабочий процесс, как и свои усилия по производству продукта, в качестве объекта для непрерывного улучшения. Мы часто советуем командам начинать с минимально жизнеспособного процесса и использовать ретрооценки и непрерывную обратную связь (как внутри, так и за пределами команды), а также экспериментировать с процессами для улучшения совместной работы и рабочего процесса в целом.

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

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

КЛЮЧЕВЫЕ МОМЕНТЫ ПОДХОДА «ПОЧУВСТВОВАТЬ И ОТРЕАГИРОВАТЬ» ДЛЯ МЕНЕДЖЕРОВ

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

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

✓ Чтобы организовать сотрудничество, рассмотрите возможность использования целевых автономных команд, многофункциональных команд, а также профильных команд.

✓ Поддержите новые рабочие потоки и разместите команды в одном помещении. Если вы привлекаете удаленных или внешних сотрудников, будьте осторожны, оценивайте их влияние на agile-процесс.

✓ Адаптация минимального жизнеспособного процесса и проведение регулярных ретроспективных обсуждений будут способствовать более эффективному сотрудничеству членов команды.

Глава 7
Непрерывное все

AutoTrader UK является крупнейшим рекламным сайтом с объявлениями о продаже автотранспортных средств в Великобритании. Компания, основанная в 1977 году как печатное издание, запустила свой первый веб-сайт в 1996 году. А с июня 2013 года она полностью перешла на цифровой формат, закрыв свой печатный бизнес. Как сообщает компания, теперь AutoTrader UK контролирует более 80 % доли рынка[72]72
  Nathan Coe, interview, 2015.


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

Менеджеры могли бы легко разочароваться от негативных отзывов или списать их со счетов, потому что они противоречили их установкам. Вместо этого они воспринимали такие отклики как возможность чему-нибудь научиться: «Каждый раз, когда мы запускаем новое обновление, мы видим, где мы были правы, а где нет. И чем чаще мы будем применять новые идеи, тем быстрее мы сможем обучаться и вносить корректировки». Они начали задаваться вопросом: «Почему же мы учимся только четыре раза в год? Почему бы не делать это четыре раза в неделю?»

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

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

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

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