Шаблон инженерной культуры: документ + реальные примеры
"Freedom & Responsibility" Netflix — дек, скачанный больше 20 миллионов раз после того, как Пэтти Маккорд выложила его в 2009. Engineering principles Stripe, GitLab Handbook, Shape Up от Basecamp — публичные документы культуры, ставшие ориентирами, делят три свойства: короткие, opinionated, описывают как принимаются решения, а не что команда ценит в абстракции.
Большинство документов культуры в большинстве компаний умирают в течение года. Умирают потому, что написаны для оффсайта, распечатаны на постер и никогда больше не упоминаются, когда приходит реальный тест: конфликт между скоростью отгрузки и качеством кода в 17:30 в четверг. Пост даёт шаблон, который выживает этот момент, с тремя заполненными примерами из реальных инженерных организаций.
{/* truncate */}
Почему большинство документов культуры не работают
Опрос First Round Capital 2023 среди 250+ инженерных лидеров: 68% компаний имели письменный документ культуры, но только 19% инженеров в этих компаниях могли назвать 3 принципа из него без подглядывания. Разрыв между "он у нас есть" и "он направляет решения" огромный.
Провалы группируются в четырёх паттернах:
- Расплывчатые values. "Мы ценим excellence" — описывает 100% инженерных организаций и направляет 0% решений.
- Слишком длинный. 30-страничный документ читается один раз, на первой неделе онбординга, и забывается.
- Aspirational, не descriptive. Утверждает, что команда "ego-free и collaborative", когда на самом деле review жёсткие, решения top-down. Инженеры замечают разрыв за месяц.
- Нет правил принятия решений. Документ без "как решаем, когда X и Y конфликтуют" — постер.
Шаблон ниже отвечает на эти четыре провала напрямую.
Шаблон: 6 разделов, 3-5 страниц суммарно
1. Что мы строим и для кого
Один абзац. Для чего существует инженерная организация, кто конечный клиент, какая north-star метрика. Звучит очевидно; на удивление редкое. Без этого все последующие разделы болтаются.
2. Как мы принимаем решения
Самый важный раздел. Decision rules, а не values. Конкретные примеры:
- "Пишем спеки для всего, что отгружается >1 спринт. Меньше — чатимся."
- "Когда скорость и архитектурная чистота конфликтуют, выбираем скорость, если цена чистоты обратима. Если one-way door — выбираем чистоту."
- "Разногласия идут через
/decideв Slack: предлагающий формулирует решение, 48-часовое async-окно, default approve."
Хорошая секция decisions имеет 5-9 правил, каждое с конкретным примером. Меньше — театр; больше — никто не помнит.
3. Как мы не соглашаемся
Документ культуры без механики несогласия — неполный. Кто кого оверрайдит? Когда? Как фиксируется disagreement?
Модель "disagree and commit" Stripe — самый частый паттерн, но деталь реализации важна. Хороший вариант:
"Кто угодно может флажить 'strong disagreement' на решение. Предлагающий обязан ответить. Если не разрешено за 72 часа — ближайший EM решает и записывает рассуждение в decision log. Несогласного не ждут согласным — ждут исполнения."
4. On-call, oncall, операционные trade-offs
Инженерная культура сильнее всего проявляется в том, как команда держит production. Ваш документ должен явно формулировать:
- Кто on-call и за что
- Какой threshold для пейджера разумен в 3 ночи
- Кто ревьюит post-mortem и разрешён ли blame
- Инженер, отгрузивший поломку в prod, чинит сам или команда
Команды, пропускающие раздел, разбирают его на каждом инциденте. Неэффективно и разъедает.
5. Hiring bar
Два-три предложения. Кого нанимаем, какой bar, что дисквалифицирует. Инженерные культуры, не совпадающие со своим hiring filter, умирают быстро: либо over-hire и культура размывается, либо фильтр приводит людей, которым культура чужая.
6. Performance signals
Как выглядит "отлично", как — "не сработалось", как мы это говорим. Этот раздел чаще всего пропускают — и чаще всего к нему возвращаются инженеры. Без него performance-разговоры удивляют людей.
Культура — операционная система для решений. Эти шесть секций вместе дают boot sequence.
Заполненный пример: три реальных паттерна
Сжатые версии трёх реальных документов, которые я помогал ревьюить в 2024-2025. Анонимизировано, но структура и конкретные формулировки точные.
| Раздел | Early-stage стартап (12 инж) | Scale-up (80 инж) | Enterprise platform (300 инж) |
|---|---|---|---|
| Decision unit | Вся команда в комнате | Pod из 6-8 | Architecture council + pod |
| Порог для spec | Всё >3 дня | Всё >1 спринт | Всё, трогающее >2 команды |
| Разрешение конфликта | CTO, быстро | EM, 72ч async-окно | RFC + 2-reviewer approval |
| On-call | Кто рядом | Недельная ротация, пейджер | Follow-the-sun команда |
| Hiring bar | "Работал бы я на этого человека?" | Техника + culture add | Структурированные loops, калибровка |
| Perf review | Ежеквартально, письменно | Раз в полгода, 360 | Раз в год, calibration committee |
Три очень разные компании. У всех трёх — письменный документ культуры менее 5 страниц, публично упоминаемый внутри компании. Самый длинный — 4,2 страницы.
Типичные ошибки
| Ошибка | Почему больно | Как чинить |
|---|---|---|
| Values без decision rules | Ничего не направляет | Правила с конкретными trade-off примерами |
| Копирование документа другой компании дословно | Не подходит вашей культуре | Пишите свой; чужой читайте ради формата |
| Aspirational-формулировки, противоречащие поведению | Инженеры теряют доверие | Описывайте, что реально делаете; документ улучшается, когда поведение улучшается |
| Не ссылаться из онбординга | Новички не узнают | Документ культуры — первое чтение недели 1 |
| Не пересматривать | Документ дрейфует за 12-18 месяцев | Ревью ежеквартально, правки ежегодно |
| Пропускать on-call | Крупнейший источник трения | Должно быть явно |
| 30+ страниц | Никто не читает | Макс 5 страниц, глубина — ссылками |
Ошибка "aspirational contradicts behavior" — самая разъедающая. Документ, утверждающий "мы любим писать тесты" на кодовой базе с 20% coverage, учит инженеров игнорировать документ и в остальном тоже.
Чеклист (копируйте и используйте)
- Меньше 5 страниц
- Открывается с того, что строите и для кого
- 5-9 конкретных decision rules с примерами
- Явно описывает механику disagreement и override
- Есть раздел on-call и операционный
- Hiring bar в 2-3 предложениях
- Ясно описаны performance signals
- Ссылка из онбординга недели 1
- Ревизия ежегодная, версионирование видно
- Опубликован внутри компании (не только лидерству)
- Как минимум один инженер вне лидерства ревьюил и правил
Как понять, что документ работает
Три сигнала. Первые два наблюдаемы по поведению; третий — простой опрос.
- Время onboarding-рампы — как долго до первого PR нового инженера без уточняющих вопросов по процессу. Команды с рабочим документом культуры отчитывают 4-7 дней; без — 2-4 недели. В нашей статье про developer onboarding подробнее про замер.
- Вариативность decision-speed — сколько берёт типичное кросс-командное решение и насколько сильно это колеблется. Высокая вариативность — процесс не закодирован.
- Тест "назови 3 принципа" — ежеквартально, попросите 5 случайных инженеров назвать 3 вещи из документа без подглядывания. Таргет — 4/5 называют 3+.
Команды с PanDev Metrics видят onboarding-рампу автоматически: IDE heartbeat показывает кривую coding-time нового разработчика за первые 90 дней, и форма кривой говорит, работает ли онбординг. Документ культуры живёт слоем выше, но он driver'ит эти данные.
Когда шаблон не подходит
Два случая. Очень маленькие команды (3-8 инженеров) не нуждаются в письменном документе — у них рабочая культура быстрее любого документа, потому что вся команда в одном разговоре. Писать рано — окостенить то, что ещё должно адаптироваться. Очень крупные организации (1000+ инженеров) нуждаются в нескольких слойных документах: company-level, division-level, team-level README. 5-страничный шаблон ложится на division-level; скрутите вверх в company, вниз — в команду.
Читать дальше
- Инженерные метрики без токсичности: как трекать продуктивность
- Онбординг разработчика: как метрики показывают ramp-up
- Как вести data-driven 1:1 с разработчиками
- Внешне: GitLab Handbook — самый подробный публичный документ инженерной культуры
- Внешне: Netflix Culture — оригинальный шаблон
Острая версия: ваша инженерная культура — это то, что вы делаете, когда тяжело. Ваш документ должен описывать это поведение, а не стремиться к другому. Если между ними разрыв — закрывайте с той стороны, которую легче менять. Обычно это поведение, а не документ.