Привет, Хабр! Я Максим Коробов, 12 лет работаю в Т-Банке и занимаюсь клиентскими интерфейсами для физических лиц. Все, что фронт, желтое приложение или интернет-банк, — в моей зоне ответственности.
Расскажу про опенсорс, который сейчас есть в Т, и про то как он развивался. Надеюсь, наш опыт поможет кому-то сэкономить силы в аналогичной ситуации, а если будет что посоветовать — жду в комментариях.
Closed source, inner source
В большинстве компаний, в которых мне давали информацию об устройстве ИТ, говорили о том, что по умолчанию доступ к исходникам проекта имеет та команда, которая его разрабатывает.
Рядом со мной может сидеть коллега, который работает на соседнем проекте. Он может рассказать о нем, показать на мониторе, но увидеть что-то в коде по умолчанию я не смогу.
По пути к опенсорсу в ИТ-культуре хочется упомянуть иннерсорс — состояние, в котором по умолчанию исходники доступны всем внутри одной компании.
Всегда есть исключения: процессинг, безопасность, какие-то критичные системы, которые работают с персональными данными и поэтому их не должно быть в доступе. Но у фронта или прикладных сервисов отсутствие доступа к коду скорее препятствие для классных штук.
Наша компания прошла через несколько итераций переговоров с информационной безопасностью и добилась того, что больше 90% исходников доступны всем айтишникам. Тот, кто занимается процессингом, может посмотреть код API физлиц или мобильного банка и задать вопросы.
Открытие исходников стало первым шагом к иннерсорсу, но далеко не единственным. Необходима популяризация успешных решений, создание культуры открытости и возможности вклада в чужой проект.
Иннерсорс ведет к инженерной культуре открытости и взаимопомощи:
Ускоряются поставки и улучшается time-to-market для бизнеса.
ИТ становится как «Лего» — можно переиспользовать наработки соседних команд.
Дорабатывать проще, чем попросить. Удобнее и легче вносить вклад в соседний проект.
Растет инженерная культура: улучшается качество документации, автоматическое QA и CI/CD.
Основной барьер работы с иннерсорсом — информационная безопасность. Люди долгое время апеллировали к тому, что информация утечет, что взломают и так далее. Этот вопрос мы решали двумя способами: работали силой слова и накрутили кучу аудитов против утечек.
Пара примеров из жизни: UI KIT для ангуляра и VoIP SDK, который сделали для мобильного банка. Мы думали: «Зачем потратили силы, зачем выложили и оформили в виде библиотеки?» А через три года это понадобилось Инвестициям, Мобильному оператору, Бизнесу, и коллеги сказали: «Какие вы молодцы, что еще несколько лет назад подумали о том, что это может пригодиться!»
Теперь мы занимаемся иннерсорсом системно. У нас есть витрина, и там можно посмотреть все, что можно использовать: сервисы, библиотеки, платформы. В ней хранятся богатые коллекции кубиков «Лего», которые появились из-за того, что открылись исходники и выросло вовлечение.
Сотрудники могут:
Быстро найти конкретное решение под свою текущую проблему.
Собрать типовые прикладные сервисы из стандартных решений за часы, а не дни.
Монетизация проектов
Случается, что хорошие проекты становятся коммерческими. Успешная монетизация — доказательство востребованности продукта:
появляется внешнее финансирование развития продукта;
потребности выравниваются под нужды рынка, а не только для внутренних заказчиков.
К сожалению, большинство проектов, какими бы классными они ни были, будут не востребованы. Трудно ограниченными силами команды или компании сделать лучше что-то, что накоплено в мировом опыте и коммерциализируется.
Пример стартапа, который родился из ИТ-продукта, — наш Voice Kit. Мы автоматизировали работу колл-центра, чтобы обзвоны с напоминаниями о платежах проходили без участия человека.
AI-модель для преобразования текста в аудио и в обратную сторону мы сделали давно — лет семь назад. Делали для себя, но потом оценили, что решение сравнимо с рыночными, и завернули в сервис. Не то чтобы случился большой успех, но мы проверили, что так делать можно. А еще это оказалось конкурентным решением — и часть компаний с подходящими задачами выбирали нас.
Особая гордость — история с Sage. Система мониторинга Splunk была индустриальным стандартом для управления логами, удобный язык, с которым можно было делать борды. В 2022 мы не смогли продлить лицензию и стали анализировать, что есть на рынке.
Альтернативы нас не удовлетворили. Создали свое решение — так родился продукт, который называется Sage. Поначалу он был создан для мониторинга и управления логами, но постепенно вырос в платформу наблюдаемости с метриками, трейсингом и так далее.
История повторилась: сначала мы закрывали свою потребность, а когда ее закрыли, поняли, что из этого можно сделать деньги.
Опенсорс
Бывает такое, что проект, продукт или библиотека получились качественными, но не видно коммерческого потенциала. Такими продуктами можно поделиться с миром, и так мы приходим к опенсорсу.
Когда мы принимаем решение о публикации проекта, мы исходим:
из целесообразности, то есть того, в каком формате взаимодействия мы видим больше ценности — в опенсорсе или монетизации;
внутреннего желания — про отдавание в сообщество и подобное.
От опенсорса получается польза для всех сторон: сотрудников, бизнеса и мирового сообщества. Это в первую очередь:
развитие профессиональных навыков сотрудников;
нетворкинг в компании;
свобода участия в любое время в любом проекте и в любом объеме;
формирование профессиональных связей: контактов и опыта работы с профессионалами по всему миру;
развитие личного бренда, репутации и портфолио;
возможность влиять на индустрию разработки ПО;
вклад в общее благо;
улучшение эффективности, инженерной культуры и надежности;
повышение привлекательности HR-бренда компании в ИТ-среде;
рост социального статуса и благотворительного имиджа;
возможность переиспользования наработок внутри одной компании.
Выгода от опенсорса придет не сразу, но в долгосрочной перспективе она будет многократной.
Например, есть у нас проект, выложенный на Гитхабе, — библиотека утилит utils.js для веба. Делали для себя, потом посмотрели, что у нас неплохие результаты, и выложили. Этой библиотекой пользуются, есть метрики по перфомансу.
У нас есть графики — срезы по годам, когда был выложен проект по разным признакам: языкам программирования, типам проекта. Цифры одни и те же, просто разные срезы. Важно отметить тренд: чем раньше начнешь вкладываться в open source, тем быстрее окажешься в периоде четырех последних столбиков.
Плюсов для бизнеса и ИТ в этой истории много. За три года, как мы начали заниматься системной работой, мы:
собрали открытые проекты на любой вкус;
набрали очков популярности HR-бренда;
привлекли в проекты сторонних разработчиков.
Гибридные схемы
Между коммерцией и оперсорсом есть гибридные схемы. Немного про них расскажу.
Open Core — модель бизнеса, когда базовая часть у продукта открыта и можно пользоваться ею неограниченно, но есть расширенные платные функции или платная поддержка. Такой формат совмещает коммерцию и опенсорс.
Например, когда студенты делают какие-то стартапы, они пользуются базовой частью. Потом они становятся сотрудниками крупной компании, продолжают пользоваться этими продуктами, но уже в рамках интерпрайз-лицензии.
Open Source SDK — вариант, при котором исходники открыты, но под капотом лежит платный сервис. Можно разобраться, как это работает, проще контактировать с авторами, потому что есть площадка.
SDK выступает формой доступа к API, и, благодаря тому что она опенсорсная, ее можно доработать или портировать. У нас был пример с SDK для эквайринга. В нем есть прием платежей за услуги, который был написан на родных инструментах: на Котлине и Свифте для iOS и Android.
Компания-подрядчик Mad Brains взяла наше опенсорсное SDK и портировала его на Flutter, так как необходимо было встроить в мобильное приложение на нем. Благодаря тому что ПО было открыто, в Mad Brains решили свою задачу. Заказчик получил приложение, а мы — поддержку продукта на Flutter.
Этапы развития проектов в Т
Я собрал этапы развития проектов в единую схему.
Продуктовая трансформация ИТ в Т-Команде началась в 2020 году. Мы стали слишком большими, чтобы единое ИТ в режиме сервиса удовлетворяло потребности бизнеса. Мы трансформировались в кросс-функциональные команды под управлением бизнес-линий, но стали терять в эффективности и горизонтальных связях.
Проблему решили двумя действиями:
Создали Core Tech. Стали едиными базовые технологии, общие компоненты и общие инструменты. Все, что можно, стало общественным достоянием.
Создали Институт лидеров профессий. Ведущие представители разных бизнес-линий и команд хороводят сообщество и транслируют общую повестку. Они авторитетны и влияют на профессию внутри компании.
Лидер профессии — роль, а не должность. Был риск, что, если мы оставим все как есть, человек перестанет быть экспертом в своей профессии и уже не сможет быть ее лидером.
Лидеров профессии выбирают по 4 критериям:
заряженные;
мощные;
авторитетные;
разнообразные.
В теме open source лидеры профессий решают, какие новые проекты достойны выкладки от имени компании. Мы дошли до той стадии, на которой иногда отказываем.
Важность открытой документации
Очень важно описать правила игры. Вроде бы банальщина, но в половине случаев люди не знают процессы, хотя и готовы их соблюдать.
У нас есть упрощенный список, о чем сказать, когда хочешь поделиться своими наработками. Еще есть чат в корпоративном мессенджере для общих новостей и объявлений.
В очень большое количество критериев бренда работодателя бьет опенсорс. Эту информацию можно показывать техническим продактам, директорам или просто высокогрейдовым сотрудникам, которые говорят, что еще не время заниматься опенсорсом.
Всегда будет выгоднее в моменте делать задачи бизнеса. Всегда будут задачи, которые нужно сделать здесь и сейчас. Опенсорс всегда будет не вовремя, если пока его в компании нет.
Вопрос: откуда брать время на опенсорс? Я думаю, что это нужно делать целенаправленно. Находить таких же заряженных людей и, по сути, заниматься изменением инженерной культуры. Вот несколько рабочих рецептов:
убеждать руководство выделять рабочее время на опенсорс;
устраивать и поощрять участие в хакатонах и внешних мероприятиях;
применять опенсорс для образовательных программ, если они есть.
Да, это просто молоток, но он отлично забивает гвозди.
У меня есть смешной пример. Когда-то давно я столкнулся с багом в Википедии для iOS. При просмотре PDF там плохо работала прокрутка, я зарепортил 10 строчек и стал знаменитостью.
Хочется, чтобы люди, когда сталкивались с проблемой, не замалчивали ее, а говорили об этом. Столкнулся с проблемой, починил и счастлив оттого, что код приняли. Такие примеры хочется популяризовать.
Опенсорс — это часть материалов, которые нужны для производства ценности команды. Доработали документацию, добавили тестовый пример, которого не было в базе, — и какой был бы другой мир. Куча талантливых инженеров и продактов, которые подарили миру кучу крутых продуктов. Великая штука.
Выводы
Опенсорс — модель взаимодействия сотрудника, компании и внешнего мира, где все выигрывают. Такое сотрудничество — единственная стратегия, при которой все в плюсе. Моя цель — зарядить вас на это!
Я приводил примеры, где внутри компании образовалась выгода, когда через опенсорс и иннерсорс получилась огромная витрина сервисов, продуктов и библиотек. Да, не сразу, но со временем это принесло выгоду.
Мне кажется, классно, что можно прийти к коллеге и дополнить его работу, а не изобретать велосипеды.
С чего начать:
добиться открытия хранилищ кода сначала для инженеров компании;
найти заряженных людей и дать им полномочия;
пропагандировать культурные изменения на уровне компании.
Долгосрочные цели всегда будут проигрывать краткосрочным, и изменение культуры — это очень долгосрочное, что-то мета над нами. Нужно в какой-то момент остановиться и сказать: да, сейчас мы пожертвуем чем-то, чтобы через несколько лет у нас было все классно.
Не обязательно открывать все репозитории сразу, можно начать с малого. Например, с фронтов: там меньше всего секретов. Открыть один репозиторий, но рассказать о нем всем. Устроить хакатон и предложить всем, кто не в проекте, найти по 10 багов. Есть способы, чтобы маленькие шаги привели к большим сдвигам.
