Привычки основателей, которые замедляют старших инженеров

Почему сильные инженеры всё ещё кажутся медленными

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

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

Потерянное время легко не заметить, потому что оно редко выглядит драматично. Инженер может остановиться на 10 минут, чтобы ответить в Slack, посмотреть новый запрос или отреагировать на сообщение основателя. Потом требуется ещё 20 минут, чтобы вернуться в контекст задачи. Повторяйте это несколько раз в день — и часы улетают незаметно.

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

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

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

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

Сколько на самом деле стоят поздние изменения объёма работ

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

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

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

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

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

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

Как приватные обещания создают скрытую работу

После звонка продаж основатель может сказать: «Да, мы добавим это к пятнице». Команда об этом узнаёт позже, обычно в спешке в Slack или на стендапе, где и так много тем.

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

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

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

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

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

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

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

Почему постоянные сообщения в Slack съедают производительность

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

Двухминутный вопрос редко остаётся двухминутным. Инженер перестаёт читать код, оставляет незаконченный замысел, открывает Slack, восстанавливает контекст, отвечает и затем пытается вернуться к задаче. Вот этот последний шаг и занимает время. Вернуться в глубокую работу может потребоваться 10–15 минут, иногда больше.

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

Представьте разработчика, который отлавливает баг в биллинге через три сервиса. Основатель пишет: «Быстрый вопрос: можем ли мы добавить CSV-экспорт на этой неделе?» Ответ может занять 30 секунд. Но прерывание всё равно сносит 20 минут сосредоточенной работы.

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

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

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

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

Неделя стартапа, которая тихо уходит с пути

В понедельник утром план кажется чистым. У одного старшего инженера три задачи на неделю: закончить баг в биллинге, посмотреть pull request и выпустить первую версию небольшого админ-инструмента. Это уже полная неделя, но реалистичная.

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

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

В среду в личных сообщениях основателя появляется проблема клиента вместо команды. Основатель пересылает её с дополнительным давлением: «Я сказал, что мы посмотрим сегодня». Теперь у инженера две неофициальные задачи и один официальный план спринта. Ни одна из них не стыкуется.

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

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

Со стороны неделя выглядит продуктивной, потому что никто не сидел без дела. На самом деле это не была продуктивная неделя. Чёткая работа была разрезана на фрагменты, скрытые обещания перескочили очередь, а поздние изменения съели часы, которые должны были пойти на выпуск рабочего ПО.

Как основателям это исправить

Начните с одного правила: если работа не в общем списке приоритетов, то это не текущая задача команды. Простая доска — уже достаточно. Основатель, инженеры и дизайнер должны видеть один и тот же список в одном порядке.

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

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

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

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

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

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

Ошибки, которые основатели повторяют, не замечая этого

Большинство основателей не хотят замедлять команду. Но несколько повседневных привычек постоянно сбивают фокус.

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

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

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

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

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

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

Короткая проверка перед тем, как прерывать команду

Большинство прерываний для основателя кажутся маленькими и дешёвыми, а для инженера — дорогими. Одно сообщение в Slack может разрушить 20 минут фокуса, и цена выше, если оно попадает в разгар написания кода, отладки или ревью рискованного изменения.

Перед тем как отправлять сообщение, быстро проверьте:

1. Можно ли это подождать до следующего чек-ина?
2. Если это войдёт в работу сегодня, что тогда перемещается в сторону?
3. Кому действительно нужно видеть это прямо сейчас?
4. Нужно ли мне решение, оценка или просто информирование?

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

Пишите запросы одним простым предложением, если можете. Коротко — нормально. Ясно — лучше.

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

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

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

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

Это также улучшает разговоры. Вместо того чтобы сказать «инженерия кажется медленной», вы можете сказать: «мы меняли объём четыре раза и прерывали трёх человек каждый день после обеда». Это достаточно конкретно, чтобы исправить.

Если после короткого теста команда всё ещё крутится на месте, может помочь внешний оператор, который установит правила работы и будет их поддерживать. Это та уборка, которую хорошо делает fractional CTO. Олег Сотников на oleg.is работает со стартапами над техническим лидерством, архитектурой продукта и AI-first разработкой, и одно из первых достижений обычно — вернуть под контроль область задач, запросы и доставку.

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