Техническая очистка перед наймом инженеров: что исправить в первую очередь

Почему найм первым делом может только усугубить хаос

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

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

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

Это не онбординг. Это задержка.

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

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

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

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

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

Начните с доступов и админ-контроля

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

Начните с простого списка. Запишите все места, где можно менять код, инфраструктуру, биллинг или доступ клиентов. Включите туда репозитории, облачные аккаунты, домены, консоли app store, CI, аналитику, мониторинг, доставку писем, саппорт-инструменты и любую админ-панель, где можно менять настройки.

Обычной таблицы достаточно, если для каждой системы она отвечает на такие вопросы:

• Что контролирует этот аккаунт?
• У кого сейчас есть админ-доступ?
• Какой email им владеет?
• Где лежат шаги восстановления и резервные коды?

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

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

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

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

Проверьте контроль над вендорами и биллинг

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

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

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

Для каждого сервиса проверьте четыре вещи: кто владеет аккаунтом, кто оплачивает счет, у кого есть админ-права и как вы выгружаете данные. Если ответ зависит от одного человека, начните исправление с этого.

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

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

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

Определите права на релизы до роста команды

Растущая команда без правил релиза может превратить небольшую ошибку в простой.

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

Запишите роли по релизу простым языком. Не оставляйте их в сообщениях Slack или в чьей-то голове. Достаточно простой таблицы, если она отвечает на такие вопросы:

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

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

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

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

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

Нарисуйте границы продукта на бумаге

Большинство команд говорят «продукт», будто это что-то одно. Обычно это не так.

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

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

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

Для каждой области запишите четыре вещи:

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

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

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

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

Небольшая продуктовая команда может нарисовать такую карту меньше чем за час. У SaaS-компании на этой карте могут быть dashboard и onboarding как основные функции, refund tool и support panel как внутренние инструменты, а функция AI summary — как эксперимент. Когда карта готова, найм становится проще. Новые инженеры понимают, где можно двигаться быстро, где нужен approval и какие части могут навредить за пределами их зоны.

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

План очистки на 30 дней

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

Дни 1–3 уходят на сбор фактов. Соберите в одну таблицу все аккаунты, домены, облачные сервисы, хосты кода, аналитические инструменты, ящики поддержки, платежные аккаунты и записи app store. Добавьте текущего владельца, контакт для биллинга, способ входа и срок договора. Если никто не знает, кто оплачивает сервис или кто может его отменить, поднимите этот пункт в начале списка.

Дни 4–10 посвящены админ-контролю. Переведите общие логины на именные аккаунты, дайте владельцу компании доступ ко всем критически важным системам и включите MFA везде, где можно. Уберите бывших сотрудников, старых подрядчиков и лишних админов. Эта часть скучная, но она убирает самые неприятные сюрпризы.

Дни 11–20 — про владение релизами и восстановление. Решите, кто может пушить код, утверждать изменения в продакшене, ротировать секреты, восстанавливать бэкапы и публиковать в app store. Потом проверьте это на практике. Бэкап, который никто не может восстановить, — это просто счет.

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

Дни 21–30 — это границы продукта. Разложите продукт на бумаге: что команда владеет сама, что находится у вендора, что является кастомным кодом, а что на самом деле является ручным бизнес-процессом, замаскированным под софт. Команды двигаются быстрее, когда понимают, какие изменения простые, какие требуют миграции, а какие запросы вообще не должны входить в объем работ.

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

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

Типичные ошибки во время очистки

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

Есть несколько ошибок, которые повторяются снова и снова.

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

Еще одна частая ошибка — оставлять аккаунт вендора в почте бывшего сотрудника. Так часто бывает с облачным хостингом, регистраторами доменов, аккаунтами разработчика Apple или Google и billing dashboards. Один заблокированный ящик может остановить счета, изменения DNS или обновление приложения.

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

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

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

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

Именно здесь помогает опытный fractional CTO. Внешний человек обычно быстро видит пробелы. Кто владеет DNS? Кто может утвердить релиз? Кто восстановит хост кода, если главный админ исчезнет? Ответы на такие вопросы должны быть скучными и ясными.

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

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

Проверьте это сначала:

• У компании есть доступ ко всем репозиториям, облачным аккаунтам, доменам, аккаунтам app store, инструментам аналитики и продакшен-дашбордам без зависимости от одного человека.
• Один руководитель видит все счета вендоров, даты продления, владельцев договоров и способы оплаты в одном месте.
• Команда может выкатить релиз и откатить его даже если обычный ответственный болеет, спит или уже ушел.
• У каждой части продукта есть один владелец.
• Новый инженер может прочитать документацию, запустить продукт локально или в тестовой среде и понять основы за один рабочий день.

Если не проходит один или два пункта, исправьте это до увеличения штата. Если не проходят три, проблема не в найме. Проблема в контроле.

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

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

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

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

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

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

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

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

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

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

Вот как выглядит эта работа на практике. Она не драматична, но очень быстро экономит время.

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

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

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

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

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

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

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

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

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

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