Взаимопомощь: 6 способов, как инженеры и менеджеры продуктов могут помогать друг другу

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

1. PM: Делитесь общей картиной; Инженеры: Делитесь техническими ограничениями

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

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

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

Ресурс

Для менеджеров по продукту: "Управление продуктом на практике" от Мэтта ЛеМэя – Подробное руководство по пониманию и коммуникации целей продукта.

Where the World Designs Electronics

Break down silos and enhance collaboration across all aspects of electronics development

Find Out More

Для инженеров: "Прагматичный программист" от Эндрю Ханта и Дэвида Томаса – Книга, акцентирующая внимание на коммуникации и принятии технических решений в процессе разработки.

2. Менеджеры по продукту: Избегайте микроменеджмента; Инженеры: Участвуйте в процессе идеации

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

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

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

Ресурс

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

Для PM (менеджеров по продукту): "Empowered" (Уполномоченные) авторы Марти Каган и Крис Джонс – Эта книга исследует, как дать командам возможность взять на себя ответственность за выполнение продукта.

Для инженеров: "Creative Confidence" (Творческая уверенность) авторы Том Келли и Дэвид Келли – Отличный ресурс для инженеров, желающих творчески вносить вклад в идеацию продукта.

3. PM: Щедро делитесь заслугами; Инженеры: Публично поддерживайте решения по продукту

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

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

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

Ресурс

Для PM: "Radical Candor" (Радикальная искренность) автор Ким Скотт – Книга, которая предоставляет понимание о том, как строить крепкие отношения и давать заслуги там, где это необходимо.

Для инженеров: "Критические разговоры" Ала Свитцлера, Джозефа Гренни и Рона Макмиллана – Узнайте, как вести эффективные, поддерживающие разговоры с коллегами и руководством.

4. Менеджеры проектов: Будьте открыты к обсуждению технического долга; Инженеры: Будьте реалистичны в отношении сроков

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

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

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

Ресурс

Для менеджеров проектов: "Технический долг 101" от ThoughtWorks – Отличное введение в понимание технического долга и способы его управления.

Для инженеров: "Проект Феникс" авторства Гена Кима, Кевина Бера и Джорджа Спаффорда – Роман, иллюстрирующий важность баланса между техническим долгом и бизнес-приоритетами.

5. Менеджеры продуктов: Включайте инженеров в обратную связь от клиентов; Инженеры: Уважайте бизнес-приоритеты

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

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

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

Ресурс:

Для менеджеров продуктов: "Игровой план стройного продукта" авторства Дэна Олсена – Практическое руководство по пониманию обратной связи от клиентов и переводу ее в действенные стратегии разработки продукта.

Для инженеров: "Мифический человеко-месяц" Фредерика П. Брукса – Эта классическая книга рассматривает проблемы сроков разработки программного обеспечения и ожиданий бизнеса.

6. Руководители проектов: ставьте четкие, достижимые цели; Инженеры: будьте ориентированы на решения

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

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

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

Ресурс

Для руководителей проектов: "Измеряйте то, что имеет значение" Джона Доэра – Узнайте, как ставить четкие цели и измеримые ключевые результаты (OKR), которые соответствуют усилиям вашей команды.

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

Пример из реальной жизни: 5-шаговый алгоритм Илона Маска для сокращения внутренней бюрократии

Илон Маск известен своим смелым стилем управления в Tesla и SpaceX. В своих попытках прорваться сквозь внутреннюю бюрократию, Маск разработал пятишаговый алгоритм, подробно описанный в его недавней биографии Уолтера Айзексона, который предоставляет действенный каркас для оптимизации процессов.

1. Подвергайте сомнению каждое требование: Маск советует бросать вызов каждому требованию, даже если оно исходит от "умного человека". Привязывайте имя к каждому требованию и постоянно спрашивайте, необходимо ли оно. Если нет, устраните его.
2. Удалите любую часть процесса, которую можно: Маск подчеркивает, что простота ключевая. Удаляйте ненужные шаги — идите дальше, чем думаете, что должны. Если вам не приходится добавлять обратно хотя бы 10%, вы не удалили достаточно.
3. Упрощайте и оптимизируйте: Только после устранения ненужных шагов следует упрощать и оптимизировать то, что осталось. Избегайте ошибки оптимизации процессов, которые изначально не должны существовать.
4. Ускорение времени цикла: Как только процесс оптимизирован, сосредоточьтесь на его ускорении. Маск предостерегает от траты времени на ускорение тех частей процессов, которые являются избыточными или не нужными.
5. Автоматизация в последнюю очередь: Последний шаг Маска - это автоматизация, но только после тщательного анализа, удаления и упрощения процесса. Слишком ранняя автоматизация может привести к ненужной сложности.

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

Меньше стресса, больше страсти

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