Отсутствие технической стратегии: признаки, которые скрываются в повторяющихся задержках

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

Плохое техническое направление редко проявляется как один громкий провал. Оно видно в обычной работе.

Срок с пятницы переносится на вторник, потом на «начало следующей недели», и никто даже не удивляется. Руководители перестают доверять плану, поэтому тратят больше времени на запросы статуса, чем на помощь команде. Daily длятся дольше. Встреч по статусу становится всё больше. Люди начинают использовать чат как систему отслеживания задач, потому что официальный план уже устарел.

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

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

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

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

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

Почему одни и те же задержки возвращаются снова

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

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

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

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

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

Хороший Fractional CTO смотрит не только на последний пропущенный срок, а на цепочку решений, которая к нему привела. Кто определил приоритет? Какой компромисс выбрали? О чём команда договорилась до начала программирования? Эти ответы говорят больше, чем любой статус-апдейт.

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

Churn в roadmap как ранний сигнал

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

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

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

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

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

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

Распыление инструментов, которое скрывает более глубокие проблемы

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

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

Продакт-менеджер обновляет планы в Notion. Разработчики отслеживают работу в Jira. Поддержка сообщает о багах в Slack. Релизные заметки лежат в комментариях GitLab или в таблице. Одна фича может пройти через четыре места, прежде чем будет выпущена. Люди снова и снова задают одни и те же вопросы, потому что больше не доверяют тому, что видят.

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

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

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

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

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

Аварийная работа, которая забирает всю неделю

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

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

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

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

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

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

Простой пример из растущей компании

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

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

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

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

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

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

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

Fractional CTO обычно быстро это замечает. Больше клиентов приносит больше обещаний. Больше обещаний приносит больше инструментов. Больше инструментов приносит больше точек отказа. Основатель видит повторяющиеся задержки. Причина лежит под ними.

Как проверить проблему шаг за шагом

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

1. Возьмите последние десять задержанных задач — фич, исправлений, релизов или внутренних проектов. Запишите исходную дату, фактическую дату и простую причину, по которой задача съехала.
2. Отметьте все задачи, у которых после старта изменился объём работ. Если половина списка выросла уже в процессе, команда начинала без стабильного решения.
3. Посчитайте, сколько инструментов компания использует для планирования, code review, документации и обработки инцидентов. Распыление инструментов часто означает, что люди следуют разным правилам, не признавая этого.
4. Сравните плановую работу и аварийную за последние четыре недели. Включите инциденты, срочные запросы клиентов, hotfix и внезапные просьбы руководства.
5. Задайте три вопроса об ответственности: кто принимает архитектурные решения, кто задаёт правила поставки и кто решает, когда платить технический долг. Если пять человек дают три разных ответа, системой по сути никто не владеет.

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

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

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

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

Ошибки, которые ещё сильнее увеличивают разрыв

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

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

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

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

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

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

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

Совет звучит просто, но он работает. Уберите дублирование, сделайте приоритеты видимыми и защитите команду от случайных изменений. Это помогает сильнее, чем ещё один найм или ещё одна подписка на софт.

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

Пять прямых вопросов могут выявить проблему быстрее, чем месяц статус-встреч.

1. Попросите одного человека объяснить, почему roadmap изменился в прошлом месяце. Если ответ — «приоритеты сдвинулись», спросите ещё раз. Нужна настоящая причина: обещание клиенту, ограничение системы, неверная оценка или неожиданный баг.
2. Спросите у инженерии, какие системы чаще всего блокируют поставку. Если каждая команда называет своё, компания, скорее всего, обходит боль вместо того, чтобы её решать.
3. Спросите продукт, инженерию и продажи о дате следующего релиза. Если вы получите три даты, у вас не один план. У вас три истории.
4. Спросите, сколько часов на прошлой неделе ушло на аварийную работу. Если это никто не отслеживает, срочные задачи могут съедать половину недели, и никто этого не заметит.
5. Спросите, кто отвечает за технические стандарты. Одного чёткого владельца достаточно. Если ответственность разделена между тремя людьми, стандарты обычно превращаются в мнения.

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

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

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

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

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

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

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

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

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

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

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

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