Эдди Османи (Addy Osmani)
Ирландский инженер‑программист, руководитель, директор в подразделении Google Cloud AI, где он работает над проектами Gemini, Vertex AI и Agent Development Kit (ADK). После почти 14 лет работы в Chrome, где он руководил разработкой DevTools, Lighthouse и Core Web Vitals, он теперь объединяет команды Google DeepMind, инженеров, специалистов по продуктам и специалистов по связям с разработчиками.
Самые трудные уроки, которые я усвоил, — не о том, как работаешь ты. Они о том, как работают команды: как на самом деле принимаются решения, где ломается координация, чем отличаются команды, которые доводят дело до конца, от тех, кто стоит на месте.
Этот список советов про то, как стать сильнее как отдельный инженер, и больше — про системы вокруг инженерии.
1. Лучшие инженеры выбирают правильные задачи.
Каждое «да» — это неявное «нет» чему‑то другому.
Я видел, как талантливые инженеры выгорали, потому что соглашались на всё: каждый баг, каждую новую фичу, каждую «маленькую просьбу». Их календарь заполнялся чужими приоритетами, а собственная дорожная карта превращалась в кладбище недоделанных идей.
Иногда это просто потому, что им действительно небезразличен продукт. Защищайте своё время от «было бы неплохо» так же, как защищаете продакшен от сбоев. Настоящее мастерство — [уметь расставлять приоритеты - пер.], делать правильные вещи и игнорировать неправильные.
Самые эффективные инженеры не обязательно самые быстрые или умные. Они безжалостнее в выборе того, что достойно их внимания. Они понимают: тратя время, ты расплачиваешься упущенной возможностью заняться действительно важным.
2. Если вы не можете сформулировать, какое решение вам нужно — вы не готовы к встрече.
Большинство встреч проваливаются не потому, что они не нужны, а потому что превращаются в замаскированное «проговаривание вслух». Я провёл сотни часов, слушая, как умные люди ходят вокруг проблемы, так и не назвав, что им нужно. Встреча заканчивается позитивно, но без результата и ответственного.
Я научился начинать с запроса: утвердить, выбрать, разблокировать или проинформировать.
Эти четыре слова изменили мой подход к подготовке. Если я не могу выбрать одно, значит, я не готов тратить чужое время. А когда я сам участник, я стал спрашивать в первые две минуты: «какое решение от меня требуется?» Это звучит прямо, но люди обычно испытывают облегчение — часто они сами не осознавали, что не сформулировали это.
Скрытая цена расплывчатых встреч — не только потерянное время. Это неделя расфокусировки, пока все ждут ясности, которая так и не наступает.
3. «Надо бы» — не план. «Во вторник сделаю» — план.
Разница между движением и прогрессом — в конкретике.
Команды тонут в намерениях. Я видел дорожные карты, забитые «надо улучшить онбординг», «надо снизить задержки», «надо задокументировать API». Проходят месяцы — и всё это так и пылится, вызывая лишь чувство вины. Можно подумать, что с появлением агентных ИИ это решено, но не совсем.
Переводите разговор в самое маленькое конкретное действие, которое реально можно сделать, и закрепляйте за ним человека и срок. Не «надо улучшить онбординг», а «во вторник Саша проведёт три пользовательских интервью и задокументирует основные точки трения».
Это про внимание к тому, как люди двигаются вперёд. Размытые намерения вызывают тревогу. Конкретные обязательства создают импульс. План не обязан быть идеальным — он должен быть достаточно конкретным, чтобы с него можно было начать.
4. Медленный код иногда — симптом. Медленные решения — всегда проблема.
Скорость — это про устранение трения, из‑за которого умные люди колеблются. Там, где возможно, нужно переходить к действию.
Когда проект буксует, хочется обвинить разработчиков в медлительности: люди мало работают, код плохой, не хватает инженеров. Но по моему опыту медленный код чаще всего — следствие. Болезнь — это медленные решения.
Если решения принимаются неделями или месяцами, ищите глубже. Недостаток контекста мешает оценивать компромиссы. Неясная зона ответственности заставляет всех ждать друг друга. Страх ответственности приводит к уклончивости вместо чёткого выбора.
Самая быстрая команда, с которой я работал, не состояла из лучших программистов. Она просто принимала решения за часы, а не недели: потому что полномочия были ясны, контекст — общий, а ошибка не считалась карьерным риском.
5. Надёжность — это тоже функция продукта. Относитесь к ней так же.
Пользователи редко хвалят надёжность, но всегда замечают её отсутствие.
Это создаёт опасную динамику: работа над надёжностью незаметна, пока всё работает, и поэтому ей хронически не хватает ресурсов по сравнению с новыми крутыми фичами.
Бюджеты ошибок — один из способов сделать компромисс явным. Если у сервиса SLO 99,9% доступности, у вас есть «бюджет» в 0,1% на сбои ради инноваций. Потратили его — возвращаетесь к надёжности, пока не восстановите запас. Это инструмент для честного разговора о рисках.
Команды, которые сохраняют и скорость, и надёжность, делают это не за счёт героизма. Они рассматривают надёжность как полноценную функцию продукта — со своей дорожной картой, метриками и ответственными.
Вы же не выпускаете фичу без продуктового ревью. Не выпускайте систему без обсуждения надёжности.
6. Невозможно решить проблему плохого взаимодействия между командами, просто «наладив» коммуникацию.
Режимы взаимодействия команд существуют не просто так: сотрудничество (плотная совместная работа), сервис (чёткие API и SLA) или фасилитация (одна команда помогает другой развить компетенцию).
Большинство проблем между командами — не про усилия или добрые намерения. Они про размытые границы и неясные договорённости. Я видел, как команды «улучшали коммуникацию», добавляя встречи, чаты, синки[от synchronization meetings - пер.] — и это не помогало.
Проблема не в том, что люди мало говорят. Проблема в том, что интерфейс между командами не определён. Кто за что отвечает? В чём договорённость? На что команда A может рассчитывать от команды B — и наоборот?
Сделайте осознанный выбор — и встреч станет меньше. Попытка москировать плохой интерфейс коммуникацией приведёт лишь к выгоранию самых вовлечённых людей, а проблема никуда не исчезнет.
7. Лучший способ инициировать обсуждение проблемы — предложить решения.
«Вот проблема» — это только половина работы. Раньше я думал, что моя задача — находить проблемы и доносить их до руководства. Это необходимо, но недостаточно.
«Вот два варианта, их компромиссы и моя рекомендация» — вот что помогает сдвинуться с места и заслужить доверие. Это показывает, что вы уже проделали работу мысли. Это даёт принимающим решения не абстрактную проблему, а конкретную отправную точку.
Вы упрощаете им задачу — и повышаете шанс получить нужную поддержку.
Разница между «мне нужна помощь» и «выберите между A и B, и вот почему я склоняюсь к B» — это разница между тем, кто обозначает проблему, и тем, кто её решает.
Оба видят проблему. Но доверие и автономию получает только второй.
8. Избегайте культуры спасателей. Стройте системы, которым не нужны спасатели.
Выгоревший сотрудник, после решения "срочной проблемы", который не оставил документации и является единой точкой отказа.
Если «спасение в последний момент» становится нормой, это не повод для гордости, а признак сбоя. Я видел, как команды восхищаются решением «срочных» проблем и спасением компании, игнорируя системные проблемы, которые создали инцидент и вынудили работать сверхурочно.
Когда такие люди уходят — а рано или поздно они уходят — выясняется, что больше никто не понимает, как всё устроено. Культ спасателей маскирует простую вещь: нормальный путь для обычного человека в обычный день не работает.
Сделайте нормальный путь основным. Документируйте систему. Распространяйте знания. Проектируйте под обычный вторник, а не под чрезвычайную ситуацию. Спасатели должны быть не нужны — а если они нужны, значит, нужно работать над тем, чтобы они стали не нужны.
9. Наблюдаемость — это важно.
Фича без телеметрии — это скрытый риск.
Если вы выпустили фичу и не знаете, как она ведёт себя в продакшене, вы создали неопределённость.
Я видел, как команды праздновали релизы, а через недели обнаруживали, что у 20% пользователей всё тихо ломается. Ни логов, ни метрик, ни дашбордов — только пустота там, где должно быть понимание. Исправление такого может быть болезненным — вплоть до отката и повторного запуска с нормальной наблюдаемостью.
Логи, трейсы, дашборды и алерты — это не «операционка». Это способ учиться. Это способ понять, работает ли то, что вы сделали, для реальных людей в реальных условиях.
Лучшие инженеры считают наблюдаемость частью определения «сделано». Не «я написал код», а «я написал код и вижу, как он работает».
10. Небольшие PR(Pull Request) — это забота о других. Особенно если PR сгенерирован ИИ.
Небольшие изменения проще проверять, понимать и откатывать.
Раньше я писал большие pull request'ы. Мне нравилась идея сразу показать законченную фичу. На деле я оптимизировал своё удобство за счёт времени и нервов ревьюеров. Маленькие PR почти всегда - лучшее решение.
Они быстрее попадают в продакшен, потому что не застревают в очереди на ревью, пока кто‑то ищет час, чтобы разобраться в вашем тысячестрочном диффе. Хотите, чтобы команда доверяла вашему темпу работы — делайте работу удобной для ревью.
Есть и скрытый плюс: маленькие PR заставляют мыслить шагами. Вместо одного монолита вы наращиваете функциональность постепенно. Каждый шаг получает обратную связь. Каждый можно откатить отдельно. По отдельности это медленнее, но до продакшена — быстрее.
11. Добавляя людей в команду, вы добавляете не только узлы, но и связи.
Стоимость координации растёт быстрее, чем численность.
Вот почему «давайте просто добавим людей» часто не работает и почему расширение команды в конце проекта может его только замедлить. Каждый новый человек увеличивает нагрузку на коммуникацию со всеми, с кем нужно взаимодействовать. Граф становится плотнее, а не просто больше.
Я видел, как менеджеры искренне удивлялись: команда выросла вдвое, а результат почти не изменился. Ответ всегда один — новые связи «съели» новую ёмкость. Больше людей — больше совещаний, больше обмена контекстом, больше ожидания решений, в которых теперь участвует больше сторон.
Решение не в том, чтобы перестать нанимать. А в том, чтобы осознанно сокращать связи: чёткая зона ответственности, автономные команды с минимальными зависимостями, интерфейсы, позволяющие работать параллельно, а не синхронно. Лучшие организации — не те, где больше всего людей, а те, где выше отдача на человека.
12. Миграция — это никогда не просто миграция.
Любая миграция — это переговоры между текущей системой, желаемой системой и людьми, которые не просили ни о той, ни о другой.
Я видел, как миграции, рассчитанные на квартал, растягивались на годы. Не потому, что технический план был плох, а потому что никто не учёл человеческий фактор: необходимость убедить команды поставить вашу миграцию выше своих задач, поддерживать длинный хвост неожиданных кейсов и одновременно держать в работе две системы, пока старая не сдаётся.
Технический план — самая простая часть. Сложнее всего — спроектировать сосуществование. Старое и новое будут жить параллельно дольше, чем вы думаете. Вы обнаружите, что «легаси»‑система хранит решения, которые никто не задокументировал, и процессы, которые никто не помнит, но все от них зависят. Вам понадобится стратегия внедрения, которая не требует от всех команд остановиться и переключиться разом.
Миграции, которые действительно завершаются, объединяют три вещи: вовлечённый спонсор, который не исчезает после старта; команда, для которой миграция — не побочная задача; и чёткая дата отключения старой системы, в реальность которой верят.
Без этого миграция превращается в вечное «почти готово» — а это хуже, чем не начинать вовсе, потому что вы бесконечно платите за две системы.
Если вы не готовы инвестировать в завершение, не начинайте миграцию.
13. ИИ удешевляет создание черновиков, а опыт и насмотренность становятся дорогими.
Теперь каждый может генерировать код. Порог входа в создание кода, контента, дизайна — стремительно падает. ИИ может предложить десять вариантов там, где раньше был один.
Разница теперь — в выборе: что делать, что удалить, что упростить, что не выпускать и что считать «хорошим». Насмотренность["вкус" у автора - пер.] — способность различать варианты и выбирать правильный — становится дефицитным ресурсом.
Используйте ИИ, чтобы быстро исследовать варианты, а затем жёстко применяйте собственное суждение. Преуспеют не те, кто генерирует больше всех, а те, кто лучше отбирает.
Создавать дёшево. Редактировать дорого. Выбор решает всё.
14. Доверие — это оптимизация задержек в команде.
Самое ценное, что можно построить, — не система, а доверие.
Когда вам доверяют, не нужно пять встреч, чтобы утвердить решение. Предполагается компетентность, добрые намерения и способность доводить дела до конца. То, что в среде с низким доверием занимает недели, в среде с высоким — часы.
Каждый раз, когда вы выполняете обещание, честно признаёте ошибку или облегчаете жизнь другим, вы пополняете счёт, который будет приносить дивиденды годами.
Я видел инженеров со средними техническими навыками, которые достигали огромных результатов, потому что им доверяли. И видел блестящих специалистов, которые почти ничего не добивались, потому что никто не хотел с ними работать.
Код ничего не стоит, если вы не можете найти людей, готовых продвигать его вместе с вами.
В заключение
В прошлых статьях я писал, что все эти уроки сводятся к любопытству, скромности и пониманию, что работа — это про людей. Я по‑прежнему так считаю.
Но если в этом списке советом есть сквозная идея, то вот она: работа — это про то, чтобы обычным людям было проще делать необычные вещи в обычный день. Инженерная карьера даёт достаточно времени, чтобы выучить это на собственном опыте — зачастую непростом. И за время работы в Google я сам многому научился.
Выделите фрагмент текста и используйте ⌘/CTRL + Enter для отправки сообщения об ошибке.