Я люблю структурированность. Это можно заметить по тому, как организованы папки на моем компьютере, мой блог, мои финансовые документы и бумажные архивы. У всего есть свое место и предназначение. У меня даже есть аккуратная белая коробка, подписанная «Всякая хрень – Юрген», позволяющая отделить мои вещи от «всякой хрени Рауля». Точно так же мне хочется знать все о структуре организации, в которой я работаю, – для чего предназначен тот или иной отдел или подразделение. Включая всякую хрень.

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

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

 

О внешней среде, продуктах, размерах организаций и людях

Меня часто спрашивают: «Как мне структурировать мой бизнес и мои команды»? (Вообще-то меня никто не спрашивает, но, может быть, такие вопросы появились после прочтения предыдущей главы.) К сожалению, простого ответа на них не существует. По крайней мере правильного простого ответа. С таким же успехом можно спросить: «Как выглядит оптимальная форма для биологического вида?» Сама постановка вопроса бессмысленна. Нельзя утверждать, что форма морских звезд имеет преимущества перед формой паука. Оба вида существуют и нашли себе нишу, обеспечивающую их выживание. Паук не может жить в море. А морская звезда не выживет у меня в подвале. То же самое относится к организациям. «Оптимальная» структура зависит от внешней среды, в которой компании необходимо выживать.

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

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

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

Из этого интересного наблюдения Конвея легко сделать вывод, что организации должны быть адаптированы к тем типам продуктов, производством которых они занимаются [Poppendieck 2009: 67]. Следовательно, вторым драйвером организационной структуры будут разрабатываемые данной компанией продукты.

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

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

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

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

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

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

При чтении книг, посвященных организационным структурам, я заметил, что многие из них включают описание «стандартной» иерархической функциональной организации, а затем переходят к обсуждению «альтернативных» структур, которые, по мнению авторов, более эффективны [Augustine 2005]. В других книгах порой приводятся различные организационные архетипы или «формы», возникающие под воздействием внешней среды [Mintzberg 2009: 106]. Я попытаюсь применить другой подход и приведу несколько рекомендаций для адаптивных организаций, которые вы сможете использовать для выращивания собственных организационных структур.

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

 

Сначала подумайте о специализации…

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

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

Я бы сказал главному редактору, что он рехнулся. Если я лежу на операционном столе и мне делают подтяжку глаз, буду ли я просить операционную сестру заняться мной, потому что хирург опаздывает? Скажу ли я ей «А заодно удалите мне гланды»?

В принципе, генерализация – прекрасная идея. Но специализация – это ваш первый друг. Исследования подтверждают, что команды специалистов эффективнее, чем команды, составленные из генералистов [Anderson 2004: 271]. Если мы включаем в команду только последних, то игнорируем все, чему человечество научилось за последние 235 лет – с того самого момента, когда Адам Смит показал, что специализация ведет к повышению производительности и процветанию. Специализация объясняет, почему разработчики софта сами не пекут себе хлеб, не шьют одежду и не выращивают еду (конечно, бывают исключения, но их не так много). Чем крупнее экономика или организация, тем больше людей хочет (и может) специализироваться в той области, к которой у них больше всего способностей. Этот механизм доказал свою эффективность, причем не только в случае отдельных индивидуумов, но и в масштабах всего мира.

 

… И только потом о генерализации

С другой стороны…

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

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

Специалист со склонностью к генерализации 1) имеет одну или две технические специализации… 2) обладает как минимум общими знаниями в области разработки ПО; 3) обладает как минимум общими знаниями индустрии, в которой данное ПО применяется; 4) стремится активно расширять свои знания как в области своей специализации, так и в других областях, включая технические и предметные [78] .

Специалист со склонностью к генерализации выполняет один вид работы очень хорошо и еще несколько с приемлемым качеством. Если у вас в команде есть такие люди, повышается ее эффективность и снижается риск возникновения узких мест. Специалистов со склонностью к генерализации иногда называют Т-специалистами. Их основная специализация выглядит как вертикальная палочка, но они также любознательны и готовы развиваться в других направлениях. Такие люди являются ценным приобретением, поскольку они видят проблему с нескольких точек зрения [Brown 2005].

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

А генералисты со склонностью к специализации? Они вообще существуют?

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

 

Расширьте названия должностей

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

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

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

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

Расширенные названия должностей могут использоваться для обозначения нескольких ролей. Позиция «разработчик программного обеспечения» может включать широкий диапазон функций, начиная с дизайна, разработки и тестирования и заканчивая проектным менеджментом и техподдержкой [Abran 2004]. Поэтому «разработчик» в вашей организации может выполнять, например, роль программиста, тестировщика, специалиста по техподдержке и бизнес-аналитика. При этом сотрудникам, определение должностей которых далеко выходит за рамки позиции «разработчик» (например, менеджерам по работе с клиентами или системным администраторам), данные роли никогда поручаться не будут.

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

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

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

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

 

Культивируйте неформальное лидерство

Лидеров, которые появляются внутри команд, иногда называют лидами или ведущими специалистами. Например, они могут называться техлидами, ведущими разработчиками, ведущими программистами и ведущими архитекторами. Общее у таких людей то, что они не будут линейными менеджерами своих коллег по команде. Неформальными лидерами становятся благодаря своим заслугам или принятым на себя обязательствам. Это предполагает ответственность, не имеющую ничего общего с ответственностью линейных менеджеров [Testa 2009: 53]. Когда подобные лидеры возникают сразу в нескольких местах, такое неформальное лидерство называется распределенным. Его возникновение логически связано с наличием в командах специалистов со склонностью к генерализации и расширенной трактовкой названий должностей.

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

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

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

 

Поддерживайте границы между командами

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

Идея укрупнения: группа объектов воспринимается как единый блок. Граница этого блока немного похожа на клеточную мембрану или границу государства. Она определяет идентичность блока, состоящего из группы объектов. В зависимости от контекста мы можем игнорировать внутреннюю структуру блока либо учитывать ее [79] .

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

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

Еще одна связка, которую нужно брать в расчет, – то, как отдельные люди соотносятся с командами. Может ли один и тот же сотрудник входить более чем в одну команду? Когда людей просят уделять силы нескольким командам, это, как правило, отрицательно сказывается на продуктивности. Мик Джаггер не пытался в дополнение к The Rolling Stones подрабатывать в группе Jackson Five, и на это есть веские причины. Такие ситуации приводят к тому, что люди разрываются между разными задачами, возникает конфликт интересов, размываются обязательства и пропадает мотивация. Сделайте все возможное, чтобы конкретный сотрудник был членом только одной команды. Люди не будут эффективно действовать как часть команды, если не знают, кто в нее входит. Они могут время от времени помогать сотрудникам из других команд с их проектами или время от времени исполнить дуэт, но у каждого сотрудника должна быть только одна своя команда, в которую он возвращается с подобных заданий.

И наконец, важной темой будет жизненный цикл команд. Исследования показывают, что команды более эффективны, когда они достаточно долговечны. И не только при разработке ПО [Larman, Vodde 2009: 149/153], но и в других видах бизнеса, например в авиакомпаниях [Hackman 2002]. Так что лучше, чтобы команда существовала настолько долго, насколько это возможно, потому что для возникновения устойчивых правил и каналов связи требуется время. Оно также необходимо, чтобы люди как команда научились отличать, какая информация для них важна, а какая – нет. И еще подумайте вот о чем: какая поп-группа была самой знаменитой за всю историю? И как долго они были вместе? Больше, чем несколько лет? Я так и думал. Если ваши проекты по своей природе краткосрочны, постарайтесь сделать так, чтобы жизненные циклы команд были длиннее, чем жизненные циклы проектов. Так вы дадите одной и той же команде возможность выполнять несколько проектов один за другим.

 

Оптимальный размер команды – пять человек (скорее всего)

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

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

В Agile-методологиях, ведущей из которых на момент написания этой книги стал Scrum, в качестве предпочтительной численности команд часто указывается «семь человек плюс-минус два» (разработчики предпочитают именно так обозначать диапазон от пяти до девяти человек).

Исследования оптимальной численности групп для принятия решений позволяют сделать вывод, что эффективными будут группы, насчитывающие менее двадцати человек [Buchanan 2009: 38–39]. Группы от двадцати человек и более вряд ли можно называть командами. Если численность превышает двадцать, такое сообщество людей следует называть просто группой. (Я пишу этот текст тайком во время Скандинавской конференции разработчиков ПО, в которой участвует 600 человек. Это группа, а не команда.)

В статье этого автора отдельно упоминаются восемь человек в качестве примера неудачной численности команды, поскольку в этом случае мнения часто разделяются поровну. В ней даже утверждается, что Карл I, единственный британский монарх, работавший с тайным советом, состоящим из восьми членов, принимал настолько плохие решения, что в конечном счете это стоило ему головы [Buchanan 2009: 39].

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

Пять человек – один из трех вариантов оптимальной численности, упомянутых Джозефом Пелрайном. Эта численность также находится в диапазоне, рекомендуемом для Scrum-команд. Пять меньше двадцати и не равно восьми. Это число также приблизительно равно среднему значению 4,6, которое было определено как оптимальная численность команд в исследовании, проведенном профессором Ричардом Хэкменом [Hackman 2002: 116–122]. Но лучше всего, что это мое любимое число. Так что все правильно.

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

B = f (P,E).

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

C = f’ (P,E).

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

S = f’’ ({P},E).

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

Другими словами, S (численность команды) может принимать любые значения! Для лунной программы «Аполлон-11» оптимальная численность команды составляла три человека. В регби играют команды по пятнадцать человек. Очевидным образом, оптимальная численность зависит от проекта, людей и внешней среды. И тем не менее статистически оптимальная численность команд может составлять пять человек. Можно обозначить это в виде интервала от трех до семи. Ну или на языке разработчиков как «пять плюс-минус два». При этом оптимальная численность, к счастью, не дотягивает до восьми (рис. 13.3).

Так что мы из всего этого узнали?

Моя рекомендация – не навязывать одну конкретную численность команды в качестве предпочтительной; при этом неплохо заранее ввести несколько ограничений. Например, скажите своим сотрудникам, что не разрешается создавать команды, насчитывающие более двадцати человек, и одновременно посоветуйте им ограничиться численностью пять плюс-минус два человека на одну команду. Затем пусть самоорганизация сделает свое дело и люди сами определят (в реальной операционной среде), какая численность для них оптимальна. Они хотят вместо одной команды из семи человек создать две по три и четыре человека? Почему бы и нет? Они хотят объединиться в одну команду из пятнадцати человек? Прекрасно, пусть сами убедятся, будет ли это работать. Только предупредите, что им может понадобиться все переосмыслить, когда обстановка или набор людей в команде изменится. И последний совет: будьте готовы вмешаться, если они хотят организовать команду из восьми человек (плюс-минус ноль).

 

Функциональные и кросс-функциональные команды

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

Первый вариант предполагает, что вы собираете разработчиков вместе с разработчиками, тестировщиков вместе с тестировщиками, а проектных менеджеров вместе с другими проектными менеджерами. Такие группы называются функциональными подразделениями, а основная мотивация этого способа организации – эффективность и возможности взаимного обучения в рамках данной функции [Larman, Vodde 2009: 243]. Сотрудникам, ответственным за пользовательские истории, легче всего научиться профессии, когда они входят в состав отдела, который может так и называться: «Отдел пользовательских историй».

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

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

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

Люди, работающие над одним и тем же проектом и выполняющие разные функции, испытывают бóльшую потребность в общении друг с другом, чем люди, выполняющие одну и ту же функцию, но работающие над разными проектами (рис. 13.4). Поэтому мы можем сделать вывод, что при реализации проектов кросс-функциональные команды будут наиболее подходящим решением.

Отмечается, что организации, в которых люди организованы по функциональному признаку, страдают от чрезмерной зависимости подразделений друг от друга (иногда такие подразделения называют функциональными колодцами). Создание даже самой незначительной бизнес-ценности (например, одной характеристики продукта) требует коммуникации и координации действий множества команд [Poppendieck 2009: 68]. По этой причине наличие функциональных колодцев оборачивается высокими затратами на осуществление взаимодействий [Augustine 2005: 26].

Когда вы строите команды вокруг функциональных колодцев, а не внутри них, затраты на взаимодействие ниже, но не равны нулю. Дональд Райнертсен перечисляет три недостатка, свойственные кросс-функциональным командам: субоптимизация на уровне проектов, потери в эффективности вследствие недостаточной координации между проектами и ограниченный обмен опытом между специалистами в одной области, работающими в разных проектах [Reinertsen 1997: 104]. Таким образом, представляется, что в случае с кросс-функциональными командами расходуются дополнительные ресурсы в связи с необходимостью синхронизировать стандарты, методы и подходы в рамках одинаковых функций в организации в целом. Например, менеджеру по обеспечению качества может потребоваться больше усилий, чтобы добиться применения лучших практик в тестировании, если тестировщики и другие специалисты, отвечающие за качество, разбросаны по разным командам. Но даже в этом случае цена, которую приходится платить за кросс-функциональность, обычно ниже, чем при функциональных командах.

У кросс-функциональных команд (их также называют проектными, органическими или продуктовыми) есть еще несколько дополнительных преимуществ. Среди них эксперты называют более качественные решения в области дизайна, снижение непродуктивных затрат при передаче частично готового продукта далее по производственной цепочке, более высокую скорость реализации проектов, адаптивность, упрощенное планирование и сфокусированность на результатах [Cohn 2009: 182–188], [Larman 2009: 154].

 

Два принципа организационного дизайна

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

Психолог Фред Эмери различает два базовых принципа координации деятельности команд. Он называет их первым и вторым принципами организационного дизайна.

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

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

Второй принцип организационного дизайна очень напоминает решение, которое специалист по сложным системам Стюарт Кауфман описывает как «участки»:

Кауфман говорит: разбейте организацию на участки, подчеркнув при этом, что участки должны взаимодействовать. Это совсем не то же самое, что создавать независимые, самодостаточные подразделения в традиционном менеджменте. Кауфман считает, что характер и частота взаимодействий между участками позволят сдвинуть всю систему к глобальному оптимуму, несмотря на то что каждый участок будет действовать исключительно в своих интересах. Для осуществления взаимодействий требуется язык или какой-либо другой механизм регулярной коммуникации. Кауфман подчеркивает, что участки должны быть связанными. Если говорить на управленческом жаргоне, участки должны общаться, и не только во время ежеквартального подведения итогов [80] .

В этой аналогии участками будут самоорганизующиеся команды, а не управляемые подразделения. Их повышенная адаптивность (второй принцип организационного дизайна) в сравнении с участками, организованными согласно иерархическому менеджменту (в соответствии с первым принципом), напрямую вытекает из органического подхода к решению проблем. Каждая из команд пытается решить часть более крупной проблемы. Но из-за связанности команд решение, найденное одной командой, привносит изменения в проблему, решением которой занимаются соседние команды. Адаптивные действия соседних команд в свою очередь изменяют проблемы, решаемые остальными командами. В конечном итоге мы получаем экосистему, в которой команды (или участки) совместно занимаются решением одной крупной проблемы [Kauffman 1995: 252].

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

 

Выберите свой организационный стиль

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

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

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

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

В целом кросс-функциональные команды работают лучше, чем функциональные, а второй принцип организационного дизайна удачнее первого. По этим причинам многие консультанты по Agile-методологиям предпочитают организационный стиль № 4. Но, как всегда, все зависит от контекста. Вам может потребоваться выбрать одну из двух других разумных альтернатив, представленных организационными стилями № 2 или № 3, – либо потому, что этого требует недостаточная зрелость команд или порядок коммуникаций, либо для того, чтобы осуществить постепенный переход от организационного стиля № 1 к № 4 (рис. 13.7).

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

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

 

Превратите каждую команду в небольшую бизнес-единицу, создающую ценность

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

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

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

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

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

 

Создавайте отдельные команды для решения однотипных задач

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

Я считаю, что иногда целесообразнее поручать работу, требующую однотипных профессиональных знаний, отдельным функциональным командам, которые состоят из соответствующих специалистов. Этот подход может оказаться необходимым для проектного менеджмента, разработки отдельных компонентов архитектуры, дизайна пользовательских интерфейсов, конструирования оборудования, тестирования или какой-либо другой работы, выходящей за рамки стандартных видов деятельности в границах проектов. Это идет вразрез с «принятым» в Agile-сообществе способом мышления, выразителями которого стали авторитетнейшие специалисты, полагающие что кросс-функциональные команды эффективнее справляются с любыми видами работ – от создания пользовательских историй до бинарной сборки. Хороший пример – Scrum Of Scrums. Он предусматривает участие представителя каждой команды в ежедневных Scrum-совещаниях, а затем эти представители осуществляют координацию между командами. Такие же рекомендации высказывались в отношении Scrum-мастеров, технических лидов, дизайнеров пользовательских интерфейсов и ведущих тестировщиков.

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

Но… при этом необходимо учитывать пять важных факторов:

• Во-первых, когда какая-то работа (например, проектный менеджмент, создание архитектуры или дизайн графических пользовательских интерфейсов) передается отдельным функциональным командам, должен быть создан механизм коммуникации между кросс-функциональными командами и данной функциональной командой [Leffingwell 2007: 108]. В качестве такого механизма можно предложить регулярное участие представителя функциональной команды в стендапах проектной команды и/или назначение представителя от кросс-функциональной команды, который будет отвечать за коммуникацию с командой специалистов. Есть много вариантов обеспечить беспроблемную коммуникацию между кросс-функциональными командами и командами-специалистами.

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

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

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

• В-пятых, команда-специалист бывает виртуальной. Может оказаться достаточным время от времени собирать вместе специалистов по интерактивному веб-дизайну и давать им возможность согласовывать общие стандарты и подходы для применения кросс-функциональными командами, в состав которых они входят. Такие виртуальные команды называются сообществами практикующих или сообществами экспертов. Они представляют собой неплохой компромисс, позволяющий сочетать кросс-функциональные команды с необходимостью координации между специалистами [Augustine 2009: 71–73], [Larman, Vodde 2009: 252/253]. (Примечание: некоторые организации с теми же целями поддерживают центры передового опыта, хотя такие центры обычно имеют более формальный характер.)

Возможной или даже предпочтительной будет ситуация, когда функциональная команда возникает в результате самоорганизации. Команды-специалисты могут формироваться органически с целью решить общую для нескольких команд проблему. Например, возможно объединение в одну команду специалистов по непрерывной интеграции, чтобы на более высоком профессиональном уровне оказывать соответствующие услуги другим командам. Члены проектных команд могут входить в функциональную команду на условиях полной или частичной занятости, также возможна их ротация [Highsmith 2009: 272/280]. Могут создаваться команды, отвечающие за отдельные компоненты, – например, команда будет специализироваться на разработке архитектуры ПО и передавать готовую архитектуру проектным командам. В этом случае проектные команды выступают по отношению к ней в роли заказчиков [Cohn 2009: 185]. Главная причина формирования команд специалистов – повышение эффективности (в результате разделения труда).

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

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

А что если проектный офис работает на топ-менеджмент?

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

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

 

Каждый иерархический уровень должен создавать дополнительную ценность

Организационные иерархии – необходимое зло. Они нужны, поскольку должны существовать четкие линии подчиненности между сотрудниками и владельцами компании. Иерархии – это плохо, потому что ими очень легко злоупотреблять, а это имеет ужасные последствия для потока информации. Такие выводы вытекают (теоретически) из первого принципа организационного дизайна Эмери и подтверждаются (практически) эмпирически. Пример можно найти в книге Малкольма Гладуэлла «Гении и аутсайдеры», в которой он пишет о наличии сильной корреляции между авиакатастрофами и иерархическими культурами (из-за плохой коммуникации в кабине пилота) [Gladwell 2008]. Но это не значит, что иерархий быть не должно. Если бы иерархии были злом по определению, мы не наблюдали бы их повсюду в природе (принцип иерархии):

Сложные природные явления организованы иерархически, и каждый уровень состоит из нескольких интегрированных систем [82] .

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

Цель создания организации – снизить необходимое количество коммуникации и координации; поэтому организация сама по себе представляет собой радикальный способ решить проблему коммуникации…Организации с древовидной структурой возникают как реакция на потребность структурировать полномочия и ответственность. Поскольку невозможно одновременно служить двум хозяевам, организации и приобретают древовидную структуру. Но каналы, по которым осуществляется коммуникация, не до конца подчиняются налагаемым этой структурой ограничениям, поэтому организационное древо лишь весьма приблизительно отражает реальные процессы коммуникации, которая по своей природе будет сетевой [83] .

Нам необходимо оптимальное переплетение формальной иерархической и неформальной сетевой структур [Augustine 2005: 48]. Менеджеры должны понимать, что информация движется в первую очередь по сетевой структуре, а не по иерархическим линиям. Но не нужно пытаться заблокировать или контролировать неформальные потоки информации. Наоборот, им следует всячески способствовать. Иерархия определяет распределение полномочий; роль сетевой структуры – гарантировать эффективную коммуникацию (рис. 13.9).

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

В качестве примера Жак приводит разные горизонты планирования для разных уровней организации [Jaques 1999]. Проблемы, решение которых занимает от одного дня до трех месяцев, находятся в ведении самого нижнего уровня; второй уровень занимается вопросами с горизонтом планирования от трех до двенадцати месяцев; на третьем уровне решаются вопросы с горизонтом планирования от одного года до трех лет и так далее. У проектных команд (обычно) нет времени раздумывать о том, что необходимо для того, чтобы компания и через пять лет оставалась успешной. Есть и другие примеры: наем сотрудников, создание стратегических альянсов, сведение бюджетов – все это задачи, которыми проектные команды, как правило, сами не занимаются. Правда, стоит отметить, что не все эксперты в области менеджмента согласны с таким подходом. Некоторые из них пишут о том, что даже президенты компаний иногда вынуждены заниматься повседневными проблемами [Mintzberg 2005: 110].

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

 

Сколько нужно менеджеров, чтобы изменить организацию?

Сейчас модно рассуждать о том, что «чем меньше менеджеров, тем лучше», а у организаций должна быть максимально «плоская» структура. Так и есть. Мы все об этом знаем. И первый вопрос, который задается в этой связи, таков: «Сколько всего менеджеров должно быть?» Ответы на него, которые мне удалось найти в источниках, располагаются в диапазоне от «один менеджер на команду» [Testa 2009: 52] до «один менеджер на каждые сто сотрудников [Larman 2009: 241].

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

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

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

 

Создавайте гибридные организации

Компании, в которых проектные команды сосуществуют с командами-специалистами, а иерархии – с сетевыми структурами, можно отнести к категории гибридных организаций. Они, как утверждается, позволяют одновременно избежать недостатков, присущих функциональным командам в чисто иерархических структурах, и недостатков, типичных для автономных проектных команд в составе сетевых структур. Компании с достаточно гибкой организационной культурой и множеством одновременно реализуемых проектов обычно приходят к гибридной форме организации [Testa 2009: 370, Reinertsen 1997: 106].

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

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

Проблемы, о которых идет речь, являются результатом неправильного построения гибридной организации. Когда все сделано правильно, у каждого сотрудника компании должна быть одна и только одна линия подчинения, и она реализуется через соответствующих линейных менеджеров. Роль проектных менеджеров состоит в том, чтобы обслуживать проектные команды, а не контролировать их. Они управляют проектами, а не людьми. Я убежден, что положение проектных менеджеров ничем не должно отличаться от положения, скажем, архитекторов программного обеспечения или менеджеров, занимающихся вопросами обеспечения качества – у всех свой специфический набор функций. Между прочим, отсюда становится ясно, что у гибридных организаций обычно бывает более двух «измерений». Только одно из них ведет наверх (линия подчинения через линейных менеджеров), а остальные измерения направлены в стороны.

 

Анархия мертва, да здравствует панархия

У крупных проектов больше шансов потерпеть неудачу, чем у более мелких. Это в первую очередь обусловлено социологическими и коммуникативными причинами [DeMarco, Lister 1999: 4]. В некоторых источниках даже утверждается, что шансы на успешное завершение особо крупных проектов стремятся к нулю [Yourdon 2004: 4].

Но я анархист и оптимист. Я полагаю, что мы вполне в состоянии справиться со всеми проблемами – сначала расчленив их, а затем поместив под увеличительное стекло (фигурально выражаясь, конечно).

Сторонники Agile-методологий и анархисты разбивают крупные проекты на несколько мелких, а большие организации – на несколько небольших. Затем они решают проблемы в рамках мелких проектов, перенося опыт на похожие более крупные проекты [Highsmith 2009: 272]. В этом смысле они являются противоположностью бюрократий, в которых планирование осуществляется сверху вниз. Организациям, выстроенным по принципам Agile, присущ рост снизу вверх и связанная с этим адаптивность.

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

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

Панархия – это система перекрывающих друг друга сетей взаимодействия и подчинения. Как индивидуум я подчиняюсь (неохотно) не только правительству моей страны, но и (охотно) власти, которую имеют надо мной банк, интернет-провайдер, компания, поставляющая в мой дом электроэнергию, Twitter, Facebook и LinkedIn, спортивные и игровые клубы, некоммерческие и благотворительные организации, а также правительства других стран, если я решаю в эти страны поехать (другие люди добавляют к этому списку религиозные организации).

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

Конечно, быть анархистом в современных условиях – далеко не то, что было раньше. Сейчас я называю себя панархистом. Это анархист, действующий ненасильственными методами. Брайан Мэрик, один из подписантов первого Agile-манифеста, придерживается сходной идеологии и называет ее ремесленным ретрофутуризмом, скрещенным с командным анархо-синдикализмом. Мне кажется, проще называть это панархией. Да и стикеры в изготовлении обойдутся дешевле.

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

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

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

 

Не имейте секретов

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

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

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

Чтобы предотвратить такие проблемы, необходимо сделать информацию доступной. Общее правило: чем больше информации, тем лучше. Дайте всем доступ в интернет, ко всем сетевым директориям, базам данных проектной информации и к системам контроля версий кода. Пропагандируйте корпоративный интранет, сделайте доступными книги и профессиональные журналы и общедоступными – отчеты об использовании времени, диаграммы сгорания задач, финансовые результаты и другую корпоративную информацию. Придерживание сведений (в большинстве случаев) играет отрицательную роль. Не считайте, что какая-то информация никому не интересна. Вы можете оказаться правы, но если вы будете ее скрывать, то люди заполнят линии коммуникации искаженными данными, поскольку им надо что-то друг другу передавать. Открытость относится не только к информационным системам. Вы и сами должны демонстрировать ее, потому что талантливые люди хотят слышать правду о себе и своей компании [Kaye, Jordan-Evans 2008: 204].

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

В трудные экономические времена особенно важно, чтобы все сотрудники понимали, как в компании обстоят финансовые дела. Как пишет Джек Стэк в книге «Большая игра в бизнес», только когда сотрудникам небезразличны финансовые результаты компании, они смогут придумать способы их улучшить [Stack 1994].

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

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

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

 

Сделайте все заметным

Было время, когда я отслеживал посты Эштона Кутчера в Twitter. Решение пришло практически спонтанно. Дело в том, что Эштон был первым человеком в мире, у кого появился реальный шанс набрать 1 000 000 подписчиков. Следовательно, помимо внешности, должно же быть в этом парне что-то интересное?

Эштон Кутчер был заметным. Интернет был переполнен историями о его соперничестве с CNN, когда было еще неясно, кто из них первым наберет в Twitter миллион подписчиков. Люди вроде меня, читающие массу блогов, просто не могли не заметить эти истории. Только поэтому я и стал подписчиком Эштона Кутчера.

Так что делать, чтобы люди внедряли у себя передовые практики? Это очень просто. Нужно сделать эти практики заметными.

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

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

Увидеть – часто означает скопировать.

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

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

Наверное, вы также должны воздерживаться от демонстрации примеров нежелательного поведения. Окружающие также могут начать им следовать (ненамеренно).

 

Связывайте людей

В своей книге «Либо энтузиазм, либо выгорание» (Fired Up or Burned Out) Майкл Стэллард показал, что один из лучших способов для организаций достичь преимущества – «наладить с людьми настоящий контакт». А Беверли Кей и Шерон Джордан-Иванс в своей книге «Любите их или потеряете» (Love 'Em or Lose 'Em) описывают свою концепцию «создания связей», которую они называют одной из 26 стратегий, направленных на повышение вовлеченности сотрудников [Kaye, Jordan-Evans 2008: 113–122].

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

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

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

 

Стремитесь к адаптивности

В начале этой главы я говорил, что не существует универсальной структуры, которая подходила бы всем компаниям. Саму по себе задачу создания адаптивной организации не в состоянии решить ни кросс-функциональные команды, ни матричный подход, ни любые другие методы. Самый важный вывод, который вы должны для себя сделать, – задача менеджера состоит в том, чтобы повышать способность организации к изменениям. Должно стать нормой превращение функциональных команд в кросс-функциональные и обратно. В качестве стандартной должна восприниматься ситуация, когда при необходимости создается команда-специалист, а затем она расформировывается, если необходимость в ней отпадает. Нормально, если менеджмент пробует применить второй принцип организационного дизайна в какой-либо части компании, а затем возвращается к первому, если выясняется, что второй пока не работает. Абсолютно естественно, когда по мере накопления опыта сложные адаптивные системы пересматривают и реорганизовывают свои составные элементы. Организации в этом смысле ничем от них не отличаются [Waldrop 1992: 146].

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

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

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

 

Резюме

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

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

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

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

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

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

 

Подумать и сделать

Давайте посмотрим, какие идеи из этой главы вы можете применить в своей компании:

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

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

• Подумайте о лидерстве в применении к своей команде. Есть ли в ней неформальные лидеры? Достаточно ли эти лидерские роли динамичны – могут ли они при необходимости легко изменяться?

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

• Взгляните еще раз на матрицу организационных стилей. Какие из них присутствуют в вашей организации? Если стиль № 4 вообще не представлен, есть ли у вас план перехода к нему?

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

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

• Нарисуйте организационную структуру своего бизнеса. Ваш бизнес выглядит скорее как иерархия или как сеть создания ценности?

• Проверьте свои навыки общения. Вам удается выстраивать отношения с людьми регулярно? Если нет, то как вы собираетесь изменить эту ситуацию?