Ранняя эпоха IT в США обрела легендарный статус: про начинания таких технологических гигантов, как Apple и Microsoft, снимают фильмы и сериалы, а биографию их основателей знает каждый программист. А вот про жизнь и достижения программистов СССР того же периода знают лишь единицы.

Среди них не было таких звезд, как Стив Джобс и Билл Гейтс, а их “бизнес” был частью государственных организаций, большинство из которых исчезли после распада Советского Союза. Тем не менее, IT было одной из самых престижных профессий в СССР, а советские программисты старались извлечь максимум из ограниченных технологических возможностей за “железным занавесом”.

ИТ начались не с Билла Гейтса и Стива Джобса, и даже не с Алана Тьюринга. Первым программистом в истории была Ада Лавлейс — дочь знаменитого лорда Байрона и завсегдатая салонов начала 19 века. Рассказываем, как Лавлейс изобрела современное программирование и почему ее влияние до сих пор ощущается в этой области.

Почему банк сам учит себе разработчиков, тестировщиков и продактов, какие передовые практики использует — и почему при поступлении в «Школу» даже не смотрят на оценки в вузе — рассказывает руководитель по развитию ИТ и цифровых компетенций ПСБ Алексей Кожин.

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

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

– Зачастую причиной является неправильная работа с асинхронными операциями. В статье разберемся, как Jest помогает писать молниеносные тесты, и рассмотрим ключевые сценарии.

В прошлой статье о некоторых группах респондентов фигурировали любимцы публики: дворовый парень, VIP-клиент, эксперт, продвинутый и провинциал. На самом деле, мы невероятно благодарны за обратную связь по статье как коллегам (эх, какой был тред воспоминаний о встречах с типажами!), так и всем-всем-всем заинтересованным лицам.

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

Заметки модератора на полях про мой опыт: 12 неполных лет в качественных исследованиях (GfK, Ipsos) + год в банке. Из них 5 лет в финтех-рисече и 2 года в UX. Итак: финтех, банковская сфера, продуктовые in-house исследования.

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

• Само решение: сможем ли мы успешно конкурировать с зарекомендовавшими себя аналогами, не пострадает ли доступность и надёжность систем и автоматизация наших процессов?

• Издержки: сама миграция, адаптация к ней, сопровождение системы.

• Пользователи: полтысячи человек, привыкших к старому техпроцессу. Как они отреагируют, если их привычная система откажет?

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

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

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

В ноябре нашей собственной розничной АБС будет 17 лет – и в этой статье мы расскажем о том, как выросли в 10 раз и не сошли с ума: перевели аналоговые ТЗ в цифровой формат, внедрили процессы подбора, онбординга, оценки и развития сотрудников.

Привет, Хабр! На связи Кирилл Маканков, руководитель направления мобильной разработки малого и среднего бизнеса в ПСБ. Недавно приложение нашего банка заняло сразу два топовых места в рейтингах мобильных банков. Третье в списке лучших банков для ИП без сотрудников и второе — в общем списке лучших мобильных банков на Android.

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

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

Мы продолжаем сражаться с шаблонным кодом в табличных экранах iOS-приложений. 

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

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

В этой статье рассмотрим, как избавиться и от такого кода. 

Привет, Хабр! Меня зовут Маша Нижегородова, я работаю в отделе исследования клиентского опыта ПСБ. В этой статье я собрала стыдные вопросы про особые категории респондентов на UX-исследованиях в банковской сфере и рекомендации по работе с ними.

Я опиралась не на теорию, а на собственный опыт. Конкретнее - 12 неполных лет в качественных исследованиях (GfK, Ipsos), из них пять лет в финтех-рисёче и два года в UX. Плюс год в банке.

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

• Дворовый парень со смартфоном

• VIP-клиент

• Провинциал

• Эксперт

• Продвинутый

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

Интересно? Тогда добро пожаловать под кат :)

Привет, Хабр!

Меня зовут Вильян Яумбаев, в этой статье я расскажу вам про наши приключения на пути к SPM.

В 2015 ПСБ начал разрабатывать проект для бизнеса. Для него, в свою очередь, было нужно приложение. Сперва всё находилось в одном репозитории одного проекта в одном воркспейсе. Первые авторы подключали сторонние зависимости через CocoaPods, поскольку проприетарного менеджера зависимостей ещё не существовало. Но в тот же год в Apple началась работа над Swift Package Manager. Им предстояло встретиться в нашем проекте.

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

Нередкая ситуация: бизнес хочет быстро вносить изменения в такие справочники, как продуктовый каталог и тарифы. Уровень критичности этих справочников — mission/business critical. Самый быстрый вариант — менять сразу на проде. Но если вносить изменения в такие справочники без тестирования, то в случае ошибки рискуешь получить страховки с комиссией в разы больше или меньше нужной, да ещё полный сбой оформления кредитных заявок.

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

<Погрузиться в изменчивый мир бизнес-справочников/>

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

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

Дизайнер и фронтенд-разработчик — не чужие друг другу люди. Они работают в соседних кабинетах, вместе ходят в курилку (по крайней мере, так было до повсеместной ковидной удалёнки). Оба делают части одного большого дела и общаются если и не постоянно, то регулярно. И всё же их языки во многом отличаются. Да и не только языки — сами образы мышления.

Мы поговорили с сотрудниками Промсвязьбанка, чтобы составить небольшой… Нет, не разговорник. Понимайник. Возможно, кому-то он поможет общаться с коллегами по ту сторону HTML более конструктивно, эффективно, а главное — приятно.

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

В этой статье я расскажу о библиотеке Charts и покажу на реальном примере, как создать свой первый график. 

В декабре мы участвовали в хакатоне «Цифровой прорыв» со своим кейсом. Мы просили участников разработать программное решение для онбординга 
новых IT-специалистов банка.

Задача состояла в том, чтобы объединить информацию из нескольких систем. И команды справились. Например, предложили web- + Android- + iOS-версии системы для хранения данных банка, чтобы новичку было удобно знакомиться с проектами, командой, правилами работы, системой и её архитектурой. Решения содержали разные варианты проверки знаний нового IT-специалиста. Так новичкам будет проще адаптироваться к работе в банке.

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

В этой статье решили поделиться задачей, решениями и впечатлениями, так что если интересуетесь темой — добро пожаловать под кат.

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

Мы не сможем показать техническую часть, как это реализовано, но расскажем всё остальное:

- как мы привлекали участников,

- функционал чат-бота,

- как выглядела геймификация,

- какие получили результаты.

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

Привет, Хабр!

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

У меня возникла потребность исследовать мировые тенденции QA, чтобы понимать, какие технологии сейчас актуальны, какие из них мы используем, насколько мы в тренде как компания и что стоит взять на вооружение. Исследование показало, что большая часть статистики и прогнозов основывается на данных «Мирового отчёт по качеству» (World Quality Report), поэтому я решила обратиться к первоисточнику. Анализ этой информации был чрезвычайно полезен при составлении стратегии развития нашего направления на ближайшие несколько лет. В этой статье я разобрала пять направлений отчета. Хочу поделиться итогами анализа и обсудить их с сообществом. Например, было неожиданно узнать, что в среднем по мировой статистике автоматизировано только 15–20% всех тестов, включая регресс. Если вам интересны тренды тестирования и что будет влиять на QA в 2022-м году — добро пожаловать под кат!