Мифический мифический человеко-месяц

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

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

Опубликованная Фредериком Бруксом еще в 1975 году (вы помните 1975 год, верно? Когда разработка программного обеспечения на 100% напоминала разработку программного обеспечения в 2020 году?), эта книга довольно известна среди инженеров-программистов. В частности, во всей книге есть один известный момент (я не уверен, что люди читают что-либо, кроме этого пункта, если они вообще читали книгу):

«... добавление большего количества мужчин удлиняет, а не сокращает график».

Легко исправить. С этого момента я буду нанимать только женщин для проектов (см. « Возвращение короля» и битву с Королем-чародеем Ангмара).

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

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

Вот график из книги, иллюстрирующий этот момент:

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

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

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

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

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

Удивительно, но ответ на этот вопрос содержится в той же книге Брукса. Вот еще один график в той же главе:

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

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

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

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

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

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

Все дело в управлении зависимостями

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

Одним из решений является формирование стратегического направления для компании, которое сводит к минимуму или ограничивает зависимость посредством тщательно отобранного портфеля инициатив. Самое смешное, что многие люди будут сопротивляться этому. Допустим, у меня есть два варианта: в одном я могу выполнять проекты A, B и C, у которых очень мало координации (скажем, они влияют на разные продукты), а в другом — проекты D1, D2 и D3, которые имеют массу взаимозависимостей ( скажем, все они влияют на один и тот же продукт). Часто случается так, что мифический человеко-месяц используется против первого плана, а не против второго. Потому что на бумаге это выглядит больше .

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

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

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

Спор в « Мифическом человеко-месяце» заключается в том, что по мере того, как вы добавляете людей в программный проект, общение должно увеличиваться в геометрической прогрессии. Например, если у вас есть 3 человека в проекте, это 3 линии связи. Но если у вас 4, это 6 линий связи. Один лишний человек в этом случае ведет к удвоению общения! Весело. (Конечно, это чрезмерное упрощение общения по проектам разработки программного обеспечения.)

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

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

Итак, начало есть. Но взаимозависимости принимают множество форм помимо кода. Приведу пример из Mailchimp.

Риск, связанный с качеством обслуживания клиентов: скрытая (но приемлемая?) стоимость работы по межсетевому экрану

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

Как потребительский продукт (например, Instagram, Nintendo Switch или Roomba) мы должны быть готовы к использованию. Для универсальной маркетинговой платформы, предназначенной для развития вашего бизнеса, это сложно! А это значит, что все, что создает Mailchimp, должно быть тесно связано с точки зрения опыта.

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

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

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

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

“

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

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

Не забывайте о более мягкой стороне масштабирования

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

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

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

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