🛠 Принцип "Если может упасть - упадет"🛠
Хочу поговорить о неизбежности ошибок и сбоев в информационных системах (говорила об этом на послденем докладе) и о том, как важно принимать это во внимание при проектировании. Многие из вас знают этот принцип как "Murphy's Law" в инженерии, но в контексте IT и управления рисками, это скорее здравый реализм, чем пессимизм.
⚠️Почему важно учитывать возможность сбоев?
При разработке систем важно предусматривать, что рано или поздно что-то пойдет не так. Это может быть сбой оборудования, ошибки в программном обеспечении или даже человеческий фактор. Именно поэтому необходимо разрабатывать системы таким образом, чтобы они могли продолжать функционировать даже при частичных ошибках или проблемах.
Примеры из финтеха:
🌐 Централизованные сервисы: Если все ваши продукты зависят от одного центрального сервиса, стоит задуматься о разделении функций на «читающие» и «пишущие». Такое разделение позволяет изолировать и минимизировать последствия сбоев. Пишущие процессы, которые изменяют данные, должны быть защищены дополнительными мерами восстановления и резервного копирования.
🕵 Системы антифрода: Эти системы критически важны в финансовой сфере, но их сложность и зависимость от сторонних продуктов могут привести к непредвиденным "отдыхам". Решение? Создание двух путей обработки: основной (happy pass) для обычных операций и альтернативный ("костыляющий") для ситуаций, когда основной путь недоступен. Это может включать в себя ограниченные транзакции на основе предварительного анализа рисков или работу только с проверенными каналами.
💬 Итог
"Если может упасть — упадет" не означает, что нужно быть пессимистом, это призыв к реалистичному подходу к проектированию. Помните, что лучше заранее предусмотреть потенциальные проблемы, чем столкнуться с ними в самый неподходящий момент.
🔔 Вопрос:
Хотели бы получить арх задачку, связанную с риск-менеджментом и, в том числе, проблемами падения? Я даже придумала такую! Можем тредик выделить, если интересно "покрутить" такие проектики!
#architecture #fintech
Хочу поговорить о неизбежности ошибок и сбоев в информационных системах (говорила об этом на послденем докладе) и о том, как важно принимать это во внимание при проектировании. Многие из вас знают этот принцип как "Murphy's Law" в инженерии, но в контексте IT и управления рисками, это скорее здравый реализм, чем пессимизм.
⚠️Почему важно учитывать возможность сбоев?
При разработке систем важно предусматривать, что рано или поздно что-то пойдет не так. Это может быть сбой оборудования, ошибки в программном обеспечении или даже человеческий фактор. Именно поэтому необходимо разрабатывать системы таким образом, чтобы они могли продолжать функционировать даже при частичных ошибках или проблемах.
Примеры из финтеха:
🌐 Централизованные сервисы: Если все ваши продукты зависят от одного центрального сервиса, стоит задуматься о разделении функций на «читающие» и «пишущие». Такое разделение позволяет изолировать и минимизировать последствия сбоев. Пишущие процессы, которые изменяют данные, должны быть защищены дополнительными мерами восстановления и резервного копирования.
🕵 Системы антифрода: Эти системы критически важны в финансовой сфере, но их сложность и зависимость от сторонних продуктов могут привести к непредвиденным "отдыхам". Решение? Создание двух путей обработки: основной (happy pass) для обычных операций и альтернативный ("костыляющий") для ситуаций, когда основной путь недоступен. Это может включать в себя ограниченные транзакции на основе предварительного анализа рисков или работу только с проверенными каналами.
💬 Итог
"Если может упасть — упадет" не означает, что нужно быть пессимистом, это призыв к реалистичному подходу к проектированию. Помните, что лучше заранее предусмотреть потенциальные проблемы, чем столкнуться с ними в самый неподходящий момент.
Хотели бы получить арх задачку, связанную с риск-менеджментом и, в том числе, проблемами падения? Я даже придумала такую! Можем тредик выделить, если интересно "покрутить" такие проектики!
#architecture #fintech
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍1
Я тут внезапно решила заболеть, не то чтоб решила, но заболела на все 💯
Температура под 39, кашель и все болит…
Поэтому подвыпала ото всюду и даже MasterMind, который должен был быт вчера отменила! Спасибо всем, что поняли ситуацию и не обижаетесь!
А пока болею, ловите очень классный лонгрид про риски, тревожность и как с этим жить! Не со всеми поинтами согласна, но проверять каждые 5 минут телефон-это привычка от которой очень сложно отделаться!
Ведь единственное в чем ты уверен всегда: нет такой системы, которую НЕЛЬЗЯ УРОНИТЬ!
PS: Лучики здоровья и поддержки тоже принимаю. Так паршиво не было с covid! Но тесты на грипп и корону-отрицательные 😤
Температура под 39, кашель и все болит…
Поэтому подвыпала ото всюду и даже MasterMind, который должен был быт вчера отменила! Спасибо всем, что поняли ситуацию и не обижаетесь!
А пока болею, ловите очень классный лонгрид про риски, тревожность и как с этим жить! Не со всеми поинтами согласна, но проверять каждые 5 минут телефон-это привычка от которой очень сложно отделаться!
Ведь единственное в чем ты уверен всегда: нет такой системы, которую НЕЛЬЗЯ УРОНИТЬ!
PS: Лучики здоровья и поддержки тоже принимаю. Так паршиво не было с covid! Но тесты на грипп и корону-отрицательные 😤
Telegram
IT мудрость
Тревожность VS Продуманность 😩 🥲 😦
или "У меня есть справка, что мне уже лучше. Теперь я чайник, а не самовар"
Предполагаемое время прочтения: 10-15 минут
Осмысление: ∞
Честно скажу, я долго блуждал по коридорам сознания. И название, кажется, должно…
или "У меня есть справка, что мне уже лучше. Теперь я чайник, а не самовар"
Предполагаемое время прочтения: 10-15 минут
Осмысление: ∞
Честно скажу, я долго блуждал по коридорам сознания. И название, кажется, должно…
❤6🔥5💔4🤗2
Больница-больницей, но я ж как «нормальный блогер» пишу посты заранее, поэтому сегодня пост про справочники и классификаторы
PS: впервые с воскресенья родные 36,4
⤵️ ловите пост
PS: впервые с воскресенья родные 36,4
⤵️ ловите пост
❤6
🌍 7 универсальных справочников 🌍
Сегодня хочу поговорить о теме, которая, наверное, знакома многим: как не мудрить, выдумывая базовые справочники и классификаторы, а брать международно принятые стандарты. 🎯
Нередко при проектировании системы возникает искушение придумать свои собственные справочники и классификаторы, чтобы всё было под контролем и "как нам удобно". Но давайте будем честными: это далеко не всегда лучший путь, особенно если вы планируете интеграцию с внешними системами или ваш продукт будет использоваться международными потребителями.
Почему разумнее - не выдумывать? 🤔
🤝Универсальность: Использование международных стандартов делает ваш продукт доступным и понятным для пользователей по всему миру.
📉 Снижение затрат на интеграцию: При интеграции вы избежите необходимости разрабатывать дополнительные конвертеры и решать "олимпиадные математичесские задачи".
🧠Упрощение разработки: Стандарты уже существуют, их не нужно изобретать заново. А значит, можно сэкономить время и силы на более важные задачи.
📰Стабильность и актуальность: Международные стандарты проходят тщательную проверку и вам не надо заботиться и переживать, что вы забудете вовремя актуализировать справочник.
Вот мой топ-7 классификаторов и справочников, на которые проще опираться, чем придумывать свои:
1️⃣ISO 3166 – Коды стран 🌏
Например:
Используйте эти коды для обозначения стран в вашей системе, и ваш продукт станет сразу понятен международным пользователям. Вот ссылка на сам ISO-3166
2️⃣ISO 8601 – Формат даты и времени ⏰
Формат:
– это стандарт, который понимает весь мир. Забудьте о путанице с различными форматами дат и временем. И лучше сразу хранить часовой пояс, чем ждать расширения продукта и мигрировать данные, или начинать считать все от "Москвы" / "Тобольска" / "Рио"...
3️⃣ФИАС – Федеральная информационная адресная система (для России) 🏠
Использование ФИАС для адресов в России упрощает работу с государственными системами и обеспечивает актуальность данных. В Германии, например, используют Telefonbuch для аналогичных целей, чтобы стандартизировать адресные данные.
4️⃣ISO 4217 – Коды валют 💰
Например: USD для доллара США, EUR для евро. Стандартные коды валют делают вашу систему готовой для работы с международными транзакциями. Банки, как и почта - слишком "стары", чтобы выдумывать новое - они просто указывают международные коды и "не думают" 😊Мало того, ШОК НОВОСТЬ, ISO 4217 связан с ISO 3166-1-alpha-2!
5️⃣UN/LOCODE – Коды местоположений 🌐
Коды местоположений, разработанные ООН, помогут вам обозначить порты, города и другие географические объекты по всему миру. И снова ШОК-контент: этот справочник тоже опирается на ISO 3166-1-alpha-2!
6️⃣ISO 639 – Коды языков 🌐
Например: en для английского, ru для русского. Это облегчит добавление мультиязычности в ваш продукт.
📌Важно! Цитата с сайта ISO 639:
7️⃣БИН (Bank Identification Number) – Справочник бинов банковских карт 💳
Этот справочник используется для идентификации выпускающих банков и классификации платежных карт. Выдается, например, Visa. Это помогает банкам и платежным системам управлять транзакциями и обеспечивать безопасность.
Так что, друзья, не стоит изобретать велосипед! 🚴♂️ Ориентируйтесь на проверенные международные стандарты, и ваш продукт станет гибким, надежным и готовым к масштабированию!
А как у вас с использованием стандартов? Может, у вас есть свои фавориты? Делитесь в комментариях! 😊
#architecture
Сегодня хочу поговорить о теме, которая, наверное, знакома многим: как не мудрить, выдумывая базовые справочники и классификаторы, а брать международно принятые стандарты. 🎯
Нередко при проектировании системы возникает искушение придумать свои собственные справочники и классификаторы, чтобы всё было под контролем и "как нам удобно". Но давайте будем честными: это далеко не всегда лучший путь, особенно если вы планируете интеграцию с внешними системами или ваш продукт будет использоваться международными потребителями.
Почему разумнее - не выдумывать? 🤔
🤝Универсальность: Использование международных стандартов делает ваш продукт доступным и понятным для пользователей по всему миру.
🧠Упрощение разработки: Стандарты уже существуют, их не нужно изобретать заново. А значит, можно сэкономить время и силы на более важные задачи.
📰Стабильность и актуальность: Международные стандарты проходят тщательную проверку и вам не надо заботиться и переживать, что вы забудете вовремя актуализировать справочник.
Вот мой топ-7 классификаторов и справочников, на которые проще опираться, чем придумывать свои:
1️⃣ISO 3166 – Коды стран 🌏
Например:
Россия – RU, RUS, 643;
США – US, USA, 840.
Используйте эти коды для обозначения стран в вашей системе, и ваш продукт станет сразу понятен международным пользователям. Вот ссылка на сам ISO-3166
2️⃣ISO 8601 – Формат даты и времени ⏰
Формат:
YYYY-MM-DDThh:mm ±hh
(например, 2024-07-08T15:30:00+03:00)
– это стандарт, который понимает весь мир. Забудьте о путанице с различными форматами дат и временем. И лучше сразу хранить часовой пояс, чем ждать расширения продукта и мигрировать данные, или начинать считать все от "Москвы" / "Тобольска" / "Рио"...
3️⃣ФИАС – Федеральная информационная адресная система (для России) 🏠
Использование ФИАС для адресов в России упрощает работу с государственными системами и обеспечивает актуальность данных. В Германии, например, используют Telefonbuch для аналогичных целей, чтобы стандартизировать адресные данные.
4️⃣ISO 4217 – Коды валют 💰
Например: USD для доллара США, EUR для евро. Стандартные коды валют делают вашу систему готовой для работы с международными транзакциями. Банки, как и почта - слишком "стары", чтобы выдумывать новое - они просто указывают международные коды и "не думают" 😊Мало того, ШОК НОВОСТЬ, ISO 4217 связан с ISO 3166-1-alpha-2!
5️⃣UN/LOCODE – Коды местоположений 🌐
Коды местоположений, разработанные ООН, помогут вам обозначить порты, города и другие географические объекты по всему миру. И снова ШОК-контент: этот справочник тоже опирается на ISO 3166-1-alpha-2!
6️⃣ISO 639 – Коды языков 🌐
Например: en для английского, ru для русского. Это облегчит добавление мультиязычности в ваш продукт.
📌Важно! Цитата с сайта ISO 639:
ISO allows free-of-charge use of its country, currency and language codes from ISO 3166, ISO 4217 and ISO 639, respectively.
7️⃣БИН (Bank Identification Number) – Справочник бинов банковских карт 💳
Этот справочник используется для идентификации выпускающих банков и классификации платежных карт. Выдается, например, Visa. Это помогает банкам и платежным системам управлять транзакциями и обеспечивать безопасность.
Так что, друзья, не стоит изобретать велосипед! 🚴♂️ Ориентируйтесь на проверенные международные стандарты, и ваш продукт станет гибким, надежным и готовым к масштабированию!
А как у вас с использованием стандартов? Может, у вас есть свои фавориты? Делитесь в комментариях! 😊
#architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
ISO
ISO - ISO 8601 — Date and time format
ISO 8601 is the internationally accepted way to represent dates and times.
❤6🔥5👍4👎1
🌟 Интересный факт про валюты и коды ISO! 🌟
Легкий пятнично-вечерний контент в конце рабочей недели!
Пока писала предыдуший пост, узнала кое-что новое для себя! И хочу поделиться с вами историей о том, как "придумывались" названия валют! Сстандарт ISO 4217 связан с ISO 3166-1-alpha-2, и вот как именно:
1️⃣ США 🇺🇸: берем код из 3166 "US" + добавляем первую букву от названия валюты "Dollar" = USD.
2️⃣ Чехия 🇨🇿: берем код из 3166 "CZ" + добавляем первую букву от названия валюты "Koruna" = CZK.
А что же с рублем?! 🇷🇺
Буквенный код российского рубля в стандарте ISO 4217 — RUB, цифровой — 643; до денежной реформы 1998 года использовался кодRUR (810). Этот цифровой код (810) исключён и из стандарта ISO 4217, и из Общероссийского классификатора валют, но продолжает использоваться для нумерации банковских счетов (в некоторых банках, ну не рефачить же, право слово)!
Интересно, правда? А вы знали об этом? 😊
#fintech #architecture
Легкий пятнично-вечерний контент в конце рабочей недели!
Пока писала предыдуший пост, узнала кое-что новое для себя! И хочу поделиться с вами историей о том, как "придумывались" названия валют! Сстандарт ISO 4217 связан с ISO 3166-1-alpha-2, и вот как именно:
1️⃣ США 🇺🇸: берем код из 3166 "US" + добавляем первую букву от названия валюты "Dollar" = USD.
2️⃣ Чехия 🇨🇿: берем код из 3166 "CZ" + добавляем первую букву от названия валюты "Koruna" = CZK.
А что же с рублем?! 🇷🇺
Буквенный код российского рубля в стандарте ISO 4217 — RUB, цифровой — 643; до денежной реформы 1998 года использовался код
Интересно, правда? А вы знали об этом? 😊
#fintech #architecture
🤔3👍1
Мое главное достижение дня!
Даже НЕДЕЛИ!
А чего достиг ТЫ? 🤣
PS Надеюсь на выписку в начале недели!
#mylife
Даже НЕДЕЛИ!
А чего достиг ТЫ? 🤣
PS Надеюсь на выписку в начале недели!
#mylife
🔥18😁2
📄 Documentation 📄
Сегодня хочу поговорить о вечной проблеме всех IT-команд - документации. Этот путь познания неизбежен и часто комичен, поэтому давайте разберем его стадии:
1️⃣ Доки не нужны - я все запомню - Знакомо? Это, наверное, первое заблуждение каждого новичка.
2️⃣ Кому надо - почитают комментарии - Ага, особенно те, кто обожает разгадывать чужие ребусы.
3️⃣ Комменты нужны +- понятные - Тут уже появляется первый лучик осознания.
4️⃣ Проще "хоть как-то" писать документацию, чем вообще не писать - Начало мудрости. Начинаем что-то делать, хоть и хаотично.
5️⃣ Лучше писать документацию кратко, но понятно и сразу НОРМАЛЬНО - Вдохновение посетило, и начинается цивилизованный подход.
6️⃣ Пора структурировать и привести в порядок все написанное, а то "черт ногу сломит" - Ну, наконец-то, логика и порядок.
7️⃣ Разработка будет писать техническую и проектную документацию, а техническим писателям отдадим пользовательскую и сопровождение - это оптимально - На этом этапе команда наконец-то осознает, что разделение труда - это сила.
8️⃣ Документация - часть процесса разработки и часть поставки, и ее необходимо тестировать - Апогей эволюции. Понимание, что доки должны быть такими же качественными, как и сам продукт.
😅 Иногда между стадиями 2 и 5 приходит мысль "пора завести техписа" 🐩. Но, если осознанность не поднялась выше 3, то даже самый крутой технический писатель пойдет "во вред".
Если вы поднялись выше пункта 3 по шкале принятия документации как "неизбежного зла", то вам будет полезен вот этот плейлист.
🎥 Плей-лист с докладами Насти Граф - Настя собрала 4 своих доклада по управлению знаниями в единую серию. Редко можно встретить спикера, который из доклада в доклад работает с одной и той же темой, раскрывая ее на более глубоком уровне и объясняя особенности каждого "витка эволюции".
Надеюсь, что многим будет полезно что-то из ее докладов! А еще, ИМХО, эти принципы подходят не только для Confluence, но и для документирования API.
А какая стадия на пути к документации у вас? Делитесь в комментариях! 📚🛠️
#architecture #people_management
Сегодня хочу поговорить о вечной проблеме всех IT-команд - документации. Этот путь познания неизбежен и часто комичен, поэтому давайте разберем его стадии:
1️⃣ Доки не нужны - я все запомню - Знакомо? Это, наверное, первое заблуждение каждого новичка.
2️⃣ Кому надо - почитают комментарии - Ага, особенно те, кто обожает разгадывать чужие ребусы.
3️⃣ Комменты нужны +- понятные - Тут уже появляется первый лучик осознания.
4️⃣ Проще "хоть как-то" писать документацию, чем вообще не писать - Начало мудрости. Начинаем что-то делать, хоть и хаотично.
5️⃣ Лучше писать документацию кратко, но понятно и сразу НОРМАЛЬНО - Вдохновение посетило, и начинается цивилизованный подход.
6️⃣ Пора структурировать и привести в порядок все написанное, а то "черт ногу сломит" - Ну, наконец-то, логика и порядок.
7️⃣ Разработка будет писать техническую и проектную документацию, а техническим писателям отдадим пользовательскую и сопровождение - это оптимально - На этом этапе команда наконец-то осознает, что разделение труда - это сила.
8️⃣ Документация - часть процесса разработки и часть поставки, и ее необходимо тестировать - Апогей эволюции. Понимание, что доки должны быть такими же качественными, как и сам продукт.
😅 Иногда между стадиями 2 и 5 приходит мысль "пора завести техписа" 🐩. Но, если осознанность не поднялась выше 3, то даже самый крутой технический писатель пойдет "во вред".
Если вы поднялись выше пункта 3 по шкале принятия документации как "неизбежного зла", то вам будет полезен вот этот плейлист.
🎥 Плей-лист с докладами Насти Граф - Настя собрала 4 своих доклада по управлению знаниями в единую серию. Редко можно встретить спикера, который из доклада в доклад работает с одной и той же темой, раскрывая ее на более глубоком уровне и объясняя особенности каждого "витка эволюции".
Надеюсь, что многим будет полезно что-то из ее докладов! А еще, ИМХО, эти принципы подходят не только для Confluence, но и для документирования API.
А какая стадия на пути к документации у вас? Делитесь в комментариях! 📚🛠️
#architecture #people_management
👏9👍6
🔥 Как вам легче изучать новое? 🔥
Привет, друзья!
Вчера вечером мы с мужем затеяли интересную дискуссию о том, как нам удобнее получать новые знания. И вот что выяснилось:
✨ Мой подход:
Мне комфортнее сначала углубиться в теорию, а затем переходить к практике. Такой подход позволяет создать крепкую базу, на которую потом легко "наслаивать" конкретные примеры и кейсы.
✨ Подход Миши:
Миша же придерживается другого подхода: он любит сразу разбирать теорию на примерах. Начинает с простых задач и постепенно усложняет, таким образом глубже понимая предмет.
Но мы обсуждали про формат изучения, когда есть преподаватель. А какие еще есть способы изучения нового? Давайте разберем по пунктам:
1️⃣Групповое обучение 🧑🤝🧑:
Мастер-майнды, брейнштормы, хакатоны. Работая над задачей, вы изучаете предмет через взаимодействие с другими участниками.
2️⃣Самостоятельное обучение "по книгам" 📚:
Самообразование без привлечения кого-либо: книги, статьи, видео.
Думаю, что выбор подхода еще и связан с склонностью человека к теоретизации или ориентации на практику. Теоретики предпочитают сначала получить всю необходимую информацию, а потом уже применять ее на практике. Практики, наоборот, учатся через действия и на своих ошибках.
PSВ фильме "Опенгеймер" как раз наглядно показан подход "теоретиков" и "практиков".
И вот мой вопрос к вам: а как вам удобнее изучать новое? Делитесь своими подходами и мыслями в комментариях! 👇 Мне очень важен ваш ответ, так как начинаю готовить что-то новенькое и интересненькое!
#people_management
Привет, друзья!
Вчера вечером мы с мужем затеяли интересную дискуссию о том, как нам удобнее получать новые знания. И вот что выяснилось:
✨ Мой подход:
Мне комфортнее сначала углубиться в теорию, а затем переходить к практике. Такой подход позволяет создать крепкую базу, на которую потом легко "наслаивать" конкретные примеры и кейсы.
✨ Подход Миши:
Миша же придерживается другого подхода: он любит сразу разбирать теорию на примерах. Начинает с простых задач и постепенно усложняет, таким образом глубже понимая предмет.
Но мы обсуждали про формат изучения, когда есть преподаватель. А какие еще есть способы изучения нового? Давайте разберем по пунктам:
1️⃣Групповое обучение 🧑🤝🧑:
Мастер-майнды, брейнштормы, хакатоны. Работая над задачей, вы изучаете предмет через взаимодействие с другими участниками.
2️⃣Самостоятельное обучение "по книгам" 📚:
Самообразование без привлечения кого-либо: книги, статьи, видео.
Думаю, что выбор подхода еще и связан с склонностью человека к теоретизации или ориентации на практику. Теоретики предпочитают сначала получить всю необходимую информацию, а потом уже применять ее на практике. Практики, наоборот, учатся через действия и на своих ошибках.
PS
И вот мой вопрос к вам: а как вам удобнее изучать новое? Делитесь своими подходами и мыслями в комментариях! 👇 Мне очень важен ваш ответ, так как начинаю готовить что-то новенькое и интересненькое!
#people_management
🚀 Онбординг и ЛикБез - почему стоят рядом? 🚀
Сегодня хочу поговорить об онбординге нового сотрудника. Итак, кто же отвечает за успешное погружение новичка? Сразу скажу - не только HR! На самом деле, это совместная ответственность самого сотрудника и команды. HR, конечно, делают важную работу, развивая лояльность и соответствие культурным ценностям компании. Но конечная цель онбординга - это момент, когда новичок самостоятельно может решать задачи и руками 🤳, и мозгами 🧠. То есть не просто выполняя механические действия, но и понимая, что именно он делает и как.
Погружение новичка можно легко разделить на несколько направлений:
📈 процессы,
💻инженерные практики и технологии,
🗜 домен и его изучение.
И вот тут начинается самое интересное!
В последние годы я работаю в основном в финтех-домене, и у нас есть замечательная практика - ЛикБез (ликвидация безграмотности). Это небольшие встречи (не более чем на 1,5 часа), где "весело-задорно" рассказываем про основные особенности финтеха и объясняем основные термины. Например, рассказываем почему важен mcc код операции, чем PAN карты отличается от BIN и почему иногда работа с BIN(ами) напоминает область таролога 🔮, а не IT-шника. (Помните те случаи, когда карты МИР изначально выдавались на бины MasterCard? Да-да, веселье ещё то! )
Цель таких мероприятий - не рассказать всё, а погрузить человека в контекст домена. Создать "якоря" ⚓, за которые новичок сможет цепляться в работе, чтобы не пугаться "крыжей" ✖️ и "красненьких сальдо"💯. Уверена, что ликбез должен быть достаточно веселым, так как позитивные эмоции запоминаются намного лучше.
🌞 За это лето уже двое пришли ко мне на менторинг с запросом: расскажи "быстро и кратко" про финтех. Опыт ликбезов помог подготовить людей к собеседованиям и новой работе буквально за несколько часов. Нет, они не стали экспертами, но ушёл страх и появилось общее понимание предмета. А это уже не мало, особенно когда ты приходишь в новую для себя отрасль!
🤓 Практику ликбеза я сама когда-то почерпнула у коллег из одной финтех-компании. И для меня такой ликбез стал настоящей поддержкой и прекрасным базисом, на который я уже нанизывала новые знания.
А как у вас проходит онбординг? Используете ли вы какие-то специальные практики? Делитесь в комментариях! 👇
#people_management
Сегодня хочу поговорить об онбординге нового сотрудника. Итак, кто же отвечает за успешное погружение новичка? Сразу скажу - не только HR! На самом деле, это совместная ответственность самого сотрудника и команды. HR, конечно, делают важную работу, развивая лояльность и соответствие культурным ценностям компании. Но конечная цель онбординга - это момент, когда новичок самостоятельно может решать задачи и руками 🤳, и мозгами 🧠. То есть не просто выполняя механические действия, но и понимая, что именно он делает и как.
Погружение новичка можно легко разделить на несколько направлений:
💻инженерные практики и технологии,
И вот тут начинается самое интересное!
В последние годы я работаю в основном в финтех-домене, и у нас есть замечательная практика - ЛикБез (ликвидация безграмотности). Это небольшие встречи (не более чем на 1,5 часа), где "весело-задорно" рассказываем про основные особенности финтеха и объясняем основные термины. Например, рассказываем почему важен mcc код операции, чем PAN карты отличается от BIN и почему иногда работа с BIN(ами) напоминает область таролога 🔮, а не IT-шника. (
Цель таких мероприятий - не рассказать всё, а погрузить человека в контекст домена. Создать "якоря" ⚓, за которые новичок сможет цепляться в работе, чтобы не пугаться "крыжей" ✖️ и "красненьких сальдо"💯. Уверена, что ликбез должен быть достаточно веселым, так как позитивные эмоции запоминаются намного лучше.
🌞 За это лето уже двое пришли ко мне на менторинг с запросом: расскажи "быстро и кратко" про финтех. Опыт ликбезов помог подготовить людей к собеседованиям и новой работе буквально за несколько часов. Нет, они не стали экспертами, но ушёл страх и появилось общее понимание предмета. А это уже не мало, особенно когда ты приходишь в новую для себя отрасль!
🤓 Практику ликбеза я сама когда-то почерпнула у коллег из одной финтех-компании. И для меня такой ликбез стал настоящей поддержкой и прекрасным базисом, на который я уже нанизывала новые знания.
А как у вас проходит онбординг? Используете ли вы какие-то специальные практики? Делитесь в комментариях! 👇
#people_management
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥4👍1
🚀 Почему Self-Assessment — это базис онбординга! 🚀
Хочу еще немного поговорить об онбординге (начало вот тут) и сегодняшний пост о том, как self-assessment может стать основой для онбординга нового сотрудника и почему я считаю, что это одна из самых важных ретроспективных практик, которая помогает мне развиваться и становиться лучше как эксперту.
🤳Что такое Self-Assessment?
Self-assessment (самооценка) — это ретроспективный процесс, который позволяет выявить свои сильные и слабые стороны, а также области, требующие улучшения, путем анализа своих навыков, опыта и поведения. Это как личный аудит, только без налоговой инспекции и с кучей пользы!
Правила Проведения Self-Assessment
⏰Регулярность: Делайте самооценку регулярно, будь то раз в квартал или по мере необходимости.
📊Честность и объективность: Только факты, никаких "да я молодец, но мне просто не повезло".
🥉Конкретность: Оценивайте измеримые результаты.
✍️Анализ: Сравнивайте изменения на основе записей.
💬Обратная связь: Включайте результаты ревью, интервью и обратной связи от коллег и руководства.
Примеры Разделов для Self-Assessment
1️⃣Достижения и цели: Что вы достигли и какие цели перед вами стоят.
2️⃣Производительность: Как эффективно вы работаете и какие задачи выполняете.
3️⃣Навыки и компетенции: Какие навыки вы приобрели или улучшили.
4️⃣Коммуникация и сотрудничество: Как вы взаимодействуете с командой и коллегами.
5️⃣Развитие: Какие шаги вы предприняли для профессионального и личного роста.
6️⃣План на следующий период: Что вы планируете сделать в ближайшее время.
Когда Я обязательно ВНЕПЛАНОВО провожу Self-Assessment
🔚После завершения крупного проекта: Это помогает мне понять, что пошло хорошо, а что можно улучшить в следующий раз.
🍾Перед началом нового проекта: Чтобы определить, какие навыки и знания мне нужно подтянуть.
👨💻Во время карьерных изменений: Например, при переходе на новую должность или в новый отдел.
👁️После получения обратной связи: Чтобы учесть мнения коллег и руководства и сделать соответствующие выводы.
Self-Assessment помогает видеть не только свои успехи, но и области, требующие улучшения. Это позволяет:
🦾Развивать сильные стороны: Фокусироваться на том, что у меня уже хорошо получается, и делать это еще лучше.
📈Улучшать слабые стороны: Находить способы преодоления своих слабостей и превращать их в сильные стороны.
🎯Ставить реалистичные цели: Понимать, что я могу достичь в краткосрочной и долгосрочной перспективе.
🏋♀️Повышать производительность: Оптимизировать рабочие процессы и улучшать результаты.
Self-assessment может стать основой для онбординга нового сотрудника, потому что после первого self-assessment можно перестать гадать о целях и задачах сотрудника и сформировать их исходя из его собственной оценки и потребностей команды. Такой подход сразу базируется на принципе win-win: компания получает сотрудника, который знает, чего хочет и что может, а сотрудник получает четкие и реалистичные задачи, что приводит к лучшим результатам.
Self-assessment — мощный инструмент, который помогает мне не только развиваться как эксперту, но и делать процесс онбординга более эффективным. Ведь если я понимаю свои сильные и слабые стороны, я могу стать лучше.
#people_management
Хочу еще немного поговорить об онбординге (начало вот тут) и сегодняшний пост о том, как self-assessment может стать основой для онбординга нового сотрудника и почему я считаю, что это одна из самых важных ретроспективных практик, которая помогает мне развиваться и становиться лучше как эксперту.
🤳Что такое Self-Assessment?
Self-assessment (самооценка) — это ретроспективный процесс, который позволяет выявить свои сильные и слабые стороны, а также области, требующие улучшения, путем анализа своих навыков, опыта и поведения. Это как личный аудит, только без налоговой инспекции и с кучей пользы!
Правила Проведения Self-Assessment
⏰Регулярность: Делайте самооценку регулярно, будь то раз в квартал или по мере необходимости.
📊Честность и объективность: Только факты, никаких "да я молодец, но мне просто не повезло".
🥉Конкретность: Оценивайте измеримые результаты.
✍️Анализ: Сравнивайте изменения на основе записей.
💬Обратная связь: Включайте результаты ревью, интервью и обратной связи от коллег и руководства.
Примеры Разделов для Self-Assessment
1️⃣Достижения и цели: Что вы достигли и какие цели перед вами стоят.
2️⃣Производительность: Как эффективно вы работаете и какие задачи выполняете.
3️⃣Навыки и компетенции: Какие навыки вы приобрели или улучшили.
4️⃣Коммуникация и сотрудничество: Как вы взаимодействуете с командой и коллегами.
5️⃣Развитие: Какие шаги вы предприняли для профессионального и личного роста.
6️⃣План на следующий период: Что вы планируете сделать в ближайшее время.
Когда Я обязательно ВНЕПЛАНОВО провожу Self-Assessment
🔚После завершения крупного проекта: Это помогает мне понять, что пошло хорошо, а что можно улучшить в следующий раз.
🍾Перед началом нового проекта: Чтобы определить, какие навыки и знания мне нужно подтянуть.
👨💻Во время карьерных изменений: Например, при переходе на новую должность или в новый отдел.
👁️После получения обратной связи: Чтобы учесть мнения коллег и руководства и сделать соответствующие выводы.
Self-Assessment помогает видеть не только свои успехи, но и области, требующие улучшения. Это позволяет:
🦾Развивать сильные стороны: Фокусироваться на том, что у меня уже хорошо получается, и делать это еще лучше.
📈Улучшать слабые стороны: Находить способы преодоления своих слабостей и превращать их в сильные стороны.
🎯Ставить реалистичные цели: Понимать, что я могу достичь в краткосрочной и долгосрочной перспективе.
🏋♀️Повышать производительность: Оптимизировать рабочие процессы и улучшать результаты.
Self-assessment может стать основой для онбординга нового сотрудника, потому что после первого self-assessment можно перестать гадать о целях и задачах сотрудника и сформировать их исходя из его собственной оценки и потребностей команды. Такой подход сразу базируется на принципе win-win: компания получает сотрудника, который знает, чего хочет и что может, а сотрудник получает четкие и реалистичные задачи, что приводит к лучшим результатам.
Self-assessment — мощный инструмент, который помогает мне не только развиваться как эксперту, но и делать процесс онбординга более эффективным. Ведь если я понимаю свои сильные и слабые стороны, я могу стать лучше.
#people_management
Telegram
ITKatya: культурные паттерны в IT
🚀 Онбординг и ЛикБез - почему стоят рядом? 🚀
Сегодня хочу поговорить об онбординге нового сотрудника. Итак, кто же отвечает за успешное погружение новичка? Сразу скажу - не только HR! На самом деле, это совместная ответственность самого сотрудника и команды.…
Сегодня хочу поговорить об онбординге нового сотрудника. Итак, кто же отвечает за успешное погружение новичка? Сразу скажу - не только HR! На самом деле, это совместная ответственность самого сотрудника и команды.…
🔥4❤2
🎨 Кем я стану, когда вырасту? 👶
Многие мои знакомые, кто не работают в IT, уверены, что айтишники на 100% уверены в выборе своей профессии и вообще счастливчики, ведь они смогли войти в IT! Но вот моя практика показывает, что чаще всего с вопросом о карьере и "в кого вырасти" ко мне обращаются ребята с опытом 5-8 лет‼️ Работали в нескольких компаниях с громкими именами, занимают позиции не ниже мидла, а зачастую уже сеньоры или даже лиды/руководители подразделения. И тут начинается… скука🥱! Ощущение, что попробовал уже всё и везде, и хочется чего-то новенького, интересного, чтобы снова горели глаза. Но возникают вопросы: КУДА ИДТИ и КЕМ СТАТЬ?!
Недавно ко мне пришли ребята из стартапа Aidentity. Они разрабатывают сервис прогнозирования карьерного пути человека на основе личностных качеств, интересов и сильных сторон. Сейчас они собирают данные и анкетируют специалистов, чтобы сформировать модель для мэтчинга профилей людей, кто ищет себя, с профилями верифицированных специалистов.
Ребята рассказывают о себе так:
Если вы относите себя к таким людям, пройдите 5-минутную форму по ссылке: Форма для участия
Если вас заинтересует проект и вы найдете 5 минут для опроса – будет классно! А я была рада помочь ребятам и стать одним из "профиков" – спецтермин для тех, кто "не хочет выходить из IT"😇
✨ И напоминаю, что ко мне можно приходить по вопросу "в кого мне вырастать?" ✨
#people_management
Многие мои знакомые, кто не работают в IT, уверены, что айтишники на 100% уверены в выборе своей профессии и вообще счастливчики, ведь они смогли войти в IT! Но вот моя практика показывает, что чаще всего с вопросом о карьере и "в кого вырасти" ко мне обращаются ребята с опытом 5-8 лет‼️ Работали в нескольких компаниях с громкими именами, занимают позиции не ниже мидла, а зачастую уже сеньоры или даже лиды/руководители подразделения. И тут начинается… скука🥱! Ощущение, что попробовал уже всё и везде, и хочется чего-то новенького, интересного, чтобы снова горели глаза. Но возникают вопросы: КУДА ИДТИ и КЕМ СТАТЬ?!
Недавно ко мне пришли ребята из стартапа Aidentity. Они разрабатывают сервис прогнозирования карьерного пути человека на основе личностных качеств, интересов и сильных сторон. Сейчас они собирают данные и анкетируют специалистов, чтобы сформировать модель для мэтчинга профилей людей, кто ищет себя, с профилями верифицированных специалистов.
Ребята рассказывают о себе так:
Профориентационные тесты не научились на них отвечать, поэтому команда Aidentity создает сервис, который будет мэтчить ваши личностные качества с предлагаемыми возможностями на рынке. Они объединяют знания профессионалов о своей профессии с профилированием людей.
Для того чтобы сервис заработал и начал помогать людям находить себя, ребята ищут специалистов, кто определился со своей профессией и чувствует себя на своем месте.
Если вы относите себя к таким людям, пройдите 5-минутную форму по ссылке: Форма для участия
Если вас заинтересует проект и вы найдете 5 минут для опроса – будет классно! А я была рада помочь ребятам и стать одним из "профиков" – спецтермин для тех, кто "не хочет выходить из IT"
✨ И напоминаю, что ко мне можно приходить по вопросу "в кого мне вырастать?" ✨
#people_management
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Профориентация на личностных качествах для профессионалов
Приветствую!
На связи Aidentity — сервис прогнозирования карьерного пути человека на основе личностных качеств, интересов и сильных сторон человека.
Наша миссия — помочь как можно большему количеству людей получать удовольствие от своей работы и чувствовать…
На связи Aidentity — сервис прогнозирования карьерного пути человека на основе личностных качеств, интересов и сильных сторон человека.
Наша миссия — помочь как можно большему количеству людей получать удовольствие от своей работы и чувствовать…
👍10❤5🔥5
📚 Как не слушать умных советов и заболеть снова (но пост про книгу!) 📚
Знаете, неделю назад я загремела в больницу с высоченной температурой и пневмонией. 5 полных дней, 7 всего в больнице! Постоянные капельницы, уколы, упражнения от физиотерапевта, ингаляции, микстуры и таблетки, и вот меня выписали!
Конечно, как только меня начало "отпускать", я сразу взялась за работу (да, прямо из больницы)! Рекорд маразма - в руке две капельницы, на лице ингаляционная маска, рядом медсестра измеряет давление и температуру, а я в ноуте на совещании - обсуждаю пользовательские сценарии. 🤦♀️
Предсказуемые последствия? Во вторник выписали из больницы, к субботе снова температура и осложнение пневмонии - снова мокрота и клокотание! На второй раз я решила начать уже думать ГОЛОВОЙ🧠 и уползти на больничный (врач увидев меня, сразу выдала больничный на 2 недели)!
И пока я болею по второму кругу, мне попалась вот такая книга: "FOMO sapiens. Как избавиться от страха упущенных возможностей и начать принимать правильные решения" от Патрика Макгинниса. Она есть по подписке на литресе: ссылка.
📖 Книга объясняет частично и мое глупое поведение, и страхи поколений миллениалов и зумеров, и даже пользовательские привычки.
Книга рассказывает о FOMO (fear of missing out - страх упущенных возможностей) и FOBO (fear of better options - страх перед лучшими вариантами или страх выбора) страхах.
Мне особенно откликнулась часть про FOMO! И о том, что существует 2 вида FOMO:
🏆Амбициозный FOMO. В его основе лежит порожденное асимметрией информации ощущение, будто некая вещь или событие лучше, чем те, что уже есть в вашей жизни.
🐃Стадный FOMO. Он подпитывается стремлением быть своим в группе и настоятельной потребностью участвовать в том, чего вам, на ваш взгляд, не хватает.
💡 Автор предлагает стратегии выхода из FOMO:
🙏Благодарность. Важно вернуть фокус в свою жизнь. Что классного уже есть в твоей жизни?
🌏Реальность. Сохранять объективность и не действовать на эмоциях.
⚖️Альтернатива. Убирать асимметрию информации. Изучать, пользоваться разными источниками информации. Очень важный пункт, так как ИИ и мат модели все больше замыкают нас в рамках информационного пузыря в котором нам комфортно! Нам показывают те статьи, с которыми мы согласны; тех людей, которыми мы восхищаемся. Так появляется иллюзия того, что все вокруг, как ты!
🩺Фокус на своей реальной жизни, отношениях и целях.
💱Начать делать наоборот. Намеренно упускать что-то. Например, устраивать детоксы от соцсетей и событий.
Конечно же, кроме того, что я посмотрела под новым углом на ситуацию своей болезни, я еще и много размышляла о продукте, о пользователе. И тут книга потрясающе легла на статьи и интервью, которые я послушала про ребрендинг Сбера и Т-банка (а о них сейчас только ленивый не говорит).
Так что, мне книга зашла! Рекомендую!
NB! И, да, если вам врач сказал
- так и сделайте! Пневмония по второму кругу - несусветная ДИЧЬ! 😅
#books
Знаете, неделю назад я загремела в больницу с высоченной температурой и пневмонией. 5 полных дней, 7 всего в больнице! Постоянные капельницы, уколы, упражнения от физиотерапевта, ингаляции, микстуры и таблетки, и вот меня выписали!
Конечно, как только меня начало "отпускать", я сразу взялась за работу (да, прямо из больницы)! Рекорд маразма - в руке две капельницы, на лице ингаляционная маска, рядом медсестра измеряет давление и температуру, а я в ноуте на совещании - обсуждаю пользовательские сценарии. 🤦♀️
Предсказуемые последствия? Во вторник выписали из больницы, к субботе снова температура и осложнение пневмонии - снова мокрота и клокотание! На второй раз я решила начать уже думать ГОЛОВОЙ🧠 и уползти на больничный (врач увидев меня, сразу выдала больничный на 2 недели)!
И пока я болею по второму кругу, мне попалась вот такая книга: "FOMO sapiens. Как избавиться от страха упущенных возможностей и начать принимать правильные решения" от Патрика Макгинниса. Она есть по подписке на литресе: ссылка.
📖 Книга объясняет частично и мое глупое поведение, и страхи поколений миллениалов и зумеров, и даже пользовательские привычки.
Книга рассказывает о FOMO (fear of missing out - страх упущенных возможностей) и FOBO (fear of better options - страх перед лучшими вариантами или страх выбора) страхах.
Мне особенно откликнулась часть про FOMO! И о том, что существует 2 вида FOMO:
🏆Амбициозный FOMO. В его основе лежит порожденное асимметрией информации ощущение, будто некая вещь или событие лучше, чем те, что уже есть в вашей жизни.
🐃Стадный FOMO. Он подпитывается стремлением быть своим в группе и настоятельной потребностью участвовать в том, чего вам, на ваш взгляд, не хватает.
💡 Автор предлагает стратегии выхода из FOMO:
🙏Благодарность. Важно вернуть фокус в свою жизнь. Что классного уже есть в твоей жизни?
🌏Реальность. Сохранять объективность и не действовать на эмоциях.
⚖️Альтернатива. Убирать асимметрию информации. Изучать, пользоваться разными источниками информации. Очень важный пункт, так как ИИ и мат модели все больше замыкают нас в рамках информационного пузыря в котором нам комфортно! Нам показывают те статьи, с которыми мы согласны; тех людей, которыми мы восхищаемся. Так появляется иллюзия того, что все вокруг, как ты!
🩺Фокус на своей реальной жизни, отношениях и целях.
💱Начать делать наоборот. Намеренно упускать что-то. Например, устраивать детоксы от соцсетей и событий.
Конечно же, кроме того, что я посмотрела под новым углом на ситуацию своей болезни, я еще и много размышляла о продукте, о пользователе. И тут книга потрясающе легла на статьи и интервью, которые я послушала про ребрендинг Сбера и Т-банка (а о них сейчас только ленивый не говорит).
Так что, мне книга зашла! Рекомендую!
NB! И, да, если вам врач сказал
болеть и не рыпаться
- так и сделайте! Пневмония по второму кругу - несусветная ДИЧЬ! 😅
#books
Литрес
FOMO sapiens. Как избавиться от страха упущенных возможностей и начать принимать правильные решения — Патрик Макгиннис | Литрес
Представьте ситуацию. После утомительного рабочего дня вы листаете ленту социальных сетей. Видите фотографии с вечеринки, где отдыхают ваши друзья. Вас приглашали, но вы отказались, а теперь жалеете.…
🔥7❤6👍1
👨🦳Онбординг для старичков!👵
Несколько постов назад я рассказывала про онбординг, ликбез и self-assessment. А сегодня я нашла интересный доклад про онбординг для тех, кто уже давно работает в компании — “старичков”! 🤯 Если честно, до этого доклада я не задумывалась об очевидной теме, что онбордить и вовлекать нужно не только новеньких, но и любых сотрудников, которым предстоит погружение во что-то им неизвестное: новую команду, домен, продукт или позицию.
🌊 Старички тоже нуждаются в онбординге!
Увы, я не встречала практику корпоративного плавного погружения сотрудников в новые полномочия или проекты. Обычно со мной случался паттерн:вот тебе море — учись плавать, мы в тебя верим ! 🌊💪 Да и сама не могу сказать, что поддерживала сотрудников при внутренних переходах. Мало того, могу с большой долей уверенности сказать, что подобные практики не способствуют развитию поддержки в компании. Наоборот, после собственных страданий хочется сесть на бережку и понаблюдать, как барахтается следующий “неудачник”! А если и идешь протягивать руку помощи — то чувствуешь себя в этот момент ГЕРОЕМ! 🦸♀️ И это КОШМАРНО! Это же путь к “паучеству в банке”! 🕷️
И вот, собственно, ссылка на доклад
Может быть, вас он тоже приведет к мысли о том, что надо что-то менять в онбординге старичков! Ведь поддержка и плавное погружение в новые обязанности могут значительно улучшить качество работы и атмосферу в коллективе.
P.S. У Даши (автора доклада) есть канал со всякими полезняшками — ловите ссылку: @trainingwithMulyk.
#people_management
Несколько постов назад я рассказывала про онбординг, ликбез и self-assessment. А сегодня я нашла интересный доклад про онбординг для тех, кто уже давно работает в компании — “старичков”! 🤯 Если честно, до этого доклада я не задумывалась об очевидной теме, что онбордить и вовлекать нужно не только новеньких, но и любых сотрудников, которым предстоит погружение во что-то им неизвестное: новую команду, домен, продукт или позицию.
🌊 Старички тоже нуждаются в онбординге!
Увы, я не встречала практику корпоративного плавного погружения сотрудников в новые полномочия или проекты. Обычно со мной случался паттерн:
И вот, собственно, ссылка на доклад
Может быть, вас он тоже приведет к мысли о том, что надо что-то менять в онбординге старичков! Ведь поддержка и плавное погружение в новые обязанности могут значительно улучшить качество работы и атмосферу в коллективе.
P.S. У Даши (автора доклада) есть канал со всякими полезняшками — ловите ссылку: @trainingwithMulyk.
#people_management
❤4🔥4
👩🦱Миледи и 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