Узкое место у вендора: как проверить, прежде чем винить код

Как это выглядит в жизни

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

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

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

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

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

Кто на самом деле управляет релизом

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

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

Самый быстрый способ это увидеть — составить карту аккаунтов и прав доступа, которые важны. Посмотрите на production-серверы или облачные аккаунты, доступ к App Store для мобильных релизов, настройки домена и DNS, CI/CD и хостинг, управление секретами и любое ручное согласование перед релизом. Один потерянный логин может остановить выпуск на дни.

Частый пример: вендор завершает исправление, но аккаунт Apple App Store принадлежит клиенту, и никто с доступом не может отправить сборку. Со стороны кажется, что вендор медлит, хотя на деле он просто ждёт.

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

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

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

Проверьте требования, прежде чем судить о работе

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

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

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

Потом проверьте изменения объёма работ. Несколько изменений — это нормально. Постоянные изменения — нет. Если команда начинала с простого checkout-flow, а потом пришлось добавить правила скидок, налоговую логику, гостевой checkout и мобильные edge cases, сроки сдвинулись, даже если вендор работал качественно.

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

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

Это постоянно случается в маленьких командах. Основатель говорит: «сделайте, как в старой системе», но никто не документирует старые edge cases. Вендор строит очевидный вариант. Начинается ревью, всплывают скрытые правила, и все называют это промахом. На самом деле команда оценила исполнение раньше, чем проверила бриф.

Проследите цикл поддержки от проблемы до исправления

Выберите один недавний баг и проследите его от первой жалобы до финального релиза. Не начинайте с коммита в коде. Начните с первого сообщения в поддержке, чате, email или системе тикетов.

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

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

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

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

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

Небольшой пример это хорошо показывает. Пользователь сообщает о неудачном checkout в 9:00. Поддержка отвечает в 11:00 и просит скриншот. Пользователь отвечает на следующее утро. В 2:00 инженерия просит order ID и версию браузера. Поддержка получает это на следующий день. Инженерия находит и исправляет баг за 25 минут. Медленной была не правка.

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

Найдите зависимости, о которых никто не сказал заранее

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

Начните с простого списка всех сервисов, которые нужны продукту для работы. Сделайте его скучным и конкретным. Включите платёжные инструменты, провайдеров логина, email-доставку, SMS-вендоров, data feeds, проверку App Store, облачные аккаунты, старые внутренние системы и любые шаги согласования вне кодовой базы.

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

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

Часто это всплывает в логине и платежах. Команда заканчивает правку checkout, а потом ждёт три дня новые API credentials. Или исправляет sign-in flow, но у никого нет прав администратора у identity provider. Со стороны это выглядит как медленная разработка. На деле это проблема доступа.

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

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

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

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

Составьте простую хронологию от первого запроса до продакшена. Держитесь фактов. Запишите дату, человека или команду и сколько времени занял этот шаг.

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

• кодирование
• ожидание
• согласование
• переделки

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

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

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

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

Startup advisor или Fractional CTO часто делает это с помощью таблицы и получаса интервью. Это не модно. Но это работает, потому что превращает обвинения в наглядный путь. Когда путь виден, следующий шаг становится очевидным.

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

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

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

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

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

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

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

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

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

Ошибки, из-за которых делают неверный вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте этот короткий список:

• Мог ли вендор выпустить изменение без ожидания вашей команды?
• Был ли у последней задачи понятный объём, edge cases и правила приёмки?
• Крутились ли обращения в поддержку по одним и тем же людям, прежде чем кто-то их исправил?
• Зависит ли продукт от систем, API или вендоров, которые ваша команда разработки не может изменить?
• Упираются ли большинство задержанных задач в один и тот же блокер: согласование, доступ или недостающие данные?

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

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

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

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

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

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

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

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

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

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