В 2020 году сообщество InnerSource Commons представило
паттерны InnerSource, описывающие лучшие практики применения InnerSource в едином и структурированном формате. Такой формат упрощает понимание, оценку и повторное использование практик, а также предоставляет участникам сообщества общий язык для краткого и однозначного обмена знаниями. Это способствует системному развитию практик InnerSource внутри организаций. Каждый паттерн описывается через набор стандартных разделов: название (Title), формулировка проблемы (Problem Statement), контекст (Context), силы (Forces) и решения (Solutions).
Одним из таких паттернов является
модель зрелости InnerSource, предназначенная для оценки уровня зрелости команд и выявления паттернов и практик, с которыми они ранее могли быть не знакомы. По мере развития InnerSource в организации команды часто сталкиваются с ограниченным пониманием доступных и проверенных подходов, которые могли бы помочь им перейти на следующий уровень зрелости. При этом набор проблем и болевых точек различается от команды к команде и зависит от их контекста и рабочей среды, что делает единое представление о лучших практиках особенно важным.
Модель зрелости InnerSource структурирована по четырем ключевым областям:
Transparency (Прозрачность),
Collaboration (Сотрудничество),
Community (Сообщество) и
Governance (Управление). Каждая область описывает отдельный аспект организационной, культурной и процессной зрелости InnerSource и отражает, насколько системно и последовательно практика применяется в организации. Внутри каждой области выделяются конкретные направления, описывающие отдельные практики, механизмы или поведенческие паттерны, критичные для устойчивого развития InnerSource.
Каждое направление представлено в виде четырех уровней зрелости:
- Level 0 — Accidental (Individual initiatives). Практики возникают случайно в виде отдельных индивидуальных инициатив и не имеют организационной поддержки;
- Level 1 — Exploration (Let’s try this). Организация и команды находятся на этапе экспериментирования, осознанно пробуют новые подходы, однако их применение остается ограниченным и нестабильным;
- Level 2 — Adoption (Corporate support). Практики получают поддержку на уровне организации, формализуются и начинают системно внедряться и масштабироваться;
- Level 3 — Efficient (Widely adopted). Практики широко распространены, последовательно применяются и глубоко интегрированы в повседневные процессы организации.
Transparency (Прозрачность)Plans & Products (Планы и продукты). Проекты InnerSource выигрывают от прозрачного планирования на уровне всей организации, так как это позволяет заинтересованным сторонам лучше понимать принимаемые решения и влиять на них таким образом, чтобы этот процесс был прозрачен и воспроизводим для других.
- PP-0. Отдельные специалисты и команды не раскрывают свои планы или продукты на регулярной основе для нескольких заинтересованных сторон. В организации отсутствуют формализованные действия в этой области.
- PP-1. Отдельные специалисты и команды обеспечивают видимость своих планов или продуктов для нескольких заинтересованных сторон до начала их реализации. Используется общий roadmap.
- PP-2. Существуют общие roadmap с четкими рекомендациями и правилами участия, в рамках которых заинтересованные стороны могут предоставлять обратную связь. Однако данный подход не стандартизирован на уровне всей организации, и не все проекты предоставляют такую информацию.
- PP-3. Roadmap публикуются по умолчанию, и в организации существует стандартный процесс и единый подход к их ведению на уровне каждого проекта InnerSource. Этот подход включает четкие правила участия и влияния на roadmap.
Development Process & Tools (Процессы разработки и инструменты). Проекты InnerSource развиваются наиболее эффективно, когда участники становятся активными и вовлеченными в совместную работу. В связи с этим упрощение процесса внесения вклада должно быть сбалансировано с достижением чисто технических целей.
- DP-0. Каждая команда следует собственным процессам разработки и использует свои инструменты. Эти процессы и инструменты не предназначены для обмена знаниями и артефактами за пределами команды разработки. Команды разработки изолированы друг от друга.
- DP-1. Команды разработки используют общие репозитории кода внутри организации. Некоторые команды разрабатывают собственные процессы CI (Continuous Integration), используя некорпоративные или нестандартные инструменты CI. Процесс code review не определен, хотя отдельные проектные команды применяют его внутри своих проектов.
- DP-2. Организация поддерживает и продвигает общий репозиторий для коллективного накопления знаний. Некоторые команды разрабатывают собственные процессы CI, используя корпоративные инструменты CI. Существуют CI-окружения. Процесс code review определен и используется в ряде проектов. В отдельных случаях code review выполняется участниками из других команд.
- DP-3. Большинство команд разрабатывают собственные процессы CI, используя корпоративные инструменты CI. Существуют CI-окружения. Процесс code review определен и используется. Code review выполняется как участниками команды, так и представителями других команд.
Decisions (Принятие решений). Для того чтобы мотивировать коллег вносить вклад в работу за пределами своей основной команды, им необходима прозрачность процесса принятия решений (decision-making process) в принимающем проекте, а также ощущение того, что их мнение услышано и имеет ценность.
- DC-0. Лица, принимающие решения, часто намеренно или непреднамеренно удерживают данные и ресурсы, связанные с проектными решениями.
- DC-1. Материалы, относящиеся к практикам принятия решений, становятся доступными для ознакомления после того, как решения уже приняты.
- DC-2. Сотрудники чувствуют, что они осведомлены о большинстве, но не обо всех, важных решениях и помогают формировать их по мере принятия. Материалы, относящиеся к практикам принятия решений, доступны в определенные контрольные точки проекта.
- DC-3. Сотрудники ощущают себя частью общего стандартизированного процесса коллективного принятия решений, который поддерживается организацией. Материалы, относящиеся к практикам принятия решений, доступны на постоянной основе в ходе рабочих процессов.
Helpful Resources (Полезные ресурсы). Для привлечения участников вспомогательные материалы должны быть легко доступны.
- RS-0. Отдельные специалисты и команды не вносят вклад в общий репозиторий знаний (shared repository of knowledge) и не используют его.
- RS-1. Отдельные специалисты и команды публикуют материалы проектов для внутреннего ознакомления после завершения своей работы. Специалисты и команды обмениваются ресурсами, но делают это в разрозненных, фрагментированных или индивидуальных и изолированных системах или репозиториях. Специалисты и команды делятся ресурсами, но при этом отсутствует общее и явно сформулированное понимание критериев, по которым определяется, является ли информация чувствительной или нет. Мышление и рассуждения не разделяются с другими.
- RS-2. Отдельные специалисты и команды делают материалы, связанные с проектами, доступными для части участников проектных команд в соответствии с четко определенными и разделяемыми форматами и или протоколами. Специалисты и команды удерживают чувствительные данные и ресурсы, предоставляя ограниченные детали, контекст и охват информации.
- RS-3. Отдельные специалисты и команды делают материалы, связанные с проектами, широко доступными для всей организации, а в отдельных случаях и за ее пределами, в соответствии с четко определенными и разделяемыми форматами и или протоколами. Специалисты и команды, которым необходимо удерживать чувствительные данные и ресурсы, ясно обозначают, какие материалы не публикуются, а другие участники понимают причины недоступности этих материалов.
Stories (Истории). При работе в принимающих командах ошибки неизбежно становятся широко видимыми. Для поддержания высокого уровня вклада корпоративная культура должна рассматривать неудачи как возможность для роста и обучения.
- ST-0. Отдельные специалисты и команды не делятся ни успехами, ни неудачами, чтобы другие могли извлекать из этого знания.
- ST-1. Отдельные специалисты и команды чувствуют себя комфортно, делясь историями об успехах, но не о неудачах.
- ST-2. Отдельные специалисты и команды чувствуют себя комфортно, делясь историями об успехах и неудачах в рамках ретроспектив и обзоров.
- ST-3. Отдельные специалисты и команды чувствуют себя комфортно, делясь историями об успехах и неудачах, и извлекают уроки из неудач в соответствии с формализованными протоколами.
Collaboration (Сотрудничество)Channels for Providing Feedback (Каналы для предоставления обратной связи). Для снижения уровня изолированности между подразделениями коллегам необходимо чувствовать себя комфортно при открытом обмене обратной связью. Одним из простых способов поддержки этого является использование единых принципов коммуникации на всех уровнях иерархии. В идеале в организации формируется набор корректно выстроенных каналов коммуникации, известных всем сотрудникам, при этом разные каналы ориентированы на разные цели: объявления, поддержку пользователей, обсуждение разработки, обсуждение инфраструктуры и другие. По мере роста зрелости проектов InnerSource формируется набор лучших практик, включая внедрение правил сетевого этикета (netiquette) и открытие проверенного набора стандартных каналов для каждого нового проекта InnerSource, которые архивируются, являются публично доступными и пригодными для поиска.
- CF-0. Процессы и устоявшиеся каналы отсутствуют. Отдельные участники организации обмениваются материалами через приватные каналы или закрытые обсуждения.
- CF-1. Организация находится в процессе формирования внутренних рекомендаций и каналов, направленных на поощрение различных точек зрения по вопросам решений на уровне компании или подразделений, доступных для использования всеми сотрудниками. Отдельные участники организации неформально распространяют материалы, связанные с принятием решений, с использованием неофициальных платформ. Руководители поддерживают как минимум один четкий и прямой канал, через который сотрудники могут конструктивно высказывать свое мнение по отдельным вопросам, связанным с их работой.
- CF-2. В организации сформированы внутренние рекомендации и каналы, а также предоставляются конкретные ресурсы, такие как программы обучения и доступ к материалам, для поощрения и сбора различных точек зрения по вопросам командной работы или принятия решений.
- CF-3. Сотрудники организации публикуют материалы, связанные с принятием решений, на официально утвержденных платформах. Сотрудники открыто обмениваются материалами через несколько каналов и используют различные способы предоставления обратной связи. Руководители сами используют эти каналы, открыто поощряют других к их использованию и ведут ориентированные на команды или публичные записи с полученной обратной связью и или с действиями, предпринятыми для ее учета.
Leadership (Лидерство). Проекты InnerSource поощряют сотрудников вносить вклад в проекты, находящиеся за пределами прямого влияния их непосредственного руководителя. Для этого необходима культура доверия.
- LS-0. Культура централизованного управления и контроля в рамках сильно иерархичной организации.
- LS-1. Отдельные руководители открыты к получению обратной связи и формированию среды, в которой сотрудники чувствуют себя в безопасности при ее предоставлении.
- LS-2. Большинство руководителей в организации открыты к получению обратной связи и формированию среды, в которой сотрудники чувствуют себя в безопасности при ее предоставлении. При этом руководители проявляют пассивность в понимании того, чувствуют ли все сотрудники себя наделенными полномочиями и возможностями для выражения мнения. Организация поощряет руководителей активно искать и вовлекать в диалог те голоса, которые в нем не представлены.
- LS-3. Сотрудники чувствуют себя наделенными полномочиями и возможностями конструктивно высказывать свое мнение по любым вопросам, относящимся к их работе или вызывающим у них профессиональный интерес.
Organizational and Functional Structure (Организационная и функциональная структура). Когда InnerSource выходит за рамки исключительно уровня написания кода и переходит на уровень сообществ и рабочих групп, появляется потенциал для снижения изолированности между подразделениями даже в тех случаях, когда прямое совместное развитие кода невозможно.
- OF-0. Рабочие группы, как правило, остаются статичными с точки зрения состава участников и набора компетенций.
- OF-1. Существуют кросс-функциональные команды (cross-functional teams), однако роли внутри команд часто не определены, а структуры управления и координации размыты.
- OF-2. Кросс-функциональные команды широко распространены, и команды публично публикуют информацию о своих ролях и целях.
- OF-3. Кросс-функциональные команды широко распространены и делают свою деятельность широко известной в рамках всей организации; в свою очередь, организация продвигает лучшие практики совместной работы.
Contribution (Вклад и участие). При проектировании паттернов внесения вклада (contribution patterns) необходимо учитывать совместную работу, если целью является снижение изолированности между командами.
- CB-0. Полная изоляция, отсутствует совместная работа за пределами команд. Имеются лишь отдельные примеры взаимодействия, обусловленные существованием кросс-функциональных команд.
- CB-1. Сотрудники и команды в организации взаимодействуют между собой, однако часто отмечают, что это слишком сложно. Команды редко возвращаются к анализу результатов своего взаимодействия.
- CB-2. Сотрудники и команды активно ищут возможности для совместной работы. Команды регулярно обсуждают, пересматривают и анализируют результаты своих совместных усилий и по умолчанию делают эти результаты доступными.
- CB-3. Сотрудники организации взаимодействуют как внутри организации, так и за ее пределами таким образом, чтобы это приносило пользу всем участникам. Команды регулярно обсуждают, пересматривают и анализируют результаты своих совместных усилий, делятся полученными знаниями за пределами организации и по умолчанию делают эти результаты доступными во внешнем контуре.
Community (Сообщество)Sharing Policies (Политики совместного использования). Наличие базового набора разделяемых ценностей упрощает работу на границах между командами. Пересечение этих границ становится проще, если в организации действует ограниченный набор базовых правил и рекомендаций, которые применимы повсеместно и на которые можно легко сослаться.
- SP-0. Отсутствует культура совместного использования и отсутствуют зафиксированные в письменном виде политики.
- SP-1. Отдельные участники организации объединяются для определения ценностей и принципов, однако при этом не получают явной поддержки.
- SP-2. Участники организации совместно документируют общее видение и договоренности, такие как формулировки миссии (mission statements) и кодексы поведения (codes of conduct), делают их легко доступными и регулярно на них ссылаются. Материалы для онбординга и вводные ритуалы обеспечивают достаточный контекст, помогающий новым участникам понять, какую пользу организация получит от их вклада.
- SP-3. Разделяемые ценности и принципы используются при принятии решений, разрешении конфликтов и в процессах оценки. Участники организации последовательно ссылаются на эти ценности и принципы как в устной, так и в письменной коммуникации.
Feel part of the Organization (Чувство принадлежности к организации). Одной из возможных причин внедрения InnerSource в организациях является повышение вовлеченности (engagement). Данный аспект отслеживает, как меняется уровень вовлеченности по мере внедрения InnerSource.
- PA-0. Низкий уровень вовлеченности, отсутствует совместная работа, и сотрудники не чувствуют себя комфортно при обмене информацией с другими.
- PA-1. Участники организации чувствуют себя комфортно, делясь своими мыслями и мнениями без страха негативных последствий, но только в знакомых им областях. Сотрудники понимают, что лучшие идеи получают развитие, а лидерские роли формируются у тех, кто имеет историю вклада и вовлеченности.
- PA-2. Участники организации чувствуют себя комфортно, делясь своими мыслями и мнениями без страха негативных последствий. Руководители демонстрируют приверженность разделяемым ценностям организации.
- PA-3. Организация проактивно доносит до сотрудников, что получает пользу от их вклада; в результате сотрудники демонстрируют общее понимание целей и наделенное полномочиями исполнение, а также чувствуют ответственность перед сообществом. Руководители понимают, что они развиваются, помогая развиваться другим, и наставляют младших участников организации.
Governance (Управление)Rewards (Вознаграждения). Для стимулирования внедрения InnerSource могут использоваться внешние мотиваторы (extrinsic motivators), направленные на усиление межкомандного взаимодействия.
- RW-0. Вознаграждения отсутствуют.
- RW-1. Руководителям рекомендуется поощрять исключительные примеры совместной работы, однако формализованные политики и процессы отсутствуют.
- RW-2. В организации внедрены стандартные процессы вознаграждения за сотрудничество за пределами команд разработчиков. Решение о том, кто подлежит вознаграждению, принимают руководители команд или коллегиальные органы.
- RW-3. Вознаграждения не только предлагаются организацией, но и определяются самими сообществами как наиболее ценные. Сообщество самостоятельно принимает решение о том, кто подлежит вознаграждению.
Monitoring Policies (Политики мониторинга). Проектам InnerSource необходимы механизмы для самооценки. Метрики (metrics) могут быть одним из аспектов, поддерживающих такую оценку. Кроме того, в организациях с высоким уровнем зрелости внедрения InnerSource ожидается, что степень его распространения будет отслеживаться на основе четко определенных и согласованных метрик.
- MP-0. В организации отсутствуют политики мониторинга на любом уровне.
- MP-1. Метрики являются значимыми для отдельных команд, и они начинают использовать их изолированно.
- MP-2. На уровне организации существует стратегия в отношении метрик, которые помогают проверять соблюдение отдельных политик в масштабах всей организации. Такая политика мониторинга действует на уровне некоторых проектов InnerSource.
- MP-3. Существуют четкие рекомендации, руководства и обучающие программы по использованию метрик, а также соответствующая инфраструктура, предоставляемая организацией. Это применяется на двух уровнях: на уровне программы InnerSource для понимания общего уровня внедрения InnerSource в организации и на уровне отдельных проектов InnerSource.
Support and Maintenance (Поддержка и сопровождение). В проектах InnerSource ответственность команд не ограничивается только разработкой функциональности — поддержка и сопровождение также являются частью ключевых задач команд.
- SP-0. Поддержка осуществляется основной командой разработки или выделенной командой поддержки. Поддержка гарантируется бизнес-договором. За пределами команды отсутствуют знания о продукте.
- SP-1. Существуют правила и регламенты, формализующие поддержку продукта, которая осуществляется выделенной командой поддержки.
- SP-2. Поддержка вкладов InnerSource формализована с использованием паттернов InnerSource, таких как 30 Day Warranty или Service vs. Library.
- SP-3. Существуют правила и регламенты, формализующие поддержку продукта, которая осуществляется зрелым сообществом.
Culture (Культура). Существует несколько уровней движения в сторону культуры совместной работы (collaborative culture).
- CL-0. Изолированность — команды работают независимо, но при этом обособленно друг от друга.
- CL-1. Реактивный уровень — команды работают независимо, но умеют реагировать на недостатки и сбои в зависимостях.
- CL-2. Уровень вклада — команды активно помогают улучшать свои зависимости за счет внесения вклада.
- CL-3. Уровень активного участия — команды активно ищут помощь, наставляют и привлекают новых участников для внесения вклада.
InnerSource Roles (Роли InnerSource). InnerSource предполагает наличие явно определенных ролей. На ранних этапах некоторые паттерны могут применяться без формального внедрения этих ролей, однако использование явных названий ролей в коммуникации внутри проектов упрощает взаимодействие.
- RO-0. Отсутствуют специальные роли, поддерживающие внедрение InnerSource. Присутствуют только стандартные роли разработки: разработчик, аналитик, тестировщик и другие.
- RO-1. В отдельных случаях некоторые сотрудники и команды вносят вклад в другие проекты. Речь идет о технических вкладах, при которых проявляется роль пользователя или контрибьютора (user/contributor). В некоторых командах можно выделить как минимум одного участника, выступающего в роли технического ориентира, который объясняет процесс разработки другим членам команды разработки. Такой участник может рассматриваться как кандидат на роль доверенного коммиттера (trusted committer).
- RO-2. Роль InnerSource Officer отвечает за управление и поддержку, включая процессы и другие аспекты. Эта роль определяет потребности в обучении и обеспечивает их реализацию на уровне организации, а также ведет и наставляет организацию в вопросах вовлечения в проекты InnerSource. Это первый формализованный шаг, в рамках которого определяется видение InnerSource и его roadmap. В организации определена роль доверенного коммиттера (trusted committer), который является точкой контакта и экспертизы не только для членов команды разработки, но и для внешних контрибьюторов. Существует стандартный процесс, описывающий порядок внесения вклада в сообщество, и присутствует роль контрибьютора (contributor). Роль Data Scientist отвечает за управление следами активности, оставляемыми инициативой InnerSource, которые необходимы для измерения развития InnerSource. Роль trusted committer со временем эволюционирует в более технический профиль, а роль community manager берет на себя задачу оживления сообщества, основной ответственностью которой является привлечение и удержание новых разработчиков и пользователей (контрибьюторов и участников сообщества).
- RO-3. Евангелисты перемещаются внутри организации, информируя других о текущей работе, о том, что представляет собой InnerSource, как с ним работать, а также помогая сотрудникам понять инициативу и стать ее частью. Появляются нетехнические контрибьюторы.
Модель зрелости InnerSource в виде таблицы представлена ниже: