Проектный менеджмент в бигтехе: как там все устроено, и почему во всем этом отсутствует Scrum

Это перевод статьи pragmatic engineer авторства Гергели Ороза – инженера с опытом лидирования веб- и бэкенд-направлений в Uber. Также в послужном списке автора работа в Skyscanner и Skype. Подробнее об авторе можно узнать здесь.  

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

• Подходы к управлению проектами в разных отраслях. Обзор исследования, в котором приняли участие более 100 компаний, и основные выводы.

• Управление проектами в Бигтехе. Как это происходит? Как организационная структура в бигтехе влияет на выполнение проектов?

• Отсутствие Scrum в бигтехе. Почему так?

• Как следует вести проекты в вашей команде? Я поделюсь своим личным мнением.

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

Skype, Scrum и то, что действительно важно

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

Переход на Scrum в Skype считался успешным шагом. Мы перешли от поставок флагманского приложения для Windows в лучшем случае раз в квартал к ежемесячным поставкам. Большинство команд выпускали что-то каждые 2-4 недели. В командах менялись роли Scrum-мастеров, Agile-коучи приезжали, чтобы дать обратную связь командам, а Microsoft, которая только что приобрела Skype, хотела уметь так же.

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

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

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

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

Подходы к управлению проектами в отрасли

Как компании управляют проектами? Вот результаты опроса, в котором приняли участие более 100 человек. 

Если кратко: «It depends». И это в общем не удивительно. Недавно основанный стартап с пятью сотрудниками будет работать совсем не так, как медленно растущая нетехнологическая компания с 1000 сотрудниками. Даже в группе крупных нетехнологических компаний одни экспериментируют с новыми подходами, а другие придерживаются того, что хорошо работает уже много лет.

Компании разделены следующим образом:

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

• Крупные стартапы: стартапы с финансированием серии B и выше. Эти компании обычно оцениваются не менее чем в $300 млн, активно растут и часто планируют IPO через несколько лет.

• Небольшие стартапы: стартапы, привлекающие предварительное финансирование или финансирование серии А. Как правило, это растущие компании с менее проверенными бизнес-моделями.

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

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

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

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

• Отсутствие прописанной методологии: характерно для государственных и венчурных технологических компаний.

• Планирование-Итерации разработки-Запуск: характерны для государственных и венчурных технологических компаний.

• Scrum: характерна для крупных компаний, не связанных с технологиями, не финансируемых венчурными фондами, и консалтинговых компаний.

• Канбан: упоминается во всех компаниях.

• SAFe (Scaled Agile Framework): упоминается в крупных компаниях, не связанных с технологиями, и в одной компании, не финансируемой венчурными фондами.

• Shape Up: упоминается в нескольких компаниях с венчурным финансированием.

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

Итак, респонденты оценивали по шкале от 1 до 5 удовлетворенность используемой в компании методологии ведения проектов. На основе этих оценок удалось выявить следующие тезисы:

• Команды с выделенными руководителями проектов, как правило, менее довольны в государственных или венчурных технологических компаниях. Однако в компаниях, не финансируемых венчурными фондами, и в консалтинговых компаниях некоторые респонденты были очень довольны своими PM и говорили, что все работает хорошо именно благодаря им. 

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

• Автономность команды и высокая удовлетворенность, кажется, коррелируют. Многие люди, оценившие свою удовлетворенность на 4 или 5 баллов, в качестве положительных моментов отмечали автономность, свободу и гибкость, а также то, что у команды в приоритете качество, а не следование определенному процессу.

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

• JIRA – скорее вред чем польза: все 13 упоминаний JIRA были в негативном ключе. Возможность показать результат в работе без частого использования JIRA, была отмечена как положительный момент. Кроме того, недавно вышедшая на IPO быстрорастущая технологическая компания перешла на JIRA и провела опрос среди инженеров. По его результатам 83 % инженеров не советовали использовать JIRA. В качестве контраргумента инженерный руководитель большой технологической компании со стабильным ростом поделился, что их организация в значительной степени полагается на JIRA, используя ее в качестве базы знаний. В их случае JIRA хорошо работает для крупномасштабной координации. 

Плохо работающие подходы к управлению проектами в чем-то схожи, согласно мнению респондентов, которые были довольным процессами в своих компаниях на 1 или 2 балла:

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

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

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

Здесь можно ознакомиться со всеми ответами респондентов.

Как делают проекты в бигтехе

Большие технологические компании отличаются друг от друга подходами к выполнению проектов, вот сводка:

У всех бигтех компаний есть сходства в системе выполнения проектов: 

• Большинство проектов ведут технари: либо технический руководитель, либо лид-разработчик. 

• Команды вольны выбирать методологию управления проектами, которая будет для них наиболее эффективна. 

• Нет выделенного проектного менеджера для каждой отдельной команды. В большинстве компаний есть технические менеджеры (Technical Program Managers, TPM), которые участвуют в крупных проектах, охватывающих несколько команд, или выполняют их в рамках одной организации. В Uber соотношение TPM и инженеров составляло примерно 1:50. 

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

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

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

Оргструктура бигтеха, влияющая на проекты

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

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

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

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

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

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

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

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

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

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

Продуктовые менеджеры нужнее проектных 

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

Роль менеджеров по продуктам в бигтехе – в определении стратегии команды и ее реализации. Они как бы определяют для команды ответы на вопросы «почему (нам это нужно)» и «как (мы это будем делать)». Вот вариант пояснения от менеджера по продукту Facebook Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена) Уилла Лоуренса:

«Роль менеджера по продукту заключается в том, чтобы понять, в какую игру мы играем, и как мы собираемся в нее играть. Стратегия – это выбор игры, поиск областей, в которые стоит инвестировать, и создание убедительного видения того, как мы можем преуспеть в этой игре. (…) Исполнение – это то, как мы играем в игру: ежедневные процессы, решения и действия, предпринимаемые для достижения прогресса в реализации нашей миссии».

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

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

При наличии полномочных и автономных команд управление проектом редко идет сверху вниз. Успешна практика ротации роли лидера проекта среди разработчиков команды – так у каждого есть возможность развивать свои управленческие скиллы. 

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

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

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

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

Продуктоориентированная среда и отказ от Scrum

Работая в Skype, я был свидетелем того, как Scrum команда полностью отказалась от Scrum. Когда я пришел в команду Skype for Web, мы изначально проводили двухнедельные спринты и следовали Scrum. Также было разделение на программистов и QA, которых в Microsoft называют Software Development Engineer in Test или SDETs. Тем не менее, наши отгрузки происходили всего раз в две недели, но мы хотели, чтобы они происходили чаще.

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

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

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

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

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

• Владелец продукта может с уверенностью подтвердить, что работа выполнена в соответствии со спецификацией.

• Владелец продукта написал спецификацию, он ведь ее проверяет.

• Функциональность не будет отправлена на прод до подписания.

Однако в нашей среде эти предположения часто оказывались ошибочными. Весь код, который мы писали, проверялся с помощью модульных тестов или интеграционных и сквозных при необходимости. Мы навешивали на функциональность feature toggles и проверяли их поэтапным внедрением. Многие «спецификации» – или тикеты – писались инженерами, которые затем могли проверить, работают ли они так, как ожидалось. С CI/CD, feature toggles и экспериментальными инструментами мы получили более быстрые циклы обратной связи, чем если бы мы полагались на владельца продукта.

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

Есть то, с чем Scrum справиться не способен

Большинство инженеров Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена), Whatsapp, Google, Netflix и других подобных организаций никогда не использовали Scrum. Почему? Этому есть несколько причин:

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

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

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

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

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

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

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

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

В защиту Scrum

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

Во множестве случаев переход на Scrum имеет смысл. Например:

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

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

2. Стадии формирования и притирания новых команд. Когда собирается новая команда, ей необходимо решить, как она будет работать. Использование готового подхода почти всегда лучше для начальных этапов, чем нечто, что незнакомые друг с другом люди придумали как-то внутри себя. Или не придумали вовсе. Хорошо описанный подход типа Scrum, будет полезен, если члены команды имеют противоречивые и несовместимые мнения о «правильном способе работы».

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

Ускорение доставки было одной из главных причин перехода Skype на Scrum в 2012 году. До перехода команды выполняли поставки раз в несколько месяцев. После перехода каждая команда выполняла отгрузку один-два раза в месяц. Интересно, что те команды, которые в итоге отгружали функциональность чаще, чем сейчас, решили отказаться от Scrum, поскольку этот процесс не имеет смысла при коротких спринтах.

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

Унифицированная отчетность и детализация приоритетов на уровне команды – одно из преимуществ перехода на Scrum, которое увидело и руководство Skype. Крис Мэттс, который в то время был тренером по Agile в Skype, рассказывает, как они внедрили систему Strawberry-Jam-O-Meter и систему Wrong-Order-O-Meter, что было бы трудно сделать, если бы все команды не использовали Scrum и JIRA:

«Strawberry-Jam-O-Meter использовался для определения команд, у которых было больше всего незавершенных элементов бэклога. Wrong-Order-O-Meter использовался для выявления команд, которые работали над сущностями в неправильном порядке, в соответствии с общеорганизационным бэклогом, определенным организацией-владельцем продукта».

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

Как все-таки лучше управлять командами?

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

В качестве пищи для размышлений предлагаю следующее.

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

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

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

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

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

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

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

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

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