Знакомая ситуация: вашей команде нужна фича в чужом сервисе, вы ставите задачу — и ждёте. Неделю, месяц, квартал. Потому что у того сервиса свои приоритеты и свой ограниченный ресурс. А ваш продукт стоит.

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

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

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

---

Привет, Хабр! Меня зовут Екатерина, я Python-разработчица в Островке. Последние два года я работаю в формате иннерсорсинга: реализую задачи в кодовой базе другого сервиса и участвую в согласованиях вокруг процесса — от ревью и архитектурных решений до поддержки после релиза. 

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

Что мы называем иннерсорсингом 

Иннерсорсинг, или InnerSource, — это применение практик open source внутри компании. Если команде нужны изменения в сервисе, которым владеет другая команда, она не только ставит задачу и ждёт своей очереди, а сама участвует в реализации: пишет код, проходит ревью и работает по правилам принимающего сервиса.

Чем иннерсорсинг не является:

• Не разовая помощь соседней команде. Один MR может закрыть конкретную задачу, но не решает системную зависимость. Иннерсорсинг — это регулярный процесс с выделенным ресурсом, понятным скоупом и договорённостями между командами.

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

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

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

Почему обычный процесс перестал нас устраивать

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

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

Результат: сервисы транспортных команд ждали свои фичи кварталами.

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

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

Со временем вокруг такого подхода может сформироваться отдельная иннерсорсинг-команда. В нашем случае в неё вошли backend-разработчик, QA и frontend-разработчик (при этом он также работает над задачами в сервисе продукта).

Руководители сервисов обсудили формат, согласовали процесс — и мы начали.

Разбираем два варианта реализации

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

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

Вариант 1: Разработчик из принимающего сервиса → продуктовая сторона

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

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

Плюсы этого варианта:

• разработчик знает кодовую базу с первого дня;

• проще проходить ревью и обсуждать спорные решения;

• ниже сопротивление со стороны принимающего сервиса: человек уже знаком команде и её правилам;

• меньше нагрузка на принимающую команду на этапе онбординга.

Минусы:

• принимающий сервис фактически отдаёт разработчика в другое направление;

• продуктовый контекст нужно наращивать отдельно;

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

• от разработчика требуется высокая самостоятельность.

Вариант 2: Разработчик из продуктовой команды → принимающий сервис

Человек из продуктовой команды начинает писать код в принимающем сервисе. Бюджеты и команды не меняются.

Такой сценарий попробовала ещё одна команда в Островке, которая решила повторить наш опыт иннерсорсинга: их разработчик начал работать в кодовой базе CRM. 

Плюсы этого варианта:

• разработчик хорошо понимает продукт и бизнес-требования;

• не нужно согласовывать переход сотрудника между командами;

• продуктовая команда сохраняет ресурс внутри себя;

• проще связать реализацию с продуктовыми приоритетами.

Минусы:

• требуется серьёзное погружение в чужую кодовую базу;

• на старте выше нагрузка на принимающий сервис;

• больше риск переделок из-за незнания внутренних правил и архитектурных ограничений;

• сопротивление со стороны команды-владельца может быть выше.

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

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

Анатомия процесса: ключевые компоненты

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

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

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

1.  Онбординг: чего не хватает на старте 

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

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

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

Со стороны принимающего сервиса:

• Назначение ментора 

• Встреча с командой иннерсорсинга: презентация сервиса, рассказ об его особенностях

• Подготовка документации по архитектуре 

Со стороны команды иннерсорсинга:

• Планирование первых задач с постепенным увеличением сложности

2. Ревью: почему доступ к репозиторию ничего не решает 

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

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

• Ревью делает закреплённый человек из принимающего сервиса

• Ревью распределяется по code owners

• Ревью делает тот, кто свободен и имеет экспертизу в нужной области

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

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

3. QA: как не потерять продуктовый и системный контекст  

С QA в иннерсорсинге тоже нужно договариваться отдельно. Изменения пишет продуктовая сторона, но код попадает в сервис, за стабильность которого отвечает принимающая команда. Поэтому вопрос «кто тестирует?» не такой простой, как может показаться.

Мы рассматривали три варианта.

1. Всю QA делает принимающий сервис (в нашем случае — B2B) — минимум нагрузки на продуктовую команду, но QA B2B может не понимать продуктовый контекст.

2. Совместная работа: продуктовая команда документирует тест-кейсы, QA обоих сервисов прорабатывает их вместе.

3. Всю QA делает продуктовая команда — хорошее знание продукта, но может не хватать знания ограничений B2B-сервиса.

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

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

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

4. Поддержка после релиза: кому жить с этим кодом 

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

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

Чтобы снизить риск при поддержке, мы договорились о нескольких правилах:

• документировать значимые изменения: через комментарии в коде или описание нестандартных решений;

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

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

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

5. Архитектура: где заканчивается автономия продуктовой команды 

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

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

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

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

В другом случае архитектурное обсуждение привело не к добавлению логики в общий сервис, а к выносу части сценариев в отдельный checkout-сервис. Так мы сделали ещё один шаг в сторону юнитизации: часть логики перестала жить внутри большого общего сервиса, а продуктовая команда получила больше автономии. Для этого мы подготовили SAD — Solution Architecture Document — и согласовали решение с принимающей командой: новый сервис должен был развиваться автономнее, но при этом корректно встраиваться в существующий контур.

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

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

6. Техдолг: почему важно не оставлять «на потом» 

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

Конечно, это «потом» почти никогда не наступает само.

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

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

7. Доверие: как снизить сопротивление принимающего сервиса 

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

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

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

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

Что изменилось для команд и участников процесса 

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

Эффект оказался заметным в отношении всех причастных к процессу:

Для Delivery

Мы не заводили отдельную метрику time-to-delivery для иннерсорсинга с точностью до дня, но по 22 проектам видим устойчивый паттерн. Задачи, которые раньше попадали в общий бэклог принимающего сервиса, долго ждали своего часа ещё до полноценного discovery: в итоге их реализация затягивалась на несколько кварталов. Через иннерсорсинг такие задачи в ряде случаев удавалось доводить до релиза в пределах одного квартального цикла. В первую очередь — за счёт более быстрого старта разработки. 

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

Для продуктовой стороны

Главный профит — предсказуемость. Мы можем планировать задачи, которые требуют изменений в принимающем сервисе, внутри своего roadmap и заранее понимать, где понадобится ревью, архитектурный апрув или участие QA.

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

Для принимающего сервиса

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

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

Для разработчика

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

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

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

Чек-лист: что проверить перед запуском иннерсорсинга 

Под спойлером — подробный чек-лист по организации процесса.

1. Понятно, какую проблему решаем:

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

• у принимающего сервиса есть свой бэклог и свои приоритеты;

• задачи продуктовой команды регулярно откладываются из-за нехватки ресурса у принимающего сервиса;

• ожидание влияет на delivery продуктового направления;

• у продуктовой команды есть мотивация и ресурс самой участвовать в реализации.

2. Согласован скоуп иннерсорсинга:

• какие типы задач подходят для иннерсорсинга;

• какие изменения требуют отдельного архитектурного согласования;

• какие зоны кодовой базы доступны для изменений;

• какие сценарии нельзя менять без участия команды-владельца;

• как эскалировать спорные решения.

3. Кто иннерсорсит и как устроена команда: 

• какой сценарий подходит: разработчик из принимающего сервиса переходит на продуктовую сторону или разработчик из продуктовой команды приходит в принимающий сервис;

• формируется ли отдельная иннерсорсинг-команда или задачу закрывает один разработчик внутри продуктовой команды;

• готов ли принимающий сервис выделить время на онбординг и ревью;

• как изменится нагрузка на команды при выбранном формате.

4. Есть поддержка руководителей:

• руководители команд согласовали формат;

• понятно, чей бэклог двигает иннерсорс-разработчик;

• принимающий сервис понимает, какую роль он сохраняет в процессе;

• продуктовая сторона понимает, что берёт на себя не только реализацию, но и часть ответственности за контекст, QA и техдолг;

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

5. Онбординг не оставлен «по ходу дела»:

• назначен ментор или технический контакт со стороны принимающего сервиса;

• проведена встреча с командой сервиса;

• разработчику объяснили особенности архитектуры и процессов;

• есть документация по сервису;

• первые задачи подобраны с постепенным ростом сложности;

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

6. Назначен технический контакт в принимающем сервисе:

• кто ревьюит изменения;

• как быстро этот человек может подключаться;

• кто помогает с архитектурными вопросами;

• к кому идти, если MR блокирует релиз;

• кто помогает понять внутренние ограничения сервиса.

7. Описан процесс code review:

• ревью делает закреплённый человек, code owners или свободный эксперт;

• у принимающего сервиса есть выделенный ресурс на проверку изменений;

• продуктовая команда понимает, сколько времени может занимать ревью;

• есть способ эскалации, если MR блокирует релиз;

• MR описываются достаточно подробно: что сделали, зачем, какие сценарии затронули, какие компромиссы приняли.

8. QA-модель согласована заранее:

• кто описывает продуктовые тест-кейсы;

• кто проверяет влияние на общий контур сервиса;

• какие сценарии должна покрыть продуктовая команда;

• что дополнительно смотрит принимающий сервис;

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

• кто отвечает за проверку регрессий в связанных процессах.

9. Ownership после релиза не размыт:

• принимающей команде передан эксплуатационный контекст;

• описано, какие сценарии затронуты;

• понятно, где смотреть логи и метрики;

• указаны признаки возможной проблемы;

• понятно, когда подключать иннерсорс-разработчика;

• значимые изменения задокументированы через ADR, комментарии в коде или отдельное описание;

• после релиза принимающая команда знает, что фича реализована и работает.

10. Архитектурные решения согласуются до реализации:

• какие решения иннерсорс-разработчик может принимать самостоятельно;

• какие требуют согласования с принимающим сервисом;

• кто имеет последнее слово по архитектуре;

• нужно ли готовить SAD или другой документ по решению;

• обсуждены ли границы ответственности;

• понятно ли, где должна жить новая логика;

• оценено ли влияние на соседние сценарии и общий контур.

11. Техдолг фиксируется сразу:

• временные решения явно описаны;

• у каждого компромисса есть владелец;

• понятно, когда к нему вернутся;

• техдолг не остаётся в формате «потом поправим»;

• продуктовая сторона закладывает ресурс на закрытие техдолга по своим изменениям;

• принимающий сервис понимает риски и согласовал подход.

12. Доверие между командами строится процессом:

• MR понятны и хорошо описаны;

• спорные решения согласуются рано;

• документация не откладывается на потом;

• иннерсорс-разработчик уважает правила принимающего сервиса;

• команда заранее объясняет, зачем вносится изменение;

• после релиза нет неожиданных изменений без контекста;

• есть регулярные точки синхронизации.

13. Разработчик готов к роли на стыке команд:

• разработчик готов самостоятельно разбираться в технических решениях;

• умеет договариваться с несколькими командами;

• не воспринимает замечания принимающего сервиса как личную критику;

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

• подробно описывает MR;

• умеет объяснять компромиссы;

• готов быть точкой входа для вопросов по изменениям после релиза.

14. Понятно, как измерять эффект:

• какие задачи раньше ждали ресурса принимающего сервиса;

• какие из них теперь можно стартовать быстрее;

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

• доходят ли задачи до релиза в пределах планового цикла;

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

• стал ли процесс взаимодействия с принимающим сервисом предсказуемее.

И короткая версия чек-листа, которую можно использовать как памятку перед запуском процесса:

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

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

---

• TG-канал Ostrovok! Tech