35 записей с тегом "tutorial"

Сеньорный инженер у fintech-клиента потратил 3.5 часа на runbook для процесса деплоя, который она надеялась никогда не запускать вручную. Через 8 месяцев это спасло джуна на on-call примерно 4 часа в 2 часа ночи на банковском выходном. Дока дала аккуратный возврат в 15% времени. Соседняя дока той же недели — 6-страничный архитектурный обзор системы, которую выводят из прода — по логам вики не открывалась ни разу. Та же команда, те же часы, радикально разный ROI.

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

Инженеры теряют в среднем 11.5 часов в неделю на митинги и штраф на refocus после них. Gloria Mark из UC Irvine (классическое исследование 23 минут, обновление 2023) сейчас оценивает стоимость одного прерывания для knowledge workers в 23 минуты 15 секунд. Четыре митинга в день — это буквально три дополнительных часа потерянного focus time сверх самих митингов. Google Calendar показывает 6 часов; реальная цена ближе к 9.

Это playbook того, как уполовинить нагрузку митингов в инженерной команде без потери alignment, который митинги (теоретически) давали. Async-first, не async-only — некоторые митинги всё ещё правильный инструмент, и игнорирование этого — способ, которым async-культуры сами проваливаются.

VP of Engineering сказал число, которое болит: «Мы потратили $140,000 на offsite в Бали в Q1. К Q3 никто в команде не помнил ни одного решения, которое мы там приняли». Offsite на 40 инженеров регулярно стоит $80-200K прямых расходов (перелёты, площадка, питание, активности) плюс 200-320 инженеро-недель вытесненной работы, и Gallup Workplace Report 2023 фиксирует, что только 29% компаний могут сформулировать измеримый outcome от последнего off-site.

Дефолтный фейл — не площадка и не agenda, а то, что offsite был назначен как культурный ритуал с outcomes, определёнными постфактум. Переворот порядка меняет ROI на порядок. Фреймворк ниже — то, как инженерные лидеры с повторяемо-измеримым ROI планируют offsites, и работает он через три формата, дающих измеримые результаты: hackathons, strategy sprints и team-bonding. У каждого формата своя экономика.

Исследование Microsoft Research 2024 по 31 000 календарям knowledge-workers показало: медианный инженер в software-компании на 200-500 человек сидит в 23 часах запланированных митингов в неделю. Глория Марк из UC Irvine — исследовательница, давшая нам число "23 минуты на рефокус" — говорила, что типичного knowledge-worker'а прерывают каждые 3 минуты 5 секунд, как только заканчиваются митинги и начинается Slack. Добавьте 40-минутный commute, который многие тихо вернули в 2026, — и день кода стартует в 11:00.

Большинство советов про "гигиену календаря" — либо одноразовые ("просто говори нет митингам"), либо религиозно жёсткие ("maker time Пн/Ср/Пт, всё остальное нельзя"). Ни то ни другое не выживает в реальной инженерной организации, где ваша фича зависит от design review другой команды. Это шаблон, который выживает.

Офсайт команды в календаре. Исторически trust falls и escape room'ы получают 1.8/10 на вопрос «повторил бы». Внутренние хакатоны — 8.4/10, bug bash day — 7.1/10, lunch & learn — 6.8/10. Цифры собраны за 2 года опроса 23 инженерных команд (327 инженеров в сумме) параллельно с нашим IDE-датасетом. Паттерн грубый: инженеры оценивают активности рядом со своей работой заметно выше, чем активности, специально от неё оторванные. Google Project Aristotle нашёл, что психологическая безопасность — сильнейший предиктор эффективности команды, и активности, которые её строят, не те, что HR обычно выбирает.

Эта статья — что реально коррелирует с сигналами здоровья команды (удержание, добровольная коллаборация, участие в PR-ревью), а что — только со счётом в бюджете. На выходе — шортлист и guardrails, что выкинуть.

У каждой инженерной организации был свой kudos-бот. Большинство умирают за 9 месяцев. Мета-анализ Gallup 1.2M работников (2024) нашёл специфическую вещь для технических ролей: peer recognition даёт в 2.7× больше engagement, чем похвала менеджера, но только если признание отвечает трём критериям — конкретное поведение, публичная видимость, своевременность. Средняя команда /kudos в Slack не выполняет ни одного.

Это playbook peer-recognition системы, которая реально переживает первый год. Работает для команд 10–200, стоит меньше $50 на инженера в год и — вопреки большинству vendor-деков — не имеет отношения к баллам и бейджам.

Два senior-инженера в 60-человеческой SaaS, которую я менторил, перестали разговаривать на семь недель. По их версиям, причина — «несовместимость характеров». По данным: инженер A мёржил без ревью в сервис инженера B 23 раза за 8 недель; очередь ревью инженера B выросла с 4 PR до 31 за то же окно. У каждого была легитимная обида, которую не получалось чисто сформулировать. В момент, когда EM положил оба числа на слайд, драка закончилась — не потому, что кто-то выиграл, а потому что спор перестал быть про характер другого человека.

Большинство конфликтов в инженерных командах — не про личности. Это пробелы в процессах, рассинхрон приоритетов и неравенство нагрузки, которых люди не видят изнутри конфликта. Исследование Harvard Business Review 2022 по командной дисфункции назвало «неоднозначность, кто за что отвечает» драйвером №1 межличностных конфликтов в knowledge-work-командах. Решение — не лучшие чувства, а общая картина реальности. Данные — как её строить.

"Freedom & Responsibility" Netflix — дек, скачанный больше 20 миллионов раз после того, как Пэтти Маккорд выложила его в 2009. Engineering principles Stripe, GitLab Handbook, Shape Up от Basecamp — публичные документы культуры, ставшие ориентирами, делят три свойства: короткие, opinionated, описывают как принимаются решения, а не что команда ценит в абстракции.

Большинство документов культуры в большинстве компаний умирают в течение года. Умирают потому, что написаны для оффсайта, распечатаны на постер и никогда больше не упоминаются, когда приходит реальный тест: конфликт между скоростью отгрузки и качеством кода в 17:30 в четверг. Пост даёт шаблон, который выживает этот момент, с тремя заполненными примерами из реальных инженерных организаций.

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

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

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

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