Что такое развитие в Сбербанке? Глазами обычного айтишника: «Вот где код был написан, туда и иди!» Но это уже давно стереотип, и они нехорошие.
Быстрое развитие открытого исходного кода доказывает, что такая культура давно изжила себя, и предприятие (если оно разумное) уже давно пересмотрело разрозненный подход к разработке.
Публикация всего банковского ПО в открытом исходном коде — эффектный метод самоубийства, достаточно спорное решение, и нужен какой-то промежуточный этап.
С масштабами банка мы можем запустить собственный внутренний опенсорс, а не пытаться проверить то, что мы можем показать всем и трястись от страха за свои маленькие большие секреты.
Что такое ИннерСорс?
В 2000 году Тим О'Рейли термином «внутренний исходный код» описан возможный шаг на пути к входу закрытой компании в чудесный мир открытого исходного кода.Это применение лучших практик из открытого исходного кода внутри корпорации: от общей открытости и активной взаимопомощи до формирования рынка лучших решений.
Компания продолжает писать собственный код, но каждый ее сотрудник имеет возможность модифицировать любую внутреннюю систему.
Плюсы InnerSource можно перечислять долго: сокращение времени выхода на рынок, улучшение качества кода, замена внешнего найма внутренним, улучшение межкомандного взаимодействия и так далее.
Сложность в том, что все описанное выше требует изменения культуры общения между сотрудниками и командами, а это не так-то просто сделать в организации, которая десятилетиями работала по-другому.
Конечно, Сбер — не единственная компания, которая додумалась сделать нечто подобное.
Сообщество создано в 2015 году.
Внутренний источникCommons , что популяризировало этот подход и убрало из термина пробелы, чтобы его было легче найти в поисковых системах.
В этом сообществе собран успешный опыт десятков компаний и составлены эффективные рекомендации по внедрению InnerSource в вашей компании, а для обмена опытом два раза в год проводится конференция.
Есть также много известных технологических компаний, которые занимались этим еще со времен печенегов и половцев, до того, как это стало мейнстримом.
В России, насколько нам известно, целенаправленным внедрением InnerSource активно занимается только один крупный ритейлер на рынке строительных услуг с зеленым логотипом; другие компании либо не афишируют свой опыт, либо не участвуют в сообществе.
Каждая из этих компаний имеет как положительный, так и отрицательный опыт. Общий вывод очень схож: самые вкусные блага можно получить только при участии подавляющего большинства.
Зачем я это собираю?
Практически в каждом разговоре о разработке в Сбербанке возникает вопрос «сколько у вас там программистовЭ» У нас их более десяти тысяч по всей стране, они активно работают над тысячами компонентов, систем, библиотек и иже с ними.Как следствие таких объемов, нам каждый день приходится решать вопросы управления зависимостями от смежных команд, взаимоотношениями руководства и фазами Меркурия.
Проведя опрос о том, что вредит инженерам, в конце 2018 года Сбер решил создать племя SberWorks, которое взяло на себя все, что связано с процессами и инструментами производства ПО в банке.
Задачи и цели модуля практически полностью были выведены из списка собранных болевых точек разработчиков.
Стыдно признаться, что самой большой болью в конце прошлого года было незнание, чем занимаются соседи по цеху или даже в соседнем квартале на открытом пространстве.
Благодаря этому мы изобрели не только колесо, но и два (подставьте нужное число) одинаковых колеса в разных отделах, как в разных городах, так и на соседних рабочих местах.
В результате, имея в компании огромные ресурсы, зачастую вместо того, чтобы лететь на Марс, наши команды устраивали рейк-гонки, не зная, что соседние грабли уже давно собраны.
Что со всем этим делать?
Один раз.Для решения вопросов интеграции и поиска нужных людей создайте единый реестр API для всех банковских систем с большим количеством автоматизаций: автогенерация вызовов, заглушки для следующей версии API, версионирование и тому подобное.
Сейчас этот реестр превратился в отдельный крутой продукт, который определенно достоин отдельной статьи, но это уже другая история.
Два.
Создайте своего рода «зонтик» с единой поисковой системой над всеми инженерными инструментами (JIRA, Confluence, Bitbucket, Nexus), объединив внутренний и внешний сегменты (да-да, пресловутые альфа и сигма).
Три.
Код, бэклоги и артефакты, за исключением тех, которые безопасность явно запрещает открывать, должны быть открыты для всех в компании.
Что они предложили?
В процессе общения с разработчиками мы выявили основную причину такой закрытости команд внутри себя: текущие способы взаимодействия продуктов.Любые дискуссии по улучшению связанных систем развивались по одному из трех сценариев.
"Давайте ждать"
Самый распространенный способ взаимодействия.
Соответствующая команда ставит дедлайн, нас он в целом устраивает, ставим задачу глубже в бэклог.
В целом верный вариант. Но если цепочка имеет зависимости от нескольких команд, а фичу, как обычно, нужно выпустить в продакшн еще вчера, то нужно искать компромиссы.
«Компромиссы»
Этот метод в народе называется эскалацией.
Возьмите с собой более солидного менеджера и присоединитесь к соседней команде, чтобы продвинуть свою задачу выше в бэклоге.
Минусы такого подхода очевидны: большинство команд смогут сыграть на этой карте всего несколько раз, после чего отношения между командами испортятся.
«Временная постоянная заглушка»
Оснастите свой велосипед Франкенштейна костылями и временными подставками, которые дублируют функциональность системы, от которой вы становитесь зависимыми.
Самый печальный, поскольку он почти всегда остается надолго (если не навсегда), порождает дублирование кода, и команда вынуждена поддерживать костыльное решение.
Мы предложили четвертый метод. Вносите улучшения в кодовую базу соответствующей команды под их пристальным контролем, сокращая время завершения.
Внутренний источник
В конце этого взаимодействия команда А на картинке получает ценную обратную связь, развивает экспертизу в соответствующей области и снижает время TTM своей доработки.
Забегая вперед, в банке такие взаимодействия быстро приобрели формат бартера разного типа: команда «А» закрывает задачи из технического долга команды «Б», пока они выполняют необходимые модификации.
Наш путь
В самом начале нам казалось, что нужно найти места, где InnerSource прямо сейчас будет максимально востребован.Пока мы думали, как это сделать, не впадая в цикл бесконечных обследований, мудрое руководство оценило идею и предложило к концу года обеспечить стопроцентную готовность всех систем Сбера.
Мы напряглись, наш менеджер спросил «а что такое сто процентовЭ», и количество систем сократилось примерно в 20 раз до современных и/или бизнес-критичных.
После этого начался рутинный процесс распространения этой практики по командам, в конце которого мы увидели крытую поляну со списком репозиториев и правилами работы с каждым из них.
Мы провели кучу встреч на разных уровнях: сначала с техническими руководителями отделов, затем с тимлидами и владельцами сервисов и, наконец, с членами команды.
Мы попросили представителей сервиса предоставить информацию о самой системе, стеке разработки и ссылки на репозитории, бэклог и документацию.
На этих же встречах мы смогли из первых рук получить информацию о болевых точках: бесконечное отставание, нехватка ресурсов, старый стек технологий (например, Delphi).
В процессе обращения мы выработали понимание сильных и слабых звеньев банка.
Были очень зрелые команды (например, мобильной разработки), которые уже работали по принципам InnerSource в промышленных масштабах и делились огромным количеством идей и подходов.
Но было и несколько команд (привет печенегам), которые отговаривали нас отсутствием практики автотестов, логирования и код-ревью.
В наших командах существует огромный культурный разрыв между «мое подразделение работает над правильными вещами» и «давайте сделаем что-нибудь крутое вместе».
Большинство реакций были довольно однообразными: «мы не хотим брать чужой код и потом нести за него ответственность», «не хотим отдавать нашим разработчикам, потому что они уйдут, а ресурсов все равно нет. » В этот момент было принято решение больше инвестировать в культуру, чем в технологии:
- Пришли в HR и сказали: вот Google, давайте делать то, что они делают, сначала давайте выделим 10% времени разработчиков на улучшение внутренних систем.
- Пришли в пиар и сказали: вот Microsoft, давайте попробуем начать движение в open source.
- Пришли к инженерам и сказали: Сбер очень большой, можно доработать что-то очень продвинутое в Delphi или поработать со стильным молодёжным GraphQL, вот 10% времени, вообще не надо выгорать!
- Они начали активно предлагать командам самостоятельно модифицировать связанную систему, размещая эту информацию в реестре API, межкомандных билетах JIRA и других внутренних процессах взаимодействия.
Наши успехи
С некоторой погрешностью мы научились отслеживать межкомандные взаимодействия, происходящие в BitBucket, и получили информацию о том, что каждый месяц мы добавляем примерно 30-50 новых авторов изменений InnerSource. Цифра количества разработчиков в банке не очень впечатляет, но это всего лишь улучшения бизнес-задач.Как и ожидалось, очень популярными стали изменения, управляемые данными, в различных интеграционных шинах и ETL-сервисах.
Это легко объясняется большим количеством задач и низкой стоимостью доработок.
Мы внимательно изучили такие улучшения на примере нашего ESB. В ближайшее время для нее запланирован переход на новое решение, поэтому дополнительные ресурсы команде выделены не были, а запросы на улучшения только росли.
Ребята из InnerSource увидели спасение, быстро включились и собрали расстановку приоритетов, которая максимизирует вашу задачу, если вы готовы выполнить ее самостоятельно.
В цифрах это выглядит так: в октябре-ноябре почти половина (101 из 209) запросов на улучшение были выполнены командами самостоятельно.
Это привело к сокращению времени ожидания в четыре раза — с 2,5 месяцев до 2,5 недель.
Совершенно неожиданно дизайнеры приняли активное участие и рады помочь смежным командам, когда последним не хватает ресурсов или нужен свежий взгляд. Как оказалось, есть немало команд, которые могут задействовать дизайнеров на 100%, а сами они — творческие люди и любят переключать фокус на какой-то новый продукт.
Послесловие
Первые шаги по внедрению практики прозрачности и взаимодействия между командами в компании, привыкшей жить по законам предприятия, всегда самые сложные.Можно смело сказать, что первые стены прорваны и собран достаточный объём успешных историй InnerSource, чтобы движение внутри Сбера набрало обороты.
Мы видим главную задачу в будущем в том, чтобы избежать Закон Гудхарта .
В любой компании среднего и крупного размера производительность необходимо измерять: придумайте цифру и заставьте ее расти.
На конференции Осенью прошлого года в Балтиморе было приведено несколько случаев, когда постановка целей по показателям готовности команды и количеству улучшений приводила к саботажу показателей и выгоранию лидеров движения.
Мы считаем, что полученные выгоды стоят затраченных усилий, а открытость сама по себе имеет бесчисленные преимущества.
Мы готовы более подробно рассказать вам наш путь и обменяться опытом, пишите или звоните - [email protected] .
Целую, Сбер.
Теги: #Управление проектами #open source #agile #Innersource #культурный сдвиг #разработка в Сбербанке
-
Как Устранить Ошибки Драйвера Принтера Hp?
19 Oct, 24 -
Как Работают Лазерные Картриджи?
19 Oct, 24 -
1Пароль Бесплатен
19 Oct, 24 -
Камеры Наблюдения За Выборами
19 Oct, 24 -
Обзор Ноутбука Thinkpad X220 С Ips-Матрицей
19 Oct, 24 -
Турнир
19 Oct, 24 -
Создатель Yslow Будет Работать На Google
19 Oct, 24 -
Коллекция Ваших Работ Об Angular.js.
19 Oct, 24
