что такое csl в сбербанке

Корпоративно-инвестиционный бизнес нового поколения Сбербанк CIB

Брокерский дом под брендом Сбербанк CIB начал свое существование в 2012 году. Его деятельность направлена на развитие инвестиционного и корпоративного бизнеса. Компания имеет широкий опыт в:

Оказание услуг и работа с банковскими продуктами проходит через ПАО Сбербанк.

Работая с финансовыми институтами, крупнейшими корпорациями, федеральными и субфедеральными органами управления, брокер осуществляет предоставление интегрированных финансовых решений и периодически выступает как финансовый советник. Иными словами Сбербанк CIB – это крупнейшая компания, чей профиль сосредоточен на управлении активами.

Сервисное обслуживание

Поскольку КИБ имеет огромные масштабы и большой объем клиентов (на обслуживании находится порядка 5,7 тыс. организаций), разумным было решение четко структурировать компанию.

ПАО Сбербанк занимается структурным и проектным финансированием, синдицированным кредитованием холдингов и конгломератов, осуществляет свою деятельность на инвестиционных и глобальных рынках.

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

Помимо этого Департамент ИД:

Следующая структурная единица – Департамент глобальных рынков. На него возложены сервисные операции по выгодному размещению ценных бумаг (инструментов срочного рынка, акций, облигаций), заключению контрактов по сырьевым материалам, валютные операции.

Департаментом глобальных рынков также осуществляется:

Аналитическая поддержка бизнеса на рынке акций и облигаций, макроэкономическое и стратегическое исследование рынка, глубокий анализ функционирования компаний РФ и предоставление независимого заключения лежит на Sberbank Investment Research.

Кому доступно обслуживание в банке

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

Стоит обратить внимание, что пакет документов для заключения договора на открытие счета для юридических лиц и физических лиц резидентов и нерезидентов имеет свои отличия. Ознакомиться с ним можно на официальном сайте sberbank-cib.ru. Для этого необходимо:

Порядок подключения QUIK

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

Подключив систему QUIK или webQUIK, при помощи браузера на ПК или ноутбуке, клиенту становится доступным участие в торгах, рыночная информация, глубокий технический анализ.

Для установки и регистрации в системе частному лицу необходимо:

Тарифы за обслуживание

Поскольку брокерская комиссия за исполнение Поручения по сделке периодически изменяется, а Sberbank CIB заботиться о достоверном информировании своих клиентов, на официальном сайте банка всегда присутствует и доступен для ознакомления PDF-документ с тарифами.

Для его просмотра необходимо:

Стать клиентом Сбербанк КИБ, значит стать успешным участником инвестиционного рынка и получать гарантированный доход и увеличение капитала благодаря содействию профессионалов высокого класса.

Источник

CSI – Индекс удовлетворённости клиентов

Для оценки лояльности клиентов компаниям недостаточно оценить свою деятельность лишь на основании оценки NPS. Покупателям задают вопрос, готовы ли они привести в данный магазин своих друзей и знакомых. Тем не менее, невозможно достоверно и сразу вычислить, что привлекло, а что отторгло этих же клиентов. Если показатель NPS «ушёл в минус», то, чтобы покупатели не перебежали срочно к клиентам, потребуется другой показатель – CSI, или индекс удовлетворённости этих же покупателей.

Индекс удовлетворительности клиентов

Customer satisfaction index – величина, определяющая, в какой степени клиенты довольны продукцией и обслуживанием в данном магазине. Так, при возрастании этой величины всего на 2% выручка магазина может возрасти также на одну пятую от первоначального объёма продаж. Выручка не менее 95% — хорошая величина. Сам индекс применяется как в бизнес-ориентированной, так и в клиентоориентированной модели продаж.

Что такое CSI?

Как уже говорилось, показатель CSI ясно демонстрирует, как покупатели относятся к продукции и сервису в том или ином магазине. Это важнейший индикатор, дающий возможность персоналу магазина и руководителям компании, в чьём ведении этот магазин находится, чутко отреагировать на пожелания клиентов.

Формула расчёта CSI

Расчёт по CSI включает в себя несколько стадий.

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

Пример расчёта CSI

Например, фирма X, торгующая оптом молочными продуктами обладает следующей сводкой.

Эта сводная таблица включает в себя четыре графы. Ценовая графа показывает, что оценка по стоимости уточняется через опрашивание клиентов. Вопрос в этом случае звучит так.

Этот вопрос включён в общее анкетирование – наряду с вопросами по качеству покупки и обслуживания. Оценивается покупка категории А.

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

УЦК= Ц кон/ Ц пр, где

УЦК — Уровень цен компании;

Ц кон. — цена конкурента;

Ц пр. — цена предприятия.

Далее используется другая форма подсчёта:

Стоимость литра молока на фирме X равна 97,6% от реальной рыночной цены, диктуемой первым конкурентом.

Графа «Качество товара» показывает, что индикатор встречаемости отбраковки равен отношению суммы бракованных упаковок к общему их количеству, ввезённому в магазин при выгрузке за один приём.

Индекс качества продукции считается по оценённому качеству на каждой из позиций. Форма расчёта состоит в следующем.

Масса продукции вычисляется по долевой продаже от общего оборота продукции. Оценивается качество на примере однолитровых упаковок пастеризованного молока. Форма отчёта выглядит следующим образом.

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

Графа «Сервис» показывает отметку дефицитности (УД), считаемую по следующему закону:

Д — дефицитность продукции в обычных единицах.

Т — показатель оборота товара в обычных единицах.

Что касается удовлетворённость складской деятельностью, то здесь также высчитываются следующие показатели.

Графа «Клиентские параметры» высчитывается показатель изменения объёмов продаж для клиентов группы А. При обнаруженном приросте продаж магазин получает уровень, равный 100%. При снижении – параметр по продажам определён в качестве отношения текущего уровня продаж к предыдущему.

Динамика по клиентам отслеживается следующим образом.

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

CSI в итоге из самой первой таблицы не доходит до 95%. Чтобы он поднялся, потребуется ещё больше снизить цены на продукцию, подняв вместе с тем качество товара (по всем параметрам) и поработать над улучшением обслуживания. Данная схема верна и работоспособна на любом предприятии.

Источник

Что такое CSI: основы

Узнайте, как измерить CSI для вашего бизнеса

CSI (Customer Satisfaction Index) — это показатель, с помощью которого измеряют удовлетворенность клиентов товарами, услугами, обслуживанием и компанией в целом.

Чтобы лучше понять, что такое CSI и как с его помощью можно улучшить customer journey, посмотрите это видео, в котором Павел Костин рассматривает кейс компании Hoff.

Содержание

Зачем измерять CSI

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

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

В следующем разделе вы ознакомитесь с преимуществами измерения индекса удовлетворенности покупателей.

Преимущества CSI

Удовлетворенность клиента влияет на уровень удержания пользователей и формирование лояльности. Поэтому многие компании стремятся измерять CSI на постоянной основе, чтобы принимать взвешенные решения и анализировать результативность маркетинговых действий. Давайте посмотрим, что позволяет узнать индекс удовлетворенности потребителей.

В следующем разделе вы узнаете, как измеряют Customer Satisfaction Index и что для этого нужно.

Как узнать CSI

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

Этап 1

Это этап подготовки, во время которого определяют цель измерения индекса удовлетворенности. Важно выбрать объект исследования и основной параметр. Чтобы увидеть реальную картину, независимо от сферы деятельности и специфики работы, следует измерять CSI по одному направлению. Для этого выделяют один из критериев комплекса маркетинга. Например, в 4P это будет продукт (Product), цена (Price), месторасположение (Place) и продвижение (Promotion).

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

Этап 2

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

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

Предположим, компания В решила исследовать качество сервиса. В опросе принимали участие 50 человек, а общая сумма оценок обслуживания составила 425 баллов. Давайте рассчитаем индекс удовлетворенности.

CSI = 425 / 50 = 8,5 баллов

По такому же принципу рассчитывают и важность качества обслуживания для клиентов. Поскольку анализ проводили по десятибалльной шкале, результат 8,5 считается высоким. Чтобы увидеть, что необходимо улучшить, следует выделить пользователей, которые поставили низкую оценку качеству сервиса, и установить причину.

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

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

Источник

Как мы переписывали сервер-сайд СберБанк Онлайн на микросервисы

Вы, наверное, в последнее время часто слышите о новых продуктах Сбера, со многими из них сталкиваетесь как клиенты.

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

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

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

Уточним вводные, с которыми предстояло работать:

продуктовых команд будет много (несколько сотен — в ближайшей перспективе и тысячи — в перспективе). Размер одной команды — около 10 человек, возможность разрабатывать функционал end-to-end;

T2M по бизнес-функционалу — 2‒3 недели. Разумеется, срочные фиксы должны выходить на клиентов в течение часов;

приложения должны иметь лучший клиентский опыт и высокие оценки в App Store и Google Play;

текущий сервер-сайд и фронтальные приложения — монолиты с многолетней историей;

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

большинство операций — банковские. Это к тому, что платёжные транзакции, в отличие от, например, развлекательного контента, нельзя терять ни в коем случае. А если мы не отразим корректный остаток по картам в момент входа, сразу положим контакт-центры высоким количеством обращений клиентов;

надёжность и безопасность — высшие приоритеты.

Теперь пару слов о том, что мы называем сервер-сайдом СберБанк Онлайн. Как правило, сервер-сайд в крупной организации можно условно разделить на два основных слоя — мидл, который обеспечивает надёжность, доступность и хороший UX клиентских приложений, и бэкенд, который хранит и обрабатывает мастер-данные по разным системам (например, карточный процессинг, вклады или «Кредитная фабрика»).

Когда мы говорим «сервер-сайд приложений СберБанк Онлайн», имеем в виду именно мидл-слой, который отвечает за следующий функционал:

бизнес-приложения (прикладные), которые реализуют конечный функционал для пользователей приложений;

аутентификацию пользователя в приложении;

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

общие страницы приложения (главный экран, история операций и т. д.);

логирование, мониторинг, авторизацию и другой функционал для надёжности и безопасности.

Список на этом не заканчивается, но должен дать общее представление. Явно ещё раз подчеркну, что бэкенд не входил в объём поставленной задачи.

Зачем новая платформа

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

Достичь низкой связанности можно было двумя способами. Первый — глубокий рефакторинг текущего Legacy с целью разделить прикладной и платформенный функционалы на отдельные компоненты, которые взаимодействуют по зафиксированным контрактам. И второй — создание платформы с нуля с последующей миграцией прикладного функционала и пользователей. По совокупности причин выбрали второй вариант.

Ключевые моменты

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

Разделили сервисы на две группы — платформенные и прикладные

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

Для таких сервисов невозможно обеспечить T2M в пару недель, потому что все пользуются логированием, и, если мы не протестируем потребителей во время нового релиза, есть риск потерять в качестве.

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

Почему мы акцентируем внимание на количестве связей? Если грубо, то каждая зависимость — это дополнительный тестовый кейс или несколько кейсов. Кроме того, при росте количества связей мы получаем высокую спутанность и, как следствие, циклические зависимости. И неутешительные сроки по исправлению дефектов. Всё это напрямую влияет на T2M.

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

В нашем случае получилось порядка 40 платформенных и около 10 пилотных бизнес-сервисов на старте. На данный момент количество платформенных сервисов почти не изменилось, а число прикладных проектов превысило 250.

Создали отдельные релизные процессы

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

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

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

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

Ввели контроль платформенного API

Понятная вещь, о которой все говорят, но которая не всегда случается. Обязательные правила, которые мы применили:

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

создали инструмент, который осуществляет контроль этого API. У нас для этого есть отдельный компонент — синтетическое приложение. О нём чуть позже;

сделали процесс согласования изменения API максимально дорогим:

согласование изменений архитектурой платформы;

согласование со всеми потребителями API;

согласование с руководителями. Инициатор изменений должен был получить ОК от двух ключевых людей — владельца СберБанк Онлайн и руководителя программы внедрения новой платформы. Да, им лично приходилось объяснять, почему API всё-таки нужно поменять и как так случилось, что делать это нужно после того, как началась разработка. И да, такие кейсы были, но штучные. По сравнению с потоком изменений, которые были до введения контроля, — ничтожное количество.

Важно отметить, что мы строго контролируем API в рамках минорных релизов платформы и не строго (изменения возможны, но согласуются с архитектурой) — в рамках мажорных релизов.

Следим за удобством разработки на платформе

Случается так, что платформу сделали, а пользоваться ей неудобно. Вроде как клиент платформы — внутренний, поэтому может потерпеть. Это большая ошибка, особенно когда потребителей платформы много. И мы создали независимый орган, который следит за клиентским опытом потребителей платформы и отстаивает их интересы — «Синтетическое приложение».

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

выпуск POM/BOM. Большая часть платформенного API предоставляется в виде клиентских библиотек. Ребята из «Синтетического приложения» собирают их вместе, разрешают конфликты зависимостей и публикуют для потребителей POM- и BOM-файлы;

контроль обратной совместимости API. Кроме проверки на конфликт зависимостей, все библиотеки проходят тестирование на бинарную совместимость с предыдущими версиями;

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

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

СSI и обратная связь. Продукт не может быть хорошим, если нет механизма обратной связи от клиентов. Мы проводим регулярную оценку CSI и сессии обратной связи с потребителями платформы. После этого направляем фидбэк в команды разработки платформенных сервисов и контролируем, что «боли» клиентов не останутся без внимания;

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

Архитектурный контроль

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

Где мы сейчас и что делаем дальше

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

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

Тем не менее мы ещё в начале пути и ещё много задач, которые предстоит решить:

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

нормальный технологический стек и удобство разработки. Если вы обратили внимание, в цели проекта не входило внедрение нового стека. Даже больше: мы сознательно от него отказались. Основной аргумент — не увеличивать сложность на и так сложном проекте. Если смена стека с точки зрения разработки несёт приемлемые риски, то с точки зрения эксплуатации и внедрения риски очень высокие. Так как надёжность, доступность и безопасность — самые важные критерии, которым мы следуем при любой разработке в СберБанк Онлайн, то и требования к инфраструктуре и эксплуатации очень высокие. Поэтому смена стека в run-time требует большой аккуратности, что неизбежно сказалось бы на сроках.

Так что наши разработчики счастливо программируют на Java 8. А деплоится это всё на вендорском JDK. Многие, кто слышит об этом на наших собеседованиях, расплываются в улыбке от счастья. Или не от счастья, мы точно не знаем. Если серьёзно, то это надо менять, и одна из текущих задач на платформе сейчас — смена стека. А для прикладных команд мы обсуждаем возможность разработки на Kotlin.

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

Спасибо за внимание, жду вопросы в комментариях.

Источник