Сломанные инженерные решения: почему ещё один найм не поможет

Как это выглядит в повседневной работе

Сломанные инженерные решения редко проявляются как одна громкая неудача. Чаще они выглядят как одна и та же трение снова и снова.

В одном и том же платежном модуле возникает баг в двух продуктах, которые делали две разные команды. Один и тот же шаг согласования тормозит каждый релиз. Инженеры на каждом спринте снова поднимают старый спор, потому что никто не записал, какое решение считается базовым, кто за него отвечает и при каком условии его можно менять.

Со временем картина становится знакомой. Похожие баги появляются в разных частях продукта. Проекты застревают на одних и тех же передачах задач. Новые сотрудники задают базовые вопросы о процессе и получают разные ответы от разных людей. Срочная работа обходит обычную очередь, потому что никто не доверяет стандартному пути.

Представьте небольшой стартап, который быстро выпускает фичи, но постоянно ломает права доступа к аккаунтам. Backend-инженеры чинят один случай. Frontend-инженеры закрывают другой. Support добавляет ручной обход. Потом приходит новый senior engineer и ожидает чистую модель доступа. Вместо этого он находит пять исключений, неясного владельца и ни одного письменного правила о том, кто может обходить обычный поток.

Вот как выглядят сломанные решения в повседневной работе. Люди заняты. Тикеты двигаются. Внешне какое-то время всё выглядит нормально. Но команда снова и снова платит за одно и то же отсутствующее правило.

Почему ещё один инженер это не исправит

Новый инженер обычно попадает в ту же систему, которая тормозила всех остальных. Код может быть запутанным, но глубинная проблема часто проще: у команды нет понятных правил, по которым принимаются решения.

Когда это происходит, даже сильный кандидат начинает гадать. Он копирует самого громкого человека, следует старым привычкам или обходит проблему сбоку. Код он может писать чище, но всё равно работает в той же неясной системе.

Увеличение штата иногда даже ухудшает ситуацию. Если команда и так принимает слабые решения, дополнительные руки помогают принимать их быстрее. Один инженер придумывает обходной путь. Другой строит на нём следующий слой. Третий отправляет это в релиз, потому что финальное решение никому не принадлежит. Команда выглядит продуктивной. Риск всё равно растёт.

Найм ещё и на несколько недель может скрыть пробелы в ответственности. Тикеты снова двигаются, и всем становится легче. Потом тот же паттерн возвращается под новым названием. В прошлом квартале это была «нестабильность деплоя». В этом квартале — «edge cases» или «проблемы интеграции». Формулировка меняется. Отсутствующее правило — нет.

Возьмём команду, которая постоянно выпускает фичи, ломающие отчётность. Они нанимают ещё одного backend engineer. Этот человек добавляет проверки, разгребает очередь и закрывает срочные проблемы. Через два месяца отчётность снова ломается, потому что никто не договорился об одном правиле: изменения схемы данных должны проходить проверку влияния на downstream до релиза. Дополнительный инженер помог с объёмом, а не с суждением.

Если одна и та же поломка возвращается под новыми словами, не спешите думать, что вам нужна ещё одна закрытая вакансия. Возможно, вам нужны правило, понятный владелец и команда, которая следует им обоим.

Начните с последних трёх инцидентов

Последние три инцидента обычно говорят больше, чем стопка собеседований. У недавних инцидентов ещё есть контекст: поспешные сообщения, не до конца ясные допущения и момент, когда кто-то выбрал скорость вместо ясности.

Начните с исходных материалов. Возьмите заметки по инциденту, командные чаты и простую хронологию того, что произошло. Если формального postmortem никто не писал, соберите его из сообщений и алертов.

Потом найдите решение, из-за которого восстановление заняло больше времени. Сам outage часто менее интересен, чем тот шаг, который превратил маленькую проблему в долгую.

Возможно, кто-то отложил rollback ещё на один шаг, потому что хотел получить один дополнительный лог. Возможно, два инженера меняли один и тот же сервис, потому что за инцидент никто не отвечал. Возможно, менеджер продолжал требовать обновления, пока у команды не было понятного лидера по исправлению.

Достаточно короткого разбора:

• Запишите первое решение, которое добавило задержку, путаницу или лишний риск.
• Укажите, кто его принял.
• Отметьте, во что этот человек верил в тот момент.
• Проверьте, было ли у команды правило на такой случай.

Именно последний шаг важнее всего. Команды часто останавливаются на «плохом суждении». Но если один и тот же shortcut появляется дважды, дело не только в суждении. У команды либо нет правила, либо есть правило, которому никто не доверяет.

Если в ваших последних трёх инцидентах снова и снова встречается что-то вроде «подождать ещё немного перед rollback», это не три отдельные ошибки. Это один повторяющийся пробел в принятии решений. Возможно, команда не знает, кто может одобрить rollback, когда влияние на клиента важнее поиска root cause и сколько доказательств достаточно, чтобы действовать.

Держите разбор фактическим. Не превращайте его в поиск виноватых. Спросите, кто принял решение, какое давление человек чувствовал, какие сигналы видел и какие варианты считал доступными. Обычно люди следуют привычкам и стимулам вокруг себя.

Если один и тот же shortcut встречается больше чем в одном инциденте, исправьте его до того, как откроете новую роль. Новый инженер всё равно унаследует тот же туман во время outage.

Разберите один застопорившийся проект по шагам

Теперь выберите один проект, который затянулся, хотя никто не может назвать один конкретный blocker. Не outage, не сбой у поставщика, не отсутствующий человек. Такие случаи полезны, потому что команда обычно была занята, но работа так и не приблизилась к релизу.

Постройте простую хронологию от идеи до запуска. Запишите каждую передачу задач по порядку: запрос, одобрение, scope, дизайн, разработка, ревью, тестирование, релиз. Поставьте имя рядом с каждым шагом. Если вы не можете сказать, кто владел одной передачей, скорее всего, вы уже нашли часть проблемы.

Представьте обновление клиентского кабинета, которое опоздало на десять недель. Sales запросили его. Product написали короткое описание. Design ждали ответов от backend. Backend ждал, пока product определит спорные случаи. Frontend начал работу, а потом остановился, когда изменилась API. QA так и не получил стабильную сборку. Все работали. Ничего не вышло в релиз.

Когда вы раскладываете такой задержанный проект по шагам, ищите момент, когда движение стало просто движением без результата. Это часто происходит, когда одобрение идёт вперёд без одного владельца, дизайн начинается до того, как scope устоялся, ревью снова открывает решения, которые уже должны были быть закрыты, или тестирование ждёт, пока вся фича станет «полностью готова».

После того как вы нашли место, где всё застопорилось, запишите правило, которому люди следовали в тот момент. Сделайте его прямым. Возможно, правило звучало как «product должен ответить на каждый edge case до старта backend» или «любой senior engineer может менять план во время ревью». Команды следуют таким правилам годами, даже ни разу не произнеся их вслух.

Потом спросите, пытался ли кто-то оспорить это правило, когда задержка стала очевидной. Если нет, проблема была не в усилиях. Это был пробел в правилах. Другой инженер вошёл бы в тот же поток, застрял бы на той же передаче задач и потерял бы те же две недели.

Один застопорившийся проект может рассказать больше, чем десяток статус-апдейтов. Он показывает точное правило, которому команда подчиняется, когда работа начинает тормозить.

Назовите пробел в правилах

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

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

Если никто не отвечает за одобрение rollback, это отсутствующее правило. Если каждый небольшой релиз должен ждать еженедельной встречи, это плохое правило.

Неписаные правила наносят большой ущерб, потому что их никто не фиксирует. Команды говорят что-то вроде «обычно сначала советуемся с ops» или «frontend может выкатывать изменения текста без ревью», но эти привычки живут в истории чатов и в памяти людей. Новый инженер их не видит. Он узнаёт о них, только когда что-то ломает.

Ещё стоит смотреть на места, где две команды следуют разным правилам и даже не подозревают об этом. Product может считать, что фича готова, когда демо работает. Engineering может считать, что она готова только после мониторинга, шагов rollback и заметок для support. Обе стороны звучат разумно. Но конфликт всё равно ведёт к пропущенным датам и повторяющимся передачам задач.

Сначала сосредоточьтесь на решениях, которые создают повторную работу. Если люди снова и снова открывают один и тот же тикет, пересобирают одну и ту же интеграцию или спорят, кто одобряет релиз, пробел, скорее всего, больше, чем кажется.

Размытая привычка становится проще для исправления, когда вы превращаете её в одно понятное предложение:

• Изменения схемы данных требуют заметки о rollback до начала ревью.
• Изменения в биллинге должны согласовать один product owner и один инженер.
• У инцидента должен быть один владелец в течение 15 минут.
• Команды не объединяют работу, если есть открытые вопросы о владении данными.

Такой уровень детализации работает. Вам не нужна длинная политика. Вам нужно правило, которым люди действительно смогут пользоваться под давлением.

Простой пример для команды

Небольшой стартап постоянно пропускает сроки релиза, и основатели делают очевидный ход — нанимают ещё одного backend engineer. Через три месяца календарь всё равно сдвигается, тикеты в support всё так же всплывают после запусков, а команда по-прежнему чувствует перегрузку.

На бумаге команда стала больше. На практике те же две проблемы продолжают тянуть работу вниз.

Во-первых, согласование со стороны product приходит слишком поздно. Инженеры заканчивают фичу во вторник. QA проверяет её в среду. Потом релиз ждёт, потому что никто из product не даёт финальное «да» или «нет» до вечера пятницы. Из-за этой задержки запуск уходит на следующую неделю. Команда читает это как проблему инженерной мощности, хотя код был готов ещё несколько дней назад.

Во-вторых, инциденты остаются открытыми дольше, чем должны. Релиз выходит, растёт error rate, и команда начинает спорить в чате. Один инженер хочет исправить вперёд. Другой — откатить назад. Product спрашивает, затрагивает ли проблема платящих пользователей. Никто не отвечает за решение об откате, поэтому спор съедает 40 минут, пока клиенты остаются посередине.

Исправление меньше, чем ещё один найм. Никакой релиз не должен планироваться, если один человек не отвечает за решение о выпуске от начала до конца. Этот человек должен получить одобрение product к заданному времени, и он же должен иметь право запускать rollback без группового согласования.

Команде не нужен был ещё один backend engineer, чтобы решить проблему поздних согласований. Ей понадобились дедлайн и названный принимающий решение. Ей не нужен был отдельный hire в operations, чтобы снизить шум от инцидентов. Ей нужен был один владелец с полномочиями на время окна релиза.

После этого запуска стали проще. Product пришлось принимать решения раньше. Инженеры перестали ждать ответов в последний момент. Когда релиз ломался, один человек принимал решение об откате за минуты, а не после длинной переписки.

Вот почему правила принятия решений часто важнее, чем численность команды.

Ошибки, которые команды здесь допускают

Первая ошибка — превратить системную проблему в проблему людей. Одного инженера назначают «причиной» того, что релиз задержался или миграция застопорилась. Это кажется аккуратным объяснением. Обычно оно неверно.

Если один и тот же тип сбоя появляется у разных людей, у вас не один слабый исполнитель. У вас слабое правило. Да, кто-то принял плохое решение, но большая проблема в том, что у команды не было понятного правила, когда эскалировать, когда останавливаться и кто может сказать «нет».

Вторая ошибка — считать каждую задержку нехваткой людей. Команда не укладывается в сроки, и руководство открывает новую вакансию. Новый инженер приходит в тот же неясный scope, те же слабые передачи задач и ту же путаницу с одобрениями. Штат помогает с объёмом. Он не чинит сломанные решения.

Третья ошибка — писать правила, которыми никто не может пользоваться. «Communicate earlier» — это не правило. «Test more» — тоже не правило. Рабочее правило звучит так: если задача меняет поведение API, один назначенный человек должен проверить её до старта работы.

Ещё один частый промах — фокусироваться только на самом громком инциденте. Большой outage получает встречу, заметки и новый чеклист. А между тем два более тихих проекта застопорились по той же причине: никто не знал, кто может менять scope после начала работы. Outage был просто самым шумным вариантом того же паттерна.

Команды ещё меняют один шаблон, переименовывают одну встречу и думают, что проблема решена. Потом та же задержка появляется через две недели, потому что никто не проверил, изменилось ли поведение.

Прежде чем просить о новом найме, задайте четыре простых вопроса. Происходил ли один и тот же сбой с разными людьми? Картировал ли кто-то путь решения перед открытием роли? Достаточно ли новое правило конкретно, чтобы им можно было пользоваться под давлением? Проверила ли команда, изменило ли первое исправление хоть что-то?

Слабые ответы обычно означают, что команда всё ещё латет симптомы.

Быстрые проверки перед открытием новой роли

План найма имеет смысл только после того, как вы решили, есть ли у команды проблема людей или проблема правил. Многие застопорившиеся проекты снаружи выглядят как нехватка сотрудников. Внутри же повторяется одно и то же плохое решение, никто за него не отвечает, а каждый инженер обходит его по-своему.

Используйте последние несколько болезненных недель как доказательство. Если один релиз задержался, потому что никто не знал, кто может одобрить изменение базы данных, и другой задержался по той же причине, это не нехватка мощности. Это пробел в правилах.

Пройдите короткую проверку:

1. Запишите сломанное правило одним простым предложением. «Любое изменение API требует одобрения product и backend» — это правило. «Коммуникация развалилась» — нет.
2. Проверьте, нанесло ли одно и то же правило вред больше чем одному проекту или инциденту. Если оно появилось дважды, считайте это паттерном.
3. Назначьте одно имя на решение. Если им как бы владеют три человека, то в момент цейтнота им не владеет никто.
4. Спросите себя, наткнётся ли новый инженер на тот же лабиринт согласований в первую же неделю. Если ответ «да», роль добавит зарплату, но не уберёт задержку.
5. Попробуйте небольшое изменение правила на две недели. Сократите один путь согласования, назначьте одного владельца или задайте default action на случай, если в течение дня никто не ответит.

Полезно и простое мысленное упражнение. Представьте, что завтра вы нанимаете сильного senior engineer. Он приходит, находит застрявшую миграцию, просит одобрение и затем ждёт product, legal и основателя, который в поездке. Проходит две недели. Вы наняли не того человека? Нет. Вы оставили неправильное правило.

Вот где сломанные решения остаются скрытыми. Найм ощущается конкретным. Исправление правил кажется более медленным, даже когда оно экономит больше времени.

Что делать дальше

Вам не нужен месячный аудит, чтобы это заметить. Выберите один недавний инцидент и один проект, который тянется намного дольше, чем должен. Обычно этого уже хватает, чтобы найти правило, о которое команда снова и снова спотыкается.

Сделайте это на этой неделе, пока детали ещё свежие. Если вы подождёте более спокойного момента, люди забудут, что произошло, и заполнят пробелы мнениями.

Начните с четырёх шагов:

• Выберите один инцидент, который причинил реальную боль, например downtime, плохой релиз или rollback.
• Выберите один проект, который застрял на ревью, редизайне или согласовании.
• Запишите три правила, которым ваша команда уже следует, даже если раньше их никто не формулировал.
• Перепишите одно размытое правило так, чтобы за решение отвечал один человек и он знал, когда его принимать.

Держите правила простыми. «Backend changes need a written rollback plan» — понятно. «Инженеры должны быть внимательнее» — бесполезно.

Если инцидент начался с срочного изменения базы данных, а ваш застрявший проект заблокирован потому, что никто не хочет одобрить изменение API, под обоими проблемами может быть один и тот же пробел: у команды нет понятного владельца изменений, которые затрагивают несколько частей продукта.

Погоняйте новое правило две-четыре недели, прежде чем утверждать рост штата. Смотрите, что меняется. Решения принимаются быстрее? Ревью становятся короче? Меньше задач прыгает между людьми? Если да, вы нашли управленческую проблему до того, как заплатили за кадровое исправление.

Если ничего не меняется, аргументы в пользу найма становятся сильнее, потому что вы сначала убрали один источник шума. Это ещё и делает следующую роль проще для описания и намного проще для онбординга.

Если вам нужен второй взгляд перед увеличением штата, Oleg Sotnikov на oleg.is работает как Fractional CTO и Startup Advisor. Короткий разбор недавних инцидентов, правил поставки и пробелов в ответственности может показать, нужен ли вам ещё один инженер, лучшая модель принятия решений или и то и другое.