Текст книги "Как создать настоящую команду"

Алгоритм
«Какие привычки нужны нам как команде?»

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

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

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

Самооценка: какие привычки помогают командам?

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

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

1. Составьте список индивидуальных привычек

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

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

● Ответ на электронные письма в течение 24 часов, хотя бы с тем, чтобы сказать, когда ожидать исчерпывающего ответа.

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

2. Проинформируйте команду о своих привычках

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

3. Решите, какие привычки вы хотите закрепить

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

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

Процедура «Проверка общекомандных привычек»

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

Подготовка команды к следующим этапам

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

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

Какую проблему мы пытаемся решить?

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

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

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

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

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

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

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

Теперь давайте рассмотрим вторую цель проекта. Биллинговую систему компании необходимо как можно скорее обновить, поскольку база данных, на которую она опирается, постоянно дает сбои и выставляемые клиентам счета полны ошибок. Поможет ли данный проект решить эту проблему? Сможет ли новая биллинговая система полностью устранить ее? Или через год вам придется собираться снова, чтобы исправить ситуацию?

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

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

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

Алгоритм
«Какую проблему мы пытаемся решить?»

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

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

Шаблоны для постановки проблем достаточно часто используются в бизнес-сообществе. Ниже представлена наша версия, отчасти опирающаяся на книгу Майкла Шраге «Гипотеза новатора» (The Innovator’s Hypothesis):

Рассмотрим каждый из этих элементов более подробно.

Кого мы обслуживаем?

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

● Конкретная проблема. Проблема, которую определенная группа людей пытается решить.

● Данная ситуация. Определяется местом и временем возникновения конкретной проблемы.

● Желаемый результат. То, чего хочет группа людей и чего она пока не получает. Именно на этом должна сосредоточиться команда. Она должна точно определить, как именно будет достигаться этот результат.

Кто выигрывает?

● Наша команда. Люди, которые работают над проектом.

● Результат проекта. То, что позволяет команде считать проект успешным (с точки зрения результативности).

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

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

Вот пример полной постановки задачи.

1. Выясните мнения членов команды о том, кого вы обслуживаете

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

2. Поделитесь своими соображениями

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

3. Решите, что необходимо включить в постановку проблемы

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

4. Повторите этот процесс для второй половины постановки проблемы

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

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

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

Процедура «Пересмотр постановки проблемы»

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

Процедура «Использование постановки проблем при тестировании решений»

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

Алгоритм
«Что мы знаем? Что нам нужно узнать?»

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

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

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

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

Это упражнение взято из описания процесса, представленного в докладе «Презентация презентации» (Presentation Presentation) Майка Круженицки на интерактивной дизайн-конференции HOW в Сан-Франциско, Калифорния, в 2014 г.

1. Опишите то, что вы уже знаете, и то, что вам нужно узнать

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

Что мы знаем о проблеме?

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

Что нам нужно узнать о проблеме?

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

2. Поделитесь своими взглядами

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

3. Идентификация предположений

Начните с левой колонки. По каждому пункту спрашивайте команду: «Как убедиться в том, что это правда?» Если команда признает, что данный элемент в списке достоверен, то на него можно опираться в ходе реализации проекта. Если команда не уверена в достоверности, переместите элемент в правую колонку.

4. Формулирование вопросов, на которые команда должна ответить

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

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

Процедура «Уточнение предположений по окончании каждого этапа проекта»

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

Вперед, к успеху! Стоп, а это что такое?

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

Что можно считать успехом?

Как определить, достигнута цель или нет? Слово «успех» достаточно емкое, и разные люди в вашей организации могут понимать его по-разному.

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

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

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

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