В последние годы получила распространение концепция InnerSource. Она предполагает использование принципов Open Source в одной организации. Иными словами, в рамках этой модели выстраивается сообщество, но только из сотрудников компании, в результате чего права на код остаются за ней.

Автор труда «The Art of Community» и основатель проекта Jono Bacon Consulting Джоно Бэкон на страницах сайта OpenSource.com рассказывает, что уже работает с предприятиями, выстраивающих внутри себя InnerSource-сообщества. По первым итогам этой деятельности он смог сформулировать несколько важных принципов, которыми делится с читателями.

Сначала культура, потом код

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

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

Существует ошибочное мнение, что самое важное для InnerSource заключается в создании жизненного цикла разработки ПО в конкретной компании. А именно, организация хранилищ и каналов связи, анализ кода и непрерывная интеграция вкладов... Безусловно, всё это играет существенную роль.

Однако Бэкон уверен, что эти составляющие — примерно то же самое, что элементы конструктора Lego. Истинный же смысл InnerSource заключается в создании стимулов для людей, создающих из «кирпичиков» невероятные вещи.

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

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

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

Разработка методологии

Несмотря на то, что InnerSource — относительно новая концепция, к ней вполне применимы некоторые проверенные методики, давно практикуемые сообществом Open Source. Разумеется, с некоторыми оговорками и уточнениями.

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

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

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

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

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

Удалённость и асинхронность

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

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

Если слепо переносить корпоративные принципы на InnerSource, то команды будут формироваться «по офисам», что совершенно неэффективно, поскольку автоматически вычёркивает из разработки потенциально полезных специалистов компании, работающих в других городах. В то время как проекты Open Source уже давно и успешно функционируют в асинхронном режиме, при котором место и часовой пояс участников не имеет никакого значения.

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

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

Экспертиза в рабочем процессе

У Open Source есть два важных принципа. Во-первых, вклад любого участника рассматривается другими разработчиками, которым предлагается найти недостатки и исправить их. Во-вторых, экспертиза (как процесс, так и результат) открыта для всех.

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

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

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

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

Стимулирование участников

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

Бэкон выделяет три момента, на которые следует обратить внимание руководству компании.

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

Во-вторых, на основе этого представления следует обеспечить участникам InterSource-команд какие-то стимулы и дополнительные выгоды. Они могут быть либо материальными (деньги, футболки, подарочные карты и т. д.) или моральными (публичное признание заслуг, уважение, восхищение и т. п.). Поскольку и то, и другое одинаково важно, руководство компании должно сочетать виды поощрений.