Я работал в разнообразных технологических компаниях: от «традиционных» центров программирования и консалтингов до инвестиционных банков и быстрорастущих технологических фирм. Также я общался с разработчиками ПО, работающими в стартапах, банковской сфере, автомобилестроении, big tech и в более «традиционных компаниях». В этой выборке была приличная доля компаний из Кремниевой долины и тех, которые находятся вне её.
Я заметил, что компании Кремниевой долины часто «схватывают» то, что их традиционные конкуренты не могут даже понять и реализовать на практике — особенно в Европе. Эти практики приводят к ускоренным инновациям на уровне компаний, более качественному профессиональному росту инженеров и просто к «оптимальности» в лучшем значении этого слова. В свою очередь, компании Кремниевой долины могут платить (и платят!) больше, и могут получить больше пользы от одного и того же человека.
В этой статье я буду использовать термин «компания в стиле Кремниевой долины», подразумевая современные компании, оптимально использующие каждого разработчика ПО и традиционно находящиеся в Кремниевой долине (хотя многие новые компании этого типа обосновываются уже не там). Такие компании сравнимы по КПД инженера с Meta* или Google. Они используют схожие методологии и часто могут привлекать персонал из других компаний «в стиле Кремниевой долины».
Вот основное, что эти компании понимают лучше, чем многие другие.
▍ 1. Автономность разработчиков ПО
В «традиционных» компаниях разработчики получают назначенные им рабочие задания, чаще всего через тикеты JIRA. Эти тикеты проверяются менеджером продукта или проекта и в них содержатся основные и ключевые подробности для выполнения работы. И от разработчиков ожидается, что они будут делать только это. Вопросов почти не требуется, если только для уточнения подробностей тикета.
Но в компании «в стиле КД» вы этого почти не увидите. В них есть проекты, менеджеры программ и менеджеры по разработке. Но по большей мере от инженеров ожидается, что они сами поймут, «как» выполнять работу, в том числе и принимать серьёзные решения. В некоторых местах каждым проектом руководит инженер, упрощающий разбиение работы на части. В других местах эту работу могут выполнять менеджеры по разработке или сеньор-разработчики. Как бы это ни происходило, всех инженеров мотивируют смотреть на картину в целом, чтобы они могли быть гибкими и решать любые проблемы.
Компании «в стиле КД» мотивируют инженеров брать инициативу в свои руки. В них часто можно увидеть сервисы и функции, предложенные инженерами, или команды, тратящие время на выплату технического долга, который решили устранить люди в команде. И очень редко менеджеры говорят инженерам, что им нужно делать, разбивают их работу на мелкие части и занимаются микроменеджментом. Люди находятся на самоуправлении.
В традиционных компаниях от разработчиков ожидается, что они будут выполнять назначенную им работу. В компаниях в стиле КД ожидается, что они будут решать проблемы бизнеса. Разница огромна. Она влияет на повседневную жизнь любого инженера.
В традиционных компаниях такая ситуация часто приводит к тому, что разработчики оказываются в иерархической структуре. Я как-то общался с людьми из банка, у них было шесть уровней руководства проектами. Разработчики находились на двух нижних. Решения могли принимать сотрудники начиная с третьего уровня. По сути, те, кто выполняет работу, по определению не имеют права голоса. Нужно ли говорить, что у этого банка были проблемы с работой его программного отдела?
Уровни ниже красной линии не имеют права на принятие решений. Иерархический взгляд на мир. Некоторые традиционные компании по-прежнему так работают
Сравните это с компаниями, где признаётся способность инженеров решать практические вопросы лучше, чем кто-либо другой. Руководители знают, что в интересах бизнеса делиться с ними всем релевантным бизнес-контекстом и дать им свободу реализации.
Совместная работа над реализацией с командой и разработчиками. Эффективные организации получают преимущество благодаря передаче контекста вниз и предоставлению автономности
▍ 2. Любопытные решатели проблем, а не безмозглый ресурс
Традиционные компании склонны считать, что 8 часов времени инженера должны тратиться на кодинг. Любое время, проведённое не за компьютером и не за написанием кода, часто воспринимается как пустые траты. И это оправдывается высокой зарплатой разработчиков. Я слышал, что эту логику кто-то объяснял так:
Разработчикам ПО платят больше, чем многим другим должностям. Поэтому нужно и загружать их соответственно. Мы не можем позволить им работать вхолостую.
Компании «в стиле КД» воспринимают разработчиков ПО как людей, лучше всего подходящих для решения задач организации. Они нанимают не только за технические навыки, но и за навыки коммуникации и решения проблем. Они мыслят примерно так:
Разработчики ПО — одни из самых высокооплачиваемых людей в нашей компании. Так получилось потому, что благодаря кодингу и решению задач они одни из самых полезных людей. Мы хотим познакомить их с бизнесом, чтобы параллельно с выполнением своей «обычной» работы они могли находить возможности, оказывающие сильное влияние на бизнес.
На практике, мотивированный инженер может приносить во много раз больше пользы, чем «заводской рабочий», которому просто говорят, что делать. В худшем случае, когда спецификация работы четка и корректна, оба человека обеспечат одинаковый результат. Однако инженеры, мотивированные решать задачи, часто останавливаются и задумываются, прежде чем браться за работу, выявляя наиболее важные возможности. Вот примеры пары разговоров, которые у меня были в компаниях «в стиле КД» после того, как я задал инженеру вопрос, сможет ли он сделать X:
- «Я немного изучил вопрос, и хотя мы можем сделать X, если у нас получится уменьшить масштаб проекта на эту функцию, которая никак не повлияет на пользу для бизнеса, то мы сможем выпустить это без изменений в коде, просто модифицировав несколько файлов конфигурации.»
- "Меня тревожит, сможем ли мы выпустить проект, и я думаю, что мы должны поставить это на паузу. Я изучил, что делают наши конкуренты, один из них выпустил похожую функцию, но откатил её, столкнувшись с расследованием регулирующего органа. Мы спрашивали у юридического отдела, можно ли вообще выпускать это?"
- «Я изучил наш бэклог и обнаружил, что проект Y очень похож на X. Если бы мы скомбинировали проект X и проект Y, то смогли бы выпустить две вещи, потратив лишь незначительное количество лишних ресурсов.»
- «Мы могли бы построить этот проект сейчас на легаси-инфраструктуре, но потом нам придётся мигрировать на новую инфраструктуру, которая будет готова через месяц. Можно ли отложить проект на месяц, пока не будет готова новая инфраструктура, чтобы избежать двойной работы? Для бизнеса нет никаких веских причин выпускаться в этом месяце, так что я настоятельно рекомендую подождать»
В окружении, стимулирующем к решению проблем и к достижению результатов, а не следованию указаниям, принимаются более качественные решения.
▍ 3. Прозрачность внутренних данных, кода и документации
Степень прозрачности в компаниях КД высока. Хотя есть и исключения — предположительно, Apple и Palantir стремятся предоставлять своим инженерам минимально возможный объём информации, по моим наблюдениям, большинство компаний «в стиле КД» максимально делятся знаниями. Разумеется, насколько это возможно в соответствии с требованиями GDPR, PII и других законов.
Сотрудники (и не только инженеры) часто имеют доступ к бизнес-метрикам в реальном времени, а также источники данных для написания собственных запросов и создания произвольных отчётов. В Skyscanner мы ежедневно получали электронные письма со сводками по дневному доходу с разбивкой по пунктам. В Uber сотрудники еженедельно получают рассылку о росте компании.
С ростом и выходом на IPO компаний происходит консолидация этой информации. Однако у инженеров всё равно остаётся доступ к бизнес-данным их организации, которые помогают им в принятии решений.
В традиционных компаниях практически ничего подобного нет. Инженеры получают спецификацию, а уже руководство понимает, почему принимается решение — по крайней мере, принцип таков.
▍ 4. Доступ к бизнесу и бизнес-метрикам
В компаниях КД ожидается, что каждый участник команды понимает, на какую часть бизнеса и как влияет его работа. Цели команды редко заключаются лишь в выпуске фичи: они выбирают, уменьшить ли отток клиентов на 2%, выпустив Фичу 1, или повысить прогноз дохода на $10 миллионов в год, выпустив Проект X.
Инженеров КД мотивируют взаимодействовать с остальной частью бизнеса и образовывать связи не только с коллегами-инженерами. На практике часто оказывается так, что сеньор-разработчики занимаются следующим: от проведения совещаний 1:1 с менеджерами продуктов до участия в сессиях исследований клиентов. Но я видел и то, как новички-инженеры без малейших проблем работали напрямую с руководителями бизнеса.
В традиционных компаниях, напротив, разработчикам часто мешают общаться с остальной частью бизнеса. Конечно, это презентуется не так. Обычно говорится: «Мы хотим защитить своих разработчиков от отвлекающих факторов». Но я слышал истории о том, как менеджер по разработке хотел пригласить участников своей команды на презентацию продукта, однако менеджер по продукту запретил это делать. «Нам нужно, чтобы они работали, мы не можем позволить, чтобы их отвлекали», — стандартное объяснение.
Когда инженер в традиционной компании создаёт взаимосвязи за пределами своей команды, ему часто говорят, что он «недостаточно сосредоточен», «тратит время» или занимается «не своим делом». Подобные «необычные» действия даже часто фиксируются как отрицательные в оценке его производительности.
Мне кажется безумием, что компании запирают своих лучших решателей задач в загоне с формулировкой «вы просто пишете код», но такое происходит. И те же компании, которые пытаются мерить продуктивность разработки метриками, связанными со строками кода или коммитами, удивляются, почему их инженеры не нацелены на продукт или не осведомлены о нём.
▍ 5. Коммуникация «инженер-инженер» вместо «треугольной» коммуникации
Если вы инженер и у вас есть вопрос о том, как другая команда делает то или иное, то процесс коммуникации в традиционной компании и компании «в стиле КД» строится по-разному.
Традиционные компании стимулируют к иерархической коммуникации. Это происходит и для «защиты» инженеров, и потому, что менеджеры в таких организациях стремятся быть информационными центрами, не отдавая никому власти над этой сферой. Вот как часто происходит передача вопроса к другой команде:
Компании «в стиле КД» стимулируют к коммуникации «инженер-инженер» и и избавлению от промежуточных звеньев. Это быстрее во всех случаях. А в случаях, когда инженер другой команды не может помочь, этот процесс можно откатить к «традиционной» модели с менеджером, помогающим в дискуссии:
Гораздо более эффективная коммуникация
▍ 6. Инвестирование в снижение неудовлетворённости разработчиков
Разработка может быть стрессовым процессом. Не из-за написания кода — это-то легко! — но из-за сопровождающих его вещей. Настройки зависимостей. Развёртывания в продакшене или тестовых окружениях. CI/CD. Мониторинга и систем уведомлений. Всё это не так серьёзно, когда команда состоит из небольшого количества людей. Но она всё равно будет разрастаться.
Однако с ростом компании удовлетворённость разработчиков снижается. Всё начинается с мелочей: увеличивается время сборки, добавляются зависимости, требуется вносить изменения в разных сервисах. Потом приходится разбираться, какая команда отвечает за какой сервис, мелкие миграции разрастаются из-за влияния на несколько команд, а потом даже иногда приходится заново создавать архитектуру для всей системы.
Фреймворки и инструментарий быстро меняются и инструментарий редко поспевает за развитием. Компании, которым важно, чтобы инженеры сосредоточились на быстром решении задач, создают различные инфраструктурные, платформенные и SRE-команды, уменьшающие неудобства разработчиков.
Хотя может показаться контринтуитивным нанимать разработчиков ПО, занимающихся ускорением работы других разработчиков ПО, часто это не так. Это обеспечивает большую выгоду, помогает компаниям двигаться быстрее и разгрузить разработчиков.
▍ 7. Более оптимальное использование --> более высокая {автономность, зарплата}
Многим компаниям в стиле КД, стремящимся конкурировать в сфере зарплат инженеров, нужно обеспечивать их оптимальное применение, чтобы приносимая этими разработчиками польза превышала их зарплаты. Эта оптимизация может использоваться как при масштабировании, так и при росте бизнеса. Оптимизацию повышают такие вещи, как снижение времени, потраченного на ненужную коммуникацию, так и совершенствование инструментария. Для обеспечения высокой оптимизации следует давать инженерам достаточную автономность, чтобы они могли делать вклад в бизнес.
Google, Meta* и другие успешные компании платят сегодня высокие зарплаты за использование масштаба. Инженер в таких компаниях часто создаёт фичи, используемые миллионами клиентов. Такая оптимизация и принесение пользы оплачивают себя сами.
Больше автономности --> больше оптимизации --> больше пользы --> выше зарплаты (и при этом компания продолжает приносить прибыль)
Стартапы в стиле КД используют разработчиков ПО для роста бизнеса. Именно так разработчик ПО в Fog Creek Software реализовал идею рекламы на миллион долларов. Именно так несколько инженеров и дизайнеров разрабатывали кнопку Like в Facebook**. Польза этой кнопки для бизнеса исчисляется миллиардами долларов: она позволила Meta* (пере-)таргетировать рекламу и «отслеживать» пользователей за пределами сайта Facebook**.
Если бы эти люди работали в «традиционной» среде, их идеи остались бы только идеями. Стартапы «в стиле КД» мотивируют инженеров придумывать идеи для бизнеса и реализовывать их. От этого выигрывают все: и люди с идеями, и бизнес.
Компании, оптимально использующие инженеров, не будут испытывать трудностей с оплатой их труда по рынку или выше. Basecamp — хороший пример компании не из «Big tech», оптимально использующей инженеров, что позволяет ей также платить зарплату по верху рынка Сан-Франциско, при этом оставаясь прибыльной.
▍ Технические отделы — это центр извлечения прибыли, а не источник затрат
Ещё один способ взглянуть на то, как работают компании «в стиле КД» — это увидеть, что они считают технические отделы центром извлечения прибыли, а не источником затрат. Изучая таблицу из двенадцати самых «дорогих» (на июль 2022 года) компаний, можно заметить очевидные тенденции:
12 самых «дорогих» компаний с указанием, является ли разработка ПО их центром получения прибыли. Корреляция или причинно-следственная связь?
▍ Самая большая разница
Существует множество аспектов в различиях между разными компаниями в том, как они относятся к инженерам. Однако самый важный заключается в том, что компании «в стиле КД» считают инженеров генераторами пользы и творческими решателями задач. Традиционные компании воспринимают их как заводских рабочих.
Эта разница в приводит к тому, что прогрессивно мыслящие компании могут и платить инженерам больше, и давать им больше свободы. Польза от заводского рабочего чётко определена и с её учётом можно выполнять планирование. С другой стороны, творческий решатель задач может при правильном использовании принести в десять раз больше пользы. Разумнее платить ему больше, давать больше свободы, позволяя делать больший вклад в бизнес.
Поработав в стиле Кремниевой долины, вы с трудом вернётесь на «традиционное» рабочее место, где у каждого есть своя чёткая роль, а попытки выйти за её рамки вызывают непонимание.
Разработчику ПО приятнее работать там, где он решает задачи, а не воспринимается как заводской рабочий.
Meta Platforms*, а также принадлежащие ей социальные сети Facebook** и Instagram**
* — признана экстремистской организацией, её деятельность в России запрещена
** — запрещены в России
Автор:
ru_vds
