Архив рубрики ‘инженерная культура’

Ваши постмортемы — это поминки. И добрая половина процессов в компании тоже

Однажды я зашёл в компанию через неделю после крупного падения и попросил показать постмортем. Мне показали — с гордостью. Таймлайн поминутно, five whys, аккуратный список action items, owner напротив каждого, разослано по всем спискам. Красиво. «Видите, мы серьёзно подошли». Я задал один вопрос: а постмортем по прошлому такому же падению — где? Нашли. Открыли. Те […]

Поколение «Approve»: почему я заставил команду переписать проект, который уже работал

Предистория Последние пару лет, кажется, невозможно поговорить об ИИ в разработке, чтобы разговор не упирался в тему производительности. Отовсюду постоянно вылезают новые истории успеха. Кто-то показывает, как сократил время разработки в несколько раз. Кто-то рассказывает, что теперь пишет за день столько кода, сколько раньше писал за неделю. Иные вообще собирают полноценный продукт за выходные и […]

Backstage — управление микросервисным ландшафтом без хаоса

Представьте: в вашей компании уже не десятки, а сотни микросервисов. Новый разработчик приходит в команду и первую неделю тратит не на код, а на поиски. «Где лежит этот API?», «Как запустить этот сервис локально?», «Кому писать, если он падает?». Каждая команда изобретает свои велосипеды для документации, а общие инструменты превращаются в разрозненную коллекцию закладок в […]

Ошибка найма «рок‑звезды» — как один супер‑инженер разрушил команду за полгода

Привет, Хабр! Меня зовут Андрей Бирюков. Я являюсь независимым экспертом в области ИТ и ИБ, преподаю в учебных центрах и пишу книги. Каждая компания‑разработчик хочет иметь в своей команде сильных специалистов, и зачастую поиск и найм таких спецов ограничивается только бюджетом. Однако в этой статье мы рассмотрим ситуацию, в которой у нас была возможность нанять гениального одиночку, но в итоге мы получили […]

Культура инцидентов. Почему поиск виновных на постмортемах убивает надёжность системы

Результат разбора любого инцидента — наказание виновного или виновных. Но наказание за ошибки не делает систему надёжнее. Вместо этого оно мотивирует скрывать недочеты. Единственный способ построить предсказуемо работающую ИТ‑инфраструктуру — создать среду, в которой инженеры добровольно и без страха рассказывают о том, что пошло не так. И это задача не HR, а системного менеджмента. О том, как этого достигнуть, делимся в статье. Природа ошибки в сложных системах

Джуны теперь пишут лучше, чем понимают. Что с этим делать

Всем привет, это команда SimpleOne SDLC. Вокруг ИИ в разработке уже сформировались два шумных лагеря: одни уверены, что джуны теперь не нужны, другие считают, что ничего принципиально не изменилось. На практике неверны обе крайности.

В защиту «обычных» разработчиков

Эта статья изначально была заказана Лукой Росси для refactoring.fm 11 февраля 2025 года. Лука отредактировал материал, в ней получился акцент на важности построения «команд инженеров 10×». Позже материал забрал IEEE Spectrum — они выкинули большую часть содержания про команды и опубликовали более короткий текст. Это — моя личная редакция. Она не совпадает ни с одной […]

Петух на проекте

Есть тимлиды у которых команда разваливается стоит им только отвернуться. А есть тимлиды которые могу сходить в отпуск и этого даже никто не заметит. В одних командах разработчики счастливы, в других выгорают.  Чтобы понять почему так происходит, придется обсудить петухов. Не с целью оскорбить а с целью разобраться. Это, пожалуй, самая точная метафора про управление […]

Секреты передачи знания: переход границ опыта при уходе ключевых инженеров и документирование архива проектов

Каждый разработчик рано или поздно сталкивается с ситуацией: из команды уходит «тот самый» человек, который держал в голове половину архитектуры. Вместе с ним уходит не только опыт, но и часть будущего проекта. В статье делюсь мыслями и подходами, как минимизировать потери при передаче знаний, какие форматы работают, а какие — нет, и почему документация должна […]

CTO: рынок, стратегия и инженерная культура

За последние 10+ лет я строил продуктовые инженерные практики и культуру как в стартапах, выросших с нуля до 100+ человек, так и в корпорациях с 1000+ штатом.  Это конспект моего опыта и ответы на четыре вопроса: что делает