Успешность любого продукта во многом зависит от того, насколько точно он отвечает запросам конечных пользователей. Но даже если продакт-менеджер обладает гигантским опытом и великолепным чувством вкуса, есть вероятность принять неверное решение, ведь продукт должен быть ориентирован на определенную аудиторию и учитывать постоянно меняющиеся тренды. Поэтому перед разработкой любые продуктовые гипотезы желательно проверять на целевой аудитории. Есть несколько методик проведения подобных исследований, одна из них — A/B-эксперименты. 

Меня зовут Евгений Мочалин. Я работаю в технической команде медицинской компании СберЗдоровье. В этой статье я хочу рассказать о нашей A/B-платформе, предпосылках ее появления, итоговой реализации и планах на будущее. Но начнем с небольшой теории. Поехали!

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

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

С 12 марта 2024 года показатель FID (First Input Delay) из семейства Core Web Vitals заменён новой метрикой — INP (Interaction to Next Paint), которая отражает скорость отклика сайтов. Необходимость такой замены, среди прочего, подтверждают данные об использовании Chrome: согласно им, 90% времени пользователь проводит на странице после её загрузки. Таким образом, важно тщательно измерять скорость реагирования сайта на протяжении всего жизненного цикла страницы. В этом и помогает метрика INP.

Меня зовут Коновалов Илья. Я Performance Engineer и Front-end Developer в медицинской компании «СберЗдоровье». В этой статье я расскажу, что такое INP и как работать с новой метрикой.

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

Меня зовут Антон Гришин. Я продакт в медицинской компании СберЗдоровье. Когда-то я сам столкнулся с тяготами и лишениями трудоустройства на новую работу и после небольшого анализа понял, что эту проблему реально решить. Рассказываю, как медицинской компании СберЗдоровье удалось автоматизировать онбординг — с чего начинали, с чем столкнулись и что получили в итоге.

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

Меня зовут Евгений Шалаев. Я Frontend-разработчик в команде СберЗдоровье. В этой статье я расскажу о теханализе в разработке, его пользе, принципах выполнения и своем опыте проведения подобных исследований.

Тестирование занимает важное место в iOS-разработке — без него нельзя гарантировать стабильность работы приложения в продакшене и оперативно выявлять возникающие баги. Но для части iOS-разработчиков тема тестов по-прежнему остается запутанной и сложной для понимания. Исправляем ситуацию.

Меня зовут Евгений Плёнкин. Я iOS разработчик компании СберЗдоровье. В предыдущем материале я рассказал об автоматизированном тестировании, кому оно нужно, месте модульных тестов в пирамиде тестирования и основном инструменте тестирования для iOS-разработчиков. Сегодня материал будет посвящен «чистым» тестам и видам имитирующих объектов, подменяющие реальные на время теста.

Приступим.

Статья написана в рамках серии «Модульное тестирование в iOS: всё, что надо знать».

Приветствую всех читателей. Меня зовут Роман Доронин. Уже 2 года я iOS-разработчик в компании СберЗдоровье, работаю в платформенной команде. Именно здесь я близко познакомился с понятием фича флага и увидел всю силу этого инструмента.

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

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

Модульное тестирование в iOS: все, что надо знать. Часть 1

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

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

Статья написана в рамках серии «Модульное тестирование в iOS: все, что надо знать».

Всем привет! Меня зовут Александр Ровнов. Я Android разработчик в СберЗдоровье.

Статей про «чистую» архитектуру и многомодульность очень много. Но не многие компании готовы делиться своим опытом и полученными результатами от внедрения этих практик. Я хочу попробовать исправить ситуацию.

В этом материале я расскажу о принципах построения многомодульного приложения, как мы применяем их при разработке мобильного приложения СберЗдоровье под Android и что это нам даёт.

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

Приступим.

Чистая архитектура и ее цель.

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

Меня зовут Кирилл Смирнов. Я технический лидер iOS команды в СберЗдоровье. Последний год наша команда плотно занималась улучшением инструментов разработки, в том числе модуляризацией. В этом материале я поделюсь опытом и рекомендациями по подготовке бизнеса (заказчиков, исполнителей, смежников и др.) к модуляризации iOS приложений.

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

Хабр, привет. Меня зовут Рамиль Шайбаков, я фронтенд‑разработчик в СберЗдоровье. Последние несколько лет я часто собеседую кандидатов на позицию frontend‑разработчика в нашу компанию и заметил одну закономерность — у большинства специалистов нет опыта в тестировании. Причем знаниями о unit/интеграционных/e2e‑тестах, пирамиде тестирования, красно‑зелёном рефакторинге, TDD и BDD, скриншот‑тестировании и других техниках не могут похвастаться как новоиспеченные фронтенды, так и специалисты уровня Senior. Причины и аргументы у всех разные, но итог один — фронтенды часто не делают тесты.

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

Мы делили апельсин, много нас, а он один…

Привет! Я Слава, QA в мобильной разработке компании «СберЗдоровье». В прошлых статьях я рассказывал о наших процессах тестирования при активном росте команды и о разделении на фича-команды.

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

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

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

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

Поговорим о провайдере

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

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

Привет! Я Даша Почекуева, дизайнер в СберЗдоровье. В последние полтора года я работаю над  личным кабинетом врача телемедицины — платформой, на которой врачи СберЗдоровья общаются с пациентами.

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

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

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

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

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

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

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

Мы Дима и Настя, Android-разработчики в компании СберЗдоровье. В этой статье мы хотим рассказать о том, как мы перевели весь наш проект с LiveData на Flow, с какими трудностями столкнулись и что полезного узнали. Эта статья будет полезна тем, кто работает с LiveData, уже пробовал / хочет попробовать Flow для хранения состояний во ViewModel, а также командам, которые планируют миграцию всего проекта на новый инструмент.