Короткий ответ

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

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

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

Почему это минное поле, а не просто незнакомый проект

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

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

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

Задача узкая, ответственность — за весь портал

Клиент формулирует запрос конкретно: «настройте вот это», «доделайте вот то». Он не просит разобрать всё — и не должен: он платит за результат, а не за экскурсию по собственному порталу.

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

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

Как разбирать, чтобы не задеть чужое

Порядок, который снижает риск подорваться на чужой настройке:

  1. Выписать всё, что связано с зоной задачи — стадии, роботы, бизнес-процессы, поля, права. Не всё на портале, а всё вокруг конкретного участка.
  2. Восстановить логику каждого найденного элемента. Не «что он делает», а «зачем он здесь» — иначе легко принять важную настройку за мусор.
  3. Проверить связи наружу. Не завязан ли элемент из зоны задачи на что-то за её пределами — на другую воронку, на внешнюю интеграцию, на смежный отдел.
  4. Зафиксировать находки письменно до того, как начинать правки. Не для отчётности — чтобы не полагаться на память через неделю, когда деталей накопится больше, чем можно удержать в голове.
  5. Менять по одному элементу, проверяя после каждого шага, что не сломалось смежное.

Это медленнее, чем «переделать по-своему». Но переделка по-своему на чужом портале означает снести то, за что клиент уже заплатил прошлому подрядчику и чем реально пользуется.

Несколько интеграторов на одном портале одновременно

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

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

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

Что даёт документация проекта

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

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

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

Что сделать, если вы клиент

  1. Требуйте документацию как часть проекта, а не бонус. Раздел настройки — минимум: что сделано, зачем, с чем связано.
  2. Не экономьте на ней при смене подрядчика. Дешевле оплатить час на актуализацию документа сейчас, чем оплатить недели реконструкции следующему.
  3. При параллельной работе нескольких подрядчиков — письменно фиксируйте, кто что меняет, и держите это в одном месте, доступном всем.

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

Чтобы понять, что у вас на портале, — закажите аудит Битрикс24.