Аудит аутсорсной разработки, когда проекту нужен перезапуск

Когда проекту нужен перезапуск

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

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

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

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

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

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

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

Что должен ответить двухнедельный аудит

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

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

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

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

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

К концу аудита вам нужны четыре простых ответа:

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

Этот список дает первый честный план перезапуска.

Сначала задайте границы

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

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

До первой рабочей сессии соберите базовые вещи:

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

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

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

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

Внешний советник или фракционный CTO может вести процесс, но со стороны клиента все равно нужен один владелец, который сможет выбирать между вариантами и принимать неприятные выводы.

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

Проведите аудит по шагам

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

Дни 1–5

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

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

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

Дни 6–14

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

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

Последние четыре дня используйте, чтобы написать план перезапуска. Он должен быть коротким и прямым. В нем нужно указать:

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

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

Разделите сборку на «оставить», «исправить» или «заменить»

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

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

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

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

Полезно использовать простой фильтр:

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

Не останавливайтесь на ярлыке. Добавьте к каждому пункту четыре заметки: примерную трудоемкость, владельца, следующий шаг и срок первого контрольного созвона. Трудоемкость можно писать просто: 1 день, 1 неделя или 1 спринт. Владельцем должен быть реальный человек, а не «подрядчик» и не «команда разработки». Следующий шаг должен быть конкретным, например «добавить тесты вокруг оплаты» или «перенести деплой со старого сервера».

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

Найдите пробелы в ответственности

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

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

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

Аудит должен проверить и бизнес-логику, которая обычно живет у кого-то в голове. Спросите, кто понимает:

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

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

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

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

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

Простой пример для стартапа

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

Потом продукт начинают использовать реальные клиенты.

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

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

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

В этом случае ответ довольно понятен:

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

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

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

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

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

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

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

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

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

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

Лучше поступить проще:

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

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

Быстрые проверки перед тем, как одобрить перезапуск

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

Эти проверки специально простые. Они быстро показывают, найдет ли аудит реальные операционные проблемы или просто подтвердит то, что вы и так подозревали.

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

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

Что делать после аудита

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

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

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

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

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

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

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

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