Список запретов для внешних инженеров до начала правок кода

Почему работа в первую неделю идёт не так\n\nВнешние инженеры редко создают проблемы из‑за небрежности. Проблемы начинаются потому, что они попадают в кодовую базу, полную скрытого контекста, неописанных правил и старых решений, которые никому не объяснили.\n\nНовый инженер может увидеть небольшую правку на странице тарифов и воспринять её как обычное изменение интерфейса. В вашем продукте та же страница может быть связана с логикой биллинга, лимитами пробных периодов, правилами скидок или вебхуком, от которого зависит бухгалтерия. Небольшая правка может остановить новые продажи за считанные часы.\n\nТо же самое случается в потоках входа, скриптах деплоя, админ‑инструментах и экспортных задачах. Для новичка эти области выглядят рутинными. Внутри команды они часто примыкают к выручке, данным клиентов или стабильности продакшна.\n\nСтарые привычки усугубляют ситуацию. Инженеры приносят рабочие привычки из других команд, и они часто логичны — просто не для вашей конкретной системы. Одна команда быстро выкатывает мелкие правки. Другая требует ревью на каждое изменение базы. Одна считает staging необязательным, другая не выпускает без тестового отката.\n\nЛюди часто думают, что здравый смысл заполнит пробелы. Не заполнит. Если границы не прописаны, новые люди будут принимать собственные решения. Иногда это проходит без последствий. Иногда это создаёт такую путаницу, которую убирают днями.\n\n## Что должен включать список запретов\n\nСписок запретов убирает домыслы. «Продакшн» — слишком расплывчато. Назовите точный репозиторий, сервер, панель, хранилище секретов, страницу настроек и рабочий процесс, которые могут сломать биллинг, логин, данные клиентов или релизы.\n\nДля большинства команд первая версия должна покрывать очевидные зоны риска: продакшн‑базы, бэкапы, скрипты миграций, аутентификация, биллинг, почта, DNS, настройки домена, пайплайны деплоя, сборочные скрипты, секреты, права в облаке, публичные API, вебхуки, задания экспорта и правила оповещений, которые могут скрыть настоящую проблему.\n\nДальше определите, какие действия всегда требуют одобрения до начала работы. Прямой доступ в прод — пример простой точки. Изменения в базе, правки инфраструктуры, изменения в платёжных потоках и любые новые сервисы, хранящие данные клиентов, тоже должны быть в списке.\n\nБудьте предельно ясны. Подрядчик должен понять за 10 секунд, может ли он действовать один или нужен зелёный свет.\n\nПолезно иметь одно простое правило для серых зон: если работа касается денег, личности, продакшн‑данных, хостинга или обещаний клиентам — остановитесь и спросите сначала. Одна строка спасёт от многих ошибок в первую неделю.\n\n## Назовите области, к которым никто не прикоснётся без разрешения\n\nБольшинство ранних ошибок возникают не из‑за плохого кода, а из‑за того, что кто‑то слишком рано полез в неправильную систему.\n\nНачните с денег и доступа. Если изменение может снять платёж, заблокировать аккаунт, стереть данные или остановить логины, никто не должен править это без согласия владельца этой части продукта.\n\nОбычно вне допуска оказываются знакомые вещи:\n\n- биллинг, платежи и логика подписок\n- аутентификация, роли пользователей и потоки сброса пароля\n- продакшн‑базы, исправления данных и скрипты миграций\n- настройки инфраструктуры: DNS, бэкапы, секреты и CI/CD\n\n- страницы цен, юридические тексты и письма клиентам\n\nКаждый из этих пунктов может быстро привести к дорогим последствиям. Изменение биллинга может списать деньги дважды. Правка в потоке пароля может заблокировать всех пользователей. Поспешный скрипт по базе может удалить правильные данные или оставить половину записей в неверном виде.\n\nИнфраструктура требует той же осторожности. Внешние инженеры не должны менять DNS, настройки деплоя, задания бэкапов или секреты продакшна только потому, что нашли файл. На маленькой команде одна неудачная правка в CI/CD может блокировать релизы на часы. Одна неверная настройка бэкапа может превратить мелкую ошибку в полный аутейдж.\n\nНеслужебный контент тоже в списке. Тексты о ценах, условия, формулировки по возвратам и писем клиентам влияют на выручку и доверие. Даже смена формулировки способна породить обращения в саппорт или юридический риск, если никто это не проверил.\n\n## Решите, кто утверждает каждый тип изменений\n\nВнешние инженеры тормозят команду, когда никто не знает, кто может сказать «да». Назначьте для каждого репозитория или сервиса одного ясного владельца и сделайте его дефолтным утверждающим для изменений в этой области.\n\nНе гоните все решения через одного человека. Доступ к данным нуждается в отдельном владельце — кто‑то, кто понимает записи клиентов, правила удержания, экспорты и бэкапы. Инженер может писать чистый код и при этом создать проблему, запросив не ту таблицу, изменив права или выплеснув приватные данные в логи.\n\nИзменения в инфре и деплоях тоже должны проходить через отдельного владельца. Секреты, CI‑задачи, DNS, контейнеры, правила масштабирования и настройки продакшна могут сломать продукт за минуты. Пусть это проходит через того, кто управляет окружением, а не только через владельца фичи.\n\nНебольшая карта утверждений хватает:\n\n- изменения кода приложения — владельцу репозитория или сервиса\n- чтение, запись, экспорт и правки схемы — владельцу данных\n- инфра, деплой и секреты — владельцу операций\n- простые правки копирайта или низкорискованный UI — через продукт или дизайн\n\nЭто правило важно. Если подрядчик меняет только метку кнопки или исправляет опечатку, ждать два дня старшего инженера не имеет смысла. Дайте быстрый путь для таких мелочей, но только если они не затрагивают логику, трекинг, биллинг или права.\n\nПропишите правило на случай, когда владелец недоступен. Владельцы уходят в офлайн, болеют или не видят сообщения. Установите окно ответа, затем назначьте второго утверждающего. Если никто не ответил вовремя — инженер должен остановиться и ждать. Домыслы — источник того, как небольшая правка превращается в аутейдж.\n\n## Пропишите правила отката до любой правки\n\nВнешние инженеры не должны ничего менять, пока путь отката не записан. «Мы потом всё поправим» — именно так маленькая правка превращается в долгий простои.\n\nПлан отката должен быстро ответить на один вопрос: что делаем в первые пять минут, если что‑то пошло не так?\n\nНачните с обратного шага. Если меняют feature‑флаг — запишите старое значение и где оно хранится. Если правят серверную настройку — сохраните текущий файл, запишите команду восстановления и прикрепите оба к таску. Никому не должно приходиться рыться в чате в поисках последней рабочей конфигурации.\n\nЭто особенно важно для данных. Если изменение касается записей клиентов, биллинга, логина или продакшн‑настроек — сначала сделайте бэкап или снапшот. Для правок базы до начала решите, хватит ли отката кода или нужно отдельное восстановление данных. Если никто не может ответить однозначно — работа не готова.\n\nБольшинству команд хватает короткого набора правил:\n\n- напишите шаг отката до первой правки\n- сохраняйте старые значения конфигураций и копии файлов в одном доступном месте\n- делайте бэкап или снапшот перед рискованными изменениями данных\n- установите жёсткий лимит на попытки отката, например 10–15 минут\n- отменяйте изменение, если безопасного пути отката нет\n\nЭтот лимит важнее, чем думают. Команды часто продолжают ковыряться в упавшем деплое, потому что кажется, что они близки к решению. Тогда 10 минут превращаются в час. Жёсткое ограничение сдерживает масштаб ущерба.\n\nЭто не бюрократия — это дешёвая страховка. Одна короткая запись, сохранённая конфигурация и снапшот могут сберечь маленькую команду от недели уборки последствий.\n\n## Делайте день‑первый доступ в правильном порядке\n\nПорядок важен. Если внешнему инженеру дали доступ до появления правил, люди заполняют пробелы домыслами. Домыслы быстро становятся дорогими.\n\nСначала видимость, а не контроль. Опишите, что они могут видеть в первый день: доску тасков, стейджинг‑приложение, логи, документацию и тестовые данные. Если им пока не нужен доступ к системе — не давайте его. Ограниченный доступ упрощает ревью ранней работы.\n\nДалее напишите список запретов простым языком. Без политических формулировок. Скажите: «Не меняйте продакшн‑настройки биллинга.» Скажите: «Не запускайте миграции базы.» Скажите: «Не правьте живые шаблоны писем.» Чёткие границы предотвращают распространённую ошибку первой недели, когда кто‑то думает, что маленькое изменение безвредно.\n\nПрикрепите к каждой рискованной операции ответственного утверждающего. Для деплоя это может быть тим‑лид. Для правки схемы — CTO. Доступ к записям клиентов может требовать двух согласований. Если никто не знает, кто утверждает — ответ должен быть «нет».\n\nПосле этого добавьте шаги по откату для частых задач. Делайте их достаточно короткими, чтобы ими можно было воспользоваться в стрессовой ситуации. Для большинства команд базовый сценарий простой: откатить коммит или конфигурацию, восстановить последнюю рабочую версию, проверить логи и оповещения, сразу сообщить владельцу и приостановить дальнейшую работу до стабилизации сервиса.\n\nЗакончите коротким обзором перед выдачей доступа. Десятиминутный звонок часто спасает целый день уборки.\n\n## Дайте внешним инженерам безопасную стартовую работу\n\nНе начинайте с живых данных, платёжных потоков или глубоких бэкенд‑правок. Первая неделя должна научить, как в вашей команде называются вещи, как вы релизите и как замечаете риски. Выбирайте задачи, которые легко проверить и легко откатить.\n\nДокументация — хороший старт. Попросите поправить шаги установки, обновить скриншоты или привести в порядок руководы, которым никто не доверяет. Так вы увидите, насколько тщательно человек читает, а команда получает полезный результат, даже если подрядчик не трогал продакшн‑код.\n\nНебольшие баги интерфейса — ещё один безопасный вариант. Берите низкорискованные страницы: экран настроек, внутреннюю панель или справочную страницу. Избегайте всего, что связано с платежами, авторизацией, удалением аккаунтов или записями клиентов, пока подрядчик не отработает правила без проблем.\n\nСтарый хрупкий код тоже даёт безопасный путь. Вместо переписывания попросите добавить тесты вокруг участка, которого все боятся. Хороший подрядчик добавит покрытие, опишет странное поведение и покажет, где будущие изменения могут сломать систему.\n\nАудиты в режиме «только чтение» дают сигнал без риска. Пусть посмотрят логи, отчёты об ошибках и дашборды мониторинга, а затем напишут короткое заключение. Это часто ловит громкие алерты, повторяющиеся сбои или плохую практику релизов до того, как кто‑то начнёт рискованную правку.\n\nПрактическая последовательность первой недели может выглядеть так:\n\n- почистить документацию или рук��вод\n- исправить одну мелкую проблему UI\n- добавить тесты вокруг хрупкого кода\n- просмотреть логи и группы ошибок в режиме только чтение\n- отложить работу с данными клиентов, пока правила не заработают на практике\n\nЭта последовательность не захватывает воображение, и в этом смысл. Безопасная стартовая работа показывает, задаёт ли человек правильные вопросы, уважает ли лимиты и оставляет ли код чуть лучше, чем нашёл.\n\n## Простой пример из небольшой продуктовой команды\n\nНебольшая SaaS‑команда привлекает подрядчика на две недели перед обновлением цен. Нужно быстро, но свободы на первый день не дают. Их список запретов короткий и понятный: не трогать код биллинга, настройки платёжного провайдера, налоговые правила или живую конфигурацию вебхуков без письменного одобрения.\n\nПоэтому первая задача остаётся маленькой. Подрядчик работает только с текстами на странице оформления заказа: обновляет заголовок, укорачивает примечание о возвратах и исправляет непонятную подпись поля, которая порождала тикеты в поддержку. Работа важна, но она не ломает поток денег.\n\nКоманда явно рисует границы. Копирайт живёт в одном месте приложения, платёжная логика — в другом. Настройки вебхуков остаются за админом, к которому у подрядчика нет доступа. Код биллинга лежит в защищённой зоне, и тим‑лид не разрешает правки там, пока подрядчик не получит контекст.\n\nПродакт менеджер утверждает правку текста до релиза. Это кажется базовым, но предотвращает обычную проблему: инженеры догадываются с формулировками и меняют юридический смысл, намерение ценообразования или обещания поддержки.\n\nПодрядчик выпускает изменения в небольшом окне релиза поздним днём, когда и продакт, и инженер на месте. Запись по откату уже в тикете: revert commit 8f3c, восстановить старые строки оформления и проверить текст на проде. Если саппорт увидит всплеск обращений, команда отменит изменение за минуты.\n\nНичего драматического не происходит. В этом и смысл. Подрядчик сделал полезную работу, команда приобрела доверие, и никто не провёл вечер в фиксе платежного сбоя из‑за «маленькой правки».\n\n## Ошибки, которые быстро становятся дорогими\n\nВыдать подрядчику админ‑доступ в прод «прямо на сегодня» удобно примерно один день. Потом никто не помнит, что именно можно менять, что уже тронуто и как ограничить последствия, если что‑то сломается.\n\nСообщение в чате — ещё одна западня. «Выглядит нормально» или «сделай это, пожалуйста» — это не процесс утверждения. Такое сообщение не фиксирует, какую систему можно менять, кто владеет риском и кто подпишется, если пострадают пользователи. При биллинге, авторизации или данных клиентов расплывчатое одобрение почти равно его отсутствию.\n\nПравки в пятницу проблематичны: люди уезжают на выходные. Если до изменения не сделали заметки по откату, команде придётся действовать в догадках под давлением.\n\nСтарые документы создают тихую гавань проблем. Многие думают, что правила онбординга у них есть, но они лежат в устаревшей папке, которую никто не открывает. Внешние инженеры действуют по тому, что видят в первый день. Если список запретов спрятан — они заполнят пробел своими суждениями.\n\nРавный доступ — ещё одна дорогостоящая ошибка. Подрядчикам не нужны те же права, что у сотрудников с опытом, которые знают историю продукта, влияние на клиентов и старые схемы инцидентов. Широкие права превращают узкую задачу в риск для всей компании.\n\nСтоимость проявляется быстро:\n\n- неудачный деплой, который останавливает регистра��ю или платежи\n- правка базы, которую нельзя полностью откатить\n- ночная паника у людей, не причастных к изменению\n- утечка безопасности из‑за того, что слишком много аккаунтов имеют доступ в прод\n\nМаленькая команда избежит большей части этого одним листом правил: назовите запрещённые зоны, требуйте именных утверждений, ограничьте доступ под задачу и блокируйте пятничные правки без заметки по откату.\n\n## Бычная проверка перед стартом\n\nКороткая предварительная проверка предотвращает большинство ошибок первой недели. Занимает около 10 минут и экономит дни уборки, неловких звонков и неожиданных простоев.\n\nПопросите инженера проговорить ограничения вслух. Если он не может перечислить системы, в которые нельзя лезть, значит, он ещё не готов. Это особенно важно для биллинга, продакшн‑данных, авторизации, бэкапов, CI/CD и клиентских систем.\n\nПроверьте цепочку утверждений. Он должен точно знать, кто утверждает код, кто — работу с данными и кто — правки инфраструктуры. Если ответ «команда» или «кто‑то в Slack», остановитесь и назначьте имя для каждой области.\n\nДайте минимально достаточный уровень доступа, который всё ещё позволяет делать полезную работу. Часто на первый день достаточно прав только для чтения. Так можно смотреть логи, читать код и изучать систему, не внося случайных изменений.\n\nПеред первой правкой попросите объяснить план отката простыми словами. Если правка конфигурации — как её отменить? Если миграция — как восстановить? Если ответ расплывчат — изменение не готово.\n\nНебольшая итоговая проверка:\n\n- он может перечислить системы и папки, к которым нельзя прикасаться\n- он знает, кто утверждает код, данные и инфру\n- у него права только для чтения там, где запись не нужна\n- он может описать, как откатить первую планируемую правку\n- один человек владеет финальным решением «да/нет»\n\nЛюди работают лучше, когда линии ясны. Команды тоже. Подрядчик, который стартует с безопасными границами, обычно движется быстрее к третьему дню, чем тот, кому дали широкий доступ сразу.\n\n## Что делать дальше\n\nСделайте правила на одной странице и убедитесь, что её невозможно не заметить. Подрядчик должен увидеть её до получения доступа, а не после первого pull request. Если ему нужно спрашивать, где лежат правила — настройка уже слишком свободная.\n\nДержите документ простым и конкретным. Он должен указывать зоны, которых нельзя касаться, кто утверждает каждый тип изменения и какой шаг отката применяется при проблеме. Добавьте контакты для оперативных ответов.\n\nБольшинству одномстраничных онбордингов хватает пяти вещей:\n\n- запрещённые системы, файлы и окружения\n- имена утверждающих для кода, данных, инфры и прод‑изменений\n- шаги отката для каждого рискованного типа правки\n- ограничения доступа на первую неделю\n- одно место для сообщений о блокерах или неясностях\n\nПосле первой недели подрядчика просмотрите, что вызывало трения. Ищите повторяющиеся вопросы, медленные утверждения и любые правки, которые казались рискованнее, чем ожидаемо. Перепишите спорные места до следующего человека. Если правило однажды вызвало путаницу — исправьте его текст до следующего старта.\n\nМаленькие команды часто оставляют эту работу без явного владельца. Отсюда и начинаются дорогие ошибки. Если никто не может чётко сказать, что запрещено, кто утверждает и как откатиться — найдите того, кто возьмёт на себя картину в целом. Для стартапов и маленьких команд это часто значит привлечение временного CTO.\n\nOleg Sotnikov на oleg.is делает подобную работу со стартапами: прокладывает пути утверждений, определяет границы продакшна и прописывает практические правила развёртывания до того, как внешние инженеры начнут менять чувствительные системы. Такое наблюдение не бросается в глаза, но предотвращает ошибки первой недели, которые отнимают два дня и подрывают доверие в команде.