96 записей с тегом "engineering-management"

Tom Preston-Werner опубликовал "Readme Driven Development" в 2010-м, большинство инженерных команд прочитало, кивнуло и продолжило писать сначала код. Пятнадцать лет спустя команды в нашем датасете, которые реально практикуют RDD, дают на 22% меньше переписываний в первые 90 дней нового сервиса и онбордят новых инженеров в этот сервис в 3× быстрее, чем команды, пишущие документацию после кода. Разрыв не про качество документации. Он про то, что письмо заставляет продумать.

RDD — это рабочая практика: написать правдоподобный README того, что вы собираетесь строить, получить ревью, потом писать код. Эта статья — что меняется у команд, принимающих RDD, измеримая разница по 28 RDD-командам, которые мы трекаем, и честные лимиты, где это помогает, а где театр.

Две команды по 30 инженеров, тот же стек, примерно одинаковая сложность продукта. Команда A работает async-first: один письменный дамп вместо стендапа в день, решения в RFC-тредах, code review в течение 48 часов. Команда B sync-first: два ежедневных стендапа, архитектурный sync дважды в неделю, решения принимаются на митингах. Мы меряли coding-time и lead-time обеих команд полный квартал. У команды A 2ч 50м медианы активного кодирования в день, lead time 4.2 дня. У команды B 48 минут медианы, lead time 2.1 дня. Один выход, разные бутылочные горла. Универсально "лучше" нет ни одного.

Async-first нарратив доминировал в 2021-2023. Handbook GitLab, Shape Up Basecamp и десятки remote-работа-thinkpieces представили синхронные митинги как productivity-театр. Обратная коррекция происходит сейчас: команды, ушедшие в полный async, обнаружили, что латенси решений тоже стоит, и возвращают часть sync-работы. Microsoft New Future of Work 2023 явно отметили: команды с нулевым синхронным временем имели на 33% более длинные циклы принятия решений, при росте индивидуального фокуса. Эта статья — о трейд-оффах в цифрах.

В большинстве инженерных команд 2026 года сидят на одной зарплатной ведомости три разных типа промпт-юзеров. Есть power user с 60-строчным Cursor rules, вычитанным за полгода. Есть casual user, который копипастит «fix this bug please» и в целом рад. И есть скептик, попробовавший два раза, получивший мусор и решивший, что AI-кодинг — хайп. AI-продуктивность вашей команды стягивается к среднему этих трёх, не к вершине.

Индивидуальный prompt skill — это личный лайфхак. Командный prompt engineering — это процесс. И большинство команд пока так его не воспринимают. Распишем плейбук: что шарить, что оставлять индивидуальным, какие метрики говорят, что работает, и какие failure mode мы видели у клиентов.

Senior backend-кандидат, которого я собеседовал в марте 2026 для 40-человечного скейлапа, прислал 4-часовой take-home, очевидно сгенерированный AI за 30 секунд чтения. Не потому, что код плохой — код был слишком хорош: консистентный стиль в 14 файлах, docstring на каждой функции и подозрительно хорошо структурированный README, покрывающий edge-кейсы, которых задача не требовала. Что окончательно спалило: переменная is_applicable_within_business_context — ровно та фразировка, которую Claude 3.7 Sonnet использует, когда его просят написать «enterprise-grade» код.

Взяли другого. Через два месяца LinkedIn того же кандидата показал новую работу у конкурента, который не проверил. Не знаю, прошёл ли он бар on-the-job; индустрия рассказывает истории в обе стороны. Что точно: AI-assisted читерство стало дефолтом, а не outlier-ом, и воронки найма, спроектированные до 2024, отбирают не то. Опрос Stack Overflow 2024 обнаружил: 76% профессиональных инженеров активно используют AI-coding-tools; tooling кандидатов отстаёт от tooling разработчиков на недели, а не годы.

Директор инженерии регионального ретейлера на 400 магазинах сформулировал это чисто: «Когда мы релизим фичу, ускоряющую сайт, маркетинг аплодирует. Когда мы релизим фичу, снижающую число кликов для продавца в зале, — тишина. А потом двигаются квартальные цифры». Retail-инженерия — это дисциплина обслуживания двух популяций (покупатели и продавцы) и двух физических реальностей (склад и торговый зал) из одной кодовой базы.

Отчёт McKinsey State of Retail 2024 зафиксировал: 73% покупателей используют несколько каналов для одной покупки — листают в приложении, мерят в магазине, покупают онлайн, возвращают curbside. Каждый переход — инженерная поверхность: product-detail страница должна знать доступность в магазине, BOPIS-флоу должен атомарно зарезервировать inventory, kiosk возвратов должен его un-reserve. Исследование IHL Group 2023 задокументировало $1.75 трлн глобальных потерь ретейла из-за out-of-stock — и многие из них из-за latency inventory-сервиса или сбоев синхронизации, не из-за физического стокаута.

Fintech-команда, с которой мы работаем, отгрузила одну 400-строчную фичу четыре раза. Figma-файл обновился во вторник. Разработчик взял в среду. Дизайн переоткрыл файл в четверг утром, чтобы «уточнить spacing», и ещё раз в пятницу вечером ради «ещё одной микро-интеракции». Фича уехала в понедельник. Потом инженер два дня чинил visual regressions, пойманные PM-ом после релиза. Итого 7 инженерных дней. Чистого нового кода — 400 строк. Handoff убил больше, чем сама работа.

Разговор про «Figma → код» обычно про инструменты: Zeplin, Figma Dev Mode, Locofy, Visual Copilot. Ни один из них не чинит реальную проблему: handoff дизайн→разработка — это пробел в измерении, прячущийся в пробеле процесса. Определим метрики, которые реально предсказывают хороший handoff, как их мерить без оверхеда, и где выбор инструмента важен (иногда), а где нет (обычно).

Notion проходит невидимый порог отказа где-то в районе 300 страниц на инженерный воркспейс. До этой точки инструмент любят. После — поиск разваливается, накапливаются дубликаты, команда делится на два лагеря: тех, кто продолжает писать, и тех, кто перестал читать. Stack Overflow Developer Survey 2024 поставил Notion в топ-3 не-IDE инструментов у инженеров — и одновременно отметил его как #1 инструмент, от которого инженеры уходят в 18 месяцев, обычно именно из-за этого коллапса.

Коллапс — не вина Notion. Это проблема структуры. Вот playbook воркспейса из 7 баз, который остаётся навигируемым от 5 до 50 инженеров, и конкретные правила, которые предотвращают «проблему 300 страниц».

45-инженерная платформенная команда, с которой я работал в Q4 2025, имела 214 Slack-каналов, 82 из них активных за последние 7 дней. Средний инженер состоял в 31 канале, получал упоминания в 14 в неделю и — по нашим данным IDE heartbeat — терял 5 часов 42 минуты coding-time в неделю на Slack-триггеримых context-switch. Больше 10% рабочей недели, испарившихся до того, как кто-то вообще добрался до meeting-календаря или code review.

Slack не злодей — злодей sprawl каналов плюс сломанные нормы. Исследование Глории Марк (UC Irvine) за десятилетия называет стоимость восстановления после одного прерывания 23 минутами до возврата в полный фокус. Накладите на 14 Slack-упоминаний в неделю — и математика беспощадна. Хорошая новость: фикс не требует смены инструментов или Zen-mode-софта. Это набор явных норм, применимый в любой 10-500-инженерной организации за квартал.

Linear катит новую фичу почти каждую неделю и стал дефолтным трекером для "мы современный стартап". У Jira — 20 лет институциональной мускульной памяти, 3000+ Marketplace-апп и одинаково сильная репутация "медленной" и "настраиваемой под что угодно". Между ними сидят 200 000+ инженерных команд, делающих неверный выбор на шестизначные суммы в год.

Это сравнение уходит за поверхность feature-matrix. Оно смотрит, что ломается, когда команда переключается, какова реальная цена миграции и где дизайн-решения каждого инструмента тихо исключают его из определённых форм команд.

Series-B презентация совету в 2023 пошла под откос, когда директор — бывшая VPE GitHub — задала CTO три вопроса подряд, к которым он не был готов. Он знал deployment frequency и размер команды. Он не знал median lead time, скорость найма против плана и долю инженерного фонда от operating burn. Совет не урезал инженерку, но добавил квартальный engineering review с другим CTO на созвоне. Встреча стала экзаменом, который команда сдала, а CTO нет.

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