Я тут внезапно решила заболеть, не то чтоб решила, но заболела на все 💯

Температура под 39, кашель и все болит…

Поэтому подвыпала ото всюду и даже MasterMind, который должен был быт вчера отменила! Спасибо всем, что поняли ситуацию и не обижаетесь!

А пока болею, ловите очень классный лонгрид про риски, тревожность и как с этим жить! Не со всеми поинтами согласна, но проверять каждые 5 минут телефон-это привычка от которой очень сложно отделаться!

Ведь единственное в чем ты уверен всегда: нет такой системы, которую НЕЛЬЗЯ УРОНИТЬ!

PS: Лучики здоровья и поддержки тоже принимаю. Так паршиво не было с covid! Но тесты на грипп и корону-отрицательные 😤

Больница-больницей, но я ж как «нормальный блогер» пишу посты заранее, поэтому сегодня пост про справочники и классификаторы

PS: впервые с воскресенья родные 36,4

⤵️ ловите пост

🌟 Интересный факт про валюты и коды 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, и из Общероссийского классификатора валют, но продолжает использоваться для нумерации банковских счетов (в некоторых банках, ну не рефачить же, право слово)!

Вот так и живем: счет RUR с балансом 100 RUB! 💸

Интересно, правда? А вы знали об этом? 😊

#fintech #architecture

Мое главное достижение дня!

Даже НЕДЕЛИ!

А чего достиг ТЫ? 🤣

PS Надеюсь на выписку в начале недели!

#mylife

📄 Documentation 📄

Сегодня хочу поговорить о вечной проблеме всех IT-команд - документации. Этот путь познания неизбежен и часто комичен, поэтому давайте разберем его стадии:

1️⃣ Доки не нужны - я все запомню - Знакомо? Это, наверное, первое заблуждение каждого новичка.
2️⃣ Кому надо - почитают комментарии - Ага, особенно те, кто обожает разгадывать чужие ребусы.
3️⃣ Комменты нужны +- понятные - Тут уже появляется первый лучик осознания.
4️⃣ Проще "хоть как-то" писать документацию, чем вообще не писать - Начало мудрости. Начинаем что-то делать, хоть и хаотично.
5️⃣ Лучше писать документацию кратко, но понятно и сразу НОРМАЛЬНО - Вдохновение посетило, и начинается цивилизованный подход.
6️⃣ Пора структурировать и привести в порядок все написанное, а то "черт ногу сломит" - Ну, наконец-то, логика и порядок.
7️⃣ Разработка будет писать техническую и проектную документацию, а техническим писателям отдадим пользовательскую и сопровождение - это оптимально - На этом этапе команда наконец-то осознает, что разделение труда - это сила.
8️⃣ Документация - часть процесса разработки и часть поставки, и ее необходимо тестировать - Апогей эволюции. Понимание, что доки должны быть такими же качественными, как и сам продукт.

😅 Иногда между стадиями 2 и 5 приходит мысль "пора завести техписа" 🐩. Но, если осознанность не поднялась выше 3, то даже самый крутой технический писатель пойдет "во вред".
Если вы поднялись выше пункта 3 по шкале принятия документации как "неизбежного зла", то вам будет полезен вот этот плейлист.

🎥 Плей-лист с докладами Насти Граф - Настя собрала 4 своих доклада по управлению знаниями в единую серию. Редко можно встретить спикера, который из доклада в доклад работает с одной и той же темой, раскрывая ее на более глубоком уровне и объясняя особенности каждого "витка эволюции".

Надеюсь, что многим будет полезно что-то из ее докладов! А еще, ИМХО, эти принципы подходят не только для Confluence, но и для документирования API.

А какая стадия на пути к документации у вас? Делитесь в комментариях! 📚🛠️

#architecture #people_management

🔥 Как вам легче изучать новое? 🔥

Привет, друзья!

Вчера вечером мы с мужем затеяли интересную дискуссию о том, как нам удобнее получать новые знания. И вот что выяснилось:
✨ Мой подход:
Мне комфортнее сначала углубиться в теорию, а затем переходить к практике. Такой подход позволяет создать крепкую базу, на которую потом легко "наслаивать" конкретные примеры и кейсы.
✨ Подход Миши:
Миша же придерживается другого подхода: он любит сразу разбирать теорию на примерах. Начинает с простых задач и постепенно усложняет, таким образом глубже понимая предмет.

Но мы обсуждали про формат изучения, когда есть преподаватель. А какие еще есть способы изучения нового? Давайте разберем по пунктам:
1️⃣Групповое обучение 🧑‍🤝‍🧑:
Мастер-майнды, брейнштормы, хакатоны. Работая над задачей, вы изучаете предмет через взаимодействие с другими участниками.
2️⃣Самостоятельное обучение "по книгам" 📚:
Самообразование без привлечения кого-либо: книги, статьи, видео.

Думаю, что выбор подхода еще и связан с склонностью человека к теоретизации или ориентации на практику. Теоретики предпочитают сначала получить всю необходимую информацию, а потом уже применять ее на практике. Практики, наоборот, учатся через действия и на своих ошибках.

PS В фильме "Опенгеймер" как раз наглядно показан подход "теоретиков" и "практиков".

И вот мой вопрос к вам: а как вам удобнее изучать новое? Делитесь своими подходами и мыслями в комментариях! 👇 Мне очень важен ваш ответ, так как начинаю готовить что-то новенькое и интересненькое!

#people_management

🚀 Почему 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

📚 Как не слушать умных советов и заболеть снова (но пост про книгу!) 📚

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

Конечно, как только меня начало "отпускать", я сразу взялась за работу (да, прямо из больницы)! Рекорд маразма - в руке две капельницы, на лице ингаляционная маска, рядом медсестра измеряет давление и температуру, а я в ноуте на совещании - обсуждаю пользовательские сценарии. 🤦‍♀️

Предсказуемые последствия? Во вторник выписали из больницы, к субботе снова температура и осложнение пневмонии - снова мокрота и клокотание! На второй раз я решила начать уже думать ГОЛОВОЙ🧠 и уползти на больничный (врач увидев меня, сразу выдала больничный на 2 недели)!

И пока я болею по второму кругу, мне попалась вот такая книга: "FOMO sapiens. Как избавиться от страха упущенных возможностей и начать принимать правильные решения" от Патрика Макгинниса. Она есть по подписке на литресе: ссылка.

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

Книга рассказывает о FOMO (fear of missing out - страх упущенных возможностей) и FOBO (fear of better options - страх перед лучшими вариантами или страх выбора) страхах.

Мне особенно откликнулась часть про FOMO! И о том, что существует 2 вида FOMO:
🏆Амбициозный FOMO. В его основе лежит порожденное асимметрией информации ощущение, будто некая вещь или событие лучше, чем те, что уже есть в вашей жизни.
🐃Стадный FOMO. Он подпитывается стремлением быть своим в группе и настоятельной потребностью участвовать в том, чего вам, на ваш взгляд, не хватает.

💡 Автор предлагает стратегии выхода из FOMO:
🙏Благодарность. Важно вернуть фокус в свою жизнь. Что классного уже есть в твоей жизни?
🌏Реальность. Сохранять объективность и не действовать на эмоциях.
⚖️Альтернатива. Убирать асимметрию информации. Изучать, пользоваться разными источниками информации. Очень важный пункт, так как ИИ и мат модели все больше замыкают нас в рамках информационного пузыря в котором нам комфортно! Нам показывают те статьи, с которыми мы согласны; тех людей, которыми мы восхищаемся. Так появляется иллюзия того, что все вокруг, как ты!
🩺Фокус на своей реальной жизни, отношениях и целях.
💱Начать делать наоборот. Намеренно упускать что-то. Например, устраивать детоксы от соцсетей и событий.

Конечно же, кроме того, что я посмотрела под новым углом на ситуацию своей болезни, я еще и много размышляла о продукте, о пользователе. И тут книга потрясающе легла на статьи и интервью, которые я послушала про ребрендинг Сбера и Т-банка (а о них сейчас только ленивый не говорит).

Так что, мне книга зашла! Рекомендую!

NB! И, да, если вам врач сказал

болеть и не рыпаться

- так и сделайте! Пневмония по второму кругу - несусветная ДИЧЬ! 😅

#books

👨‍🦳Онбординг для старичков!👵

Несколько постов назад я рассказывала про онбординг, ликбез и self-assessment. А сегодня я нашла интересный доклад про онбординг для тех, кто уже давно работает в компании — “старичков”! 🤯 Если честно, до этого доклада я не задумывалась об очевидной теме, что онбордить и вовлекать нужно не только новеньких, но и любых сотрудников, которым предстоит погружение во что-то им неизвестное: новую команду, домен, продукт или позицию.

🌊 Старички тоже нуждаются в онбординге!

Увы, я не встречала практику корпоративного плавного погружения сотрудников в новые полномочия или проекты. Обычно со мной случался паттерн: вот тебе море — учись плавать, мы в тебя верим! 🌊💪 Да и сама не могу сказать, что поддерживала сотрудников при внутренних переходах. Мало того, могу с большой долей уверенности сказать, что подобные практики не способствуют развитию поддержки в компании. Наоборот, после собственных страданий хочется сесть на бережку и понаблюдать, как барахтается следующий “неудачник”! А если и идешь протягивать руку помощи — то чувствуешь себя в этот момент ГЕРОЕМ! 🦸‍♀️ И это КОШМАРНО! Это же путь к “паучеству в банке”! 🕷️

И вот, собственно, ссылка на доклад

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

P.S. У Даши (автора доклада) есть канал со всякими полезняшками — ловите ссылку: @trainingwithMulyk.

#people_management

Еще 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