Siebel oui тинькофф что это

Обновлено: 19.04.2024

Эта статья пишется для того, чтобы дать представление о довольно специфическом программном комплексе, который используется во многих крупных предприятиях по всему миру, но при этом остается малоизвестным широкому кругу IT-специалистов, даже в сравнении с подобными ему продуктами, как, например, SAP.
Доступной литературы по ней довольно немного, или она настолька туманна и запутанна, что человеку «с улицы» может быть нелегко понять, что это вообще такое. Здесь мы попробуем прояснить этот вопрос.

Весь этот комплекс я буду называть просто Siebel, официально он называется Oracle Siebel CRM. Название Siebel представляет собой фамилию основателя компании (Thomas Siebel). В 2006 году компания была продана корпорации Oracle.

Siebel в первую очередь представляет собой систему управления взаимоотношениями с клиентами (Customer Relationship Manаgement — CRM). Эта система может быть установлена во множестве уже готовых «из коробки» конфигураций, как-то Siebel Call Center, Siebel Finance, Siebel Loyalty (с движком для системы программ лояльности клиентов), Siebel Hospitality (для гостиничного бизнеса) и многих других. Тем не менее, потребители продуктов Siebel (обычно это достаточно крупные компании, работающие по крайней мере с десятками тысяч клиентов), как правило, требуют «заточки» системы под нужды не только отрасли, но и конкретного предприятия. Поэтому создатели системы старались обеспечить максимальную гибкость настройки и разработки.

image

С точки зрения пользователя (сотрудника компании-заказчика) Siebel, как декларируется, представляет собой практически zero-footprint application, т.е для работы не требуется установка какого-то специального клиента. Работа с Siebel осуществляется просто в окне Internet Explorer. На самом деле при первом обращении к серверу устанавливаются соответствующие ActiveX компоненты, обеспечивающие действия с элементами управления.
К сожалению, на данный момент другие броузеры (кроме IE) не поддерживаются. Как легко понять, это привязывает пользователей к Windows (что касается серверов Siebel, то они могут работать как под Windows, так и под Linux, а также Solaris, HP-UX и т.д.).
Графический интерфейс пользователя выглядит примерно так:

Разумеется, доступны модули поддержки множества языков, включая русский.

image

Основной объект GUI Siebel — так называемый апплет. Это часть экрана, отображающая таблицу (list-applet) или данные из одной записи в виде формы (form-applet). Апплет обычно содержит меню и элементы управления в виде кнопок на экране. С их помощью пользователь добавляет или удаляет записи, совершает запросы (query) и другие действия, например, запуск какого-либо бизнес-процесса. Как уже говорилось, Siebel представляет огромные возможности для кастомизации, ограниченные разве что фантазией заказчика/разработчика. На картинке мы можем видеть один лист-апплет и один форм-апплет.

Здесь мы не можем вдаваться в тонкости работы с GUI, лучше опишем, как все это реализовано технически.

Как уже стало понятно, Siebel в первом приближении представляет собой некую графическую надстройку над БД, работающую, как веб-приложение. Базой может быть не только Oracle, но и, например, MS SQL Server или что-то еще. При установке системы автоматически создается огромное количество таблиц — создатели старались включить в комплект все, что кому-то может понадобиться. Тем не менее, всегда можно добавить и кастомные таблицы и колонки. Подавляющая часть информации о конфигурации самого Siebel (списки элементов GUI, кастомные скрипты, взаимосвязи между объектами) также хранится в той же базе, причем там может находиться множество репозиториев (версий конфигурации Siebel) сразу. Тем не менее, та конфигурация, которая реально используется сервером в данный момент, должна быть скомпилирована в специальный файл с расширением SRF. Без этого файла сервер работать не может.

Серверы Siebel объединяются в логические группировки (Enterprises). Работой энтерпрайза управляет служба под названием Siebel Gateway Name Server. К этому серверу обращается веб-сервер (Оracle, IIS..), снабженный специальными «расширениями» (SWSE — Siebel Web Server Extensions). Таковы основные элементы среды Siebel.

image

Основной инструмент разработчика Siebel — программа под названием Siebel Tools, которая и осуществляет компиляцию.

image

image

В простых случаях разработка осуществляется декларативно, посредством «перетаскивания мышкой» ЭУ GUI на форму и заполнения соответствующих полей данными, наподобие того, как создается приложение Windows Forms в Visual Studio. Для программирования более сложного поведения системы обычно используется либо встроенный язык (фактически это JScript или VBScript, на выбор разработчика), либо графический Workflow Designer.

Основной инструмент отладки — Siebel Dedicated Web Client (на жаргоне его называют «толстым клиентом», в отличие от «тонкого клиента», с которым работают пользователи работающей системы). Несмотря на название, «толстый клиент» представляет собой некий мини-сервер Siebel, запускаемый, как и Siebel Tools, на машине разработчика. Обычно работа разработчика представляет собой последовательность следующих действий:


Банк собирался заменить старую систему на новую, чтобы повысить эффективность работы операторов:

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

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

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

  1. мы изучаем работу операторов системы и формулируем требования к новому интерфейсу;
  2. в соответствии с полученными требованиями разрабатываем концептуальные, а затем и детализированные прототипы новой системы;
  3. тестируем систему, корректируем прототип;
  4. оцениваем потенциальную эффективность новых интерфейсов по методу GOMS;
  5. дизайнеры Тинькофф Банка отрисовывают экраны новой системы в соответствии с нашими прототипами;
  6. команда разработчиков Тинькофф Банка воплощает новую систему в коде.

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

Проблема: конкуренция двух команд

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

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

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


Фрагмент переписки с заказчиком

Выход: сотрудничество двух команд

Сложная ситуация во взаимодействии между проектировщиками USABILITYLAB и дизайнерами Тинькофф Банка заключалась в том, что и те, и другие пытались выполнить одну и ту же задачу: подготовить макеты экранов, опираясь на результаты проведенного командой USABILITYLAB исследования и свой опыт. Поэтому, чтобы выйти из тупика, мы договорились с руководителем проекта со стороны банка о разделении обязанностей между нами и дизайнерами. Мы стали отвечать за компоновку всех информационных блоков на экране и за общую концепцию, а дизайнеры — за визуализацию этой концепции. Готовые экраны мы вместе должны были представлять представителям руководства Тинькофф Банка каждую неделю. Таким образом, «команда USABILITYLAB» и «команда дизайнеров Тинькофф Банка» исчезли: мы стали единым целым с общим заказчиком и общими целями.


Фрагмент переписки с заказчиком, в которой были зафиксированы договоренности по новому формату работы

Работая по такой схеме, мы каждый день созванивались с дизайнерами и обсуждали: что было сделано за день, в чем возникли проблемы и что будет делаться дальше. Для созвонов и обмена файлами мы использовали Skype, а достигнутые договоренности записывали в Google Docs. Мы создали единый документ, в котором для каждого созвона фиксировали дату, вопросы, которые обсудили и задачи, которые надо было решить. Для каждой задачи обязательно прописывался ответственный в лице конкретного сотрудника.


Пример фиксации итогов созвона

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

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

Результат проекта


Концептуальная схема строения основных экранов системы

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


Пример работы «умной» поисковой строки

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


Пример рабочей области основного экрана системы для входящего звонка с неизвестного номера

По нашей предварительной оценке, выполненной по методу GOMS, работа с новой системой может позволить сократить время обработки одного обращения примерно в 2-4 раза, а в некоторых случаях даже почти в 6 раз, за счет сокращения числа действий, которые оператор совершает в системе.


Отрывок из отчета о предварительной оценке системы. Оценивается «чистое» время работы оператора в боевой системе и в прототипе, т.е. оценка времени посчитана без учета разговора с клиентом, поскольку длительность реплик клиента контролировать невозможно. Также в оценку не входило время отклика системы, т.к. в случае прототипа отклик заведомо быстрее, поскольку не происходит обращений в базу данных, как в боевой системе.

Совместная работа двух команд как фактор успеха проекта

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

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

Заключение

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

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

Подписывайтесь на наш Телеграм, чтобы не пропустить выход новых полезных статей!

Москва, 22 марта 2007 года. Компания Sputnik Labs объявила о том, что реализует проект внедрения CRM-системы на основе Oracle Siebel CRM в банке «Тинькофф. Кредитные системы».Банк «Тинькофф. Кредитные системы» - новый проект Олега Тинькова в области розничного кредитования. Внедряемая CRM-система поможет «Тинькофф. Кредитные системы» стать самым технологичным розничным банком, специализирующимся на кредитных картах, и предназначенным для работы с несколькими миллионами клиентов. Система Oracle Siebel CRM была выбрана руководством банка как лучшее решение на мировом рынке, аккумулирующее опыт ведущих розничных банков и отвечающее основным требованиям: богатым набором CRM-функциональности для розничного банка, возможностями масштабируемости и прозрачной методологией внедрения. Работы по проекту осуществляет компания Sputnik Labs, сертифицированный партнер Oracle по продукту Oracle Siebel CRM, обладающая широкой экспертизой внедрения Oracle Siebel CRM в розничных банках в России и СНГ.По мнению Кирилла Булгакова, генерального директора компании Sputnik Labs, внедрение Oracle Siebel CRM в банке «Тинькофф. Кредитные системы» является одним из знаковых проектов. Он демонстрирует, что CRM становится ключевым приложением, без которого эффективное существование розничного банка в современных условиях невозможно.

Sputnik Labs (OOO «Спутник Лаборатории») – лидер на рынке систем управления клиентскими отношениями (CRM). Основной акционер Sputnik Labs – инвестиционная компания Sputnik Group. Область специализации с момента создания и по сегодняшний день – Управление Взаимоотношениями с Клиентами, начиная от разработки стратегии и заканчивая адаптацией пользователей, их мотивацией и обучением. Благодаря стратегическому партнерству с ведущими мировыми поставщиками CRM-систем компания Sputnik Labs обладает уникальным опытом и отраслевой экспертизой успешных внедрений CRM-систем. За 6 лет работы компанией реализовано более 25 успешных проектов Oracle Siebel CRM в крупнейших финансовых, страховых, фармацевтических, производственных и телекоммуникационных компаниях России и СНГ. Sputnik Labs является сертифицированным партнером корпорации Oracle по продукту Oracle Siebel CRM в России и СНГ.

Для получения дополнительной информации обращаться:

Релиз опубликован: 2007-03-22

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

Банкирам трудно угодить, поскольку такие заказчики являются одними из наиболее консервативных и в то же время – одними из наиболее современных в плане требований к ИТ. Внедрение компанией "БиАй Телеком" BPM-системы и системы управления бизнес-правилами (BRM) в банке "Тинькофф Кредитные Системы" (ТКС) стало серьезным шагом в направлении банковской автоматизации. О том, как проходила реализация проекта, в интервью CNews рассказали председатель правления банка "Тинькофф Кредитные Системы" Георгий Чесаков, вице-президент банка ТКС Вячеслав Цыганов и заместитель генерального директора, операционный директор компании "БиАй Телеком" Роман Ткачёв.

Интервью с экспертами

CNews: Какими факторами, на ваш взгляд, обусловлено развитие ИТ в целом и BPM в частности в России?

Георгий Чесаков: В сфере ИТ Россия совершенно объективно отстает от Запада. Даже о таких популярных за рубежом системах, как CRM, можно сказать, что у нас они только завоевывают рынок. Точно определить, почему это происходит, сложно, но факт тот, что в плане внедрения приложений для автоматизации бизнеса вообще и банковского – в частности, Россия не является лидером.

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

Чтобы соответствовать новым требованиям, надо менять старые технологии. Особенно это актуально, если необходимо предоставлять какие-то услуги в режиме онлайн, например, выпускать кредитные карты (если люди сегодня подают нам заявление, то около 95% из них получают ответ "да или нет" в течение 3-х минут, а готовая карта приходит к ним уже на следующий день). Сегодня мир ускоряется, причем не на проценты, и даже не в разы, а на порядки.

Особенно это заметно в мегаполисах, таких как Москва, и городах-миллионниках. Даже поездка из дома на работу и обратно отнимает достаточно много времени и сил, а если надо ехать еще и в банк… Это может стать достаточно серьезной проблемой.

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

CNews: Расскажите, трудно ли внедрить процессный подход в банке? Ведь без такого подхода BPM едва ли сможет эффективно работать…

Георгий Чесаков: BPM - это не только, и даже не столько ИТ-система, сколько сам процессный подход, заложенный в ее основе. Однако во многих российских банках, да и в российской экономике вообще, сегодня по-прежнему господствует функциональный подход. Создаются многочисленные департаменты, за человеком закрепляется определенная функция или ряд функций.

Об интеграторе
Исполнитель проекта, компания "БиАй Телеком", внедряет системы управления бизнес-процессами (BPM) в отечественных организациях более 5 лет. На раннем этапе развития она оказывала консалтинговые услуги в области процессного управления и моделирования деятельности таким крупным операторам связи, как "МТС", "ВымпелКом", "МегаФон", помогая выстроить бизнес-процессы с использованием лучших мировых стандартов eTOM, NGOSS, BPMN. Параллельно процессному консалтингу в компании активно развивались направления автоматизации бизнес-процессов с помощью BPM-систем и системной интеграции с использованием ESB/SOA, которые постепенно привлекали всё больше клиентов из других отраслей.

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

О заказчике Банк "Тинькофф Кредитные Системы" основан в 2006 году предпринимателем Олегом Тиньковым для дистанционного обслуживания клиентов на рынке кредитных карт. В середине 2007 года банк приступил к эмиссии кредитных карт. Банк "Тинькофф Кредитные Системы" входит в Систему страхования вкладов. Программа онлайн-депозитов банка успешно стартовала в марте 2010 года и действует в Москве, Санкт-Петербурге, Екатеринбурге, Казани, Красноярске, Новокузнецке, Новосибирске, Перми, Сочи, Тольятти, Томске, Ульяновске и Уфе. По состоянию на 25 июля 2011 года число выпущенных карт превысило 1,3 млн штук. На 1 июля 2011 года банк занимает 5 место по кредитному портфелю на рынке кредитных карт (15,5 млрд рублей) с долей 5,4%.

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


Кратко, наши принципиальные требования к BPM – это максимальная гибкость бизнес-процессов в сочетании с возросшей скоростью их исполнения (на порядки быстрее и производительнее той системы, которая использовалась до внедрения) при том же (или более выском) уровне надежности. Любой ИТ-специалист скажет, что добиться этих пожеланий одновременно крайне сложно.

CNews: До принятия решения о внедрении BPM в ТКС ключевые функции банка уже были автоматизированы. Чего не хватало? Какими были предпосылки принятия решения о внедрении BPM?

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

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


Задачи и результаты проекта

Проект "Онлайн обработка кредитных заявок" непосредственно затронул интересы и деятельность трех подразделений банка "Тинькофф Кредитные Системы": Департамента информационных технологий, Департамента бизнес-технологий и Департамента управления рисками. Департамент информационных технологий стремился получить в своё распоряжение быструю и надежную систему, удобную в администрировании и поддержке. Задача минимизировать время системной обработки стала одним из главных вызовов проекта для команды "БиАй Телеком". Банк обозначил, что это время должно измеряться минутами, а не часами. При этом система обязана выдерживать максимальную нагрузку в несколько тысяч заявок в час. Исходя из указанных целевых показателей принималось большинство архитектурных решений, на их основании проведен расчет требуемых аппаратных ресурсов, закуплены и развернуты промышленные серверы. В завершающей фазе проекта многократные нагрузочные испытания на промышленном контуре показали, что системное время обработки при пиковой нагрузке не превышает пятнадцати минут (в реальной эксплуатации оказалось даже менее 5 минут). Разработанная на платформе BPM-система призвана гарантировать не только скорость, но и надежность процесса обработки, а также гибкость управления входящим потоком заявок. Надежность обеспечивается сквозным обработчиком ошибок, интерфейс которого наглядно представляет администратору все исключительные ситуации в процессе. Найденные ошибки группируются по типам, работает поиск и фильтрация результатов, доступны детальное описание ситуации по каждой проблемной заявке и вся история обработки. Результаты промышленных испытаний показали, что объем непредусмотренных ситуаций в процессе составляет в пике несколько процентов, и наличие обработчика ошибок актуально. Для управления входным потоком разработчиками "БиАй Телеком" создан сервис удержания заявок, позволяющий блокировать автоматическую обработку экземпляров заданных типов для принятия экспертных решений, а затем вернуть удержанные заявки в основной процесс индивидуально или партиями для продолжения обработки. Этот функционал активно применяется для рассмотрения спорных заявок и быстрого реагирования на форс-мажорные ситуации.


Знакомьтесь: библиотека TiRecycler


Всем привет! Меня зовут Александр Гузенко, и в Тинькофф я занимаюсь всякими техническими вещами вроде CI/CD, gradle и внедрением новых подходов. Хочу рассказать вам про библиотеку, которую мы создали в команде Тинькофф Бизнеса, когда столкнулись с многословными адаптер-делегатами.

Дополнительные временные ряды в ETNA


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

Использование Gatling. Тестирование gRPC


Всем привет! Команда тестирования производительности Тинькофф продолжает цикл статей о нагрузочном тестировании различных протоколов с помощью Gatling.

Gatling. Тестирование JDBC


Тинькофф Инвестиции про новую версию API и конкурс торговых роботов


Привет! На связи команда Тинькофф Инвестиций. Мы запустили новую версию программного интерфейса для алгоритмического трейдинга. Расскажем про Tinkoff Invest API и что новенького в сервисе.

Как мы научили «AI да Пушкин» создавать стихи и какие еще технологии использовали


Привет! Недавно мы представили проект «AI да Пушкин». Благодаря нейросетям поэт генерирует четверостишия по первым словам, которые предлагает пользователь. А затем читает вслух то, что получилось. Увидеть и услышать, как это происходит, можно на сайте проекта. А мы расскажем, как решили проблему отсутствия рифмы с помощью контролируемой генерации текста и какие технологии использовали, чтобы сделать проект более эффектным.

Как мы ускоряли е2е-тесты на Cypress в GitLab


Всем привет! На связи Николай Мезинов, разработчик фронтенда в продуктовой команде DevPlatform. Хочу поделиться опытом, как мы ускоряли прохождение e2e-тестов на Cypress в пайплайнах GitLab.

Как сделать инициирующую загрузку в NiFi


Давайте поговорим про Apache NiFi. Этот ETL-инструмент все чаще используют при загрузке данных в хранилище, правда, не всегда по назначению. Об одном из таких сценариев я рассказывал на конференции SmartData. Видео можно посмотреть на Ютубе, но я все равно рекомендую вам прочитать этот текст: здесь я собрал новые мысли и идеи. Речь пойдет об инициирующей загрузке, или перегрузке данных из источника.


Всем привет! Это команда тестирования производительности Тинькофф, и мы продолжаем цикл статей о Gatling.

Как сохранять историю процессов в Camunda без вреда для них


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

Как прогнозировать временные ряды с ETNA


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

[Под катом много картинок и GIF]

Использование Gatling. Введение


Привет! Мы — команда тестирования производительности в Тинькофф, и мы любим инструмент Gatling. В цикле статей мы расскажем об использовании Gatling и дополнительных инструментов, упрощающих разработку скриптов.

Возможно, вы уже читали наши статьи про Gatling: первую и вторую. Они успели устареть, поэтому мы решили вернуться с обновленной информацией.

Зачем системному аналитику читать «Чистую архитектуру» Роберта Мартина


Меня зовут Сергей Марков, я системный аналитик бэковой части в Академии Инвестиций Тинькофф.

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

Кто такой data-инженер в Тинькофф и как им стать


Привет! Меня зовут Михаил Иванов, я работаю архитектором DWH в Тинькофф и занимаюсь развитием Batch ETL направления платформы обработки данных. Я расскажу о направлении data engineering в Тинькофф, о том, чем занимаются data-инженеры и как попасть к нам в команду.

100 символов, или Как влияет длина строки на читаемость текста


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

Роберт Брингхерст в книге «Основы стиля в типографике» говорит, что оптимальное значение длины строки составляет от 45 до 75 знаков. 66 — идеальный вариант, а для многоколонного набора — 40—50 знаков.

Максим Ильяхов пишет, что за максимум берет 75 знаков, — столько помещается на страницу А4 с полями при наборе 12-м кеглем.

Smashing Magazine в 2009 году провели исследование и выяснили, что средний результат символов на строку равен 88,74, а среднее значение изменяется от 75 до 85.

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

Автор статьи

Куприянов Денис Юрьевич

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: