Как вам новое название канала и аватарка?

♥️ - если нравится 🔥 - если огонь

🌍 Культурные паттерны в финтехе: история, скрытая за POS-терминалами 🏦✨
#культурныйпаттерн

Первый пост рубрики: "Культурный паттерн"!

Что такое "зоопарк" терминалов?
Начнем с картинки: магазин и множество терминалов! Картинка утрирована, но нескольких терминалов в одном магазине встречается достаточно часто - присмотритесь. Почему в одном магазине может быть коллекция терминалов?

Причины многообразия:
1. Комиссия за операцию: Варьируется в зависимости от банка-эмитента.
2. MCC-коды: Вид деятельности / товар, который продается в магазине.
3. Нормативно-правовое поле: Бизнес требующий особенного процееса лицензирования.

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

Причина? Комиссии! В Турции продавцы могут платить до 8% от суммы сделки, что для дорогих товаров, как антиквариат, существенно бьет по карману.
Решение? Чтобы снизить издержки (антиквариат - высокие ставки и не маленький чек) владельцы магазинов заключают договора с несколькими банками на POS-терминалы и ведут сразу несколько бухгалтерских учетов, которые сводят в общий отчет, но тем самым экономят на комиссии. Так как комиссия, в основном, варьируется по следующим показателям:
- банк-эмитент карты (по своим картам процент ниже)
- валюта операции (в местной валюте % ниже, чем в иностранной)

В следующем посте расскажу про MCC-коды и почему они тоже могут привести к зоопарку POS-терминалов! 🌐💬

Словарик:
Банк-эмитент - банк, выпускающий пластиковые карты и обслуживающий их владельцев.

#fintech

👀 Как насмотренность усиливает вашу экспертизу в любой сфере? 🧠✨

Вчера завершилась неделя потрясающего онлайн-интенсива от USkillz "Творчество как навык", в котором я участвовала благодаря @baldoverdikt. На интенсиве много говорили о насмотренности как навыке, который помогает в любой отрасли: будь то IT, музыка или ресторанное дело. Насмотренность тесно связана с умением замечать детали, обращать внимание на отличия и воспринимать известное через призму нового и неизведанного. Сегодня один из моих любимых фильмов с детства стал для меня не только источником удовольствия, но и мощным инструментом для усиления профессиональных навыков. И вот как это работает:

🎥 От кино до бережливой архитектуры
Сейчас я готовлю доклад по бережливой архитектуре для ближайшей конференции Podlodka Techlead Crew. Верите ли вы, что главные выводы в докладе мне помогают сформулировать цитаты из фильма "Тот самый Мюнхгаузен"! Иногда неожиданный источник может подсказать вам уникальную идею, которая выделит вашу мысль среди множества других.

🧠 Мозг не умеет скучать
Даже когда мы отдыхаем, наш мозг работает на полную катушку. Во время сна или просмотра фильма он анализирует информацию, делает выводы и устанавливает связи. Исследования в области нейробиологии показывают, что мозг продолжает обрабатывать внешние стимулы на подсознательном уровне. Наши развлечения и интересы могут серьёзно повлиять на профессиональные навыки и наоборот.

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

😢 А еще меня абсолютно нехватает на канал, когда идет подготовка к выступлениям 😢 А как ваши дела?

Очень приятно, когда выходят такие посты в каналах, которыми регулярно пользуешься!

А если вы еще не знаете про Дашу, и вам нужна помощь с придумыванием тем ретро - ее канал НАХОДКА!!!

#toolkit

🎟️ РОЗЫГРЫШ БИЛЕТА 🎟️

Написала хорошую заметку про тренировку насмотренности, но не успеваю оформить 🤣! Так как доготавливаюсь к конфе PodlodkaCrew!

Но, пусть я ничего не успеваю, но сегодня открою розыгрыш билета на Подлодку 🤿

Условия просты: оставьте комментарий под этим постом, а завтра утром я выберу, используя рандомайзер победителя, который получит бесплетный билет на конференцию! 🎉

Но, если вы еще и решите поделиться моим каналом с друзьям/коллегами, кому может быть полезен канал - буду признательна 😁

Результаты розыгрыша и поздравляю @alenkaiva 🥳

🌊 Привет, морские волки! 🌊

После недели, проведенной в недрах подготовки, я, словно субмарина, всплыла на поверхность, чтобы поделиться с вами своим докладом на конференции Podlodka Techlead Crew!

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

🔥 Ожидаю бурю мнений в комментариях! Давайте вместе разберемся в каждой детали и поспорим на здоровье. 💬

PS: Не забыла про обещанный пост о насмотренности — он уже на подходе! Ожидайте свежие мысли в ближайшие дни. 🎞️📖

#architecture

🌟 Развиваем насмотренность! 🌟

Привет! Наконец-то давно обещанный пост о "насмотренности" — умении видеть глубже очевидного. Это та самая способность, которая помогает нам не просто смотреть, но видеть и анализировать, связывая казалось бы несвязанное!

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

✍️ Советы для повседневной практики:
👁‍🗨Расширяйте кругозор: Чем больше вы знакомитесь с разными жанрами искусства, культуры или пробуете что-то новое, тем больше нейронных связей устанавливает ваш мозг. Изучайте, как сделано у других, исследуйте открытые источники, интересуйтесь новыми технологиями и методологиями — это поможет вам находить неочевидные решения для сложных технических задач.
Пример: вам необходимо сделать гибкую систему комиссий за проведение платежа. Можно пойти по пути типизации платежей, а можно, по аналогии с системой MCC-кодов, вынести основное назначение платежей на уровень мерчантов и, в зависимости от мерчанта и вида его деятельности, настроить динамический % за услуги.
⚖️Анализ и рефлексия: После просмотра фильма, прочтения книги или посещения выставки попробуйте задуматься, какие идеи или темы вы могли бы адаптировать в своей работе. После каждого проекта проводите ретроспективу, анализируйте, какие подходы были эффективны, и какие уроки можно извлечь. Комбинируйте "культурный" опыт с опытом, получаемым на работе.
Пример: Однажды, размышления о Листе и Рахманинове помогли мне придумать способ разделения пользователей, а именно упростить выдачу продуктовых ролей и при достижении пользователем определенных условий, так как роли перестали быть набором "галочек", а стали разрешением к действиям, как когда-то Рахманинов "разрешил" себе быть и гениальным пианистом и гениальным композитором.
💬Обсуждение: Обсуждение помогает углубить понимание и может привести к новым идеям. Делитесь своими находками с коллегами. Обсуждение углубляет понимание и способствует генерации новых идей.
🪄Креативное мышление: Например, попробуйте использовать методы из геймдизайна для оптимизации пользовательского интерфейса в вашем программном продукте. Как - легко, даже для админки интегрированных продуктов.
Пример: Вспомните работу с "сундуком" и "вещами", возможно, это то, что нужно вам при настройке сложных фильтров для громоздких таблиц с платежами!
🛠Интеграция и применение: Когда встречаете интересную идею или концепцию, подумайте, как ее можно адаптировать и применить в вашей сфере. Не бойтесь экспериментировать с новыми подходами.
Пример: Если бы люди все делали только по инструкции, мир IT никогда бы не получил прекрасный LEAN-Design, так как бережливое производство ТОЛЬКО ДЛЯ АВТОПРОМА!
📚Создайте свою "библиотеку идей": Идея может быть классной, но не ко времени. Заведите заметку/борду, куда будете выписывать "озарения", и иногда проводите ревизию.

И знаете что? Насмотренность - навык, который можно развивать не только у себя, но и у младших членов вашей семьи, превращая обучение в увлекательную игру. И вместе с детьми прокачивать себя! Если хотите расскажу как-ниб про игры, которые прокачают вас и "займут" ребенка?

А как вы тренируете "насмотренность" и помогает ли она вам в работе?

#product_management

🚀 10 Капитанских правил для REST-API в Финтехе 🚀

Привет всем!

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

1️⃣ Понятность названий параметров: Каждый параметр должен однозначно объяснять своё предназначение и формат. Пример: параметр "visibility_flag", кажется должен быть булевым (true/false). Однако часто такие параметры могут быть представлены как int со значениями 0, 1, 2, 3... Это создаёт путаницу и уменьшает читаемость API.

2️⃣ Использование префикса для булевых переменных: Для булевых переменных используйте префикс 'is', например, 'is_visible'. Это сразу делает понятным, что переменная имеет два состояния: истина (и true = видимо) или ложь, и упрощает работу с кодом.

3️⃣ Ясное описание происходящего: Если можно объяснить ситуацию словами — делайте это. Вместо того чтобы заставлять пользователя дешифровать числовые значения в 'invisibility_reason', лучше сразу указывать причину: 'blocked', 'fraud', 'no money'. Это делает API более дружелюбным и понятным.

4️⃣ Прозрачность ошибок: Не заставляйте пользователей разбираться в сложных таблицах для понимания ошибок. Ошибки должны быть понятны и просты для интерпретации, чтобы пользователи могли быстро находить и исправлять проблемы. Самый странный протокол в моей жизни содержал 57 печатных страниц с расшифровкой кодов ошибок.

5️⃣ Полная информация об ошибках: Если в процессе выполнения запроса обнаружено несколько ошибок, сообщайте о всех одновременно. Это позволяет пользователям быстрее и эффективнее устранять проблемы. Пример: отправлены данные пользователя. Но одно из обязательных полей пропущено, а в паспорте нехватает цифры. Если обе проверки выполняются на API (а скорее всего - да, так как это валидация данных) - отдайте сразу обе ошибки и о нехватке данных, и об ошибке в номере паспорта.

6️⃣ Отсутствие дублирующих параметров: Избегайте создания параметров с похожими названиями и разной логикой. Пример: 'is_visible' и 'visible_flag'. Если хотите в поле 'visible_flag' поместить причину - назовите 'visibility_reason', если "буль" передающий информацию о ручной установки видимости из админки 'is_visible_manual'.

7️⃣ Один метод — одна функция: Избегайте создания универсальных методов, которые меняют своё поведение в зависимости от передаваемых параметров. Это усложняет поддержку и отладку. Иногда встречается попытка создать единый метод для старта однофазного и двухфазного платежа, внутри которого флагом отмечается какой это платеж. Вместо того чтобы явно прописать, что за метод вызывает. К сожалению, это путь к проблемному дебагу и сложному мониторингу.

8️⃣ Продуманность структуры данных: Лучше заранее подумать о данных, которые могут понадобиться в будущем (в части сущностей, где вы не main система), чем впоследствии их добавлять. Например, клиент-создается на стороне Мерчанта, вы только обогащаете его параметрами. Но клиент может иметь «галочку», которая вам если и понадобится, то не раньше чем через год. При большой пользовательской базе и части процессов идущих напрямую через вас, добавление параметра через год, может стоить дорого.

9️⃣ Изолированность данных в методах: Убедитесь, что каждый метод работает с данными только одной сущности. Это облегчает понимание и поддержку API. Не стоит в клиентские методы прокидывать параметры счета и наоборот. Если признак тестовости у клиента, а счет не имеет признака тестовости, то методы аккаунтов не должны содержаить параметь 'is_test'.

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

Надеюсь, эти правила помогут сделать наш API не просто функциональным, но и удобным в использовании!

#architecture

Уже поступили вопросики про следующую встречу!

Следующая встреча будет в начале июля!

Если вам интересен мастер-майнд приходите в этот пост в комментарии 😍