Культура уважения к инженерному труду
Миграции и оценка объёма данных — Пакетная работа, Основы БД. Проверка на стенде — SQL для тестировщика. Карта — о разделе.
Уважайте программистов
Эта статья — про то, почему уважение к инженерному труду — условие предсказуемой поставки — меньше скрытого техдолга, меньше героизма в проде, меньше текучки. Здесь разберём типичные мифы ("сидит — значит отдыхает"), разрушительные фразы и практики, которые зрелые команды встраивают в процесс — focus time, blameless postmortem, ADR.
Если вы руководитель или аналитик — материал поможет не давить метриками "активности". Если вы разработчик — даст аргументы для спокойного разговора о сроках и качестве, без конфликта.
Уважение
Уважение к профессионалу — это про признание сложности и ценности его труда в объективных, измеримых категориях. В программировании уважение — это инженерная необходимость. Пренебрежение, стереотипы и когнитивные искажения ведут к демотивации и структурному ухудшению качества программного обеспечения, росту технического долга, увеличению времени вывода продукта на рынок и даже к системным сбоям.
Я работал не только в IT, и знаю, как работают множество других отраслей - строительство, архитектура, юриспруденция, государственная служба, военная служба, суды, университеты, и даже медицина - и скажу, что везде есть одна главная проблема - перекладывание ответственности. Руководству нужно всегда знать, с кого спрашивать - это важный элемент управления, но он не очень хорошо реализуется на практике, потому что все это знают и перекладывают ответственность друг на друга. В IT это раскрывается по-особому для программистов - ведь работают на самом близком к оборудованию уровню, поэтому все беды бросают на них, как и на медсестер, преподавателей, или любых других младших сотрудников.
Думаете, почему некоторые сеньоры могут становиться инфантильными, грубыми и холодными? Из-за многих лет плохого отношения к себе, это профдеформация. Если разработчик будет развиваться в комфортных условиях, он останется дружелюбным, добрым и отзывчивым. Может быть, даже счастливым.
Сложность программного обеспечения — экспоненциальная. Добавление одной функции в плохо спроектированную систему может увеличить сложность на 10 %, а в хорошо спроектированную — на 0,1 %. Эта разница определяется глубиной понимания домена, архитектурных принципов и контекста технического наследия. И это понимание формируется годами. Оно не поддаётся измерению в человеко-часах, строках кода или статусах в Jira.
Уважение начинается с отказа от поверхностных метрик и признания того, что внешняя активность не коррелирует с интеллектуальной продуктивностью. Как писал Г. Харди:
"Лучшие идеи приходят не в момент напряжённой концентрации, а в паузах — при прогулке, во сне, при чтении чужой работы. Умственный труд не подчиняется ритму конвейера".
1. Когнитивный разрыв
Большинство людей, включая руководителей, формируют понятие "усердной работы" на основе наблюдаемой физической активности. Строитель копает — видно. Грузчик грузит — видно. Программист сидит — "ничего не делает". Это — когнитивный диссонанс, вызванный неспособностью воспринимать когнитивную нагрузку как реальную работу.
Даже в рамках одного проекта это приводит к парадоксальным выводам. Рассмотрим классический кейс:
- Команда А постоянно "тушит пожары" — система падает, откаты, дебаг в production, совещания у монитора, ночные смены.
- Команда Б работает в спокойном режиме — изменения вносятся, тесты проходят, инцидентов мало, рабочий день заканчивается вовремя.
С точки зрения внешнего наблюдателя, Команда А — "работает", Команда Б — "расслабилась". На деле же первая — управляет последствиями технического долга, а вторая — поддерживает устойчивость и предсказуемость. Первичная оценка по "напряжённости" приводит к обратному эффекту: поощряются симптомы системной несостоятельности.
Это прямая причина появления методологий вроде Agile, XP, TDD. Они возникли как реакция на хроническое недоверие со стороны менеджмента, выражавшееся в:
- игнорировании времени на анализ и проектирование,
- отрицании необходимости документирования,
- требовании срочной реализации без учёта последствий,
- оценке задач исключительно по "логике UI" ("это же кнопка — две строчки, зачем день?").
Agile, в частности, пытается внедрить прозрачность не через контроль, а через совместное понимание рисков и неопределённости. Scrum-ритуалы — для создания пространства, где можно честно говорить о том, что "мы не знаем, как это сделать, и нам нужно время, чтобы выяснить".
2. Мифы и их технические последствия
Ниже приведены распространённые представления, их происхождение и конкретные технические издержки, к которым они ведут.
2.1. "Написание кода — это основная работа; отладка — побочный эффект"
Это представление лежит в основе всех нереалистичных оценок сроков. На практике, в зрелых проектах (свыше 50 тыс. строк кода), время, затрачиваемое на понимание, анализ и отладку, превышает время непосредственного написания в 3–7 раз.
Причина — в природе сложных систем:
- Состояние системы неявно — данные распределены по памяти, БД, кэшам, внешним API.
- Поведение зависит от окружения — ОС, сетевые задержки, конкурентный доступ.
- Легаси-код часто лишён документации, типизации, тестов — его нужно реконструировать, прежде чем изменить.
Игнорирование этого ведёт к:
- хроническому невыполнению сроков (сначала оценивают 2 дня, потом "тянут" неделю, затем "доделывают в выходные"),
- росту количества инцидентов в production,
- переходу на "героический режим", когда один разработчик месяц правит ошибки, допущенные при спешке.
2.2. "Если он сидит и смотрит в экран — он отдыхает"
Это классическая ошибка, основанная на путанице вычислительной работы и мышечной активности. В программировании значительная часть труда — ментальное моделирование:
- построение в уме дерева вызовов функций,
- предсказание побочных эффектов изменения,
- сопоставление доменной логики и архитектурных ограничений,
- отладка "в голове" по логам и стектрейсам.
Нейровизуализационные исследования (например, работы из лаборатории MIT CSAIL, 2019) показывают: при решении алгоритмической задачи без ввода кода активность префронтальной коры и теменных долей сравнима с активностью при написании кода, а в фазах глубокого погружения — даже выше. Молчаливое созерцание экрана может быть вершиной когнитивной нагрузки.
Отвлекать в этот момент — всё равно что выдергивать из-под пресса деталь, пока идёт штамповка.
2.3. "Хороший программист не ошибается"
Это один из самых разрушительных мифов. Он подавляет культуру безопасной разработки.
Ошибка — неотъемлемый элемент процесса познания сложной системы. Современные практики — TDD, code review, статический анализ, feature flags — построены не на иллюзии "идеального кода", а на принятии ошибки как данного и построении инфраструктуры для её раннего обнаружения и безболезненного исправления.
Критика за ошибки → страх коммитов → откладывание изменений → рост размера PR → рост риска конфликтов и регрессий → ещё больше ошибок.
2.4. "Всё уже написано, нужно только скопировать"
Это заблуждение связано с непониманием стоимости интеграции и адаптации.
Да, современное ПО на 70–90 % состоит из внешних зависимостей — фреймворков, библиотек, SDK. Но:
- выбор библиотеки — это архитектурное решение (лицензии, совместимость версий, активность поддержки, безопасность),
- интеграция — это проектирование адаптеров, обработка граничных случаев (edge cases), маппинг типов, обработка ошибок,
- обновление — это риск — новые версии ломают обратную совместимость, вносят уязвимости, конфликтуют с другими зависимостями.
"Скопировал с Stack Overflow" — это отсрочка оплаты технического долга. Иногда оправданная, но всегда осознанная.
2.5. "Программист = хакер = админ = техподдержка"
Это конфлатирование ролей, свойственное неспециалистам. В профессиональной среде эти роли имеют:
- разные области компетенции (прикладная разработка ↔ безопасность ↔ эксплуатация),
- разные инструменты и метрики успеха,
- разные когнитивные модели (например, разработчик думает в терминах состояния программы, админ — в терминах состояния среды).
Попросить бэкендера "починить Wi-Fi" — всё равно что попросить кардиохирурга отремонтировать вентиляцию в операционной — оба работают в больнице, но у них разные лицензии, разные модели ответственности и разный риск при вмешательстве.
3. Истоки давления
Давление на программистов — не про "злых боссов". Оно структурно. Его источники:
3.1. Отсутствие обратной связи в реальном времени
Физический труд даёт немедленный результат: кирпич уложен — стена выше. В ПО:
- эффект от рефакторинга виден через месяцы (меньше багов, быстрее фичи),
- технический долг накапливается незаметно, пока не "лопнет",
- качество архитектуры не измеряется в KPI.
Поэтому инвестиции в "невидимую" работу (анализ, тестирование, документирование) кажутся "роскошью".
3.2. Принцип "клиент всегда прав" как замена договорённостям
Каждое изменение вне ТЗ — не просто "дополнительная задача". Оно:
- нарушает баланс ресурсов,
- подрывает предсказуемость,
- создаёт юридический и технический риск ("мы сами ломаем контракт, вы сами чините").
Это отсутствие процесса управления изменениями — одного из базовых элементов любого зрелого IT-процесса (ISO/IEC 12207, CMMI, ITIL в рамках ITSM).
3.3. Конфузия между "быстро" и "быстро сейчас"
Менеджмент часто требует "быстро сейчас", не понимая, что:
- "быстро сейчас" = "медленно потом",
- "медленно сейчас" = "быстро потом".
Рефакторинг, тесты, CI/CD — это ускорение в долгосрочной перспективе. Отказ от них — ссуда под высокие проценты.
4. Фразы, разрушающие инженерную культуру
Некоторые обращения к программистам воспринимаются как бытовая грубость — но их опасность глубже. Они сигнализируют о фундаментальном непонимании природы разработки ПО и, будучи повторяемыми регулярно, трансформируют организационную среду в технически неустойчивую.
Разберём ключевые категории.
4.1. Фразы, отрицающие неопределённость
"Долго ещё?"
"Когда задача будет завершена?"
"Он справился за час, значит, и ты можешь"
Эти вопросы исходят из предположения, что программирование — это детерминированный, повторяемый процесс, как сборка мебели по инструкции. Но разработка — это исследовательская деятельность. Даже в рамках одного кодбейза:
- одна и та же задача (например, "добавить поле в форму") может занять от 15 минут до двух недель — в зависимости от того, где это поле должно сохраняться, как валидироваться, как логгироваться, как влиять на API-контракты, отчёты, интеграции.
- время на решение обратно пропорционально предсказуемости окружения: легаси-система без тестов — зона высокой неопределённости.
Требование точных сроков в таких условиях — имитация контроля. Оно заставляет разработчика:
- либо давать заведомо оптимистичные оценки (с последующим срывом и выгоранием),
- либо "накидывать запас" (что снижает доверие к оценкам в будущем),
- либо фокусироваться на быстром решении — даже если оно породит регрессию.
Техническое следствие: рост количества "быстрых фиксов", которые через 3–6 месяцев требуют полного переписывания модуля. Организации с хронической практикой подобных вопросов неизбежно накапливают технический долг экспоненциально.
4.2. Фразы, отменяющие разделение труда
"У меня принтер сломался — почини"
"Слушай, а не глянешь, у меня тут телефон глючит?"
"Ты же всё равно за компьютером сидишь"
Эти просьбы кажутся безобидными, но их совокупный эффект значим:
- они размывают границы профессиональной ответственности,
- они нормализуют представление о техническом специалисте как о "универсальном солдате",
- они создают эффект переключения контекста, который в интеллектуальном труде имеет высокую стоимость.
Исследования (например, работы Gloria Mark, UC Irvine, 2008–2015) показывают: после прерывания разработчику требуется в среднем 23 минуты, чтобы вернуться к прежнему уровню концентрации. При этом 41 % прерываний носят "внезапный, непланируемый" характер — как раз те самые "глянь, пожалуйста".
Когда "глубокая работа" становится невозможной, остаётся только поверхностная — копипаста, минимальные изменения, избегание сложных задач. Это не лень — это адаптация к среде, где глубина вознаграждается меньше, чем видимость.
4.3. Фразы, заменяющие анализ — обвинением
"Кто это писал?" (в смысле "какой идиот")
"Ничего не работает!" (без логов и шагов воспроизведения)
"Эта задачка под силу даже студенту"
Такие фразы нельзя использовать в здоровой команде — даже в шутку. Это разрушение психологической безопасности, без которой невозможно:
- честное признание ошибок,
- предложение радикальных улучшений,
- передача знаний.
Когда в коде появляется комментарий вроде "here be dragons" или "sorry", это крик о боли: система настолько хрупка, что даже автор боится в неё лезть. Обвинять этого автора — значит гарантировать, что следующий разработчик будет скрывать сложность, а не документировать её.
Критика кода без анализа контекста его создания (сроки, требования, состояние инфраструктуры на момент написания) — это всё равно что осуждать архитектора за то, что дом, построенный в 1950-м по нормам того времени, не выдерживает современных сейсмических нагрузок. Технический долг — это не порок, это исторический артефакт.
4.4. Фразы, отрицающие ценность инфраструктуры
"Никакого рефакторинга, продукт нужен сегодня"
"Да ты же просто скопировал"
"Это и нейронка сделает"
Здесь проявляется путаница между продуктом и способностью продукта развиваться.
Рефакторинг — не "украшение кода". Это инвестиция в производительность команды. Исследования McKinsey (2021) и Google (в рамках проекта Project Aristotle) показывают — команды, регулярно занимающиеся техническим обслуживанием (тесты, чистка зависимостей, обновление инструментов), достигают в 2,4 раза более высокой скорости доставки новых функций через 12 месяцев — по сравнению с командами, фокусирующимися только на фичах.
"Просто скопировал" — это заблуждение о природе инженерного труда. Копирование — лишь первый шаг. Интеграция — это:
- проверка лицензий (GPL vs MIT),
- согласование версий (например,
lodash@4.17.21может вызвать конфликт сwebpack@5), - адаптация под контекст (глобальные переменные, side effects, контекст исполнения),
- покрытие тестами (чтобы копипаста не стала точкой отказа).
Что до "нейронок": современные генеративные модели (Copilot, CodeLlama) — это ускоритель рутинных операций. Но:
- они не понимают домена,
- не могут оценить архитектурные последствия,
- генерируют код с известной частотой ошибок (в среднем 26 % сгенерированных сниппетов содержат уязвимости, согласно исследованию NYU, 2023).
Их эффективное применение требует высокой компетентности оператора — иначе они становятся инструментом массового внедрения технического долга.
5. Мифы, мешающие профессиональному росту
Далее рассмотрим распространённые представления, которые не просто неверны, но блокируют развитие и кросс-функциональное понимание.
5.1. "Программист обязан отлично знать математику"
Это — наследие первых десятилетий вычислительной техники, когда программирование было уделом учёных-математиков. Современная разработка расщепилась на домены:
- в численных методах, ML, криптографии, компиляторах, игровых физических движках — математика (линейная алгебра, теория вероятностей, дискретка) действительно критична;
- в веб-разработке, мобильной разработке, BPM, интеграциях, devops — ключевые компетенции — это:
- понимание протоколов (HTTP, gRPC, AMQP),
- работа с состоянием (сессии, кэши, транзакции),
- управление зависимостями и жизненным циклом,
- знание ограничений платформ (браузер, ОС, облако),
- умение декомпозировать бизнес-процессы.
Требовать от frontend-разработчика знания теоремы Байеса — так же нелепо, как требовать от Данные scientist умения писать WASM-модули без просадок производительности.
Более того — избыточный упор на "математику как меру интеллекта" отталкивает талантливых людей, чьи сильные стороны — в системном мышлении, коммуникации, эмпатии к пользователю. А это — ключевые качества для архитекторов, техлидов и product-инженеров.
5.2. "HTML/CSS/SQL — это программирование"
Здесь проблема в недоразличении уровней абстракции и типов вычислений.
- HTML — язык разметки (declarative markup), не имеет переменных, циклов, условий, логики выполнения.
- CSS — язык описания представления; его "программирование" ограничено каскадом, специфичностью, медиавыражениями (что ближе к правилам вывода, чем к алгоритмам).
- SQL — декларативный язык запросов (DSL); он описывает что, а не как. Планировщик СУБД решает, как выполнить запрос.
Это не "меньше программирования" — это другой вид инженерии:
- вёрстка — это прикладная типографика и графический дизайн в интерактивной среде,
- SQL — это проектирование реляционных моделей и оптимизация доступа к данным.
Путать их с императивным программированием (где разработчик управляет потоком выполнения) — значит не понимать, какие когнитивные ресурсы и навыки требуются на каждом уровне стека. Это ведёт к недооценке фронтендеров ("они же стили правят") и бэкендеров-датаинженеров ("они же один SELECT пишут").
Кстати — фронтендеры сегодня работают с конечными автоматами, реактивными потоками, виртуальными DOM-деревьями, SSR/ISR-стратегиями — это полноценная прикладная computer science. "Перекрасить кнопочку" может означать:
- изменить темизацию в Проектирование Tokens,
- пересобрать CSS-in-JS бандл,
- обновить accessibility-атрибуты,
- протестировать на 12 device profiles.
Если после этого интерфейс "повесил" браузер — дело в том, что команда не выделила времени на performance audit.
5.3. "Python — змея, Java — жаба" и прочие языковые насмешки
Это кажется безобидным, но на деле — проявление культурной небрежности. Языки программирования — это экосистемы с историей, философией и компромиссами:
- Python построен на принципе "читаемость превыше всего" (The Zen of Python),
- Java — на "write once, run anywhere" и строгой типизации,
- JavaScript — на event loop и асинхронности в single-threaded среде.
Осмеяние названий — это отказ признавать осознанный выбор. Когда продакшен-система работает на Java 8 с legacy JAXB, переход на Python не "проще" — он требует перестройки всей инфраструктуры — логгирования, мониторинга, CI/CD, деплоя, управления памятью. Язык — это не синтаксис, это контракт с окружением.
6. Программист как человек
Здесь важно отойти от романтизации ("гений в подвале") и демонизации ("ленивый офисный планктон"). Рассмотрим программиста как когнитивного работника со специфической физиологией труда.
6.1. Циклы внимания и "невидимая" работа
Как показывают нейропсихологические исследования (например, работы Barbara Oakley, A Mind for Numbers), интеллектуальная работа требует чередования двух режимов:
- фокусированный (решение известной задачи по известному алгоритму),
- диффузный (поиск новых связей, инсайтов — происходит при отдыхе, ходьбе, сне).
Программист, который "целый день сидит и ничего не коммитит", может быть в фазе диффузного мышления: его мозг ищет оптимальную структуру решения. Прерывание в этот момент не просто мешает — уничтожает результат 40–60 минут предшествующей фокусировки.
Отсюда — важность:
- блокированного времени (no-meeting days, focus hours),
- права на "непродуктивный" внешний вид (чтение статьи, прогулка, просто сидение с закрытыми глазами),
- асинхронной коммуникации как нормы (Slack → почта / документация / issue tracker).
6.2. Ошибки — норма процесса
В 1972 году Эдсгер Дейкстра написал:
"Отладка кода вдвое сложнее, чем его написание. Следовательно, если вы пишете код настолько умно, насколько можете, вы, по определению, недостаточно умны, чтобы его отладить".
Это не призыв к примитивности — это призыв к умеренности сложности. Хороший код:
- не тот, который демонстрирует гениальность автора,
- а тот, который позволяет следующему разработчику — менее опытному, уставшему, новичку — понять его за разумное время.
Культура, в которой боятся ошибаться, производит:
- монолиты ("если не трогать — не сломается"),
- отсутствие тестов ("не напишем — не будет провалов"),
- сокрытие проблем до катастрофы.
Уважение — это создание условий, где ошибку можно назвать до того, как она стала инцидентом.
6.3. Телесность программиста
Стереотип "худого очкарика" — артефакт 1980–90-х. Современный программист — это:
- инженер, который может стоять 4 часа у серверной стойки,
- человек, который тратит 600–900 ккал в день на когнитивную активность (равно 8–10 км ходьбы),
- профессионал, для которого эргономика — профилактика профессиональных заболеваний (RSI, туннельный синдром, хронические боли в шее и пояснице).
Совет "встань, прогуляйся" — хорош, если он следует через 90 минут фокуса и предлагается как часть ритуала. Но если он звучит как упрёк ("ты же сидишь, оторвись") — это отрицание физиологических законов внимания.
7. Программист в команде
7.1. Опытный → начинающий
Одна из самых частых ошибок в технических командах — это когда старший разработчик, столкнувшись с вопросом новичка ("а почему тут так?"), отвечает:
"Потому что иначе не работает"
или
"Это очевидно".
Это не злоба — это потеря доступа к собственному состоянию незнания. Человеческий мозг, освоив сложную модель, подавляет воспоминания о том, как она усваивалась (феномен curse of knowledge, описанный в Made to Stick, Heath & Heath).
Но для начинающего разработчика отсутствие объяснения — не просто "неудобство". Это:
- блокировка самостоятельного принятия решений (он будет бояться менять даже очевидные вещи),
- накопление скрытого технического долга (он внесёт "очевидное" изменение, не зная о побочных эффектах),
- ускоренное выгорание (постоянное ощущение, что "все, кроме меня, всё понимают").
Уважение здесь — в инвестиции времени в реконструкцию контекста. Это означает не "объяснить за 30 секунд", а:
- вместе пройти по истории коммитов (почему решение менялось),
- показать логи инцидентов, вызвавших текущую архитектуру,
- проговорить trade-offs: "мы выбрали X, потому что в 2021 году Y было дороже/недоступно/нестабильно; сегодня это, возможно, неверно".
Это — техническая документация в действии. Без неё знание умирает вместе с человеком.
7.2. Стоимость молчания
В среде, где "быть умным" = "всё знать", начинающий разработчик предпочитает:
- искать решение в Stack Overflow 6 часов,
- копировать фрагмент без понимания,
- внедрить фикс, который "локально работает", но ломает интеграцию.
В исследовании Google Project Aristotle (2016) психологическая безопасность оказалась главным предиктором эффективности команды — выше, чем IQ, опыт или инструменты.
Признаки отсутствия психологической безопасности:
- на митингах обсуждения решений инициирует только один человек (обычно tech lead),
- в ревью кода комментарии носят форму "исправь", а не "почему выбран этот подход?",
- ошибки называются "провалами", а не "данными для улучшения".
Уважение — это создание каналов для безопасного выражения незнания:
- регулярные сессии "любой вопрос уместен" (no stupid questions),
- анонимный сбор обратной связи по техническим решениям,
- ритуал "пять почему" при каждом инциденте — без указания имён, только про систему.
7.3. Стоимость ухода
Многие организации считают знания разработчика личным активом. Это ошибка. Знания — это системный актив, и их концентрация в одном человеке — это точка отказа.
Когда уходит разработчик, который 5 лет поддерживал модуль:
- время на передачу знаний ≈ 30–50 % от его годовой зарплаты,
- время на стабилизацию после ухода — 3–6 месяцев,
- количество регрессий в его модуле растёт в 4–7 раз (данные DORA, 2022).
Уважение — это проактивная децентрализация знания:
- обязательный pair programming при внесении сложных изменений,
- документирование решений, а не только результата (ADR — Architecture Decision Records),
- ротация владения модулями ("мы все отвечаем, но сейчас в ротации ведёт Y").
Это распределение отказоустойчивости.
8. Уважение как инженерная практика
Уважение невозможно поддерживать только через тренинги и ценности на сайте. Оно должно быть встроено в процессы и инструменты. Ниже — проверенные практики, имеющие измеримый эффект.
8.1. Инженерные грейды
В зрелых организациях (Google, Spotify, JetBrains) грейды описывают области ответственности и масштаб влияния, а не "степень подчинения". Пример:
- Junior — решает задачи в рамках известного контекста, под наставничеством.
- Mid — самостоятельно проектирует компоненты, учитывает побочные эффекты, участвует в ревью.
- Senior — проектирует подсистемы, выявляет технический долг, участвует в дорожной карте (roadmap) продукта.
- Staff/Principal — решает кросс-командные проблемы, формирует стратегию технического развития, защищает инженерные решения на уровне бизнеса.
Важно:
- переход между уровнями оценивается по демонстрируемым артефактам (документы, архитектурные решения, улучшения в метриках),
- повышение не сопровождается переходом в менеджмент ("управленческая" и "техническая" карьерные лестницы разделены),
- компенсация на старших технических позициях сопоставима с VP Engineering.
Это уважение к профессионализму как самостоятельной ценности, а не как ступени к "настоящей" роли.
8.2. Время для глубокой работы
Как показывают данные Basecamp и RescueTime, в среднем разработчик получает 2–3 часа непрерывного времени в день. Остальное — митинги, Slack, email, переключения.
Уважение — это институционализация focus time:
- No-Meeting Wednesdays (или два дня в неделю),
- асинхронный статус по умолчанию ("не в офисе — значит, в фокусе", а не "прогуливает"),
- ограничение на срочные задачи (не более 10 % от capacity в спринте),
- инструменты для "не сейчас" — например, в Notion — шаблон "Поставь задачу, но не жди ответа до X".
Это повышение quality-adjusted throughput — количества рабочих фич на единицу времени с учётом багов и регрессий.
8.3. Blameless postmortems
После инцидента зрелая команда проводит разбор по принципу:
"Какие условия, процессы и инструменты позволили человеку принять это решение?"
— а не
"Кто нажал не ту кнопку?"
Это даёт:
- выявление системных дыр (например, "нет чек-листа для деплоя в prod"),
- снижение страха перед экспериментами,
- накопление базы знаний по отказоустойчивости.
Документ postmortem — техническая спецификация на устойчивость.
8.4. Technical enablement
Многие компании считают "техническое обслуживание" фоновой активностью. Зрелые — выделяют dedicated capacity (15–30 % от спринта) на:
- рефакторинг критических модулей,
- обновление зависимостей (особенно с уязвимостями),
- улучшение CI/CD (сокращение времени сборки, повышение покрытия),
- обучение (не "курсы", а "время на чтение RFC, эксперименты в песочнице").
Это — технический R&D. Его отсутствие — как отказ от НИОКР в производственной компании.
9. Как измерить уважение?
Уважение можно измерить объективно. Ниже — метрики, которые коррелируют с инженерной устойчивостью и вовлечённостью.
| Метрика | Что показывает | Целевое значение (benchmark) |
|---|---|---|
| Lead time for changes (DORA) | Время от коммита до продакшена | ≤ 1 день (Elite), ≤ 1 неделя (High) |
| Change failure rate (DORA) | Доля деплоев, требующих hotfix | ≤ 15 % (Elite) |
| Mean time to recovery (MTTR) | Время восстановления после инцидента | ≤ 1 час (Elite) |
| % времени на рефакторинг/долг | В спринте или квартале | ≥ 15 % (минимум), ≥ 25 % (зрелые команды) |
| Psychological Safety Index | По анонимному опросу: "Могу ли я признать ошибку без последствий?" | ≥ 4.5 / 5 |
| Internal Mobility Rate | Доля инженеров, сменивших модуль/проект за год | ≥ 30 % (предотвращает застои знания) |
| Code Review Depth | Среднее число содержательных комментариев на PR | ≥ 3 ("почему выбран алгоритм X?") |
Если эти метрики растут — уважение становится инфраструктурой.
Если они падают — даже самые красивые ценности — декорация.
Практика — как сказать иначе
| Не стоит | Почему больно | Лучше |
|---|---|---|
| "Долго ещё?" | Давит без контекста неопределённости | "Что блокирует? Нужна помощь с X?" |
| "Ты же за компьютером — почини принтер" | Размывает роль, рвёт фокус | "Это к ИТ-поддержке; я в задаче PROJ-123" |
| "Какой идиот это писал?" | Обвинение, страх трогать код | "Разберём контекст: сроки, ограничения, ADR" |
| "Просто скопировал" | Обесценивает интеграцию | "Адаптировал библиотеку: лицензия, версии, тесты" |
| "Никакого рефакторинга" | Закрепляет техдолг | "15 % спринта на долг — чтобы фичи шли быстрее дальше" |
Шаблон ADR
# ADR-012: Хранение сессий в Redis
## Статус
Принято (2024-03-15)
## Контекст
Нужна горизонтальная масштабируемость API без sticky sessions.
## Решение
Сессии в Redis с TTL 24 ч.
## Альтернативы
- JWT в cookie — отклонено: сложный отзыв доступа
- In-memory на ноде — отклонено: нет масштабирования
## Последствия
+ Единый logout, − зависимость от Redis (нужен мониторинг)
Шаблон blameless postmortem
# Postmortem — падение оплаты 2024-05-10
## Что произошло
14:02–14:18 MSK 12 % платежей с ошибкой 502.
## Влияние
~340 неуспешных транзакций, без потери данных.
## Корневая причина (система)
Нет проверки timeout при смене версии клиента платёжного шлюза.
## Действия
- [ ] Контрактный тест на timeout (владелец: Иван, срок: 17.05)
- [ ] Чек-лист деплоя: smoke оплаты (владелец: QA, срок: 15.05)
Практический чек-лист уважительной инженерной среды
- В календаре команды есть защищённые блоки для глубокой работы.
- В релизном цикле закреплён разбор инцидентов по системным причинам.
- Технический долг планируется отдельными задачами с владельцами.
- В code review обсуждаются решения и контекст, а не личности.
- Новички получают объяснение причин архитектурных компромиссов.
Такой базовый набор превращает "уважение" в ежедневную инженерную практику.