Инженерная культура и эффективное взаимодействие между разработчиками и менеджерами продуктов (PM) — вечные темы для дискуссий в IT-индустрии. Камиль Фурнье, легендарный CTO Rent The Runway и автор культовой книги «The Manager’s Path» («Путь менеджера»), в беседе с Ленни Рачицким разбирает «болевые точки» в отношениях между инженерами и бизнесом, объясняет ловушки масштабных переписываний кода и делится принципами построения платформных команд.
🤬 Что больше всего раздражает инженеров в работе с PM 0:00
Отношения между инженерами и менеджерами продуктов часто напоминают «игру в сломанный телефон». По мнению Камиль Фурнье, существуют четыре критических фактора, которые вызывают наибольшее раздражение у технических специалистов:
- Присвоение всех заслуг (Hoarding credit). PM часто становится «лицом» проекта перед руководством и клиентами . Если менеджер не упоминает вклад инженеров, у команды возникает ощущение, что их тяжелый труд остался незамеченным, а успех присвоен одним человеком .
- Игнорирование деталей. Инженерное дело — это работа с деталями. Когда менеджер ведет себя так, будто технические нюансы не имеют значения («Просто скажи, когда будет готово!»), это демонстрирует отсутствие эмпатии к сложности процесса . Камиль считает, что PM не обязан знать всё досконально, но обязан уважать глубину работы инженера .
- Роль посредника или «испорченный телефон». Раздражение вызывают ситуации, когда PM пытается быть единственным каналом связи, не понимая технической сути вопросов . Если менеджер постоянно отвечает: «Я уточню и вернусь», вместо того чтобы соединить специалистов напрямую, это тратит общее время .
- Монополия на идеи. Когда PM считает, что только он должен придумывать функции, инженеры теряют творческий интерес к продукту и начинают искать выход своей креативности в «овер-инжиниринге» — бесконечном выборе фреймворков и переписывании систем .
Камиль утверждает, что лучшие менеджеры — те, кто говорит меньше всех на презентациях и дает слово инженерам .
🏗️ Ловушка «большого переписывания»: почему rewrites — это опасно 14:43
Желание инженеров переписать старую систему с нуля («legacy просто ужасен») — одна из самых частых причин конфликтов с бизнесом. Фурнье настроена к масштабным переписываниям скептически .
Её основные аргументы против тотального обновления систем:
- Недооценка сложности миграции. Инженеры «катастрофически» ошибаются в прогнозах времени, необходимого для переноса старых данных и пользователей в новую систему .
- Скрытая бизнес-логика. Старые системы часто не документированы, и в их коде зашиты тысячи условий, о которых все забыли. При переписывании эти правила теряются, что ведет к багам .
- Стоимость простоя. Редко какой бизнес может позволить себе заморозить выпуск новых функций на полгода или год ради «чистоты кода» .
Вместо радикального сноса Камиль рекомендует «эволюционный путь»: выделение конкретных проблемных узлов (например, рекомендательного движка) и их постепенный апгрейд через API, сохраняя остальную систему стабильной .
📈 Путь в менеджмент: когда инженеру пора менять роль 20:58
Один из самых спорных советов Камиль Фурнье касается времени перехода из индивидуальных контрибьюторов (IC) в руководители. По её мнению, инженеру стоит ждать около 10 лет (включая обучение и интенсивную практику), прежде чем становиться менеджером .
Это необходимо для достижения истинного «мастерства на уровне костей» . Если этот фундамент заложен, даже спустя годы работы руководителем, человек сможет быстро вернуть техническую форму. Фурнье полагает, что слишком ранний переход в менеджмент лишает специалиста уверенности и авторитета в глазах подчиненных .
Для тех, кто уже стал руководителем, Камиль дает рекомендации, как оставаться «технически релевантным»:
- Не пытайтесь диктовать, какую библиотеку выбрать, если не писали код два года — это раздражает .
- Задавайте «правильные вопросы»: как система будет масштабироваться? Какие основные риски при реализации?
- Сохраняйте любопытство. Камиль сама признается, что до сих пор интересуется новинками в области баз данных и инфраструктуры, хотя давно не программирует фултайм .
🛡️ Секреты создания платформных команд (Platform Engineering) 54:11
Новая книга Камиль посвящена Platform Engineering — дисциплине создания внутренних инструментов, которые ускоряют работу всей компании.
Ключевые идеи Фурнье об эффективных платформах:
- Платформа — это продукт. К ней нужно относиться так же, как к внешнему приложению: заниматься поиском проблем пользователей (инженеров), собирать отзывы и измерять ROI .
- Нужны PM для внутренних инструментов. Камиль настаивает на найме продакт-менеджеров в платформные команды, иначе инженеры будут строить «что-то крутое, но бесполезное» .
- Состав команды. В платформе должны быть не только SRE (инженеры по надежности), но и полноценные разработчики ПО, способные строить сложные архитектурные решения .
Она также отмечает, что создавать такую команду стоит только тогда, когда в компании больше 50 инженеров . До этого момента централизация часто порождает лишнюю бюрократию. Главная метрика успеха здесь — сокращение времени цикла (cycle time) разработки для остальных продуктовых команд .
🧘 Культура работы без выгорания: фокус и делегирование 45:26
Фурнье не верит в продуктивность 60-часовых рабочих недель. По её мнению, переработка — это способ избежать сложной задачи определения того, что действительно важно .
Её советы по управлению временем:
- Аудит времени. Нужно регулярно проверять, на что уходят часы, и беспощадно вычеркивать задачи, не приносящие ценности .
- Делегирование как инструмент роста. Руководители часто боятся делегировать, считая, что сделают быстрее сами. Но без передачи ответственности команда не растет, а лидер становится «бутылочным горлышком» .
- Жесткие границы. Камиль практиковала глубокую фокусировку в рабочие часы (без соцсетей и лишних кофе-брейков), чтобы заканчивать работу вовремя и не брать её на выходные .
В завершение беседы Камиль упомянула свои ритуалы продуктивности, среди которых кофеин (чай и диетическая кола) и музыка без слов (например, Four Tet или Andre 3000), помогающая войти в состояние потока .
