Что такое разработка в Сбере? В глазах обычного айтишника: «Вот где код написали, туда и идите!». Но это давно уже стереотип, а они хорошими не бывают. Стремительное развитие open source доказывает, что такая культура давно себя изжила, и энтерпрайз (если он умный) давно пересмотрел silo-based подход к разработке.
Публикация всего банковского ПО в open source —эффектный способ самоубийства довольно спорное решение, и нужен какой-то промежуточный этап. C масштабами банка мы можем запустить свой внутренний open source, а не пытаться проверить, что можно показать всем и трястись от страха за наши маленькие большие секреты.
В 2000 году Тим О’Райли описал термином inner source возможную ступеньку к выходу закрытой компании в прекрасный мир open source. Это применение лучших практик из open source внутри корпорации: от общей открытости и проактивной взаимовыручки до формирования рынка лучших решений. Компания продолжает писать проприетарный код, но каждый её сотрудник имеет возможность доработать любую внутреннюю систему.
Плюсы InnerSource можно перечислять долго: снижение time to market, повышение качества кода, замена внешнего хайринга внутренним, улучшение кросс-командного взаимодействия и так далее.
Сложность же состоит в том, что всё описанное выше, требует изменения культуры общения сотрудников и команд, а это не так просто сделать в организации, которая десятилетиями работала иначе.
Конечно же, Сбер не единственная компания, которой пришло в голову делать что-то подобное. В 2015 году было создано сообщество InnerSource Commons, которое популяризировало подход и убрало из термина пробел, чтобы было проще найти в поисковиках. В этом сообществе собран опыт успеха десятков компаний и составлены эффективные рекомендации для внедрения InnerSource в вашей компании, а дважды в год проводится конференция по обмену опытом. Ещё есть много всем известных технологических компаний, которые занимались этимсо времён печенегов и половцев до того, как это стало мейнстримом.
В России, насколько нам известно, намеренным внедрением InnerSource активно занимается только один крупный ритейлер на рынке строительных услуг с зелёным логотипом, остальные компании либо не афишируют свой опыт, либо не участвуют в сообществе.
У каждой из этих компаний свой как положительный, так и отрицательный опыт. Общий вывод при этом получается очень похожий: самые лакомые бенефиты можно будет получить только при участии подавляющего большинства.
Почти каждый разговор о разработке в Сбере приходит к вопросу «а сколько же у вас там программистов?». По всей стране у нас их больше десяти тысяч, они активно работают над тысячами компонентов, систем, библиотек и иже с ними. Как следствие таких объёмов, каждый день приходится решать вопросы управления зависимостями от смежных команд, отношения руководства и фазами Меркурия.
По завершении опроса о том, что болит у инженеров, в конце 2018 года в Сбере было принято решение создать трайб SberWorks, который взял на себя всё, что касается процессов и инструментов производства софта в банке. Задачи и цели подразделения практически полностью вытекали из списка собранных болей разработчиков.
Стыдно признать, что наибольшей болью в конце прошлого года стало незнание того, чем занимаются соседи по цеху или даже по соседнему блоку в опенспейсе. Из-за этого мы изобретали не только колесо, но и два (подставить нужное число) одинаковых колеса в разных подразделениях, причём как в разных городах, так и на соседних рабочих местах. В итоге, имея огромные ресурсы в компании, зачастую вместо полёта на Марс наши команды устраивали забеги по граблям, не зная, что соседние грабли давно собраны.
Раз. Для решения вопросов интеграции и поиска нужных людей создать единый реестр API для всех систем банка с большим количеством автоматизаций: автогенерация вызовов, заглушки для следующей версии API, версионирование и тому подобное. Сейчас этот реестр превратился в отдельный крутой продукт, который определённо достоин своей статьи, но это уже другая история.
Два. Создать своеобразный «зонтик» с единым поисковиком над всеми инженерными инструментами (JIRA, Confluence, Bitbucket, Nexus), объединяющий внутренний и внешний сегменты (да-да, infamous альфа и сигма).
Три. Код, бэклоги и артефакты, кроме тех, что безопасность явно запрещает открывать, должны быть открыты всем сотрудникам компании.
В процессе общения с разработчиками мы выделили основную причину такой закрытости команд внутри себя: текущие способы взаимодействия продактов. Любые обсуждения доработки смежных систем шли по одному из трёх сценариев.
«Подождём»
Самый распространённый способ взаимодействия. Смежная команда ставит какой-то срок, он нас в целом устраивает, мы откладываем задачку поглубже в бэклог.
В целом допустимый вариант. Но если в цепочке есть зависимости от нескольких команд, а фичу, как обычно, нужно выводить в production вчера, то нужно искать компромиссы.
«Компромиссы»
В народе этот метод называется эскалацией. Взять с собой менеджера посолиднее и прийти в смежную команду, для того чтобы подвинуть свою задачку повыше в бэклоге. Минусы этого подхода очевидны: большинство команд сможет сыграть эту карту лишь несколько раз, после чего отношения между командами портятся.
«Временная постоянная заглушка»
Напилить свой велосипед-франкенштейн с костылями и временными базёнками, дублирующими функциональность системы, от которой появилась зависимость. Самый грустный, поскольку почти всегда остаётся надолго (если не навсегда), порождает дублирование кода, а команда вынуждена поддерживать костыльное решение.
Мы предложили четвёртый способ. Выполнить доработку в кодовой базе смежной команды под их чутким присмотром, сокращая сроки выполнения.
InnerSource
По завершении такого взаимодействия команда «А» с картинки получает драгоценную обратную связь, взращивает экспертизу в смежной области и снижает TTM своей доработки. Забегая вперёд, в банке такие взаимодействия быстро приобрели форматы бартеров различного вида: команда «А» закрывает задачи из техдолга команды «В», пока они выполняют нужную доработку.
В самом начале нам показалось, что нужно найти места, в которых InnerSource будет максимально востребован прямо сейчас. Пока мы думали, как это сделать, не впадая в цикл бесконечных опросов, мудрое руководство оценило идею и предложило обеспечить стопроцентную готовность ста процентов систем Сбера к концу года. Мы напряглись, наш менеджер спросил «а что такое сто процентов?», и количество систем сократилось примерно в 20 раз до современных и/или критичных для бизнеса.
После этого начался рутинный процесс тиража этой практики на команды, в конце которого нам виделась накрытая поляна со списком репозиториев и правилами работы с каждым из них.
Мы провели кучу встреч разного уровня, сначала с техническими лидерами департаментов, затем с тимлидами и владельцами сервисов и в конце с членами команд. Представителей сервиса мы просили предоставить информацию о самой системе, стеке разработки и ссылки на репозитории, бэклог и документацию. На этих же встречах нам удалось получить информацию о болях из первых рук: бесконечный бэклог, недостаток ресурсов, старый стек технологий (например, Delphi).
В процессе тиража мы сформировали понимание сильных и слабых звеньев в банке. Были очень зрелые команды (например, мобильная разработка), которые уже работают по принципам InnerSource в промышленных масштабах и поделились огромным количеством шишек и подходов. Но было и несколько команд (привет печенегам), которые обескуражили нас отсутствием автотестов, логирования и практики ревью кода.
Среди наших команд есть огромный культурный пробел между «моя боевая единица работает над самыми правильными задачами» и «давайте все вместе сделаем круто». Большая часть реакций была довольно однообразной: «мы не хотим брать чужой код и потом за него отвечать», «мы не хотим давать своих разработчиков, потому что они уйдут, а ресурсов и так нет». В этот момент было принято решение вкладываться в культуру больше чем в технику:
С некоторой погрешностью мы научились отслеживать происходящие в BitBucket межкомандные взаимодействия и получили информацию о том, что у нас каждый месяц добавляется примерно 30-50 новых авторов InnerSource изменений. Цифра в рамках количества разработчиков в банке не очень впечатляющая, но это только лишь доработки по бизнес-задачам.
Ожидаемо стали очень востребованы data-driven изменения в различных интеграционных шинах и ETL-сервисах. Это легко объясняется большим количеством задач и низкой стоимостью доработок.
Такие доработки мы пристально изучали на примере нашей ESB. Для неё в ближайшем будущем запланирован переход на новое решение, поэтому дополнительные ресурсы команде не выделялись, тогда как запросы на доработку только росли. В InnerSource ребята увидели спасение, быстренько подсуетились и собрали приоритизатор, который поднимает вашу задачу максимально, если вы готовы сделать её сами. В цифрах это выглядит так: за октябрь-ноябрь почти половина (101 из 209) запросов на доработку были выполнены командами самостоятельно. Это выразилось в сокращении времени ожидания в четыре раза с 2,5 месяцев до 2,5 недель.
Совсем неожиданно активное участие приняли дизайнеры, которые с радостью помогают смежным командам, когда у последних не хватает ресурсов или требуется свежий взгляд. Как оказалось, довольно мало команд, которые могут утилизировать дизайнеров на 100 %, а они сами люди творческие и обожают смену фокуса на какой-то новый продукт.
Первые шаги внедрения прозрачности и практик взаимодействия между командами в компании, которая привыкла жить законами энтерпрайза, всегда самые сложные. Мы смело можем сказать, что первые стены пробиты и набран достаточный объём успешных InnerSource-историй, чтобы движение внутри Сбера набирало оборот.
Основным вызовом в будущем нам видится избегание закона Гудхарта. В любой компании среднего и большого размера эффективность должна быть измерена: придумай цифру и заставь её вырасти. На конференции в Балтиморе осенью прошлого года было приведено несколько кейсов, где постановка в цели показателей готовности команд и количества доработок приводила к саботажу метрик и выгоранию лидеров движения.
Мы считаем, что получаемые плюсы полностью отбивают вложенные усилия, а открытость сама по себе имеет бесчисленные преимущества. Мы готовы рассказать наш путь детальнее и обменяться опытом, пишите-звоните — innersource@sberbank.ru. Целую, Сбер.
Публикация всего банковского ПО в open source —
Что такое InnerSource?
В 2000 году Тим О’Райли описал термином inner source возможную ступеньку к выходу закрытой компании в прекрасный мир open source. Это применение лучших практик из open source внутри корпорации: от общей открытости и проактивной взаимовыручки до формирования рынка лучших решений. Компания продолжает писать проприетарный код, но каждый её сотрудник имеет возможность доработать любую внутреннюю систему.
Плюсы InnerSource можно перечислять долго: снижение time to market, повышение качества кода, замена внешнего хайринга внутренним, улучшение кросс-командного взаимодействия и так далее.
Сложность же состоит в том, что всё описанное выше, требует изменения культуры общения сотрудников и команд, а это не так просто сделать в организации, которая десятилетиями работала иначе.
Конечно же, Сбер не единственная компания, которой пришло в голову делать что-то подобное. В 2015 году было создано сообщество InnerSource Commons, которое популяризировало подход и убрало из термина пробел, чтобы было проще найти в поисковиках. В этом сообществе собран опыт успеха десятков компаний и составлены эффективные рекомендации для внедрения InnerSource в вашей компании, а дважды в год проводится конференция по обмену опытом. Ещё есть много всем известных технологических компаний, которые занимались этим
В России, насколько нам известно, намеренным внедрением InnerSource активно занимается только один крупный ритейлер на рынке строительных услуг с зелёным логотипом, остальные компании либо не афишируют свой опыт, либо не участвуют в сообществе.
У каждой из этих компаний свой как положительный, так и отрицательный опыт. Общий вывод при этом получается очень похожий: самые лакомые бенефиты можно будет получить только при участии подавляющего большинства.
Зачем это Сберу?
Почти каждый разговор о разработке в Сбере приходит к вопросу «а сколько же у вас там программистов?». По всей стране у нас их больше десяти тысяч, они активно работают над тысячами компонентов, систем, библиотек и иже с ними. Как следствие таких объёмов, каждый день приходится решать вопросы управления зависимостями от смежных команд, отношения руководства и фазами Меркурия.
По завершении опроса о том, что болит у инженеров, в конце 2018 года в Сбере было принято решение создать трайб SberWorks, который взял на себя всё, что касается процессов и инструментов производства софта в банке. Задачи и цели подразделения практически полностью вытекали из списка собранных болей разработчиков.
Стыдно признать, что наибольшей болью в конце прошлого года стало незнание того, чем занимаются соседи по цеху или даже по соседнему блоку в опенспейсе. Из-за этого мы изобретали не только колесо, но и два (подставить нужное число) одинаковых колеса в разных подразделениях, причём как в разных городах, так и на соседних рабочих местах. В итоге, имея огромные ресурсы в компании, зачастую вместо полёта на Марс наши команды устраивали забеги по граблям, не зная, что соседние грабли давно собраны.
Что с этим всем делать?
Раз. Для решения вопросов интеграции и поиска нужных людей создать единый реестр API для всех систем банка с большим количеством автоматизаций: автогенерация вызовов, заглушки для следующей версии API, версионирование и тому подобное. Сейчас этот реестр превратился в отдельный крутой продукт, который определённо достоин своей статьи, но это уже другая история.
Два. Создать своеобразный «зонтик» с единым поисковиком над всеми инженерными инструментами (JIRA, Confluence, Bitbucket, Nexus), объединяющий внутренний и внешний сегменты (да-да, infamous альфа и сигма).
Три. Код, бэклоги и артефакты, кроме тех, что безопасность явно запрещает открывать, должны быть открыты всем сотрудникам компании.
Что предложили?
В процессе общения с разработчиками мы выделили основную причину такой закрытости команд внутри себя: текущие способы взаимодействия продактов. Любые обсуждения доработки смежных систем шли по одному из трёх сценариев.
«Подождём»
Самый распространённый способ взаимодействия. Смежная команда ставит какой-то срок, он нас в целом устраивает, мы откладываем задачку поглубже в бэклог.
В целом допустимый вариант. Но если в цепочке есть зависимости от нескольких команд, а фичу, как обычно, нужно выводить в production вчера, то нужно искать компромиссы.
«Компромиссы»
В народе этот метод называется эскалацией. Взять с собой менеджера посолиднее и прийти в смежную команду, для того чтобы подвинуть свою задачку повыше в бэклоге. Минусы этого подхода очевидны: большинство команд сможет сыграть эту карту лишь несколько раз, после чего отношения между командами портятся.
«Временная постоянная заглушка»
Напилить свой велосипед-франкенштейн с костылями и временными базёнками, дублирующими функциональность системы, от которой появилась зависимость. Самый грустный, поскольку почти всегда остаётся надолго (если не навсегда), порождает дублирование кода, а команда вынуждена поддерживать костыльное решение.
Мы предложили четвёртый способ. Выполнить доработку в кодовой базе смежной команды под их чутким присмотром, сокращая сроки выполнения.
InnerSource
По завершении такого взаимодействия команда «А» с картинки получает драгоценную обратную связь, взращивает экспертизу в смежной области и снижает TTM своей доработки. Забегая вперёд, в банке такие взаимодействия быстро приобрели форматы бартеров различного вида: команда «А» закрывает задачи из техдолга команды «В», пока они выполняют нужную доработку.
Наш путь
В самом начале нам показалось, что нужно найти места, в которых InnerSource будет максимально востребован прямо сейчас. Пока мы думали, как это сделать, не впадая в цикл бесконечных опросов, мудрое руководство оценило идею и предложило обеспечить стопроцентную готовность ста процентов систем Сбера к концу года. Мы напряглись, наш менеджер спросил «а что такое сто процентов?», и количество систем сократилось примерно в 20 раз до современных и/или критичных для бизнеса.
После этого начался рутинный процесс тиража этой практики на команды, в конце которого нам виделась накрытая поляна со списком репозиториев и правилами работы с каждым из них.
Мы провели кучу встреч разного уровня, сначала с техническими лидерами департаментов, затем с тимлидами и владельцами сервисов и в конце с членами команд. Представителей сервиса мы просили предоставить информацию о самой системе, стеке разработки и ссылки на репозитории, бэклог и документацию. На этих же встречах нам удалось получить информацию о болях из первых рук: бесконечный бэклог, недостаток ресурсов, старый стек технологий (например, Delphi).
В процессе тиража мы сформировали понимание сильных и слабых звеньев в банке. Были очень зрелые команды (например, мобильная разработка), которые уже работают по принципам InnerSource в промышленных масштабах и поделились огромным количеством шишек и подходов. Но было и несколько команд (привет печенегам), которые обескуражили нас отсутствием автотестов, логирования и практики ревью кода.
Среди наших команд есть огромный культурный пробел между «моя боевая единица работает над самыми правильными задачами» и «давайте все вместе сделаем круто». Большая часть реакций была довольно однообразной: «мы не хотим брать чужой код и потом за него отвечать», «мы не хотим давать своих разработчиков, потому что они уйдут, а ресурсов и так нет». В этот момент было принято решение вкладываться в культуру больше чем в технику:
- Пришли в HR и сказали: вот есть Google, давайте как они, для начала выделим 10 % времени разработчиков на доработку внутренних систем.
- Пришли в PR и сказали: вот есть Microsoft, давайте попробуем начать движение в open source.
- Пришли к инженерам и сказали: Сбер очень большой, можно доработать что-нибудь очень ламповое на Delphi или поработать со стильным молодёжным GraphQL, вот вам 10 % времени, тебе совсем не обязательно выгорать!
- Стали проактивно предлагать командам самим доработать смежную систему, разместив эту информацию в реестре API, межкомандных JIRA-тикетах и других внутренних процессах взаимодействия.
Наши успехи
С некоторой погрешностью мы научились отслеживать происходящие в BitBucket межкомандные взаимодействия и получили информацию о том, что у нас каждый месяц добавляется примерно 30-50 новых авторов InnerSource изменений. Цифра в рамках количества разработчиков в банке не очень впечатляющая, но это только лишь доработки по бизнес-задачам.
Ожидаемо стали очень востребованы data-driven изменения в различных интеграционных шинах и ETL-сервисах. Это легко объясняется большим количеством задач и низкой стоимостью доработок.
Такие доработки мы пристально изучали на примере нашей ESB. Для неё в ближайшем будущем запланирован переход на новое решение, поэтому дополнительные ресурсы команде не выделялись, тогда как запросы на доработку только росли. В InnerSource ребята увидели спасение, быстренько подсуетились и собрали приоритизатор, который поднимает вашу задачу максимально, если вы готовы сделать её сами. В цифрах это выглядит так: за октябрь-ноябрь почти половина (101 из 209) запросов на доработку были выполнены командами самостоятельно. Это выразилось в сокращении времени ожидания в четыре раза с 2,5 месяцев до 2,5 недель.
Совсем неожиданно активное участие приняли дизайнеры, которые с радостью помогают смежным командам, когда у последних не хватает ресурсов или требуется свежий взгляд. Как оказалось, довольно мало команд, которые могут утилизировать дизайнеров на 100 %, а они сами люди творческие и обожают смену фокуса на какой-то новый продукт.
Послесловие
Первые шаги внедрения прозрачности и практик взаимодействия между командами в компании, которая привыкла жить законами энтерпрайза, всегда самые сложные. Мы смело можем сказать, что первые стены пробиты и набран достаточный объём успешных InnerSource-историй, чтобы движение внутри Сбера набирало оборот.
Основным вызовом в будущем нам видится избегание закона Гудхарта. В любой компании среднего и большого размера эффективность должна быть измерена: придумай цифру и заставь её вырасти. На конференции в Балтиморе осенью прошлого года было приведено несколько кейсов, где постановка в цели показателей готовности команд и количества доработок приводила к саботажу метрик и выгоранию лидеров движения.
Мы считаем, что получаемые плюсы полностью отбивают вложенные усилия, а открытость сама по себе имеет бесчисленные преимущества. Мы готовы рассказать наш путь детальнее и обменяться опытом, пишите-звоните — innersource@sberbank.ru. Целую, Сбер.
