Сильный технический владелец: проверьте гипотезу реальными данными

Почему команды слишком рано обвиняют код

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

Иногда они правы. Но часто они видят только поверхность.

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

Жалобы обычно звучат знакомо:

• «Мы не можем выпускать без регрессий»
• «Каждый релиз ощущается рискованным»
• «Бэклог всё время растёт»
• «Клиенты просят простые исправления и ждут неделями»

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

Именно поэтому медленная поставка и размытая ответственность требуют разных названий. Медленная поставка означает, что работа идёт плохо. Размытая ответственность означает, что никто не отвечает за весь путь от боли клиента до объёма работ и риска релиза. Команды постоянно путают это. Они смотрят на кодовую базу, находят шероховатости и останавливаются на этом.

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

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

Что именно должен брать на себя технический владелец

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

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

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

Технический долг требует такого же фильтра. Какой-то долг просто раздражает, но не мешает. А какой-то замедляет каждый релиз, порождает повторяющиеся инциденты или заставляет поддержку снова и снова отвечать на один и тот же вопрос. Хороший технический владелец не гонится за каждой шероховатостью. Он чинит тот долг, который стоит бизнесу времени, денег или доверия.

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

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

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

Начните с данных поддержки

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

Возьмите последние 60–90 дней тикетов поддержки. Обычно этого окна хватает, чтобы увидеть повторы, но оно ещё не слишком длинное, чтобы отражать текущий продукт и текущую команду.

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

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

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

Для каждой группы отслеживайте несколько простых показателей:

• как часто проблема появляется
• как долго она остаётся открытой
• какую функцию она затрагивает
• возвращается ли тот же фикс позже
• кто подключался, чтобы закрыть вопрос

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

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

Небольшой пример делает это очевидным. Представьте SaaS-команду, у которой 140 тикетов за 75 дней. Сначала они думают, что приложение нестабильно. После группировки по функциям выясняется, что почти половина тикетов идёт из одного экрана отчётов. Только треть — реальные ошибки. Остальное связано с неясными подписями и ручным процессом экспорта, за который никто не отвечает. Такой команде нужно не просто больше кода. Ей нужна более жёсткая ответственность за решения, передачи задач и доведение до конца.

Смотрите на историю релизов как на хронологию

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

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

Достаточно простого формата:

• обещанная дата и фактическая дата релиза
• задержка в днях
• откат или аварийный фикс
• какое более раннее изменение это затронуло или сломало
• короткие заметки команды вроде изменения объёма, пробела в тестировании или поспешного одобрения

Теперь сравните релизы с тем, что команда обещала. Если исправление в оформлении заказа задержалось на две недели из-за того, что другое изменение в биллинге его сломало, запишите это. Если срочный фикс в поиске вызвал баг входа в систему, тоже запишите. Вы считаете не только ошибки. Вы картируете боль от зависимостей и боль от решений.

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

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

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

Найдите архитектурную боль в повседневной работе

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

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

Сигналы, которые можно увидеть без большого аудита

Спросите инженеров, где они теряют время. Обычно ответы простые.

• Какие части кода страшно менять?
• Где люди останавливаются и спрашивают: «Кто знает эту область?»
• Какие шаги выкладки или отката всё ещё делаются вручную?
• Как часто крошечное изменение продукта затрагивает много файлов или сервисов?
• Какие сбои обычно приходят вместе?

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

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

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

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

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

Проведите тест за одну неделю

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

Начните с сухих фактов в первый день. Соберите последние 60–90 дней тикетов поддержки, заметок о релизах, журналов инцидентов, баг-репортов и записей об откатах. Держите всё максимально просто. Вам нужны числа, даты, затронутые области продукта и примерный бизнес-эффект.

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

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

Четвёртый день — для ранжирования проблем. Используйте две колонки: как часто это происходит и сколько это стоит. Под стоимостью могут быть возвраты, потерянные пользователи пробного периода, часы инженеров, поздние релизы или время поддержки. Ошибка, которая случается два раза в месяц, но каждый раз съедает по два дня, может быть важнее, чем шумная мелочь.

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

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

Простой пример из небольшой продуктовой команды

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

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

Но хронология рассказывала другую историю.

Каждый релиз, связанный с ценами, двигался медленно, потому что почти всё утверждал один инженер. Если этот человек был занят, изменение ждало. Если он торопился, команда выкатывала его со слабыми проверками. Данные поддержки показывали одну и ту же категорию проблемы каждую пятницу, так что дело было не в случайности. Заметки о релизах показывали кластер задержек, срочных исправлений и откатов вокруг работ с ценами.

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

Более сильный технический владелец сделал бы несколько простых вещей:

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

Это не план переписывания. Это план по ответственности.

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

Ошибки, которые искажают результат

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

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

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

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

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

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

Быстрые проверки перед выбором решения

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

Обычно этот разрыв видно в обычных местах.

• Попросите одного человека простыми словами объяснить три последних инцидента. Если никто не может сделать это без жаргона, ответственность размыта.
• Посмотрите на повторяющиеся тикеты поддержки. Если одна и та же область продукта возвращается снова и снова, проблема, скорее всего, системная, а не случайная.
• Сравните срочные фиксы с плановыми релизами за последние месяцы. Если выигрывают срочные фиксы, команда реагирует, а не управляет процессом.
• Заметьте, каких частей системы люди избегают. У каждой команды есть страшная зона, но здоровая команда всё равно понимает, как она работает и когда её менять.
• Проверьте, кто принимает компромиссы между продуктом и инженерией. Если продукт хочет скорости, инженерия — безопасности, а финальное решение никто не берёт на себя, мелкие проблемы копятся.

Такие проверки трудно подделать. Полированная дорожная карта может скрыть многое. Паттерны тикетов поддержки и история релизов — обычно нет.

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

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

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

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

Запишите три самых чётких паттерна, которые вы нашли. Хорошие примеры выглядят так:

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

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

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

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

Если после двух циклов команда всё ещё спорит о причине, позовите внешний взгляд. Люди, которые год живут внутри бардака, часто перестают видеть его ясно. Олег Сотников на oleg.is работает как Fractional CTO и советник стартапов, и такой разбор хорошо подходит для этой роли. Короткий взгляд на паттерны тикетов, поток релизов и разрывы в ответственности часто уже достаточно показывает, нужна ли вам более жёсткая техническая лидерская роль, лучшая дисциплина релизов или реальная чистка кода.