InnerSource поощряет и вознаграждает сотрудничество и переиспользование кода кем угодно, независимо от организационной структуры компании. Это отличается от традиционных подходов, продукты и идеи в которых не выходят за пределы внутренней команды, а знания не распространяются по компании. Для примера рассмотрим ситуацию.
Представьте, две команды в одной компании одновременно разрабатывают разные независимые системы, и первая команда зависит от функционала другой. К примеру, это может быть команда, которая разрабатывает интерфейс и зависит от API, предоставляемого командой бекенда. Ситуация типичная для больших организаций, в которых центральная команда создаёт сервисы, от которых зависят другие команды.
Когда у зависящих команд много «хотелок», то есть функций, которые нужно добавить в центральный сервис, авторы этого сервиса, как правило, сортируют и приоритизируют поступающие требования и решают, над каким функционалом работать в первую очередь, оставляя менее важное на потом. И если внешней команде нужно получить функционал сейчас, а реализация откладывается, у этой команды есть три пути, в каждом из которых свои недостатки:
-
Подождать. Зависящая команда бездействует и обходится без необходимого функционала. Вариант требует минимальных вложений ресурсов у запрашивающей стороны. В зависимости от получаемой от этого функционала выгоды, вариант подождать может быть приемлимым. Однако, это доставляет неудобства, в особенности если запрашиваемый функционал не будет реализован совсем.
-
Обойти. Если нет желания или возможности ждать, то можно попытаться что-то сделать и как-то обойти проблему. Для этого нужно затратить ресурсы на изменение собственного продукта. Либо создать новый продукт, который будет удовлетворять потребностям и заменять функционал центрового продукта, который медленно меняется. Этот путь позволит команде получить необходимый функционал, задействуя только собственные ресурсы. Однако есть и недостатки:
-
Другие команды с похожими нуждами не смогут воспользоваться этим решением.
-
Вместе с продуктом, команда подписывается на долгосрочную поддержку и доработку системы, фактически принадлежащей другому бизнес домену
-
Организация получает ещё один дубликат проекта и кода, решающего одну и ту же проблему.
-
-
Эскалировать. Команда-потребитель может не принять отказ в доработке и попытаться эскалировать вопрос начальству. Этот путь выглядит привлекательным для зависящей команды, они получат функционал, не тратя ресурсов на его разработку, хотя им придется отвлекаться на эскалацию. К эскалации не получится прибегать слишком часто, так как это так или иначе подрывает доверие к команде. Для центральной команды этот путь крайне нежелателен, так как внеочередной функционал ломает их рабочий процесс и методы приоритизации задач.
И тут на сцену выходит InnerSource. InnerSource применяется в случаях, аналогичных примеру, когда одна команда не получает запрашиваемый функционал от другой. Решить эту проблему можно с помощью InnerSource, нивелируя недостатки каждого из трёх путей.
InnerSource также повышает инженерную культуру компании, позволяя разработчикам поработать с другими технологиями и командами. Разработчики учатся и менторят друг друга, распространяя знания и идеи по компании. Инженерные команды переиспользуют внутренние решения для похожих проблем и фокусируют своё внимание на более ценных для организации задачах.
