👩🦱Миледи и IT: Преодолевая стереотипы 👩🦱
Внезапный пост, но не IT и финтехом едины!
📽Посмотрели мы “Три мушкетёра: Миледи” Мартена Бурбулона. У меня очень много вопросов к поведению мушкетеров по отношению к Миледи (и к Дюма в принципе)!
В 25 лет, когда Атос женится на 16-летней Анне де Бейль (имя Миледи на тот момент), она уже успела совершить ряд преступлений, а также, будучи воспитанницей в монастыре, “совратить” монаха, который был её старше и вообще был духовным лицом! В фильме хитросплетения попроще,и рассказывается о том, что для Миледи брак с Атосом был не первым, а первого мужа она убила, так как он оказался извергом и насильником.
И в книге, и в фильме, увидев клеймо на плече жены, граф де Ла Фер, пользуясь властью феодала, вешает жену на дереве! Но женщина выживает и ВНЕЗАПНО становится шпионкой🫥 и походя мстит своим обидчикам! В отличие от оригинала, Миледи в фильме даже Констанцию не убивает (та вполне справляется с “умереть по глупости”) .
👩💻 Теперь немного об IT. Как и в литературе, где женские образы часто не получают должного внимания и уважения, в IT-сфере женщины также сталкиваются с множеством стереотипов и препятствий. Но, как и Миледи, они доказывают, что могут быть сильными, умными и решительными. Надеюсь, что более простыми и менее страдательными путями, чем путь Миледи, в IT станет больше женщин, которые будут менять мир и развивать индустрию!
Кстати, недавно я получила сертификат спикера за уникальный вклад в программу “Ролевая модель” от Women in Tech Russia.
И мб появится когда-нибудь экранизация, в которой девушка, выросшая в монастыре, получившая прекрасное образование, была удостоена образа МОНСТРА из-за того, что, несмотря на насилие, издевательства, попытки убийства, не сломалась и стала прекрасным агентом и разведчиком на благо некоторых деятелей страны?
💡А вы знали, что у леди Винтер есть реальный прототип — Люси Хэй (прожила 60 лет), брошенная Бэккингемом любовница, ставшая агентом Ришелье? А кто для вас Миледи от IT?
Внезапный пост, но не IT и финтехом едины!
📽Посмотрели мы “Три мушкетёра: Миледи” Мартена Бурбулона. У меня очень много вопросов к поведению мушкетеров по отношению к Миледи (и к Дюма в принципе)!
В 25 лет, когда Атос женится на 16-летней Анне де Бейль (имя Миледи на тот момент), она уже успела совершить ряд преступлений, а также, будучи воспитанницей в монастыре, “совратить” монаха, который был её старше и вообще был духовным лицом! В фильме хитросплетения попроще,
И в книге, и в фильме, увидев клеймо на плече жены, граф де Ла Фер, пользуясь властью феодала, вешает жену на дереве! Но женщина выживает и ВНЕЗАПНО становится шпионкой
Кстати, недавно я получила сертификат спикера за уникальный вклад в программу “Ролевая модель” от Women in Tech Russia.
И мб появится когда-нибудь экранизация, в которой девушка, выросшая в монастыре, получившая прекрасное образование, была удостоена образа МОНСТРА из-за того, что, несмотря на насилие, издевательства, попытки убийства, не сломалась и стала прекрасным агентом и разведчиком на благо некоторых деятелей страны?
💡А вы знали, что у леди Винтер есть реальный прототип — Люси Хэй (прожила 60 лет), брошенная Бэккингемом любовница, ставшая агентом Ришелье? А кто для вас Миледи от IT?
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤2
🚀 Рекомендация мероприятия! 🚀
1-го августа (четверг) в 14:00 по МСК будет расширенная “режиссерская” версия доклада Руслана Сафина: “Архитектура as Code и инструменты работы с ней.”
🎤 Тема потрясающая и доклад шикарный! Я его и слышала, и статью на Хабре читала, и с Русланом обсуждали! Это БОМБА💣 ! То, что удалось сделать Руслану (и не только сделать, но и поддерживать актуальным репозиторий, пропагандировать подход в комьюнити) — достойно глубочайшего уважения! Искренне рекомендую выделить 1,5 часа и попасть на мероприятие, особенно с учетом того, что оно БЕСПЛАТНОЕ🆓 и Руслан заложил 30 минут на ответы на вопросы⏰!
🔗 Вот ссылка для регистрации: Регистрация на Timepad
NB! Нет, это не реклама, а просто рекомендация от всего сердечка! 💖
Не упустите возможность! Будет интересно, полезно и познавательно!
#architecture
1-го августа (четверг) в 14:00 по МСК будет расширенная “режиссерская” версия доклада Руслана Сафина: “Архитектура as Code и инструменты работы с ней.”
🎤 Тема потрясающая и доклад шикарный! Я его и слышала, и статью на Хабре читала, и с Русланом обсуждали! Это БОМБА
🔗 Вот ссылка для регистрации: Регистрация на Timepad
NB! Нет, это не реклама, а просто рекомендация от всего сердечка! 💖
Не упустите возможность! Будет интересно, полезно и познавательно!
#architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
byndyusoft-event.timepad.ru
Архитектура as Code и инструменты работы с ней. Онлайн доклад. / События на TimePad.ru
Обсудим что такое Архитектура as Code и какие у данного подхода есть преимущества. Рассмотрим методику и инструменты для покрытия архитектуры тестами и автоматизации работы с ней. Будет представлен OpenSource-репозиторий с инструментами для работы с архитектурой…
🔥5👍3❤1
Еще 7 капитанских правил для REST-API в Финтехе
Казалось, что в прошлом посте я собрала все основные правила. Но прошло 2 месяца, и вот еще немножко правил, которые успели "вспомниться/напомниться" за этот не очень большой промежуток времени!
1️⃣ Лишние данные. В отличие от правила "Продуманность структуры данных" (из прошлого поста), это правило про то, что не стоит руководствоваться принципом: "Суй все, API стерпит, вдруг понадобится"! Иногда таким образом в протокол проникают лишние параметры, которые НИКОГДА не используются, но могут приводить к инцидентам, так как за любыми параметрами необходимо следить!
2️⃣ 200 Ok - у вас ошибка! Это бич большого числа протоколов. И ОЧЕНЬ холиварная тема! Есть мнение, что необходимо возвращать 200, если метод был просто получен и смог быть разобран на стороне получателя. Тогда коды ошибок запихиваются внутрь тела ответа. А графики становятся "песней"! Ведь не все 200 - это хорошо!
3️⃣ Параметры через Вселенную. Бывают ситуации, когда несколько продуктов внутри одной компании имеют слабую, но связанность. Например, есть общая база пользователей, но в каждом из продуктов пользователь имеет свое представление, и ему для работы необходим свой Customer Due Diligence. Но иногда появляется продукт, агрегирующий пользователей из нескольких продуктов. И тут начинается веселье. Для одного и того же пользователя в продукте А параметр country - это страна рождения, в продукте B - гражданство, в продукте C - место жительства, но в продукте C еще есть параметр native_country - страна рождения. Вам же необходимо всего лишь собрать пазл и понять, где какая страна!
4️⃣ Транслитерация терминов. Не стоит мешать языки. Пишите на английском - пишите! Или идите кодить на 1С. Ошибка, которую совершила когда-то сама: в протоколе были параметры inn и snils. И всем было все понятно, только у одного мерчанта команда разработки оказалась из Европы, и ребята долго пытались угадать, что это за значения и где им их взять...
5️⃣ Привязка к логике Мерчанта. Частая ошибка платформенных продуктов. Можно увидеть пачку методов, объединенных общим "словом" chart, так как первый мерчант, который интегрировался с протоколом, использовал эти методы для построения графиков пользователям. Для платформы же это всего лишь выдача различных сущностей с определенными фильтрами и никак не графики. Конечно же, остальные мерчанты далеко не все решили строить графики. Многие выбрали табличные варианты данных, а часть просто не выводит пользователям эту информацию.
6️⃣ Ошибка = нормальное поведение. К сожалению, такой кейс случается часто, если уже есть прежнее архитектурное решение и привычка, выработанная у пользователей. Вы рассчитали сумму до 6-го знака после запятой и отдаете ее платежному провайдеру. Провайдер работает только с числами до 2-го знака после запятой. Он округляет вашу сумму, в результате получая 0! Но, так как этот провайдер привык не делать нулевые операции в счет пользователя, он отдает вам ошибку, что значение маленькое! Вы же на своей стороне должны обработать эту ошибку как корректное поведение провайдера, в отличие от остальных ошибок, и списать эту сумму на нераспределенку.
7️⃣ Поддержка не всех ошибок. Этим чаще всего "страдают" мерчанты при интеграции. Выставляется протокол, в котором, предположим, 36 кодов ошибок. Мерчант же принимает решение поддерживать 5, а на остальные коды повесить сообщение вида "Что-то пошло не так", а еще хуже "Сервис временно не доступен"! Чревато это сложностями при возникновении ошибок и расширении кодов. Да и вообще поддержка такого беспорядка нарастает снежным комом.
Ну что ж, на этом пока всё! До следующего поста, где, возможно, всплывут новые "правила жизни" REST-API в финтехе! 🌟
#architecture
Казалось, что в прошлом посте я собрала все основные правила. Но прошло 2 месяца, и вот еще немножко правил, которые успели "вспомниться/напомниться" за этот не очень большой промежуток времени!
1️⃣ Лишние данные. В отличие от правила "Продуманность структуры данных" (из прошлого поста), это правило про то, что не стоит руководствоваться принципом: "Суй все, API стерпит, вдруг понадобится"! Иногда таким образом в протокол проникают лишние параметры, которые НИКОГДА не используются, но могут приводить к инцидентам, так как за любыми параметрами необходимо следить!
2️⃣ 200 Ok - у вас ошибка! Это бич большого числа протоколов. И ОЧЕНЬ холиварная тема! Есть мнение, что необходимо возвращать 200, если метод был просто получен и смог быть разобран на стороне получателя. Тогда коды ошибок запихиваются внутрь тела ответа. А графики становятся "песней"! Ведь не все 200 - это хорошо!
3️⃣ Параметры через Вселенную. Бывают ситуации, когда несколько продуктов внутри одной компании имеют слабую, но связанность. Например, есть общая база пользователей, но в каждом из продуктов пользователь имеет свое представление, и ему для работы необходим свой Customer Due Diligence. Но иногда появляется продукт, агрегирующий пользователей из нескольких продуктов. И тут начинается веселье. Для одного и того же пользователя в продукте А параметр country - это страна рождения, в продукте B - гражданство, в продукте C - место жительства, но в продукте C еще есть параметр native_country - страна рождения. Вам же необходимо всего лишь собрать пазл и понять, где какая страна!
4️⃣ Транслитерация терминов. Не стоит мешать языки. Пишите на английском - пишите! Или идите кодить на 1С. Ошибка, которую совершила когда-то сама: в протоколе были параметры inn и snils. И всем было все понятно, только у одного мерчанта команда разработки оказалась из Европы, и ребята долго пытались угадать, что это за значения и где им их взять...
5️⃣ Привязка к логике Мерчанта. Частая ошибка платформенных продуктов. Можно увидеть пачку методов, объединенных общим "словом" chart, так как первый мерчант, который интегрировался с протоколом, использовал эти методы для построения графиков пользователям. Для платформы же это всего лишь выдача различных сущностей с определенными фильтрами и никак не графики. Конечно же, остальные мерчанты далеко не все решили строить графики. Многие выбрали табличные варианты данных, а часть просто не выводит пользователям эту информацию.
6️⃣ Ошибка = нормальное поведение. К сожалению, такой кейс случается часто, если уже есть прежнее архитектурное решение и привычка, выработанная у пользователей. Вы рассчитали сумму до 6-го знака после запятой и отдаете ее платежному провайдеру. Провайдер работает только с числами до 2-го знака после запятой. Он округляет вашу сумму, в результате получая 0! Но, так как этот провайдер привык не делать нулевые операции в счет пользователя, он отдает вам ошибку, что значение маленькое! Вы же на своей стороне должны обработать эту ошибку как корректное поведение провайдера, в отличие от остальных ошибок, и списать эту сумму на нераспределенку.
7️⃣ Поддержка не всех ошибок. Этим чаще всего "страдают" мерчанты при интеграции. Выставляется протокол, в котором, предположим, 36 кодов ошибок. Мерчант же принимает решение поддерживать 5, а на остальные коды повесить сообщение вида "Что-то пошло не так", а еще хуже "Сервис временно не доступен"! Чревато это сложностями при возникновении ошибок и расширении кодов. Да и вообще поддержка такого беспорядка нарастает снежным комом.
Ну что ж, на этом пока всё! До следующего поста, где, возможно, всплывут новые "правила жизни" REST-API в финтехе! 🌟
#architecture
Telegram
ITKatya: культурные паттерны в IT
🚀 10 Капитанских правил для REST-API в Финтехе 🚀
Привет всем!
На протяжении многих лет работы в IT я сталкиваюсь с "детскими болезнями" API. Не смотря на то, что написана масса статей, сделано множество докладов, и даже изданы книги, но проблема качества…
Привет всем!
На протяжении многих лет работы в IT я сталкиваюсь с "детскими болезнями" API. Не смотря на то, что написана масса статей, сделано множество докладов, и даже изданы книги, но проблема качества…
👍11❤3🔥2
У меня для вас отличная новость! Команда System Education пригласила меня провести два захватывающих вебинара, которые обещают стать настоящей находкой для всех, кто интересуется архитектурой систем.
Темы вебинаров: "Бережливая архитектура: Просто и Пошагово" и "АРХИТЕКТУРА ОТ СЛОВАРЯ: определения как базис проектирования" построение архитектуры через словарь. Оба мероприятия будут щедро приправлены идеями Domain-Driven Design (DDD), так что скучно точно не будет!
Первый вебинар уже в этот четверг! На нем мы обсудим, как внедрять принципы бережливого подхода в архитектуру и как создавать словари, которые помогут упорядочить и структурировать ваш проект.
Готовьтесь к увлекательным обсуждениям и полезным инсайтам! Жду вас на вебинаре! 📚
#architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
systems.education
Бережливая архитектура: просто и пошагово
🥰2
🔥 Как поссорились Катенька и ТимЛид: История о жарких дебатах и мирных итогах 🕊️
Сегодня модно рассказывать про успешные-успехи🏆 , но я хочу поделиться историей о том, как мы с ТимЛидом разошлись во мнениях — и даже не на шутку! Пух и перья не летели, но на эмоциях было жарко.
Повод для спора😱
Есть некая сущность Договор. У Договора есть Версии. У Договора своя статусная модель, у Версии - своя. В Договоре всегда есть хотя бы одна текущая Версия. Одновременно может быть у Договора одна текущая Версия и одна запланированная. Запланированную Версию можно отменить. В некий момент Х (не важно как определяется) Версия из запланированной становится текущей, а ранее текущая - завершенной. Все Версии Договора можно получить в истории Версий в админке.
И вот тут началась баталия!👻
1️⃣ ТимЛид предложил реализовать API отмены запланированной Версии через PUT по идентификатору версии с передачей в теле статуса Отмененный.
2️⃣ А Катенька, предложила DELETE, который заменит статус на отмененный.
ТимЛид, сторонник чистого REST, аргументировал, что PUT ближе к рекомендациям.
Я же, защищая RESTоподобный подход, утверждала, что наружу не должны утекать статусы внутренней сущности, тем более в ситуации, когда потребитель может сменить только запланированную и только на отмененную.
Но сегодня не про API и про подходы!
Итог: Зачем нужны горячие споры?🤬
И вот тут важный момент: нам не всё равно! Мы можем спорить и даже горячиться, потому что не бывает одной верной религии/ одного решения. Технические специалисты принимают решения, основываясь на опыте, знаниях о предметной области, стратегии развития продукта, технических и ресурсных ограничениях и еще сотне факторов. И да, в таких спорах люди могут нагреваться до красна, и это великолепно!
Страшно, когда никто ничего не доказывает, не противопоставляет и не отстаивает своё мнение. Это путь к диктатуре в проектировании, что ведет к ошибкам. Уверенность в своей правоте — опасная штука, потому что легко забыть о нюансах и подводных камнях.😱
Так что спорить и даже ругаться иногда полезно! Главное — потом сесть, остынуть, обсудить всё на 1:1 и найти решение, которое лучше для команды и продукта. Ведь споры — не про эго, это про то, что нам не всё равно, что происходит с продуктом. Намного хуже услышать:“Я сделал, как было сказано”!
NB! Добро на публикацию со стороны ТимЛида получено! И я тя лю, даже если ругаемся😍
#people_management
Сегодня модно рассказывать про успешные-успехи
Повод для спора
Есть некая сущность Договор. У Договора есть Версии. У Договора своя статусная модель, у Версии - своя. В Договоре всегда есть хотя бы одна текущая Версия. Одновременно может быть у Договора одна текущая Версия и одна запланированная. Запланированную Версию можно отменить. В некий момент Х (не важно как определяется) Версия из запланированной становится текущей, а ранее текущая - завершенной. Все Версии Договора можно получить в истории Версий в админке.
И вот тут началась баталия!
1️⃣ ТимЛид предложил реализовать API отмены запланированной Версии через PUT по идентификатору версии с передачей в теле статуса Отмененный.
2️⃣ А Катенька, предложила DELETE, который заменит статус на отмененный.
ТимЛид, сторонник чистого REST, аргументировал, что PUT ближе к рекомендациям.
Я же, защищая RESTоподобный подход, утверждала, что наружу не должны утекать статусы внутренней сущности, тем более в ситуации, когда потребитель может сменить только запланированную и только на отмененную.
Но сегодня не про API и про подходы!
Итог: Зачем нужны горячие споры?
И вот тут важный момент: нам не всё равно! Мы можем спорить и даже горячиться, потому что не бывает одной верной религии/ одного решения. Технические специалисты принимают решения, основываясь на опыте, знаниях о предметной области, стратегии развития продукта, технических и ресурсных ограничениях и еще сотне факторов. И да, в таких спорах люди могут нагреваться до красна, и это великолепно!
Страшно, когда никто ничего не доказывает, не противопоставляет и не отстаивает своё мнение. Это путь к диктатуре в проектировании, что ведет к ошибкам. Уверенность в своей правоте — опасная штука, потому что легко забыть о нюансах и подводных камнях.
Так что спорить и даже ругаться иногда полезно! Главное — потом сесть, остынуть, обсудить всё на 1:1 и найти решение, которое лучше для команды и продукта. Ведь споры — не про эго, это про то, что нам не всё равно, что происходит с продуктом. Намного хуже услышать:
NB! Добро на публикацию со стороны ТимЛида получено! И я тя лю, даже если ругаемся
#people_management
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8🥰2❤1
💸 Финтех-печалька: наши приключения с покупкой билетов на РЖД 🚂
Решили мы с мужем сделать его родителям подарок — отправить их в небольшую поездку в Псков на Ласточке. Очень удобно — 4 часа, и ты на месте! Но тут начались реальности…
Оказывается, сайт РЖД, если ты не в России, просто не работает! 🤷♀️ Почему наложено такое ограничение на сервис, которым могут и должны пользоваться туристы (в том числе находящиеся не в России) — не понятно. Ну ладно, включаем VPN, попадаем на сайт, выбираем места, оформляем заказ и переходим к оплате. Форма оплаты открывается в виджете ВТБ, протокол Мультикарты. Не думаю, что тут стоит что-то скрывать — это общеизвестные факты, которые очевидны любому пользователю сайта.
Так вот, при включенном VPN вы можете ввести данные карты и отправить запрос на оплату. Но дальше всё подвисает с ошибкой, до 3DS не доходит. Платёж висит, заказ тоже, и его можно только отменить. Важно отметить, что РЖД не пускает даже на повторную оплату, а каждый раз обновляет 15тиминутный счетчик на протухание заказа. Начинаем всё сначала! 🤦♀️
Хорошо, попробуем иначе: оформляем заказ с включенным VPN, а уже перед оплатой — выключаем. Ура! Проходим до 3DS, сумма авторизована, SMS о списании получено! Но страница в браузере не обновляется. Мы снова зависаем! В URL номер заказа и номер платежа. Мультикарта отправляет информацию РЖД…
Включаем снова VPN? Но нет, фокус не проходит. РЖД отбивает оплату и отменяет бронь, а деньги списаны! Теперь надо писать заявление в банк и прикладывать подтверждение отмены заказа от РЖД, чтобы вернуть деньги.
🤔 И вот главный вопрос:
как в 2024 году можно не реализовать webhook между банком и продавцом для контроля оплаты? 🤔 Почему РЖД может НЕ проверить платеж на стороне банка при ошибке?
Если вас интересует история с билетами — всё закончилось хорошо. Купили билеты на сервисе tutu, переплатив 600 рублей за сервис, даже пенсионная скидка подтянулась! 🎉
NB! Напоминаю, что сегодня в 19-00 по МСК на вебинаре будем говоить про архитектуру и финтех. Регистрация по ссылке
#fintech
Решили мы с мужем сделать его родителям подарок — отправить их в небольшую поездку в Псков на Ласточке. Очень удобно — 4 часа, и ты на месте! Но тут начались реальности…
Оказывается, сайт РЖД, если ты не в России, просто не работает! 🤷♀️ Почему наложено такое ограничение на сервис, которым могут и должны пользоваться туристы (в том числе находящиеся не в России) — не понятно. Ну ладно, включаем VPN, попадаем на сайт, выбираем места, оформляем заказ и переходим к оплате. Форма оплаты открывается в виджете ВТБ, протокол Мультикарты. Не думаю, что тут стоит что-то скрывать — это общеизвестные факты, которые очевидны любому пользователю сайта.
Так вот, при включенном VPN вы можете ввести данные карты и отправить запрос на оплату. Но дальше всё подвисает с ошибкой, до 3DS не доходит. Платёж висит, заказ тоже, и его можно только отменить. Важно отметить, что РЖД не пускает даже на повторную оплату, а каждый раз обновляет 15тиминутный счетчик на протухание заказа. Начинаем всё сначала! 🤦♀️
Хорошо, попробуем иначе: оформляем заказ с включенным VPN, а уже перед оплатой — выключаем. Ура! Проходим до 3DS, сумма авторизована, SMS о списании получено! Но страница в браузере не обновляется. Мы снова зависаем! В URL номер заказа и номер платежа. Мультикарта отправляет информацию РЖД…
Включаем снова VPN? Но нет, фокус не проходит. РЖД отбивает оплату и отменяет бронь, а деньги списаны! Теперь надо писать заявление в банк и прикладывать подтверждение отмены заказа от РЖД, чтобы вернуть деньги.
как в 2024 году можно не реализовать webhook между банком и продавцом для контроля оплаты? 🤔 Почему РЖД может НЕ проверить платеж на стороне банка при ошибке?
Если вас интересует история с билетами — всё закончилось хорошо. Купили билеты на сервисе tutu, переплатив 600 рублей за сервис, даже пенсионная скидка подтянулась! 🎉
NB! Напоминаю, что сегодня в 19-00 по МСК на вебинаре будем говоить про архитектуру и финтех. Регистрация по ссылке
#fintech
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍1
🎨 CJM — для интеграционных кейсов! ✏️
Если вы слышали про Customer Journey Map (CJM), то, скорее всего, ассоциируете его с инструментом для продактов и маркетологов. Но, поверьте, CJM — это настоящая палочка-выручалочка 🪄, когда дело доходит до интеграции между платформой и потребителем, обсуждения и согласования интерфейсов.
Лет 5 назад я искала инструмент, который позволил бы прописать пошаговый сценарий интеграции (вызовов API) и одновременно показать, что происходит на стороне Мерчанта (потребителя) в UI. И тогда я нашла UXPressia — и это была любовь с первого клика!
Пост выглядит как реклама, но я не знаю, как объяснить проще и менее “продажным” языком, почему я очень люблю этот инструмент и рекомендую вам хотя бы на него посмотреть… 🤪
10 причин ПОЧЕМУ?
1️⃣ Наглядность и простота: Легкость создания и визуализации пользовательских путей. Не нужно мучиться с выравниванием блоков (как в Miro) или шрифтами. Это специализированный инструмент, который делает одно, но делает это хорошо! Вы можете сосредоточиться на логике, а не на “наведении красоты”.
2️⃣ Совместная работа: Возможность безлимитного расшаривания схем для просмотра (есть в самом дешевом тарифе).
3️⃣ Поддержка ролей и команд: Всё под контролем! Можно настроить права и доступы, развести всё по папкам. Это особенно важно в финтехе, где безопасность — не пустой звук.
4️⃣ Гибкость тарифов: В бесплатном тарифе 1 CJM — достаточно, чтобы попробовать и понять, насколько продукт подходит. Следующий тариф — $16 за пользователя в месяц (3 CJM на пользователя), а если нужен безлимит карт — всегда можно расширить до $36.
5️⃣ Доступность: UXPressia позволяет “рисовальщикам” творить, а “смотрителям” наслаждаться результатами. Обычно, рисующих специалистов меньше, чем тех, кто будет использовать и внедрять схемы. А значит, лицензий необходимо по числу “рисовальщиков”!
6️⃣ Экономия времени: Удобный интерфейс и множество шаблонов: блоки для иллюстраций, описания happy-path сценария и ветвлений, блоки заметок и т.п.
7️⃣ Поддержка сторонних сервисов: Легко можно встроить сторонние плагины и виджеты через код. Функция есть в стартовом (за $16) тарифе. Можно легко выставить ссылки на Swagger или “запихнуть” карту в портал разработчика.
8️⃣ Экспорт в основные форматы и доступ по ссылке: Доступ по ссылке или pdf — оптимальный вариант. Экспорт в ppt доступен в пакете PRO за $36.
9️⃣ Генерация пользовательских профилей через AI: Возможность заполнить профиль через AI без переключения на другие продукты (например, ChatGPT) и использование Ctrl+C — полезная-польза!
🔟 ImpactMap: Создавался для отображения влияния ветвлений карты на продукт, но легко превращается в наглядную схему отображения ветвлений интеграционных сценариев. А с кнопкой “PRESENTATION” можно красиво и пошагово показать весь интеграционный путь, что отлично подходит для презентаций с подрядчиками или топами компании.
Да, возможно, вы скажете, что это путь “забивания гвоздей микроскопом” 🔬, но более удобного продукта, чтобы показать интеграцию фронтов и бэков, да еще и разных команд/компаний, и чтобы без сложных матриц, схем и многостраничных документов — я не видела! Возможно, интеграционным командам просто не хватает своего понятного шаблона IJM (Integration Journey Map) — только сейчас задумалась, что, мб, его стоит “изобрести”🧐 ?!
А что вы используете, чтобы наглядно показать сценарии интеграции?
#toolkit #architecture
Если вы слышали про Customer Journey Map (CJM), то, скорее всего, ассоциируете его с инструментом для продактов и маркетологов. Но, поверьте, CJM — это настоящая палочка-выручалочка 🪄, когда дело доходит до интеграции между платформой и потребителем, обсуждения и согласования интерфейсов.
Лет 5 назад я искала инструмент, который позволил бы прописать пошаговый сценарий интеграции (вызовов API) и одновременно показать, что происходит на стороне Мерчанта (потребителя) в UI. И тогда я нашла UXPressia — и это была любовь с первого клика!
Пост выглядит как реклама, но я не знаю, как объяснить проще и менее “продажным” языком, почему я очень люблю этот инструмент и рекомендую вам хотя бы на него посмотреть… 🤪
10 причин ПОЧЕМУ?
1️⃣ Наглядность и простота: Легкость создания и визуализации пользовательских путей. Не нужно мучиться с выравниванием блоков (как в Miro) или шрифтами. Это специализированный инструмент, который делает одно, но делает это хорошо! Вы можете сосредоточиться на логике, а не на “наведении красоты”.
2️⃣ Совместная работа: Возможность безлимитного расшаривания схем для просмотра (есть в самом дешевом тарифе).
3️⃣ Поддержка ролей и команд: Всё под контролем! Можно настроить права и доступы, развести всё по папкам. Это особенно важно в финтехе, где безопасность — не пустой звук.
4️⃣ Гибкость тарифов: В бесплатном тарифе 1 CJM — достаточно, чтобы попробовать и понять, насколько продукт подходит. Следующий тариф — $16 за пользователя в месяц (3 CJM на пользователя), а если нужен безлимит карт — всегда можно расширить до $36.
5️⃣ Доступность: UXPressia позволяет “рисовальщикам” творить, а “смотрителям” наслаждаться результатами. Обычно, рисующих специалистов меньше, чем тех, кто будет использовать и внедрять схемы. А значит, лицензий необходимо по числу “рисовальщиков”!
6️⃣ Экономия времени: Удобный интерфейс и множество шаблонов: блоки для иллюстраций, описания happy-path сценария и ветвлений, блоки заметок и т.п.
7️⃣ Поддержка сторонних сервисов: Легко можно встроить сторонние плагины и виджеты через код. Функция есть в стартовом (за $16) тарифе. Можно легко выставить ссылки на Swagger или “запихнуть” карту в портал разработчика.
8️⃣ Экспорт в основные форматы и доступ по ссылке: Доступ по ссылке или pdf — оптимальный вариант. Экспорт в ppt доступен в пакете PRO за $36.
9️⃣ Генерация пользовательских профилей через AI: Возможность заполнить профиль через AI без переключения на другие продукты (например, ChatGPT) и использование Ctrl+C — полезная-польза!
🔟 ImpactMap: Создавался для отображения влияния ветвлений карты на продукт, но легко превращается в наглядную схему отображения ветвлений интеграционных сценариев. А с кнопкой “PRESENTATION” можно красиво и пошагово показать весь интеграционный путь, что отлично подходит для презентаций с подрядчиками или топами компании.
Да, возможно, вы скажете, что это путь “забивания гвоздей микроскопом” 🔬, но более удобного продукта, чтобы показать интеграцию фронтов и бэков, да еще и разных команд/компаний, и чтобы без сложных матриц, схем и многостраничных документов — я не видела! Возможно, интеграционным командам просто не хватает своего понятного шаблона IJM (Integration Journey Map) — только сейчас задумалась, что, мб, его стоит “изобрести”
А что вы используете, чтобы наглядно показать сценарии интеграции?
#toolkit #architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
Uxpressia
Customer Experience Mapping Platform | User Journey Management Software
Discover UXPressia's suite of customer experience tools and user journey mapping solutions. Create exceptional UX maps and personas online with our ultimate platform and management software trusted by Waters, Michelin, Accenture, Siemens, and others.
👍2❤1
🎞 Антон Бевзюк: "Инженерные практики"! (рекомендация к просмотру) 🫵
На этой неделе на канале Neogenda вышло потрясающее интервью с Антоном Бевзюком! Если вы не знакомы с Антоном, то я скажу просто: он классный!🧡 Я очень уважаю и безмерно люблю Тоху, он был ведущим на TechLead 2022 и представлял мой доклад. Эта поддержка была невероятной! И вот теперь я надеюсь, что на TL++ нам удастся поработать с Антоном, как с куратором.
Возвращаясь к видео… Антон сам сказал об интервью так:
Но, знаете, мне оно очень понравилось!
И вот почему:
Он говорит о базовых практиках разработки, но делает это с акцентом на том, как они приносят пользу бизнесу. Он мастерски объясняет, как продать эти идеи бизнесу, и почему разработчикам ничего не продать. 🤷♀️
Вот только несколько тем из видео:
1️⃣ Code Review – Важность этой практики и как ее правильно внедрять.
2️⃣ Test-Driven Development (TDD) – Почему 100% покрытие тестами — это не фантастика.
3️⃣ Mob Programming – Работа всей команды над одним кодом одновременно.
4️⃣ Pair Programming – Почему 100 строк, написанные вдвоем, ценнее 500, написанных по отдельности.
5️⃣ Рефакторинг – Самая ценная практика для здоровья вашего кода!
Антон подчеркивает, что инженерные практики ценны не только с технической точки зрения, но и с точки зрения бизнеса. Он учит нас видеть картину шире, объяснять выгоды бизнесу и понимать, как наши действия влияют на общую картину. Ведь важно не просто кодить, а понимать, зачем ты это делаешь.
Почему это “банальное” видео было для меня так полезно?
Такие видео, как это, помогают мне:
🤝 Проверить, одинаково ли я с другими понимаю ценность практик.
🧑🎓 Узнать что-то новое и интересное.
И вот оно, новое знание для меня — mob programming! Конечно, я сразу же побежала к Антону за той самой книжкой, а теперь делюсь ссылкой на нее с вами: Mob Programming by Leanpub.
💥 Спойлер:
Антон обещал, что на зимней конференции TL++ будет доклад от спикера, который уже несколько лет практикует mob programming. Я очень хочу попасть и послушать, а вы?
Рекомендую к просмотру! Если что-то зацепит — делитесь в комментариях! 🎬
#project_management
На этой неделе на канале Neogenda вышло потрясающее интервью с Антоном Бевзюком! Если вы не знакомы с Антоном, то я скажу просто: он классный!
Возвращаясь к видео… Антон сам сказал об интервью так:
“Казалось, я банальности там говорил!”
Но, знаете, мне оно очень понравилось!
И вот почему:
Он говорит о базовых практиках разработки, но делает это с акцентом на том, как они приносят пользу бизнесу. Он мастерски объясняет, как продать эти идеи бизнесу, и почему разработчикам ничего не продать. 🤷♀️
Вот только несколько тем из видео:
1️⃣ Code Review – Важность этой практики и как ее правильно внедрять.
2️⃣ Test-Driven Development (TDD) – Почему 100% покрытие тестами — это не фантастика.
3️⃣ Mob Programming – Работа всей команды над одним кодом одновременно.
4️⃣ Pair Programming – Почему 100 строк, написанные вдвоем, ценнее 500, написанных по отдельности.
5️⃣ Рефакторинг – Самая ценная практика для здоровья вашего кода!
Антон подчеркивает, что инженерные практики ценны не только с технической точки зрения, но и с точки зрения бизнеса. Он учит нас видеть картину шире, объяснять выгоды бизнесу и понимать, как наши действия влияют на общую картину. Ведь важно не просто кодить, а понимать, зачем ты это делаешь.
Почему это “банальное” видео было для меня так полезно?
Такие видео, как это, помогают мне:
И вот оно, новое знание для меня — mob programming! Конечно, я сразу же побежала к Антону за той самой книжкой, а теперь делюсь ссылкой на нее с вами: Mob Programming by Leanpub.
💥 Спойлер:
Рекомендую к просмотру! Если что-то зацепит — делитесь в комментариях! 🎬
#project_management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Парное программирование, Zero Bug Policy, Техдолг, Сode Review и беспощадный рефакторинг
Сегодня у нас в гостях Антон Бевзюк, Head of Engineering в компании Mindbox
00:00 Интро
00:49 Знакомство
01:50 Погоня за техническим совершенством решений не противоречит ли бизнес-целям компании?
03:18 Что инженерные практики (Agile) дают бизнесу?
08:53…
00:00 Интро
00:49 Знакомство
01:50 Погоня за техническим совершенством решений не противоречит ли бизнес-целям компании?
03:18 Что инженерные практики (Agile) дают бизнесу?
08:53…
🔥6👍3❤1
🌟 2ой MasterMind! 🌟
📍Сегодня пройдет мастер-майнд на тему риск-менеджмента и одного из рисков, который, к сожалению, часто забывают учесть: "выгорание". Тот самый который из-за болезни перенесся на месяц!!!
Чтобы встреча получилась продуктивной, приготовила вот такую задачу для участников:
Описание задачи:
Выявить риски системы, обеспечивающую проведение оплаты сборных заказов, включающих товары из нескольких магазинов. На текущий момент система должна поддерживать до 5 магазинов, с возможностью расширения до 10 магазинов в будущем. Следующим этапом развития системы может стать интеграция со сторонней программой лояльности, которая позволит накапливать и использовать баллы для частичной оплаты заказов.
Некоторые направления рисков для анализа с примерами:
1️⃣Функциональные риски:
- Некорректная обработка сборного заказа при участии нескольких магазинов.
- Ошибки при расчёте итоговой стоимости заказа.
2️⃣Технические риски:
- Неправильная интеграция с платежными системами.
- Проблемы с масштабируемостью системы при увеличении количества магазинов.
3️⃣Безопасность и защита данных:
- Уязвимости в защите персональных данных покупателей.
- Риски, связанные с обработкой и хранением платежной информации.
4️⃣Операционные риски:
Сбои в работе системы при высоких нагрузках.
Невозможность восстановления данных в случае аварийных ситуаций.
5️⃣Риски интеграции программы лояльности:
- Сложности с синхронизацией баллов между системой оплаты и программой лояльности.
- Неправильное начисление или списание баллов при оплате заказов.
Надеюсь, что за 2 часа мы сможем "раскрутить" кейс и выявить особо "опасные" моменты!
А о том как прошло - напишу уже вечером! 😊
#project_management
📍Сегодня пройдет мастер-майнд на тему риск-менеджмента и одного из рисков, который, к сожалению, часто забывают учесть: "выгорание". Тот самый который из-за болезни перенесся на месяц!!!
Чтобы встреча получилась продуктивной, приготовила вот такую задачу для участников:
Описание задачи:
Выявить риски системы, обеспечивающую проведение оплаты сборных заказов, включающих товары из нескольких магазинов. На текущий момент система должна поддерживать до 5 магазинов, с возможностью расширения до 10 магазинов в будущем. Следующим этапом развития системы может стать интеграция со сторонней программой лояльности, которая позволит накапливать и использовать баллы для частичной оплаты заказов.
Некоторые направления рисков для анализа с примерами:
1️⃣Функциональные риски:
- Некорректная обработка сборного заказа при участии нескольких магазинов.
- Ошибки при расчёте итоговой стоимости заказа.
2️⃣Технические риски:
- Неправильная интеграция с платежными системами.
- Проблемы с масштабируемостью системы при увеличении количества магазинов.
3️⃣Безопасность и защита данных:
- Уязвимости в защите персональных данных покупателей.
- Риски, связанные с обработкой и хранением платежной информации.
4️⃣Операционные риски:
Сбои в работе системы при высоких нагрузках.
Невозможность восстановления данных в случае аварийных ситуаций.
5️⃣Риски интеграции программы лояльности:
- Сложности с синхронизацией баллов между системой оплаты и программой лояльности.
- Неправильное начисление или списание баллов при оплате заказов.
Надеюсь, что за 2 часа мы сможем "раскрутить" кейс и выявить особо "опасные" моменты!
А о том как прошло - напишу уже вечером! 😊
#project_management
⚡2❤2
🫵Вчера прошел MasterMind!🫵
Спасибо всем кто пришел! Было бомбически!💥
И вместо моего поста про него ловите пос от участника!
Анонс следующего будет в ближайшее время!🗓
Спасибо всем кто пришел! Было бомбически!💥
И вместо моего поста про него ловите пос от участника!
Анонс следующего будет в ближайшее время!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from System Design World (Vladimir)
⭐️ Управление рисками by ITKatya.
👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).
💵 Недавно в её блоге был анонсирован Master Mind по управлению рисками в IT проектах. Тема меня заинтересовала так как в последнее время выступаю на архитектурных хакатонах. Понял, что прокачка в этой составляющей может дать дополнительные баллы)
📕 Встреча началась с небольшого куска теории. Где рассказывалось про негативные и позитивные(!) риски. Приведена собственная типизация:
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).
🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.
🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄
❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)
⏳ Говорили про бизнес, сроки. Что заранее невозможно всё просчитать. И с этим надо смириться 😌
🙋♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.
🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.
🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.
▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)
👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).
🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.
🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄
❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)
🙋♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.
🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.
🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.
▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍1
✨ Новый анонс— погружаемся в DDD и единый язык! ✨
Всем привет!
Хочу напомнить, что в этот четверг в 19-00 online у нас будет еще один вебинар, и я приглашаю вас присоединиться! 📅 Мы поговорим про Domain-Driven Design (DDD) и создание единого языка для команды и бизнеса.
Если вы были на прошлом вебинаре про бережливую архитектуру, то знаете, как круто у нас всё прошло! Атмосфера была потрясающая, и отзывы участников — только положительные. 🙌 Если пропустили, то не переживайте — у вас есть возможность наверстать!
📌 Дата: Этот четверг
📌 Тема: DDD: проектируем через создание единого языка
📌 Формат: Online, Бесплатно, но по записи
📌 Регистрация по ссылке: Записаться на вебинар
Вебинар будет полезен:
🏗 Архитекторам и лидам
👷 Менеджерам и аналитикам
🧱 Всем, кто пропагандирует DDD или хочет узнать больше
Я расскажу и покажу, как определять понятия и термины в вашем проекте таким образом, чтобы они были понятны и однозначны для всех участников команды!
Не упустите шанс углубить свои знания в DDD и создать тот самый единый язык, который объединит вашу команду и бизнес! 💬
Буду рада видеть вас на вебинаре!
#architecture
Всем привет!
Хочу напомнить, что в этот четверг в 19-00 online у нас будет еще один вебинар, и я приглашаю вас присоединиться! 📅 Мы поговорим про Domain-Driven Design (DDD) и создание единого языка для команды и бизнеса.
Если вы были на прошлом вебинаре про бережливую архитектуру, то знаете, как круто у нас всё прошло! Атмосфера была потрясающая, и отзывы участников — только положительные. 🙌 Если пропустили, то не переживайте — у вас есть возможность наверстать!
📌 Дата: Этот четверг
📌 Тема: DDD: проектируем через создание единого языка
📌 Формат: Online, Бесплатно, но по записи
📌 Регистрация по ссылке: Записаться на вебинар
Вебинар будет полезен:
🏗 Архитекторам и лидам
👷 Менеджерам и аналитикам
🧱 Всем, кто пропагандирует DDD или хочет узнать больше
Я расскажу и покажу, как определять понятия и термины в вашем проекте таким образом, чтобы они были понятны и однозначны для всех участников команды!
Не упустите шанс углубить свои знания в DDD и создать тот самый единый язык, который объединит вашу команду и бизнес! 💬
Буду рада видеть вас на вебинаре!
#architecture
systems.education
Бесплатный вебинар. DDD: проектируем через создание единого языка
Проектировать процессы на уровне небольших компонентов, что поможет повысить модульность и масштабируемость
👍5❤2
🌟 Выделение команды интеграционного тестирования 🌟
За свою жизнь, я встречала несколько реализаций этого подхода. Иногда это были удачные решения, как в случае с Яндекс.Деньгами (ныне ЮMoney), а иногда не очень. В некоторых компаниях команды интеграционного тестирования собирались под конкретные проекты. Например, на запуск крупного проекта выделяли тестировщиков из основных команд, которые на несколько дней “выходили” из привычных задач и создавали основу для интеграционных тестов, полностью проверяя новый функционал.
Но вот только на этой неделе, кажется, я осознала, почему же классно именно выделять такую команду в отдельный, постоянный или временный юнит. Давайте разберем, почему это может быть полезно.
🤔 Сценарий 1: Классическая “трехкомандная” ситуация
Представим, что проект затрагивает три команды: две подкапотные — платежка и домен проекта, и одну команду, отвечающую за пользовательские интерфейсы — сайт, мобилка. Доменная команда сделала свою часть работы, протестировала ее, интегрировалась с платежной (которая тоже протестировала свою часть) — вроде бы все ОК, все сценарии, которые они закладывали - работают👨💻 . Но вот интеграция с командой, которая держит всю пользовательскую логику, приносит новые баги. Команда, отвечающая за пользовательский интерфейс, начинает чувствовать:
☝️ ответственность за все продукты компании, ведь они единственные, кто может протестировать ВСЕ;
😫 недовольство, ведь кажется, что остальные две команды плохо выполнили свою работу и сделали сырую поставку!
🎭 Сценарий 2: “Обезличенное” тестирование
Если же выделить отдельную команду интеграционного тестирования, ситуация становится проще. Эти ребята относятся к тестируемому продукту как к сторонней задаче, где их цель — проверить все, чтобы нигде потом не сломалось. Им не важно, кто допустил ошибку и почему. Такая команда не привязана к “своему” коду, что позволяет им быть объективными и сконцентрированными на общем результате.
🎯 Преимущества отдельного юнита
Выделение команды интеграционного тестирования позволяет фокусироваться на всём продукте, а не на его частях. Такая команда должна обладать:
👀 стратегическим видением;
👨🎓 хорошим знанием предметной области;
👀 высоким уровнем насмотренности.
Вот так я и пришла к пониманию, что выделенная команда интеграционного тестирования - БЛАГО! Это не только шаг к эффективному способу выявления и устранения багов, но и важный к созданию качественного продукта, который будет работать как часы! А, главное, спасет нервы и продукт от лишних поломок.
А что вы думаете по этому поводу? Делитесь своими мыслями и опытом! 😊
#project_management
За свою жизнь, я встречала несколько реализаций этого подхода. Иногда это были удачные решения, как в случае с Яндекс.Деньгами (ныне ЮMoney), а иногда не очень. В некоторых компаниях команды интеграционного тестирования собирались под конкретные проекты. Например, на запуск крупного проекта выделяли тестировщиков из основных команд, которые на несколько дней “выходили” из привычных задач и создавали основу для интеграционных тестов, полностью проверяя новый функционал.
Но вот только на этой неделе, кажется, я осознала, почему же классно именно выделять такую команду в отдельный, постоянный или временный юнит. Давайте разберем, почему это может быть полезно.
🤔 Сценарий 1: Классическая “трехкомандная” ситуация
Представим, что проект затрагивает три команды: две подкапотные — платежка и домен проекта, и одну команду, отвечающую за пользовательские интерфейсы — сайт, мобилка. Доменная команда сделала свою часть работы, протестировала ее, интегрировалась с платежной (которая тоже протестировала свою часть) — вроде бы все ОК, все сценарии, которые они закладывали - работают
🎭 Сценарий 2: “Обезличенное” тестирование
Если же выделить отдельную команду интеграционного тестирования, ситуация становится проще. Эти ребята относятся к тестируемому продукту как к сторонней задаче, где их цель — проверить все, чтобы нигде потом не сломалось. Им не важно, кто допустил ошибку и почему. Такая команда не привязана к “своему” коду, что позволяет им быть объективными и сконцентрированными на общем результате.
🎯 Преимущества отдельного юнита
Выделение команды интеграционного тестирования позволяет фокусироваться на всём продукте, а не на его частях. Такая команда должна обладать:
Вот так я и пришла к пониманию, что выделенная команда интеграционного тестирования - БЛАГО! Это не только шаг к эффективному способу выявления и устранения багов, но и важный к созданию качественного продукта, который будет работать как часы! А, главное, спасет нервы и продукт от лишних поломок.
Мир, дружба, выделенная команда интеграционного тестирования🕊
А что вы думаете по этому поводу? Делитесь своими мыслями и опытом! 😊
#project_management
Please open Telegram to view this post
VIEW IN TELEGRAM
🚀 Сегодня вебинар про DDD: Не пропустите!🌟
Напоминаю, что уже сегодня я проведу вебинар на одну из моих любимых тем — Domain-Driven Design (DDD)! Мы будем говорить о том, как создавать словарь, разбираться с контекстами и строить понятный и полезный язык, который будет работать на вас и ваш проект.
И конечно, вас ждет море примеров и практики! 🎯 Обещаю, будет интересно, полезно и, как всегда, весело!
Важное напоминание: Вебинар абсолютно бесплатный, но чтобы присоединиться, нужно зарегистрироваться по этой ссылке. Сама ссылка на вебинар придет вам в ответ на регистрацию. Так что не откладывайте!
Жду вас всех сегодня! 🎉
Будем вместе разбираться в тонкостях DDD, делать ваши проекты еще круче и прокачивать наши знания. До встречи на вебинаре! 👩💻
#architecture
Напоминаю, что уже сегодня я проведу вебинар на одну из моих любимых тем — Domain-Driven Design (DDD)! Мы будем говорить о том, как создавать словарь, разбираться с контекстами и строить понятный и полезный язык, который будет работать на вас и ваш проект.
И конечно, вас ждет море примеров и практики! 🎯 Обещаю, будет интересно, полезно и, как всегда, весело!
Важное напоминание: Вебинар абсолютно бесплатный, но чтобы присоединиться, нужно зарегистрироваться по этой ссылке. Сама ссылка на вебинар придет вам в ответ на регистрацию. Так что не откладывайте!
Жду вас всех сегодня! 🎉
Будем вместе разбираться в тонкостях DDD, делать ваши проекты еще круче и прокачивать наши знания. До встречи на вебинаре! 👩💻
#architecture
systems.education
Бесплатный вебинар. DDD: проектируем через создание единого языка
Проектировать процессы на уровне небольших компонентов, что поможет повысить модульность и масштабируемость
❤2
🌐 Информационный пузырь🌀
Недавно я наткнулась на интересную статью: Статья на Meduza
Не буду вдаваться в политические или другие аспекты этой статьи. Хочу обратить ваше внимание на мысль, которая меня поразила до глубины души:
🏃♂️💨 В погоне за лояльностью пользователей мы так настроили алгоритмы, что контент стал максимально приятным и близким потребителю. Если еще 30 лет назад газеты и журналы представляли разные мнения, то теперь вы должны ХОТЕТЬ видеть и узнавать “другое мнение”. По умолчанию, все ваши гаджеты и приложения стремятся создать социально-комфортные условия, где вы потратите свои деньги, время и лайки на то, что вам НРАВИТСЯ и чего вы ХОТИТЕ!
🤔 Да, это ответственность каждого из нас: жить в пузыре или создавать себе многогранный мир с неприятными темами и триггерными вопросами. Мы сами выбираем: быть в Матрице или нет.
Я справляюсь с этой проблемой тем, что стараюсь воспринимать контент на разных языках: русский, английский, греческий, турецкий. Подписываюсь на каналы людей и СМИ с полярными мнениями. Ну и конечно же — читаю художественные книги, смотрю фильмы, чтобы увидеть альтернативные версии и мнения.
💡 Вопрос для всех нас: где проходит черта, когда мы становимся создателями Матрицы, загоняем пользователей в пузырь, лишая их выбора и выкачивая ресурсы? С развитием ИИ этот вопрос становится еще актуальнее!
Но, если вы лид/менеджер/руководитель, стоит задать еще один вопрос: а не создаю ли я пузырь для сотрудников? Готов(а) ли я услышать их мнение? Готов(а) ли я столкнуться с НЕТ?
А как вы справляетесь с этой проблемой? Делитесь в комментариях!
Недавно я наткнулась на интересную статью: Статья на Meduza
Не буду вдаваться в политические или другие аспекты этой статьи. Хочу обратить ваше внимание на мысль, которая меня поразила до глубины души:
“Зумеры — первое поколение, которое выросло в эпоху соцсетей. И технологии во многом определяют их картину мира. Современные соцсети не создавали бы информационные пузыри и не радикализировали позиции людей, если бы у них была другая модель монетизации.”
🏃♂️💨 В погоне за лояльностью пользователей мы так настроили алгоритмы, что контент стал максимально приятным и близким потребителю. Если еще 30 лет назад газеты и журналы представляли разные мнения, то теперь вы должны ХОТЕТЬ видеть и узнавать “другое мнение”. По умолчанию, все ваши гаджеты и приложения стремятся создать социально-комфортные условия, где вы потратите свои деньги, время и лайки на то, что вам НРАВИТСЯ и чего вы ХОТИТЕ!
🤔 Да, это ответственность каждого из нас: жить в пузыре или создавать себе многогранный мир с неприятными темами и триггерными вопросами. Мы сами выбираем: быть в Матрице или нет.
Я справляюсь с этой проблемой тем, что стараюсь воспринимать контент на разных языках: русский, английский, греческий, турецкий. Подписываюсь на каналы людей и СМИ с полярными мнениями. Ну и конечно же — читаю художественные книги, смотрю фильмы, чтобы увидеть альтернативные версии и мнения.
💡 Вопрос для всех нас: где проходит черта, когда мы становимся создателями Матрицы, загоняем пользователей в пузырь, лишая их выбора и выкачивая ресурсы? С развитием ИИ этот вопрос становится еще актуальнее!
Но, если вы лид/менеджер/руководитель, стоит задать еще один вопрос: а не создаю ли я пузырь для сотрудников? Готов(а) ли я услышать их мнение? Готов(а) ли я столкнуться с НЕТ?
А как вы справляетесь с этой проблемой? Делитесь в комментариях!
👍6
Пятница, ура! 🎉
Сегодня пятница, и, честно говоря, ничего супер умного от меня не ждите 😅. Но зато я подготовила кое-что, что точно поднимет вам настроение!
Встречайте... барабанная дробь 🥁
Стикерпак с нашим очаровательным песиком! 🐶
Знаю, что вам как раз сегодня не хватало чего-то именно такого, поэтому делюсь с вами этим великолепием. Пусть этот четвероногий друг приносит вам радость и скрашивает ваше общение. Так что пользуйтесь на здоровье и пусть пятница станет еще немного ярче! ✨
P.S. Буду ждать ваши отзывы, как вам стикеры😉
Сегодня пятница, и, честно говоря, ничего супер умного от меня не ждите 😅. Но зато я подготовила кое-что, что точно поднимет вам настроение!
Встречайте... барабанная дробь 🥁
Стикерпак с нашим очаровательным песиком! 🐶
Знаю, что вам как раз сегодня не хватало чего-то именно такого, поэтому делюсь с вами этим великолепием. Пусть этот четвероногий друг приносит вам радость и скрашивает ваше общение. Так что пользуйтесь на здоровье и пусть пятница станет еще немного ярче! ✨
P.S. Буду ждать ваши отзывы, как вам стикеры
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥1
Романтика и KYC: Как вечер с вином и сыром привел к размышлениям о праве на забвение 🍷🧀
Вчера мы с мужем решили провести идеальный романтический вечер: петнат от Хенриха, сырная тарелка, персики с фестиваля, десерты… и, конечно же, хотелось посмотреть что-то по-настоящему романтичное. Нашли фильм 2023 года «Люби снова» с Приянкой Чопрой и песнями Селин Дион. Казалось бы, вечер обещал быть идеальным, но...
Завязка фильма неожиданно привела нас к размышлениям о KYC и проблеме информационной смерти! 😅
Что такое KYC? 🤷♂️🤷♀️
KYC (Know Your Customer) — это процедура идентификации клиентов, обязательная для финтех-компаний и банков. Она помогает бороться с мошенничеством, отмыванием денег и другими финансовыми преступлениями, гарантируя, что человек, который открывает счет или совершает транзакцию, — это действительно тот, за кого он себя выдает.
Но что делать, если клиента больше нет, а его цифровой след остался? 🤔
Личный опыт 😔
Впервые я столкнулась с понятием информационной смерти, когда умер мой коллега и друг. Было странно и больно осознавать, что его нет, но его аккаунт жив и я могу ему написать. А позже в финтехе я столкнулась с другой стороной этой проблемы: когда один человек уходит, а его номер телефона переходит другому. Как быть с аккаунтами, привязанными к этому номеру? Как правильно архивировать счета, списывать балансы и, самое главное, как не забывать, что за этими действиями стоят чьи-то жизни?
И вот тут я поняла, что ненавижу решать проблемы информационной смерти и перепривязки телефонов. Но успокаиваю себя мыслью, что, возможно, этот номер больше просто никому не нужен.
VK и право на забвение
Одними из первых в России, кто начал решать эту проблему, стали ребята из VK. Решение информационной смерти тесно связано с правом на забвение. В мировой практике самым известным прецедентом стало дело Костеха 2014 года против Google Spain. Этот случай изменил законодательства многих стран, закрепив право на удаление информации о себе из любой сети или системы.
Философский вопрос:
Можем ли мы рассматривать право на забвение как право на эвтаназию в цифровом мире? 🤔
Вот так, немного грустно-философски, я задумалась о стандартных банковских проблемах во время романтического вечера. Возможно, в следующий раз лучше выбрать фильм без привязки к KYC и финтеху! 😅
А какие бытовые ситуации 🎬🎭📖⚽️ наталкивали вас на мысли о работе?
#fintech
Вчера мы с мужем решили провести идеальный романтический вечер: петнат от Хенриха, сырная тарелка, персики с фестиваля, десерты… и, конечно же, хотелось посмотреть что-то по-настоящему романтичное. Нашли фильм 2023 года «Люби снова» с Приянкой Чопрой и песнями Селин Дион. Казалось бы, вечер обещал быть идеальным, но...
Завязка фильма неожиданно привела нас к размышлениям о KYC и проблеме информационной смерти! 😅
Что такое KYC? 🤷♂️🤷♀️
KYC (Know Your Customer) — это процедура идентификации клиентов, обязательная для финтех-компаний и банков. Она помогает бороться с мошенничеством, отмыванием денег и другими финансовыми преступлениями, гарантируя, что человек, который открывает счет или совершает транзакцию, — это действительно тот, за кого он себя выдает.
Но что делать, если клиента больше нет, а его цифровой след остался? 🤔
Личный опыт 😔
Впервые я столкнулась с понятием информационной смерти, когда умер мой коллега и друг. Было странно и больно осознавать, что его нет, но его аккаунт жив и я могу ему написать. А позже в финтехе я столкнулась с другой стороной этой проблемы: когда один человек уходит, а его номер телефона переходит другому. Как быть с аккаунтами, привязанными к этому номеру? Как правильно архивировать счета, списывать балансы и, самое главное, как не забывать, что за этими действиями стоят чьи-то жизни?
И вот тут я поняла, что ненавижу решать проблемы информационной смерти и перепривязки телефонов. Но успокаиваю себя мыслью, что, возможно, этот номер больше просто никому не нужен.
VK и право на забвение
Одними из первых в России, кто начал решать эту проблему, стали ребята из VK. Решение информационной смерти тесно связано с правом на забвение. В мировой практике самым известным прецедентом стало дело Костеха 2014 года против Google Spain. Этот случай изменил законодательства многих стран, закрепив право на удаление информации о себе из любой сети или системы.
Философский вопрос:
Можем ли мы рассматривать право на забвение как право на эвтаназию в цифровом мире? 🤔
And it hurts so
That something so strong
Someday will be gone, must say "goodbye"
Вот так, немного грустно-философски, я задумалась о стандартных банковских проблемах во время романтического вечера. Возможно, в следующий раз лучше выбрать фильм без привязки к KYC и финтеху! 😅
А какие бытовые ситуации 🎬🎭📖⚽️ наталкивали вас на мысли о работе?
#fintech
YouTube
Céline Dion - Goodbye's (The Saddest Word) (Official HD Video)
Official Video for "Goodbye's (The Saddest Word)" by Celine Dion
Listen to Celine Dion: https://CelineDion.lnk.to/listenYD
Watch more videos by Celine Dion: https://CelineDion.lnk.to/listenYD/youtube
Subscribe to the official Celine Dion YouTube channel:…
Listen to Celine Dion: https://CelineDion.lnk.to/listenYD
Watch more videos by Celine Dion: https://CelineDion.lnk.to/listenYD/youtube
Subscribe to the official Celine Dion YouTube channel:…
❤2👍2
📅 23 августа в 18:00 — Мастер-Майнд #3 "Риски бронирования"! 🎉
Друзья, анонсирую третий мастер-майнд, который пройдет уже в этот пятничный вечер, 23 августа, в 18:00! Формат, как всегда, онлайн и рассчитан на 1,5 часа интересных обсуждений и решения непростых задач.
Традиционно на MasteMind приходят тимлиды, техлиды, аналитики или другие многофункцинальные многорукие профессионалы. Мы берем какую-то острую тему (например, ближайшая - продолжаем пилить многогранные риски), я даю под нее задачу и кусок теории и коллеги делятся своими мыслыми или опытом решения. Если у вас есть сложные задачи, даже напрямую не связанные с темой, то есть верояность, что вы ее сможете решить, опылившись о коллег. Как вам❓
Тематика встречи:
В этот раз мы рассмотрим сценарий “продажи” номеров через сервис отельный-агрегат:
1️⃣ Как поступить, если 5 человек заказали и оплатили номер, а осталось всего 4 номера?
2️⃣ Как справиться с интеграцией отелей с разным количеством номеров и различными способами подключения: файлы, API, “по телефону/админка клиента”?
3️⃣ Что делать, если один номер пострадал, например, из-за протечки батареи, и затопил еще 5 ниже?
💡 Что вы получите?
🛠 Практический опыт: Мы разберем реальную задачу, связанную с управлением рисками в системе бронирования. Конкретные рабочие кейсы и проблемы, с которыми вы сталкиваетесь ежедневно.
📚 Новые знания: Получите инструменты и подходы, которые помогут вам расширить свое видение и решать задачи не только в области рисков, но и в других аспектах вашей работы.
🎓 Возможность задать вопросы и получить ответы: Это не лекция — это интерактивная работа, где вы сможете накидывать идеи, обсуждать их и находить решения вместе с другими опытными специалистами.
🤝 Работа в малых группах: Всего 10 участников, что позволяет детально обсудить каждый аспект и получить максимум пользы от встречи.
🎟️ Условия участия:
Мастер-майнд по цене кофе с десертом: 1500 рублей.
📈 Почему это важно?
Мы создаем среду, где каждый может включиться в процесс решения задач и получить реальный результат. Мастер-майнд — это не просто разговоры, а совместная работа над сложными проблемами, с которыми вы сталкиваетесь в реальной жизни.
Как принять участие?
Если хотите забронировать место, пишите в комментарии — я расскажу, как это сделать!
PS: Если интересно, как прошли предыдущие встречи — отзывы в скриншотах выше! 🚀
#fintech
Друзья, анонсирую третий мастер-майнд, который пройдет уже в этот пятничный вечер, 23 августа, в 18:00! Формат, как всегда, онлайн и рассчитан на 1,5 часа интересных обсуждений и решения непростых задач.
Традиционно на MasteMind приходят тимлиды, техлиды, аналитики или другие многофункцинальные многорукие профессионалы. Мы берем какую-то острую тему (например, ближайшая - продолжаем пилить многогранные риски), я даю под нее задачу и кусок теории и коллеги делятся своими мыслыми или опытом решения. Если у вас есть сложные задачи, даже напрямую не связанные с темой, то есть верояность, что вы ее сможете решить, опылившись о коллег. Как вам❓
Тематика встречи:
В этот раз мы рассмотрим сценарий “продажи” номеров через сервис отельный-агрегат:
1️⃣ Как поступить, если 5 человек заказали и оплатили номер, а осталось всего 4 номера?
2️⃣ Как справиться с интеграцией отелей с разным количеством номеров и различными способами подключения: файлы, API, “по телефону/админка клиента”?
3️⃣ Что делать, если один номер пострадал, например, из-за протечки батареи, и затопил еще 5 ниже?
💡 Что вы получите?
🛠 Практический опыт: Мы разберем реальную задачу, связанную с управлением рисками в системе бронирования. Конкретные рабочие кейсы и проблемы, с которыми вы сталкиваетесь ежедневно.
📚 Новые знания: Получите инструменты и подходы, которые помогут вам расширить свое видение и решать задачи не только в области рисков, но и в других аспектах вашей работы.
🎓 Возможность задать вопросы и получить ответы: Это не лекция — это интерактивная работа, где вы сможете накидывать идеи, обсуждать их и находить решения вместе с другими опытными специалистами.
🤝 Работа в малых группах: Всего 10 участников, что позволяет детально обсудить каждый аспект и получить максимум пользы от встречи.
🎟️ Условия участия:
Мастер-майнд по цене кофе с десертом: 1500 рублей.
📈 Почему это важно?
Мы создаем среду, где каждый может включиться в процесс решения задач и получить реальный результат. Мастер-майнд — это не просто разговоры, а совместная работа над сложными проблемами, с которыми вы сталкиваетесь в реальной жизни.
Как принять участие?
Если хотите забронировать место, пишите в комментарии — я расскажу, как это сделать!
PS: Если интересно, как прошли предыдущие встречи — отзывы в скриншотах выше! 🚀
#fintech
❤4🏆2