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

Вопрос: Как эффективно сочетать культуру дебатов и дискуссий при разработке продукта с быстрым продвижением и поставкой?

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

Некоторые из вас качают головами: «Ни в коем случае, Адам, ни одна компания не попадает в одну из этих двух крайностей». Другие кивают с таким энтузиазмом, что их головы вот-вот оторвутся от шеи.

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

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

• Как компания попадает в одну из этих крайностей

• Как выйти из культуры «обсуждать все»

• Как выйти из культуры «просто скажи мне, что cделать»

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

Чтобы получить несколько советов о том, как эффективно достичь желаемой культуры, я поговорил с несколькими заслуживающими доверия партнерами по разработке — Дарин Суонсон (New Relic, Gatsby), Мэтт Гринберг (Credit Karma, Reforge and Handshake), Джефф Дуайер (Prefab, ezCater, Hubspot) и Луи Беннетт (Trulia, Intercom, VSCO и Humanitec). Я также получил совет от одного из моих любимых лидеров продуктов, которые говорят все как есть: Эрика Уоррен (Change.org, WyzAnt)

---

Как компания попадает в одну из этих крайностей

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

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

В моем разговоре с Дэрином Суонсоном, мне показалось, он очень элегантно подвел итог:

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

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

Часто компания оказывается в двух, далеко не оптимальных состояниях: «обсуждать все» или «ждать, пока нам скажут».

Второй способ, по которому компании и культуры оказываются в таком положении, — это структура мотивации (или ее отсутствие) внутри компании.

Джефф Дуайер:

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

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

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

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

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

Так что же ты делать?!?

Отказ от культуры «обсуждать все»

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

1. Помогите людям действовать в «серой зоне»

2. Познакомьтесь со шкалой FG

3. Стимулируйте результаты

4. Оцените, как принимаются решения и кто их принимает.

Помогите людям действовать в серой зоне

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

Но, Адам, если люди не понимают решений, не будут ли они с большей вероятностью просто слепо им следовать? Я понимаю, что это звучит нелогично, но нет.  

Мэтт Гринберг описывает ситуацию, в которой он оказался в Credit Karma:

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

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

«В конце концов мы решили эту проблему (в основном) с помощью программы ротации как для Eng, так и для некоторых PM. Пытались наладить эмпатию и взаимопонимание. Команды внедряли по 2-3 человека на проект в течение квартала, а затем меняли их местами в следующем квартале».

Познакомьтесь со шкалой «FG».

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

От Джеффа,

«Мне очень, очень нравится шкала FG, которая, конечно же, «Fucks Give». Я часто этим пользовался, и это действительно эффективно. Когда вы попадаете в ситуацию бесконечных дебатов, просто попросите всех дать оценку FG от 1 до 10. Чаще всего я получаю много 2 и 4, может быть, одну 7. Вы можете попросить 2 и 4 высказать свое мнение, а затем они могут уйти. Обычно они говорят что-то вроде: «Вот что бы я сделал и вот почему, но я на 3 из 10, и я доверяю тебе»

И Эрика,

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

Стимулируйте результаты

Цель разработки продукта — создать ценные продукты для клиентов, которые имеют смысл для них и для нас как бизнеса. Бесконечные дебаты могут возникнуть, когда команды упускают из виду эту цель. Не давая четко понять, что важен результат, вы получите команды, которые больше сосредотачиваются на том, чтобы быть правыми или управлять своей собственной карьерой, чем на создании чего-то ценного, особенно если продакты выдвигают жесткие требования (это еще одна причина, по которой я считаю, что Briefs > PRDs).

Как говорит Джефф, 

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

И Мэтт,

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

Оцените, как принимаются решения и кто их принимает

Дарин напомнил мне цитату (часто приписываемую Уинстону Черчиллю): «Демократия — худшая форма правления, если не считать всех остальных».

Дарин делает еще один шаг вперед: «Демократия — лучшая система, но и самая медленная».

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

От Дарина,

«Когда компании меньше, по необходимости каждый играет несколько ролей, и количество вовлеченных людей ограничено, поэтому вы можете своевременно запросить информацию. Но почти в каждой компании есть этап, когда мы начинаем слышать: «Меня больше не слушают» или «Я не чувствую себя частью процесса принятия решений». [Это может привести к тому, что больше людей будут пытаться участвовать в принятии решений». что они не являются частью.] Мне хотелось бы провести тест: для любого проекта, встречи или предложения — можете ли вы указать мне на документ, в котором указано, кто будет принимать решение, а также как и когда это решение будет принято и опубликовано? ».

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

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

• Решать: После сбора и анализа необходимой информации руководитель должен принять решение. 

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

Как говорит Дарин,

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

Нигде сейчас это не является более сложной задачей, чем в более удаленном и распределенном мире. 

Дарин, еще раз,

«Я видел, как это усиливается, когда мы работаем более удаленно и более распределенно. На сбор данных может уйти хотя бы один рабочий день… неделя или больше – это не редкость! Это действительно мешает срочности и скорости. Время – это роскошь, которой у нас нет. Вместо этого перейдите к 1) публикации предложения, 2) установлению церемоний внесения предложений по предложению (которые могут включать в себя отсутствие запроса предложений… но на свой страх и риск), 3) завершению критики работы персонала или повторению предложения в рамках набора команд. и согласованные сроки, 4) собственник принимает решение и мы двигаемся дальше.

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

Наконец, важно четко понимать, что подлежит обсуждению, а что нет. Как говорит Луи Беннетт:

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

Отход от культуры «Просто скажи мне, что делать»

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

Как говорит Эрика,

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

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

1. Стимулируйте результаты и обратную связь

2. Предоставьте контекст и место для обсуждения

3. Кодифицируйте ожидания в отношении разработки и продукта

Стимулируйте результаты (и обратную связь)

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

От Мэтта,

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

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

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

Обеспечьте контекст и место для обсуждения

Если вы менеджер по продукту, ваша работа — постоянно предоставлять контекст и поощрять обсуждение (с конечной точкой, описанной выше). 

Вот как Мэтту хотелось бы это видеть:

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

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

Мэтт снова,

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

Кодифицируйте ожидания (как инженерные, так и продуктовые)

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

Как говорит Дарин, 

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

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

У Дарина очень прямое мнение о том, как инженерные руководители должны относиться к своей команде:

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

Как выйти из режима «Обсуждать всё» vs. «Просто делать»

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

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

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

Чтобы освободиться от культуры «все обсуждать, ничего не делать»:

1. Помогите людям действовать в «серой зоне»

2. Познакомьтесь со шкалой FG

3. Стимулируйте результаты

4. Оцените, как принимаются решения и кто их принимает.

И чтобы освободиться от культуры «просто скажи мне, что построить»:

1. Стимулируйте результаты и обратную связь

2. Предоставьте контекст и площадку для обсуждения

3. Кодифицируйте ожидания в отношении разработки и продукта

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

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

p.s. понравился пост, приходи в мой тг-канал Inspired Product Manager.