Low-code-платформа: подводные камни
Челлендж: как без тысячи строк кода создать систему управления предприятием?? В 2022 году работали над подобной задачей — создавали Low-code-UI-конструктор 🤓  

Это не первый такой проект, так что мы понимали:
1️⃣ Важно смотреть на платформу с точек зрения двух групп пользователей, которые будут:
▪️ с её помощью создавать конечный продукт.
▪️ непосредственно работать с этим продуктом.
Механизмы работы платформы должны быть максимально абстрактными, чтобы закрыть как можно больше кейсов использования системы.    
2️⃣ Нужно начинать работу с MVP. При этом в нашем случае даже MVP содержала объёмный набор функций, и обойтись без них было нельзя — иначе не решить задачи пользователей и не получить от них обратную связь для дальнейшего развития.
3️⃣ Нужно разбить продукт на несколько более мелких частей или релизов, чтобы чаще выпускать стабильные версии и обновления.

Тем не менее при разработке мы столкнулись с такими препятствиями:
▪️ Нужны интеграционные тесты в большом количестве. И они не всегда очевидны из аналитики.
▪️ Много тестовой документации, которую нужно обновлять. При этом компоненты сложной системы взаимосвязаны — одно изменение влечёт за собой другое.
▪️ О недостающих критичных фичах мы продолжали узнавать в процессе разработки. Это связано с масштабом системы, широким спектром компонентов и подсистем.
▪️ Большое количество микросервисов в продукте влияет и на проработку архитектуры.

❗️ То есть нужно заранее учитывать и предугадывать множество взаимосвязей и интеграций. Сложность тестирования оказалась в том, что конструктор имеет огромное количество комбинаций, которыми можно воспользоваться. Прописать в аналитике исчерпывающие сценарии использования невозможно. Уже к сдаче MVP мы поняли, что нужно менять подход к тестированию. Мало просто проанализировать целевую аудиторию, нужно покрыть все требования тестами, применить техники тест-дизайна.

В итоге мы пришли к таким решениям:
1️⃣ Проанализировали все баги и узкие места, которые возникали при использовании системы в промежуточном тестировании, и выявили часто повторяющиеся комбинации и проблемы. Все проверки включили в регресс.
2️⃣ Воспользовались техникой попарного тестирования и составили максимально возможное количество комбинаций между элементами интерфейса, доступными действиями и событиями.
3️⃣ После общения с заказчиком о задачах той или иной фичи и анализа бизнес-логики системы прописали основные интеграционные тесты.
4️⃣ Поскольку без автоматизации тестирования невозможно быстро выпускать релизы, мы разделили процесс на этапы, чтобы снизить затраты и повысить эффективность. Совместно с заказчиком определили основные критичные сценарии, которые нужно проверять каждый раз при внесении правок в систему. Это позволило нам уже на самом начальном этапе запускать автотесты и покрывать критичный функционал, быстрее «заливать» хотфиксы или срочные доработки.

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

Что, собственно, случилось?
К нам обратилась страховая компания для развития их сервиса. Нужно было настроить обмен данными между подразделениями и упростить работу с сервисом для сотрудников: ускорить оформление заявок, загрузку документов и т.д. Самое важное — нужно было сделать всё быстро.
Мы прониклись духом срочности, подключили к проекту аналитика, QA-специалиста, frontend- и backend-разработчиков, приготовились сворачивать «горы». И ничего у нас не вышло 🙃

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

Как работаем теперь
Опасения клиентов в таких случаях можно понять, а нам как аутсорс-компании важно, чтобы с нами было безопасно работать. Что мы теперь предлагаем в такой ситуации:
▪️ Составление дополнительного NDA под проект, как в описанной выше ситуации;
▪️ обезличенное сотрудничество. При необходимости все коммуникации ведутся через почту и подключённый к проекту специалист не знает, с какой компанией работает.

Как реализовать первый маркетплейс в отрасли
Партнёры из Северстали пару лет назад провели CustDev поставщиков и покупателей металлопроката и вот что выяснили:
▪️ желание поставщиков – получить новые источники привлечения клиентов;
▪️ желание клиентов – иметь оперативность и омниканальность в процессе покупки, а также знать актуальные цены и остатки.

🥁 🥁 🥁 Было решено – маркетплейсу металлпроката «Платферрум» быть!

В подкасте поговорили об организации B2B-маркетплейса – как стартовали проект и разрабатывали продукт 🏗

Таймкоды лежат в комментариях :)

Задачка для менеджеров
Ваш проект – мобильное приложение для банка. Вы занимаетесь его разработкой уже 6 месяцев. Внезапно одна из библиотек, которую вы активно использовали, перестала поддерживаться. Вы понимаете, что это может повлиять на достижение цели проекта. Что будете делать?

С комментариями вернёмся в понедельник 🤗

Комментарии к задачке
В варианте А игнорирование ситуации приведёт к проблемам в развитии продукта в дальнейшем и может повлечь за собой больше затрат, чем если бы вы сразу исправили ситуацию.
Вариант В — быстро адаптироваться к новым условиям – оптимальный.
Не всегда можно приостановить работу, как в варианте С (точнее можно краааайне редко). Например, завтра может возникнуть новая проблемная ситуация, которая потребует немедленного вмешательства. Тогда текущий вопрос точно останется нерешённым.

Как UX-тестирование помогло увеличить заявки на банковские продукты: кейс

Исходная ситуация
Приложение банка плохо «продает»
Задача
Изучить барьеры, из-за которых пользователи мобильного приложения не оформляют заявки на предлагаемые банком продукты.
Результат
Выявили 17 барьеров, с которыми сталкиваются пользователи, и провели редизайн главного экрана.

Рассказываем, как искали причины отказа пользователей и анализировали результаты и к каким результатам удалось прийти 👇

Спойлер: вовлеченность и лояльность клиентов банка выросла с 8% до 31%.

#вопросыбизнеса #кейсы

​​Не триллер, а вебинар
На проекте часто срываются сроки, бюджет проекта всё раздувается, а баги появляются просто из ниоткуда 🫠 Всё это не триллер, а реальная цена ошибки при разработке IT-проекта без QA.

28 июня в 17:00 (по МСК) проводим вебинар «Цена ошибки: как избежать повышения затрат и срыва сроков на IТ-проекте».
Наши спикеры на конкретных примерах разберут, к каким последствиям и потерям может привести экономия или отказ от некоторых видов тестирования. А также ответят на вопросы.

📌 Вебинар бесплатный, но нужно зарегистрироваться: https://s.simbirsoft.com/bYpH
После мероприятия все участники получат презентацию со списком основных триггеров, которые подскажут, есть ли в вашем IT-проекте предпосылки к увеличению затрат. Письмо придёт на указанную при регистрации почту.

Ждём в онлайне 28 июня в 17:00 (по МСК) 😎