Ревью кода фаундером: почему это тормозит senior-разработчиков

Что идёт не так, когда фаундер проверяет каждое изменение

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

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

Мелкие решения тоже начинают подниматься наверх. Если фаундер вмешивается в названия, структуру файлов, мелкие edge cases и стиль, команда быстро улавливает этот паттерн. Разработчики перестают решать обычные вопросы между собой. Они ждут, пока фаундер скажет последнее слово.

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

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

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

Почему senior-разработчики начинают тормозить

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

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

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

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

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

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

Как размывается ответственность

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

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

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

Становится грязной и схема поиска виноватых. Слабая передача задачи, размытый тикет или отсутствие теста часто всплывают как задержка на ревью. После этого все говорят, что проблема в очереди. Иногда так и есть. Но часто задержка началась раньше — когда никто не прописал критерии приёмки, не разделил работу нормально и не проверил edge cases до открытия pull request.

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

Здоровые команды делают ответственность скучной. Разработчики отвечают за качество кода в своей зоне. Лиды отвечают за наставничество и стандарты ревью. Фаундер задаёт направление и не вмешивается в рутинную цепочку согласований.

Что скрывает этот паттерн

Когда каждое изменение ждёт фаундера, проблема обычно начинается гораздо раньше, чем pull request.

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

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

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

Прямое ревью фаундера может также прикрывать пробел в техническом лидерстве. Кто-то должен каждый день отвечать за инженерные стандарты, качество ревью и дисциплину поставки. Если эту роль не закрывает lead, staff engineer или Fractional CTO, фаундер становится страховочной сеткой по умолчанию. Несколько недель это ещё может работать. Обычно всё ломается, когда команда растёт или продукт становится сложнее.

Проблемы с наймом тоже прячутся здесь. Слабый senior-сотрудник редко проваливается в один драматический момент. Чаще он оставляет за собой след из грязных diff’ов, туманных объяснений, постоянных переделок и комментариев, которые не заканчиваются. Если фаундер продолжает лично чинить результат, настоящая проблема так и остаётся невысказанной.

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

Фаундер SaaS нанимает двух senior backend-разработчиков, потому что релизы постоянно срываются. На бумаге команда сразу выглядит сильнее. У обоих специалистов хорошее суждение и достаточно опыта, чтобы работать без жёсткого контроля. Но остаётся одно правило: каждый backend-change должен одобрить фаундер, прежде чем он попадёт в прод.

Это правило меняет команду с первого дня.

Майя за три дня завершает billing-функцию. Логика работает, тесты проходят, задача соответствует тикету. Фаундер смотрит её поздно вечером и просит перестроить сервис, переименовать часть сущностей и использовать паттерн, который ему нравится по старому проекту. Майя вносит правки. На следующем ревью прилетает новая волна комментариев — снова в основном по вкусу и стилю. Когда функция наконец выходит, она фактически сделала большую часть работы дважды.

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

К концу недели релиз снова сдвигается. Команда говорит, что задержку вызвала очередь на ревью. Звучит разумно, но скрывает реальную проблему. Очередь — это не процесс. Процесс — это сам фаундер.

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

Как отойти в сторону и не потерять контроль

Контроль не возникает от чтения каждого pull request. Он возникает из понятных правил, одного владельца и быстрой обратной связи.

Практический перезапуск обычно состоит из четырёх частей:

1. Назначьте одного владельца инженерного процесса. Этот человек задаёт правила ревью, принимает финальное решение по обычным изменениям и снимает стандартные разногласия. Фаундер по-прежнему может участвовать, но через этого владельца, а не через каждый pull request.
2. Напишите короткий стандарт ревью. Сделайте его настолько простым, чтобы его можно было прочитать за две минуты. Определите, что значит готово для тестов, что требует второго взгляда, что считается рискованным изменением, когда нужно выносить архитектурное решение и как быстро ревьюеры должны отвечать.
3. Ограничьте ревью фаундера только тем, что несёт реальный бизнес-риск. Обычно это логика биллинга, изменения, связанные с безопасностью, миграции данных, крупные архитектурные решения или релизы, которые могут серьёзно повлиять на клиентов. Рутинные исправления, небольшие рефакторинги и обычная продуктовая работа должны идти без одобрения фаундера.
4. Понаблюдайте за новым процессом один месяц. Измеряйте время ожидания ревью, доработки после ревью и срывы релизов из-за задержек на одобрение. Эти цифры покажут, исчезло ли узкое место. Они также вскроют более глубокие проблемы — например, слабые спецификации, постоянно меняющиеся приоритеты или фаундера, который меняет курс посреди недели.

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

Ошибки, из-за которых узкое место остаётся

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

Есть и более тонкая ошибка. Команда начинает копировать стиль ревью фаундера вместо того, чтобы договориться о настоящих инженерных стандартах. Люди ждут, чтобы понять, что фаундер предпочитает в названиях, структуре или edge cases. Привычки одного человека превращаются в политику — а это плохая замена настоящим стандартам.

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

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

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

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

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

Обычно этот паттерн можно заметить за пять рабочих дней без полного аудита.

Посмотрите, как двигается код. Зависают ли ревью больше чем на один рабочий день, прежде чем кто-то даст понятный фидбек или одобрение? Спрашивают ли разработчики: «А что здесь хотел бы фаундер?» ещё до начала программирования? Повторяются ли одни и те же замечания по стилю? Сдвигаются ли даты релизов, когда один человек занят продажами, наймом или привлечением инвестиций? Тратят ли senior-наёмные сотрудники время на расшифровку паттернов одобрения вместо решения проблем клиентов?

Затем возьмите один pull request и проследите его от начала до конца. Отметьте, когда код был готов, когда началось ревью, какой фидбек пришёл и меняли ли комментарии сам продукт или только стиль. Один пример часто показывает всю картину.

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

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

Проведите жёсткую границу вокруг одобрения фаундера. Оставьте его только для короткого списка решений с реальным бизнес-риском — например, для безопасности, крупных архитектурных изменений, важных обязательств перед клиентами или дорогой работы. Уберите его из обычных pull request’ов, небольших рефакторингов, исправлений багов и стандартных решений по реализации.

Затем передайте ежедневное владение ревью одному человеку. Это должен быть engineering lead или доверенный senior-разработчик, а не ротационная группа и не фаундер. Один владелец удерживает стандарты стабильными, ускоряет решения и делает ответственность очевидной, когда что-то идёт не так.

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

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

Еженедельной проверки достаточно для большинства фаундеров. Смотрите на lead time, процент повторного открытия задач, заблокированные pull request’ы и то, как часто работа ждёт одного человека. Если цифры улучшаются, отходите ещё дальше. Если ухудшаются, исправляйте процесс вместе с владельцем ревью, а не возвращайте себе контроль.

Если внутри команды никто не может это настроить, внешняя помощь может сильно сократить потери времени. Oleg Sotnikov с oleg.is работает как Fractional CTO и startup advisor, и именно такие операционные проблемы часто лучше всего решает внешний взгляд со стороны. Цель простая: понятная ответственность, стабильные стандарты ревью и команда, которая может выпускать продукт, не выстраиваясь в очередь за календарём фаундера.