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

Это перевод статьи pragmatic engineer авторства Гергели Ороза – инженера с опытом лидирования веб- и бэкенд-направлений в Uber. Также в послужном списке автора работа в Skyscanner и Skype. Подробнее об авторе можно узнать здесь.  
Управление проектами – тема, по которой у большинства есть свое мнение, и я не исключение. Чтобы ответить на вопрос о том, как разные компании ведут инженерные проекты, я обратился за помощью к представителям разных отраслей. В этой статье мы рассмотрим:
Подходы к управлению проектами в разных отраслях. Обзор исследования, в котором приняли участие более 100 компаний, и основные выводы.
Управление проектами в Бигтехе. Как это происходит? Как организационная структура в бигтехе влияет на выполнение проектов?
Отсутствие 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 сотрудниками. Даже в группе крупных нетехнологических компаний одни экспериментируют с новыми подходами, а другие придерживаются того, что хорошо работает уже много лет.
Есть ли определенная методология?
Наиболее часто используемые подходы
Кто обычно ведет инженерный проект?
Бигтех и другие технологические компании
Команды могут выбирать, как им работать (чаще)
Есть рекомендованная методология, но команды вправе выбирать (реже)
Планирование-Итерации разработки-Запуск
Отсутствие прописанной методологии
Техлид
Один из разработчиков в команде
Венчурные стартапы (крупные)
Есть рекомендованная методология, но команды вправе выбирать (чаще)
Необходимость придерживаться определенной методологии (реже)
Планирование-Итерации разработки-Запуск
Отсутствие прописанной методологии
Канбан
Скрам
Техлид
Один из разработчиков в команде
Венчурные стартапы (небольшие)
Необходимость придерживаться определенной методологии (чаще)
Есть рекомендованная методология, но команды вправе выбирать (реже)
Планирование-Итерации разработки-Запуск
Скрам
Канбан
Один из разработчиков в команде
Менеджер продукта
Невенчурные технологические компании
Необходимость придерживаться определенной методологии (преимущественно)
Есть рекомендованная методология, но команды вправе выбирать (реже)
Скрам
Scaled Agile
Техлид
Выделенный проектный менеджер
Один из разработчиков в команде
Большие нетехнологические компании
Необходимость придерживаться определенной методологии (преимущественно)
Есть рекомендованная методология, но команды вправе выбирать (редко)
Скрам 
Scaled Agile
Планирование-Итерации разработки-Запуск / Канбан
Выделенный проектный менеджер
Скрам мастер
Менеджер или владелец продукта
Техлид
Консалтинговые компании
Необходимость придерживаться определенной методологии (преимущественно)
Есть рекомендованная методология, но команды вправе выбирать (редко)
Скрам 
Отсутствие прописанной методологии
Выделенный проектный менеджер
Компании разделены следующим образом:
Бигтех и другие технологические компании: компании, акции которых публично торгуются на бирже, и бизнес которых основан на технологиях. Многие из этих компаний ранее получали венчурное финансирование.
Крупные стартапы: стартапы с финансированием серии 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 плохо воспринимается разработчиками. В командах, где проекты ведут техлиды, обычно проще справиться с натиском постоянно меняющихся требований. Поэтому подход, при котором руководитель проекта не может оградить команду от изменения требований, респонденты оценивают плохо.
Низкая удовлетворенность процессами при подходе, когда команды не могут изменить неудачный подход к управлению проектами. Об этом говорили респонденты из компаний, где все команды следуют одной и той же методологии. Это пример директивного руководства. Хоть он и работает порой  в областях, не требующих особой креативности, это все же плохой способ создания продуктивных команд разработчиков. Если команды могут менять свои процессы на собственных условиях, удовлетворенность и производительность растут.
Здесь можно ознакомиться со всеми ответами респондентов.
Большие технологические компании отличаются друг от друга подходами к выполнению проектов, вот сводка:
Компания
Есть ли основная методология?
Какая проектная методология чаще всего используется для инженерных проектов?
Кто обычно ведет инженерные проекты?
Amazon
Нет, команды сами выбирают
Планирование 6-pager-Итерации разработки-Запуск
Техлид
Apple
Нет, команды сами выбирают
Планирование-Итерации разработки-Запуск
Техлид
Datadog
Нет, команды сами выбирают
Планирование RFC-Итерации разработки-Запуск
Техлид или один из разработчиков
Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена)
Нет, команды сами выбирают
Планирование-Итерации разработки-Запуск
Техлид или один из разработчиков
Google
Нет, команды сами выбирают
Планирование Design Doc-Итерации разработки-Запуск
Техлид или один из разработчиков
Netflix
Нет, команды сами выбирают
Планирование-Итерации разработки-Запуск
Техлид или один из разработчиков
Shopify
Нет, команды сами выбирают
GSD шестинедельные циклы
Техлид или один из разработчиков
Spotify
Нет, команды сами выбирают
Планирование-Итерации разработки-Запуск
Техлид или один из разработчиков
Uber
Нет, команды сами выбирают
Планирование ERD -Итерации разработки-Запуск
Техлид или один из разработчиков
У всех бигтех компаний есть сходства в системе выполнения проектов: 
Большинство проектов ведут технари: либо технический руководитель, либо лид-разработчик. 
Команды вольны выбирать методологию управления проектами, которая будет для них наиболее эффективна. 
Нет выделенного проектного менеджера для каждой отдельной команды. В большинстве компаний есть технические менеджеры (Technical Program Managers, TPM), которые участвуют в крупных проектах, охватывающих несколько команд, или выполняют их в рамках одной организации. В Uber соотношение TPM и инженеров составляло примерно 1:50. 
Артефакты и процессы управления проектами различаются между командами даже в одной и той же организации. У большинства команд есть бэклог проекта, над которым они работают по-своему, и ретроспективы время от времени.
Удобный инструментарий для разработчиков нужен и используется во всех командах. Работа в основных ветках, получение быстрой обратной связи от систем развертывания и возможность быстро поделиться разрабатываемой функциональностью с другими членами команды – это крепкая база для масштабируемого и эффективного процесса разработки.
Для тех, кто работал в бигтехе, вышеописанное – не новость. Однако, решая скопировать этот подход в более традиционной компании, жди беды. Все потому, что оргструктура в бигтехе сильно влияет на то, как команды добиваются результатов.
Чтобы понять, как в бигтехе управляют проектами, давайте сделаем шаг назад и посмотрим на условия, в которых работает большинство этих компаний.
Самостоятельность разработчиков и команд. В обычных компаниях от разработчиков ждут выполнения работы в виде «копать отсюда и до обеда». В бигтехе каждое решение разработчика или команды влияет на бизнес, решает определенную его задачу. И все это понимают.
Заинтересованность в решении проблем, а не просто отработка часов. Мотивированный инженер легко добивается в несколько раз большего результата, чем «фабричный рабочий», который делает только то, что ему говорят.  В организациях, где больше «фабричных рабочих» обычно более строгая структура управления и мало поля для маневра в контексте выполнения задач.
Прозрачность внутренних данных, кода и документации. Сотрудникам – и не только разработчикам – часто доступны бизнес-метрики и данные в реальном времени, легче писать собственные запросы и создавать пользовательские отчеты.
Знакомство с бизнесом. В бигтехе разработчикам важно взаимодействовать с остальными сотрудниками компании и строить отношения с теми, кто не имеет отношения к программированию. В традиционных компаниях часто наоборот – разработчики общаются с разработчиками, а бизнес с бизнесом. Если эти два мира и пересекаются, то в количестве, недостаточном для создания синергии при выполнении проектов.
Общение между инженерами вместо общения через посредников. Традиционные компании часто практикуют иерархический способ согласований и обмена информацией, при котором принятие решений замедляется, а с ним и выполнение проектов. 
Инвестиции в удовлетворенность разработчиков. Чтобы не испытывать отток кадров и экспертизы, компании создают условия работы, в которых сотрудники чувствуют свою ценность, ощущают комфорт и могут гордиться своим местом работы.
Более высокая зарплата, но и более серьезная ответственность. Нет проблем в том, чтобы платить по верху рынка или даже больше, если разработчики в компании регулярно показывают ожидаемые результаты и влияют на рост бизнеса. 
Качество нанимаемых специалистов. В бигтех берут высококвалифицированных и высокомотивированных людей – при вышеперечисленных факторах иначе быть не может. 
При этом зачастую от инженеров в бигтехе требуют генералистского подхода: нанимаемый специалист должен быть способен не только разбираться в своей предметной области, но и иметь представление о том, как его решения могут соотноситься с другими частями системы и работой других специалистов. 
Еще одно любопытное отличие бигтеха – в компаниях зачастую есть менеджеры продукта и полностью или почти отсутствуют менеджеры проектов.
Роль менеджеров по продуктам в бигтехе – в определении стратегии команды и ее реализации. Они как бы определяют для команды ответы на вопросы «почему (нам это нужно)» и «как (мы это будем делать)». Вот вариант пояснения от менеджера по продукту Facebook Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена) Уилла Лоуренса:
«Роль менеджера по продукту заключается в том, чтобы понять, в какую игру мы играем, и как мы собираемся в нее играть. Стратегия – это выбор игры, поиск областей, в которые стоит инвестировать, и создание убедительного видения того, как мы можем преуспеть в этой игре. (…) Исполнение – это то, как мы играем в игру: ежедневные процессы, решения и действия, предпринимаемые для достижения прогресса в реализации нашей миссии».
Менеджеры по продукту следят за тем, чтобы команда продолжала работать над нужными вещами. Здесь и работа с бизнесом, и данными, и дизайном для построения дорожной карты, создание планов, приоритезация и эскалации в случае необходимости. В крупных компаниях это уже само по себе работа на полный рабочий день.
Менеджеры продукта не занимаются управлением проектами. Команда отвечает за выполнение, а руководитель команды – обычно инженерный менеджер – отвечает за то, чтобы работа работалась.
При наличии полномочных и автономных команд управление проектом редко идет сверху вниз. Успешна практика ротации роли лидера проекта среди разработчиков команды – так у каждого есть возможность развивать свои управленческие скиллы. 
Если нет проджекта, не перегружены ли инженеры управлением? Эффективно ли используется время разработчика, если он также занимается ведением проекта? Сложно ответить однозначно.
С одной стороны, на уровне команды отсутствие выделенного руководителя проекта в итоге упрощает процессы и укрепляет личные отношения. Проджекты-технари не заинтересованы в насаждении процессов ради процессов и фреймворков ради фреймворков – они понимают, что это только навредит. Сотрудничая с другими командами – в которых тоже нет прождектов – они будут налаживать отношения с другими инженерами, ведущими проекты или продуктологами. Такая коммуникация более эффективна, чем если бы она проходила через нескольких менеджеров.
С другой стороны, в сложных проектах, которые охватывают несколько команд в разных офисах и часовых поясах, руководство таким проектом – это работа на полный рабочий день для инженера. Поэтому в бигтехе есть должность технического менеджера (TPM) для управления сложными и часто стратегическими проектами, чтобы снять нагрузку с инженеров.
Тем не менее, руководители проектов все еще существуют в бигтехе. Как правило, они ответственны за внешние процессы и отношения – например, руководитель программы партнерства со сторонней компанией. 
Работая в 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.
Большинство инженеров Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена), Whatsapp, Google, Netflix и других подобных организаций никогда не использовали Scrum. Почему? Этому есть несколько причин:
Компетентным и самостоятельным сотрудникам не нужны постоянные надзор и указания, чтобы производить надежный и качественный продукт. Бигтех привлекает и нанимает как раз таких специалистов. 
Компетентным командам предоставляют свободу выбора методов работы. Это справедливо для большинства видов инженерных работ, и не зря модель Skunk Works – автономия с уменьшенной бюрократией – это то, чего в итоге придерживаются многие высокоэффективные команды с крутыми специалистами.
Масштабирование инженерной организации выходит далеко за рамки процессов на уровне команды, и это еще одна причина, по которой большая часть бигтеха не практикует сложносочиненные процессы. Это не значит, что у таких организаций нет проблем с производительностью – просто их не решить наращиванием процессов. Вот о чем эти проблемы:
Производительность разработчиков. Как инженерам посвящать больше времени написанию кода и достижению целей команды, когда все время приходится заниматься решением багов или проблем с зависимостями? 
Закрытие техдолга. Бигтех бигтехом – со всеми его инновациями и быстрыми темпами роста – но костыли никому не чужды. Технический долг неизменно наращивается везде, и вопрос в том, как его закрытие встроить в ежедневную работу, чтобы не ждать момента Х, когда мы всей командой тратим время только на техдолг, потому что дальше оттягивать уже опасно. 
Структуры команд, соответствующие целям организации. Цели компании и дочерних организаций регулярно меняются. Как принимать эти изменения и при этом не нарушать сплоченность коллектива?
Поддерживать темп по мере роста инженерной команды. Чем больше инженеров в компании, тем более ресурсозатратно общение и принятие командных решений. Как сохранить темпы развития при кратном увеличении штата? Какие решения позволят командам работать быстро, независимо от размера организации?
Необходимость постоянно быть на острие. Как повысить производительность всей организации, чтобы при этом и инженеры были довольны, и результативность работы непрерывно наращивалась? 
Должны ли компании отказываться от 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 в первые несколько месяцев своего пребывания на посту. Они организовали крупное мероприятие, наняли рок-группу и представили новый способ работы. Последующие недели и месяцы прошли в хаосе, и организация вернулась к прежним методам работы.
Научить кого-то ловить рыбу – это больший труд, чем поймать ее для него. Мой подход к управлению проектами заключался в том, чтобы обучать и наставлять членов моей команды, чтобы они сами становились руководителями проектов. Это требовало больше усилий на начальном этапе, но в результате команда добивалась бОльших результатов, люди быстрее росли, быстрее получали повышение, и становились инженерными лидерами быстрее своих коллег. Такой подход стал одним из моих лучших решений в условиях расширения прав и возможностей. 
Руководство, наставничество и коучинг – все они имеют свое применение. Руководство – указание людям, как именно им следует поступать – выливается в  микроменеджмент, когда сотрудники в состоянии воспринимать задачи на уровне концепции, а не списка действий. Выбирайте подходы в зависимости от того, что делаете: направляете, наставляете или тренируете, давайте свободу, исходя из возможностей. 
Чем меньше людей вам нужно для принятия решений, тем быстрее вы их принимаете. Если инженеру для принятия решения нужно поговорить только с инженером, решение будет принято быстрее, чем если бы инженеру пришлось говорить с менеджером проекта, который говорит с другим менеджером проекта, который говорит с инженером, который говорит с… ну вы поняли.
Оптимизация отчетности – это оптимизация среды с низким уровнем доверия. Отчетность на уровне руководителей очень важна. Однако если вы внедряете методологии управления проектами, которые добавляют тяжелые процессы ради отчетности, то вы получите больше процессов и меньше доверия, а люди будут для отчетности играться с данными – просто чтобы цифры в итоге хорошо смотрелись.
Люди будут склонны фиксировать показатели, которые легко измерить, потому что это самый простой способ доказать свою ценность. Если легко измеримый результат действительно полезный артефакт для компании – отлично. Только убедитесь, что цели для таких показателей действительно стоящие и поставлены правильно. 
Обучение у прямых конкурентов недооценивают. Понять, что делает быстроразвивающийся конкурент, и поэкспериментировать с похожими инструментами или идеями – очень предприимчивый шаг. Посиделки за чашкой кофе с коллегой из конкурирующей компании могут стать отличным профессиональным вложением, да и для нетворка не помешают.
Некоторые из лучших инженеров скорее уволятся, чем будут подвергаться микроменеджменту, особенно когда рынок труда накален, и высок спрос на сеньорных специалистов. Вот цитата из ответа опросника: «Недавно руководители высшего звена начали навязывать всем командам свои методы работы (все должны следовать одной и той же методологии). Это привело к тому, что многие инженеры ушли».
Я рекомендую черпать вдохновение у других, экспериментировать, проводить итерации и двигаться в сторону высокодоверительной среды, где люди мотивированы. Именно так я и поступил, создав структуру, которая помогла каждому человеку в команде расти на благо всех: команды, компании и меня самого.
СТО — fuse8
Ваш аккаунт
Разделы
Информация
Услуги

source