Kitabı oxu: «Элегантная головоломка. Системы инженерного менеджмента»

В тексте упоминаются социальные сети Facebook и/или Instagram (организации, запрещённые на территории РФ).

Meta Platforms Inc. признана экстремистской организацией на территории РФ.

First published in English as An Elegant Puzzle: Systems of Engineering Management by Will Larson

Copyright © 2019 Will Larson

Published by permission of Will Larson (USA) and Nordlyset Literary Agency, LLC (USA)

via Igor Korzhenevskiy of Alexander Korzhenevski Agency (Russia)

© Шустова А. П., перевод на русский язык, 2023

© Оформление. ООО «Издательство «Эксмо», 2023

* * *

Благодарности

Хочу выразить особую благодарность некоторым людям.

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

Предисловие

Свою первую запись в блоге я опубликовал 7 апреля 2007 года под заголовком «Поиск нашего стиля программирования». Текст был не очень хорош. В том же году я написал еще 69 статей. Последняя – «Миядзима и Хиросима» – представляла собой коллекцию фотографий из поездки по Японии, во время которой я преподавал английский язык. В следующем году я написал уже 192 поста. Но манера моего письма по-прежнему оставляла желать лучшего.

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

«Элегантная головоломка» – удачное сочетание опыта, почерпнутого в Stripe, десяти лет, проведенных за написанием постов и изучением лидерства и менеджмента. Плюс мне повезло с коллегами, которые предложили объединить мои посты в единое пособие.

Я надеюсь, что каждый, кто возьмет эту книгу в руки, извлечет для себя что-то полезное. Своими комментариями и мыслями вы можете поделиться со мной по электронной почте – я буду несказанно рад: lethain@gmail.com.

Глава первая
Введение

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

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

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

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

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

Так было и в начале моего пути к идеальному руководству. Началось все с компании Digg в 2010 году. Тогда мне пришлось уволить несколько человек подряд. Это не привело к созданию строгих правил управления в моей голове. Я по-прежнему не представлял что делаю.

С самого начала я занимался самообразованием. Читал книги по менеджменту, казавшиеся мне хоть немного актуальными и практичными. Несколько из них вы найдете в разделе «Книги, которые я считаю очень полезными». Но редкие ответы, прочитанные на их страницах, тонули в постоянно растущем море вопросов. Потом мне довелось поработать в Uber (за два года их команда инженеров выросла с 200 до 2000 человек). Затем в Stripe, пережившей такой же стремительный рост. Лишь тогда я смог по-настоящему усовершенствовать свой подход к менеджменту, потому что столкнулся с бесконечным разнообразием проблем. Управление быстрорастущими компаниями спокойным не назовешь, но лучшей среды для обучения и развития было не найти.

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

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

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

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

ЕСЛИ СИСТЕМАТИЧЕСКИ ИСПОЛЬЗОВАТЬ ЭТОТ ИНСТРУМЕНТ И ВНОСИТЬ УМЕРЕННЫЕ ИЗМЕНЕНИЯ, ОТКРОЮТСЯ ВСЕ ДОРОГИ К МАСШТАБИРОВАНИЮ ПРОЦЕССОВ.

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

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

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

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

Глава вторая
Организации

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

Рисунок 2.1. Определение размеров команд и групп команд с использованием правил оптимальных размеров.

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

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

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

2.1. Выбор размеров команды

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

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

ПОД УПРАВЛЕНИЕМ ОДНОГО МЕНЕДЖЕРА ДОЛЖНО БЫТЬ ОТ ШЕСТИ ДО ВОСЬМИ ИНЖЕНЕРОВ.

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

Вот принципы, которыми я руководствуюсь для определения размера команд:

Под управлением одного менеджера должно быть от шести до восьми инженеров.

Тогда у них будет достаточно времени для того, чтобы активно обучаться, учиться действовать согласованно и выполнять задачи своей команды, следуя заданным стратегиям и структурным изменениям, основанным на корпоративном кодексе (2)(3).

У УПРАВЛЯЮЩЕГО МЕНЕДЖЕРАМИ В ПОДЧИНЕНИИ ДОЛЖНО БЫТЬ ОТ ЧЕТЫРЕХ ДО ШЕСТИ ЧЕЛОВЕК.

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

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

У управляющего менеджерами в подчинении должно быть от четырех до шести человек.

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

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

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

Рисунок 2.2. Команда, состоящая из двух групп, работающих по запросу, и разных штатных инженеров.

Оптимальный состав ротируемой группы – восемь инженеров.

Контроль над дежурными задачами осуществляется легче, если оптимальное число сотрудников двухуровневой поддержки 24/7 – восемь инженеров. Многие теперь используют групповые переписки в WhatsApp и Telegram, что накладывает ограничение на размер команды. Большое число участников чата перегружает переписку.

ОПТИМАЛЬНЫЙ СОСТАВ РОТИРУЕМОЙ ГРУППЫ – ВОСЕМЬ ИНЖЕНЕРОВ.

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

Менее четырех человек для команды слишком мало.

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

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

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

МАЛЕНЬКИЕ КОМАНДЫ ОЧЕНЬ ХРУПКИ, И ПРИ МАЛЕЙШЕМ СБОЕ ОНИ ВОЗВРАЩАЮТСЯ ОТ ИННОВАЦИОННЫХ РАЗРАБОТОК К РУТИННОМУ ИСПОЛНЕНИЮ СВОИХ ТЕХНИЧЕСКИХ ОБЯЗАННОСТЕЙ.

Собрав воедино эти руководящие принципы, я разработал удивительно простой и эффективный порядок действий:

• Формируйте команды из шести–восьми человек.

• Чтобы создать дополнительную команду, увеличьте существующую до восьми–десяти человек, а затем разделите ее на две по четыре или пять человек.

• Никогда не создавайте «пустые» команды (два-три человека).

• Никогда не просите одного менеджера вести более восьми человек.

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

2.2. Старайтесь формировать высокоэффективные команды

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

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

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

Рисунок 2.3. Четыре состояния команды.

2.2.1. Четыре состояния команды

Руководящие принципы начинаются с терминов для описания команд и их работы в данном контексте.

Команды могут находиться в одном из четырех состояний:

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

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

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

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

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

Рисунок 2.4. Четыре этапа прогресса команды – от спада производительности до внедрения инноваций.

2.2.2. Корректировка системы и тактическая поддержка

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

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

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

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

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

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

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

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

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

2.2.3. Консолидируйте усилия

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

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

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

2.2.4. Долговременный успех

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

Рисунок 2.5. Прибыль при консолидации инвестиций по сравнению с распределением инвестиций.

2.3. Аргументы против глобальной оптимизации сверху вниз

После того как я опубликовал исследование под заголовком «На пути к высокопроизводительным командам»¹ (8), многие задавали мне один и тот же вопрос: «Как только команда погасит технический долг, не должны ли лишние работники перейти в другие подразделения?»

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

Это важная проблема, требующая решения!

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

2.3.1. Команда – первый приоритет

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

МОРАЛЬ ЗАКЛЮЧАЕТСЯ В ТОМ, ЧТО НУЖНО УЧИТЫВАТЬ ЗАТРАТЫ НА ОТЛАДКУ РАБОЧИХ ПРОЦЕССОВ ПОСЛЕ ВНЕДРЕНИЯ ИЗМЕНЕНИЙ, А НЕ В ТОМ, ЧТО ИЗМЕНЕНИЙ НЕ ДОЛЖНО БЫТЬ ВОВСЕ.

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

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

2.3.2. Постоянные затраты

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

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

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

2.3.3. Наличие избыточных производительных мощностей

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

Рисунок 2.6. Постоянные затраты на управление командой.

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

ЧТОБЫ ПОБУДИТЬ ЛЮДЕЙ К ОПТИМИЗАЦИИ ГЛОБАЛЬНОЙ ЭФФЕКТИВНОСТИ, ТРЕБУЕТСЯ БОЛЕЕ ГЛУБОКОЕ ПОНИМАНИЕ ТОГО, КАК ДОСТИГАЕТСЯ ПРОИЗВОДИТЕЛЬНОСТЬ КОМПАНИИ И ЧЕМ ОНА ОТЛИЧАЕТСЯ ОТ ЛИЧНОЙ ПРОДУКТИВНОСТИ.

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

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

«Цель. Процесс непрерывного улучшения» Элияху М. Голдратта и Джеффа Кокса² (10) и «Азбука системного мышления» Донеллы Х. Медоуз³ (11) – феноменальные книги на эту тему.

2.3.4. Расширение сферы деятельности и ротация сотрудников

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

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

РАСШИРЕНИЕ СФЕРЫ ДЕЯТЕЛЬНОСТИ РАБОТАЕТ ЛУЧШЕ, ЧЕМ ПЕРЕВОД ИЗ КОМАНДЫ В КОМАНДУ, ПОТОМУ ЧТО ПОЗВОЛЯЕТ ИЗБЕЖАТЬ ЗАТРАТ НА АДАПТАЦИЮ СОТРУДНИКОВ И СОХРАНЯЕТ ПАТТЕРНЫ ПОВЕДЕНИЯ В СИСТЕМЕ.

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

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

2.4. Продуктивность в эпоху гиперактивного роста

Термин «гиперрост» (12) теперь не так часто употребляют, как пару лет назад. Примерно раз в неделю вы можете услышать о нем. Но если обратитесь к Techmeme⁴ – не увидите ни одного упоминания скачкообразного роста, что можно считать глобальным откатом в старые добрые времена. Только если речь не о единорогах⁵ (13).

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

Когда я начинал работать в Uber, у нас было почти 1000 сотрудников, и каждые 6 месяцев становилось вдвое больше. Один мой давний коллега резюмировал: «Мы растем так быстро, что каждые полгода становимся новой компанией». Другой сразу заключил: «Вот почему наш бизнес-процесс с учетом роста персонала всегда отстает от желаемого результата на два квартала».

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

2.4.1. Больше инженеров, больше проблем

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

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

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

Представим картину: обучение нового сотрудника отнимает у инженера около 10 часов в неделю, а производительность новичков на треть ниже, чем у опытных. В результате на диаграмме 2.8 (по общему признанию, это наихудший сценарий) на двух неподготовленных приходится один обученный. Хуже того, производительность этих троих суммарно равна производительности 1,16 профи (2 х 0,33 для начинающих плюс 0,5 х 1 для обучающего).

Рисунок 2.7. Темпы роста персонала быстрорастущих компаний.

Также необходимо учитывать время, затраченное на найм новых сотрудников.

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

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

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

1. На каждый дополнительный уровень инженеров необходимо разрабатывать и поддерживать вспомогательный уровень управления.

2. Каждые 10 инженеров нужно объединять в новую команду, что требует большей координации (14).

Рисунок 2.8. Больше сотрудников, больше клиентов, больше проблем.

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

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

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

Попробуем включить эти факторы в общие расчеты.

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

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

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

Иногда очень низкая ценность означает отрицательная!

2.4.2. Системы выдерживают рост на один порядок

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

Понимание общего воздействия растущей нагрузки сводится к нескольким важным тенденциям:

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

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

3. Количество поддерживаемых решений растет с течением времени по мере того, как добавляются команды, а «тривиальные» системы превращаются из неподдерживаемых второстепенных идей в фокусные точки для целых команд, поскольку достигают плато масштабирования (например, ApacheKafka⁶, доставка почты, Redis⁷ и т. д.).

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

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

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

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

Основной вопрос состоит в том, что нам со всем этим делать?

2.4.3. Способы управлять энтропией

Из книги «Проект “Феникс”» Джина Кима, Кевина Бера и Джорджа Спаффорда (15) я почерпнул такую идею: вы получаете профит от проектов только тогда, когда они заканчиваются. Чтобы добиться прогресса, прежде всего нужно убедиться, что хотя бы какие-то начатые проекты вы довели до финала.

Легко сказать – но трудно завершить проекты, когда все силы уходят на решение иных задач.

Давайте остановимся на найме персонала, поскольку он с обучением часто отнимает у команды больше всего времени.

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

ЕСЛИ УЖ КОМПАНИЯ РЕШИЛА МАСШТАБИРОВАТЬСЯ, ТО ОСТАНОВИТЬ РОСТ НЕЛЬЗЯ, НО ЕГО ТОЧНО МОЖНО ОБУЗДАТЬ ТАК, ЧТОБЫ В КОМАНДАХ ПЕРИОДЫ РАСШИРЕНИЯ ЧЕРЕДОВАЛИСЬ С ПЕРИОДАМИ АДАПТАЦИИ.

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

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

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

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

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

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

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

Рисунок 2.9. Соискатели получают офферы, становятся новыми сотрудниками, а затем проходят обучение.

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

ЛУЧШИЙ СПОСОБ ИЗБАВИТЬСЯ ОТ ОТВЛЕКАЮЩИХ ФАКТОРОВ – ЭТО КУЛЬТУРА ВЕДЕНИЯ НОРМАТИВНОЙ БАЗЫ, ЧТЕНИЯ И ПОИСКА НУЖНЫХ МАТЕРИАЛОВ, КОТОРЫЕ ДЕЙСТВИТЕЛЬНО ПОЛЕЗНЫ.

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

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

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

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

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

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

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

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

2.4.4. Заключительные мысли

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

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

А как вы сохраняете продуктивность в периоды гиперактивного роста?

2.5. Работа с организационными рисками

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

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

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

НЕСВОЕВРЕМЕННОЕ РЕАГИРОВАНИЕ НА БОЛЬНЫЕ ВОПРОСЫ НА НИЖНИХ УРОВНЯХ, НА МОЙ ВЗГЛЯД, – ОСНОВНАЯ СЛАБОСТЬ РУКОВОДСТВА БОЛЬШИНСТВА КРУПНЫХ ОРГАНИЗАЦИЙ. КАК МОЖНО ОСТАВАТЬСЯ ЭМОЦИОНАЛЬНО ВОВЛЕЧЕННЫМ В ПРОБЛЕМЫ, С КОТОРЫМИ СТАЛКИВАЮТСЯ ПОДЧИНЕННЫЕ, ЕСЛИ ОНИ НАХОДЯТСЯ В САМОМ НИЗУ СПИСКА ВАШИХ ПРИОРИТЕТОВ?

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

Со мной случалось все вышеперечисленное! И приятного было мало во всех случаях.

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

ВЫ, КАК РУКОВОДИТЕЛЬ ОРГАНИЗАЦИИ, ЯВЛЯЕТЕСЬ ДЕРЖАТЕЛЕМ ПАКЕТА РИСКОВ. И РЕШЕНИЕ НЕКОТОРЫХ ЕГО АСПЕКТОВ ВАМ ПРОСТО НЕ ПОД СИЛУ. ЭТО НЕ ТОЛЬКО НОРМАЛЬНО, ЭТО НЕИЗБЕЖНО.

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

Я предпочитаю не забывать и про них.

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

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

2.6. Планирование преемственности

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

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

2.6.1. Чем вы занимаетесь?

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

Подход, который я выбрал, заключается в том, чтобы рассмотреть работу с разных точек зрения:

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

• Сделайте второй заход в календарь и определите обязанности вне рабочих встреч, такие как проведение собеседований и найм.

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

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

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

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

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

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

Рисунок 2.10. Планирование преемственности.

2.6.2. Заполните пробелы

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

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

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

Рассортируйте проблемные области по двум группам:

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

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

ПЛАНИРОВАНИЕ ПРЕЕМСТВЕННОСТИ ПОМОГАЕТ СОЗДАТЬ УСТОЙЧИВУЮ ОРГАНИЗАЦИЮ, А ТАКЖЕ ВЫСВОБОЖДАЕТ ВРЕМЯ ДЛЯ РОСТА И ПЕРЕХОДА К БОЛЕЕ ОТВЕТСТВЕННЫМ РОЛЯМ.

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

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

Эти пункты могут стать началом списка на следующий год!

Глава третья
Инструменты

Рисунок 3.1. Схема системы найма и обучения новых менеджеров.

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

КЛЮЧЕВЫМИ ИНСТРУМЕНТАМИ ДЛЯ ЭФФЕКТИВНОЙ ТРАНСФОРМАЦИИ ЯВЛЯЮТСЯ СИСТЕМНОЕ МЫШЛЕНИЕ, МЕТРИКИ И КОНЦЕПЦИИ РАЗВИТИЯ.

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

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

3.1. Введение в системное мышление

Многие успешные лидеры, с которыми я работал, обладают сверхъестественной способностью решать вопросы с помощью различных технологических рычагов (1). В некоторых проблемных областях чрезвычайно эффективен набор навыков управления продуктом (2), но системное мышление – самый универсальный инструмент, который я находил.

Если вы действительно хотите получить четкое представление об основах системного мышления, вам следует прочитать «Азбуку системного мышления» (3) Донеллы Х. Медоуз⁸. Я постараюсь описать основы и проработать сценарий из недавнего опыта, когда системное мышление оказалось весьма полезным.

3.1.1. Запасы и потоки

Фундаментальное наблюдение относительно системного мышления состоит в том, что связи между событиями часто тоньше, чем кажется на первый взгляд. Мы стремимся описать события, используя причинно-следственные связи. Например: менеджеры перегружены, потому что мы пытаемся запустить важный проект, – но событие само по себе не уникально.

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

КАЖЕТСЯ, ЧТО БОЛЬШИЕ ПЕРЕМЕНЫ ПРОИСХОДЯТ МГНОВЕННО, НО ЕСЛИ ПРИСМОТРЕТЬСЯ, СКОРЕЕ ВСЕГО, ВЫ ЗАФИКСИРУЕТЕ МЕДЛЕННОЕ НАКОПЛЕНИЕ МАЛЕНЬКИХ ИЗМЕНЕНИЙ.

Рисунок 3.2. Системная схема для повышения производительности разработчика.

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

Другая связь, представленная на рисунке 3.1 пунктирной линией – информационная. Она демонстрирует, что:

1. Ценность запаса является фактором, влияющим на размер потока.

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

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

3.1.2. Скорость разработчика

Когда я начал думать о примере полезности системного мышления, мне на ум сразу же пришла работа «Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации» Джина Кима, Джез Хамбл и Николь Форсгрен⁹ (4).

Авторы сосредоточились на четырех показателях скорости разработки:

1. Время выполнения заказа на поставку от создания кода до его использования в производстве.

2. Частота развертывания – это то, как часто вы развертываете код.

3. Частота сбоев изменений.

4. Время восстановления сервиса, затраченное на устранение ошибок.

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

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

• Пул запросов преобразуется в готовые коммиты в зависимости от нашей скорости проверки кода.

• Готовые коммиты преобразуются в развернутые коммиты со скоростью развертывания.

• Развернутые коммиты преобразуются в ошибки со скоростью возникновения ошибок.

• Ошибки исправляются с помощью отмененных коммитов с определенной скоростью восстановления.

• Отмененные коммиты превращаются в новые запросы со скоростью отладки.

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

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

ЕСЛИ У ВАС НЕТ НАКОПИВШИХСЯ ГОТОВЫХ КОММИТОВ, ТО УВЕЛИЧЕНИЕ СКОРОСТИ РАЗВЕРТЫВАНИЯ МОЖЕТ ОКАЗАТЬСЯ БЕСПОЛЕЗНЫМ. АНАЛОГИЧНО, ЕСЛИ СКОРОСТЬ ВОЗНИКНОВЕНИЯ ОШИБОК ОЧЕНЬ НИЗКАЯ, ТО СОКРАЩЕНИЕ ВРЕМЕНИ ВОССТАНОВЛЕНИЯ МАЛО ПОВЛИЯЕТ НА СИСТЕМУ В ЦЕЛОМ.

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

3.1.3. Программы для системного мышления

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

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

3.2. Управление продуктом: Исследование, отбор, проверка

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

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

Рисунок 3.3. Повторяющийся процесс разработки продукта.

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

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

УПРАВЛЕНИЕ ПРОДУКТОМ – МНОГОУРОВНЕВАЯ ИГРА НА ВЫБЫВАНИЕ, КАЖДЫЙ РАУНД КОТОРОЙ СОСТОИТ ИЗ ОБНАРУЖЕНИЯ И ВЫБОРА ПРОБЛЕМ И ПРОВЕРКИ ПРАВИЛЬНОСТИ ИХ РЕШЕНИЯ.

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

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

3.2.1. Обнаружение проблем

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

Чтобы понять, какие проблемы у вас есть, нужно ответить на следующие вопросы:

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

Цель пользователей. Что побуждает пользователей обращаться к вашему продукту? Как помочь им достичь их целей?

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

ВРЕМЯ, ПОТРАЧЕННОЕ НА ОЦЕНКУ ПРОБЛЕМ И СПОСОБОВ ИХ РЕШЕНИЙ, – ОДИН ИЗ ЛУЧШИХ ПРЕДИКАТОРОВ ДОЛГОСРОЧНОЙ ЭФФЕКТИВНОСТИ КОМАНДЫ.

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

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

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

• Что нынешние главные конкретные преимущества позволяют вам делать сегодня?

• Какие потенциальные главные конкретные преимущества вы могли бы создать в будущем?

• Какие главные конкретные преимущества есть у ваших конкурентов?

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

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

• Пример инфраструктуры (создание софта): использование нового стандарта для отказавшей части технологии. Это решает проблему надежности, снижает стоимость технического обслуживания, а также уменьшает затраты на будущие переводы персонала из одного подразделения в другое (11).

3.2.2. Выбор проблем

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

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

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

Старайтесь выигрывать. Нужно выживать в каждом раунде, но также важно в конечном итоге выиграть раунд! Что обеспечит вам однозначную победу?

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

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

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

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

3.2.3. Проверка правильности решения

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

Подходы, которые я нашел эффективными для проверки решения, следующие:

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

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

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

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

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

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

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

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

3.3. Концепции развития и стратегии

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

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

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

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

3.3.1. Стратегии и концепции развития

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

СТРАТЕГИИ – ЭТО БАЗОВЫЕ ДОКУМЕНТЫ, В КОТОРЫХ ПЕРЕЧИСЛЕНЫ КОМПРОМИССЫ И ДЕЙСТВИЯ, ЧТО ПРЕДПРИНИМАЮТСЯ ДЛЯ РЕШЕНИЯ КОНКРЕТНОЙ ПРОБЛЕМЫ.

КОНЦЕПЦИИ РАЗВИТИЯ – ВДОХНОВЛЯЮЩИЕ ДОКУМЕНТЫ, ПОЗВОЛЯЮЩИЕ ЛЮДЯМ, КОТОРЫЕ НЕ РАБОТАЮТ В ТЕСНОМ СОТРУДНИЧЕСТВЕ, ПРИНИМАТЬ РЕШЕНИЯ, ЧЕТКО СОГЛАСУЮЩИЕСЯ ДРУГ С ДРУГОМ.

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

Рисунок 3.4. Таблица различий между стратегией и концепций развития.

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

Итак, настало время разобраться в том, как писать стратегии и концепции развития.

3.3.2. Стратегия

Стратегия рекомендует конкретные действия, направленные на устранение ограничений, связанных с проблемой. Структура, которую я нахожу чрезвычайно эффективной (13), описана в книге Ричарда Румельта «Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно»¹⁰ (14). Она состоит из трех разделов: диагностика, политика и действия.

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

ДИАГНОСТИКА – ЭТО ТЕОРИЯ, ПОМОГАЮЩАЯ ОПИСАТЬ СТОЯЩУЮ ПЕРЕД НАМИ ЗАДАЧУ.

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

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

ПОЛИТИКА – ЭТО ОБЩИЙ ПОДХОД, ЧАСТО ПОДРАЗУМЕВАЮЩИЙ КОМПРОМИСС МЕЖДУ ДВУМЯ КОНКУРИРУЮЩИМИ ЦЕЛЯМИ.

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

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

3.3.3 Концепции развития

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

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

Хорошая концепция развития состоит из следующих блоков:

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

ЭФФЕКТИВНАЯ КОНЦЕПЦИЯ РАЗВИТИЯ ПОМОГАЕТ ЛЮДЯМ МЫСЛИТЬ ЗА ПРЕДЕЛАМИ СВОЕЙ ОБЫДЕННОСТИ И ЛЕГКО ВЫХОДИТЬ НА ПУТЬ ПРОГРЕССА, НЕ ТРЕБУЯ ЖЕСТКОЙ ЦЕНТРАЛИЗОВАННОЙ КООРДИНАЦИИ.

2. Ценностное предложение. Чем вы будете полезны пользователям и компании? Какого успеха вы позволите им достичь? Существует вопрос последовательности: следует ли вам начинать с возможностей (следующий пункт) и обосновывать ценностное предложение или наоборот. Я обнаружил, что, отталкиваясь от пользователей, можно создавать более амбициозные и обоснованные концепции.

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

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

5. Будущие ограничения. С какими ограничениями вы можете столкнуться в этом прекрасном будущем? Лучше сразу описать, как эти новые ограничения будут легко преодолеваться, например, путем финансирования или найма нового персонала.

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

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

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

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

И вот еще парочка советов:

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

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

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

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

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

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

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

3.4. Метрики и базовые показатели

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

Это очень вдохновляющий момент, потому что цели отделяют «что» от «как», но также он может сбить с толку участников перехода: постановка четких целей требует некоторой практики.

Определение целей

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

Хорошие цели – это комбинация из четырех конкретных чисел:

1. Цель указывает, чего вы хотите достичь.

2. Базовый уровень определяет, где вы находитесь сегодня.

3. Тренд описывает текущую скорость.

4. Временные рамки устанавливают границы для изменения.

Соберите все воедино, и хорошо структурированная цель примет следующую форму: «В третьем квартале мы сократим время рендеринга нашей главной страницы с 600мс¹¹ (p95) до 300мс (p95). Во втором квартале время рендеринга увеличилось с 500мс до 600мс».

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

Инвестиции и базовые показатели

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

ЛУЧШИЙ СПОСОБ ИЗБЕЖАТЬ НЕПРЕДВИДЕННЫХ РЕЗУЛЬТАТОВ – СОПОСТАВИТЬ ВАШИ ИНВЕСТИЦИОННЫЕ ЦЕЛИ С БАЗОВЫМИ ПОКАЗАТЕЛЯМИ.

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

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

• Эффективность выполнения основных пакетных заданий не должна превышать текущую цену в 0,05 доллара за ГБ.

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

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

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