🔥 Как вам легче изучать новое? 🔥
Привет, друзья!
Вчера вечером мы с мужем затеяли интересную дискуссию о том, как нам удобнее получать новые знания. И вот что выяснилось:
✨ Мой подход:
Мне комфортнее сначала углубиться в теорию, а затем переходить к практике. Такой подход позволяет создать крепкую базу, на которую потом легко "наслаивать" конкретные примеры и кейсы.
✨ Подход Миши:
Миша же придерживается другого подхода: он любит сразу разбирать теорию на примерах. Начинает с простых задач и постепенно усложняет, таким образом глубже понимая предмет.
Но мы обсуждали про формат изучения, когда есть преподаватель. А какие еще есть способы изучения нового? Давайте разберем по пунктам:
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
🎨 CJM — для интеграционных кейсов! ✏️
Если вы слышали про Customer Journey Map (CJM), то, скорее всего, ассоциируете его с инструментом для продактов и маркетологов. Но, поверьте, CJM — это настоящая палочка-выручалочка 🪄, когда дело доходит до интеграции между платформой и потребителем, обсуждения и согласования интерфейсов.
Лет 5 назад я искала инструмент, который позволил бы прописать пошаговый сценарий интеграции (вызовов API) и одновременно показать, что происходит на стороне Мерчанта (потребителя) в UI. И тогда я нашла UXPressia — и это была любовь с первого клика!
Пост выглядит как реклама, но я не знаю, как объяснить проще и менее “продажным” языком, почему я очень люблю этот инструмент и рекомендую вам хотя бы на него посмотреть… 🤪
10 причин ПОЧЕМУ?
1️⃣ Наглядность и простота: Легкость создания и визуализации пользовательских путей. Не нужно мучиться с выравниванием блоков (как в Miro) или шрифтами. Это специализированный инструмент, который делает одно, но делает это хорошо! Вы можете сосредоточиться на логике, а не на “наведении красоты”.
2️⃣ Совместная работа: Возможность безлимитного расшаривания схем для просмотра (есть в самом дешевом тарифе).
3️⃣ Поддержка ролей и команд: Всё под контролем! Можно настроить права и доступы, развести всё по папкам. Это особенно важно в финтехе, где безопасность — не пустой звук.
4️⃣ Гибкость тарифов: В бесплатном тарифе 1 CJM — достаточно, чтобы попробовать и понять, насколько продукт подходит. Следующий тариф — $16 за пользователя в месяц (3 CJM на пользователя), а если нужен безлимит карт — всегда можно расширить до $36.
5️⃣ Доступность: UXPressia позволяет “рисовальщикам” творить, а “смотрителям” наслаждаться результатами. Обычно, рисующих специалистов меньше, чем тех, кто будет использовать и внедрять схемы. А значит, лицензий необходимо по числу “рисовальщиков”!
6️⃣ Экономия времени: Удобный интерфейс и множество шаблонов: блоки для иллюстраций, описания happy-path сценария и ветвлений, блоки заметок и т.п.
7️⃣ Поддержка сторонних сервисов: Легко можно встроить сторонние плагины и виджеты через код. Функция есть в стартовом (за $16) тарифе. Можно легко выставить ссылки на Swagger или “запихнуть” карту в портал разработчика.
8️⃣ Экспорт в основные форматы и доступ по ссылке: Доступ по ссылке или pdf — оптимальный вариант. Экспорт в ppt доступен в пакете PRO за $36.
9️⃣ Генерация пользовательских профилей через AI: Возможность заполнить профиль через AI без переключения на другие продукты (например, ChatGPT) и использование Ctrl+C — полезная-польза!
🔟 ImpactMap: Создавался для отображения влияния ветвлений карты на продукт, но легко превращается в наглядную схему отображения ветвлений интеграционных сценариев. А с кнопкой “PRESENTATION” можно красиво и пошагово показать весь интеграционный путь, что отлично подходит для презентаций с подрядчиками или топами компании.
Да, возможно, вы скажете, что это путь “забивания гвоздей микроскопом” 🔬, но более удобного продукта, чтобы показать интеграцию фронтов и бэков, да еще и разных команд/компаний, и чтобы без сложных матриц, схем и многостраничных документов — я не видела! Возможно, интеграционным командам просто не хватает своего понятного шаблона IJM (Integration Journey Map) — только сейчас задумалась, что, мб, его стоит “изобрести”🧐 ?!
А что вы используете, чтобы наглядно показать сценарии интеграции?
#toolkit #architecture
Если вы слышали про Customer Journey Map (CJM), то, скорее всего, ассоциируете его с инструментом для продактов и маркетологов. Но, поверьте, CJM — это настоящая палочка-выручалочка 🪄, когда дело доходит до интеграции между платформой и потребителем, обсуждения и согласования интерфейсов.
Лет 5 назад я искала инструмент, который позволил бы прописать пошаговый сценарий интеграции (вызовов API) и одновременно показать, что происходит на стороне Мерчанта (потребителя) в UI. И тогда я нашла UXPressia — и это была любовь с первого клика!
Пост выглядит как реклама, но я не знаю, как объяснить проще и менее “продажным” языком, почему я очень люблю этот инструмент и рекомендую вам хотя бы на него посмотреть… 🤪
10 причин ПОЧЕМУ?
1️⃣ Наглядность и простота: Легкость создания и визуализации пользовательских путей. Не нужно мучиться с выравниванием блоков (как в Miro) или шрифтами. Это специализированный инструмент, который делает одно, но делает это хорошо! Вы можете сосредоточиться на логике, а не на “наведении красоты”.
2️⃣ Совместная работа: Возможность безлимитного расшаривания схем для просмотра (есть в самом дешевом тарифе).
3️⃣ Поддержка ролей и команд: Всё под контролем! Можно настроить права и доступы, развести всё по папкам. Это особенно важно в финтехе, где безопасность — не пустой звук.
4️⃣ Гибкость тарифов: В бесплатном тарифе 1 CJM — достаточно, чтобы попробовать и понять, насколько продукт подходит. Следующий тариф — $16 за пользователя в месяц (3 CJM на пользователя), а если нужен безлимит карт — всегда можно расширить до $36.
5️⃣ Доступность: UXPressia позволяет “рисовальщикам” творить, а “смотрителям” наслаждаться результатами. Обычно, рисующих специалистов меньше, чем тех, кто будет использовать и внедрять схемы. А значит, лицензий необходимо по числу “рисовальщиков”!
6️⃣ Экономия времени: Удобный интерфейс и множество шаблонов: блоки для иллюстраций, описания happy-path сценария и ветвлений, блоки заметок и т.п.
7️⃣ Поддержка сторонних сервисов: Легко можно встроить сторонние плагины и виджеты через код. Функция есть в стартовом (за $16) тарифе. Можно легко выставить ссылки на Swagger или “запихнуть” карту в портал разработчика.
8️⃣ Экспорт в основные форматы и доступ по ссылке: Доступ по ссылке или pdf — оптимальный вариант. Экспорт в ppt доступен в пакете PRO за $36.
9️⃣ Генерация пользовательских профилей через AI: Возможность заполнить профиль через AI без переключения на другие продукты (например, ChatGPT) и использование Ctrl+C — полезная-польза!
🔟 ImpactMap: Создавался для отображения влияния ветвлений карты на продукт, но легко превращается в наглядную схему отображения ветвлений интеграционных сценариев. А с кнопкой “PRESENTATION” можно красиво и пошагово показать весь интеграционный путь, что отлично подходит для презентаций с подрядчиками или топами компании.
Да, возможно, вы скажете, что это путь “забивания гвоздей микроскопом” 🔬, но более удобного продукта, чтобы показать интеграцию фронтов и бэков, да еще и разных команд/компаний, и чтобы без сложных матриц, схем и многостраничных документов — я не видела! Возможно, интеграционным командам просто не хватает своего понятного шаблона IJM (Integration Journey Map) — только сейчас задумалась, что, мб, его стоит “изобрести”
А что вы используете, чтобы наглядно показать сценарии интеграции?
#toolkit #architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
Uxpressia
Customer Experience Mapping Platform | User Journey Management Software
Discover UXPressia's suite of customer experience tools and user journey mapping solutions. Create exceptional UX maps and personas online with our ultimate platform and management software trusted by Waters, Michelin, Accenture, Siemens, and others.
👍2❤1
🎞 Антон Бевзюк: "Инженерные практики"! (рекомендация к просмотру) 🫵
На этой неделе на канале Neogenda вышло потрясающее интервью с Антоном Бевзюком! Если вы не знакомы с Антоном, то я скажу просто: он классный!🧡 Я очень уважаю и безмерно люблю Тоху, он был ведущим на TechLead 2022 и представлял мой доклад. Эта поддержка была невероятной! И вот теперь я надеюсь, что на TL++ нам удастся поработать с Антоном, как с куратором.
Возвращаясь к видео… Антон сам сказал об интервью так:
Но, знаете, мне оно очень понравилось!
И вот почему:
Он говорит о базовых практиках разработки, но делает это с акцентом на том, как они приносят пользу бизнесу. Он мастерски объясняет, как продать эти идеи бизнесу, и почему разработчикам ничего не продать. 🤷♀️
Вот только несколько тем из видео:
1️⃣ Code Review – Важность этой практики и как ее правильно внедрять.
2️⃣ Test-Driven Development (TDD) – Почему 100% покрытие тестами — это не фантастика.
3️⃣ Mob Programming – Работа всей команды над одним кодом одновременно.
4️⃣ Pair Programming – Почему 100 строк, написанные вдвоем, ценнее 500, написанных по отдельности.
5️⃣ Рефакторинг – Самая ценная практика для здоровья вашего кода!
Антон подчеркивает, что инженерные практики ценны не только с технической точки зрения, но и с точки зрения бизнеса. Он учит нас видеть картину шире, объяснять выгоды бизнесу и понимать, как наши действия влияют на общую картину. Ведь важно не просто кодить, а понимать, зачем ты это делаешь.
Почему это “банальное” видео было для меня так полезно?
Такие видео, как это, помогают мне:
🤝 Проверить, одинаково ли я с другими понимаю ценность практик.
🧑🎓 Узнать что-то новое и интересное.
И вот оно, новое знание для меня — mob programming! Конечно, я сразу же побежала к Антону за той самой книжкой, а теперь делюсь ссылкой на нее с вами: Mob Programming by Leanpub.
💥 Спойлер:
Антон обещал, что на зимней конференции TL++ будет доклад от спикера, который уже несколько лет практикует mob programming. Я очень хочу попасть и послушать, а вы?
Рекомендую к просмотру! Если что-то зацепит — делитесь в комментариях! 🎬
#project_management
На этой неделе на канале Neogenda вышло потрясающее интервью с Антоном Бевзюком! Если вы не знакомы с Антоном, то я скажу просто: он классный!
Возвращаясь к видео… Антон сам сказал об интервью так:
“Казалось, я банальности там говорил!”
Но, знаете, мне оно очень понравилось!
И вот почему:
Он говорит о базовых практиках разработки, но делает это с акцентом на том, как они приносят пользу бизнесу. Он мастерски объясняет, как продать эти идеи бизнесу, и почему разработчикам ничего не продать. 🤷♀️
Вот только несколько тем из видео:
1️⃣ Code Review – Важность этой практики и как ее правильно внедрять.
2️⃣ Test-Driven Development (TDD) – Почему 100% покрытие тестами — это не фантастика.
3️⃣ Mob Programming – Работа всей команды над одним кодом одновременно.
4️⃣ Pair Programming – Почему 100 строк, написанные вдвоем, ценнее 500, написанных по отдельности.
5️⃣ Рефакторинг – Самая ценная практика для здоровья вашего кода!
Антон подчеркивает, что инженерные практики ценны не только с технической точки зрения, но и с точки зрения бизнеса. Он учит нас видеть картину шире, объяснять выгоды бизнесу и понимать, как наши действия влияют на общую картину. Ведь важно не просто кодить, а понимать, зачем ты это делаешь.
Почему это “банальное” видео было для меня так полезно?
Такие видео, как это, помогают мне:
И вот оно, новое знание для меня — mob programming! Конечно, я сразу же побежала к Антону за той самой книжкой, а теперь делюсь ссылкой на нее с вами: Mob Programming by Leanpub.
💥 Спойлер:
Рекомендую к просмотру! Если что-то зацепит — делитесь в комментариях! 🎬
#project_management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Парное программирование, Zero Bug Policy, Техдолг, Сode Review и беспощадный рефакторинг
Сегодня у нас в гостях Антон Бевзюк, Head of Engineering в компании Mindbox
00:00 Интро
00:49 Знакомство
01:50 Погоня за техническим совершенством решений не противоречит ли бизнес-целям компании?
03:18 Что инженерные практики (Agile) дают бизнесу?
08:53…
00:00 Интро
00:49 Знакомство
01:50 Погоня за техническим совершенством решений не противоречит ли бизнес-целям компании?
03:18 Что инженерные практики (Agile) дают бизнесу?
08:53…
🔥6👍3❤1
🌟 2ой MasterMind! 🌟
📍Сегодня пройдет мастер-майнд на тему риск-менеджмента и одного из рисков, который, к сожалению, часто забывают учесть: "выгорание". Тот самый который из-за болезни перенесся на месяц!!!
Чтобы встреча получилась продуктивной, приготовила вот такую задачу для участников:
Описание задачи:
Выявить риски системы, обеспечивающую проведение оплаты сборных заказов, включающих товары из нескольких магазинов. На текущий момент система должна поддерживать до 5 магазинов, с возможностью расширения до 10 магазинов в будущем. Следующим этапом развития системы может стать интеграция со сторонней программой лояльности, которая позволит накапливать и использовать баллы для частичной оплаты заказов.
Некоторые направления рисков для анализа с примерами:
1️⃣Функциональные риски:
- Некорректная обработка сборного заказа при участии нескольких магазинов.
- Ошибки при расчёте итоговой стоимости заказа.
2️⃣Технические риски:
- Неправильная интеграция с платежными системами.
- Проблемы с масштабируемостью системы при увеличении количества магазинов.
3️⃣Безопасность и защита данных:
- Уязвимости в защите персональных данных покупателей.
- Риски, связанные с обработкой и хранением платежной информации.
4️⃣Операционные риски:
Сбои в работе системы при высоких нагрузках.
Невозможность восстановления данных в случае аварийных ситуаций.
5️⃣Риски интеграции программы лояльности:
- Сложности с синхронизацией баллов между системой оплаты и программой лояльности.
- Неправильное начисление или списание баллов при оплате заказов.
Надеюсь, что за 2 часа мы сможем "раскрутить" кейс и выявить особо "опасные" моменты!
А о том как прошло - напишу уже вечером! 😊
#project_management
📍Сегодня пройдет мастер-майнд на тему риск-менеджмента и одного из рисков, который, к сожалению, часто забывают учесть: "выгорание". Тот самый который из-за болезни перенесся на месяц!!!
Чтобы встреча получилась продуктивной, приготовила вот такую задачу для участников:
Описание задачи:
Выявить риски системы, обеспечивающую проведение оплаты сборных заказов, включающих товары из нескольких магазинов. На текущий момент система должна поддерживать до 5 магазинов, с возможностью расширения до 10 магазинов в будущем. Следующим этапом развития системы может стать интеграция со сторонней программой лояльности, которая позволит накапливать и использовать баллы для частичной оплаты заказов.
Некоторые направления рисков для анализа с примерами:
1️⃣Функциональные риски:
- Некорректная обработка сборного заказа при участии нескольких магазинов.
- Ошибки при расчёте итоговой стоимости заказа.
2️⃣Технические риски:
- Неправильная интеграция с платежными системами.
- Проблемы с масштабируемостью системы при увеличении количества магазинов.
3️⃣Безопасность и защита данных:
- Уязвимости в защите персональных данных покупателей.
- Риски, связанные с обработкой и хранением платежной информации.
4️⃣Операционные риски:
Сбои в работе системы при высоких нагрузках.
Невозможность восстановления данных в случае аварийных ситуаций.
5️⃣Риски интеграции программы лояльности:
- Сложности с синхронизацией баллов между системой оплаты и программой лояльности.
- Неправильное начисление или списание баллов при оплате заказов.
Надеюсь, что за 2 часа мы сможем "раскрутить" кейс и выявить особо "опасные" моменты!
А о том как прошло - напишу уже вечером! 😊
#project_management
⚡2❤2
🫵Вчера прошел MasterMind!🫵
Спасибо всем кто пришел! Было бомбически!💥
И вместо моего поста про него ловите пос от участника!
Анонс следующего будет в ближайшее время!🗓
Спасибо всем кто пришел! Было бомбически!💥
И вместо моего поста про него ловите пос от участника!
Анонс следующего будет в ближайшее время!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from System Design World (Vladimir)
⭐️ Управление рисками by ITKatya.
👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).
💵 Недавно в её блоге был анонсирован Master Mind по управлению рисками в IT проектах. Тема меня заинтересовала так как в последнее время выступаю на архитектурных хакатонах. Понял, что прокачка в этой составляющей может дать дополнительные баллы)
📕 Встреча началась с небольшого куска теории. Где рассказывалось про негативные и позитивные(!) риски. Приведена собственная типизация:
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).
🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.
🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄
❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)
⏳ Говорили про бизнес, сроки. Что заранее невозможно всё просчитать. И с этим надо смириться 😌
🙋♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.
🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.
🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.
▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)
👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).
🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.
🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄
❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)
🙋♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.
🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.
🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.
▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍1
✨ Новый анонс— погружаемся в DDD и единый язык! ✨
Всем привет!
Хочу напомнить, что в этот четверг в 19-00 online у нас будет еще один вебинар, и я приглашаю вас присоединиться! 📅 Мы поговорим про Domain-Driven Design (DDD) и создание единого языка для команды и бизнеса.
Если вы были на прошлом вебинаре про бережливую архитектуру, то знаете, как круто у нас всё прошло! Атмосфера была потрясающая, и отзывы участников — только положительные. 🙌 Если пропустили, то не переживайте — у вас есть возможность наверстать!
📌 Дата: Этот четверг
📌 Тема: DDD: проектируем через создание единого языка
📌 Формат: Online, Бесплатно, но по записи
📌 Регистрация по ссылке: Записаться на вебинар
Вебинар будет полезен:
🏗 Архитекторам и лидам
👷 Менеджерам и аналитикам
🧱 Всем, кто пропагандирует DDD или хочет узнать больше
Я расскажу и покажу, как определять понятия и термины в вашем проекте таким образом, чтобы они были понятны и однозначны для всех участников команды!
Не упустите шанс углубить свои знания в DDD и создать тот самый единый язык, который объединит вашу команду и бизнес! 💬
Буду рада видеть вас на вебинаре!
#architecture
Всем привет!
Хочу напомнить, что в этот четверг в 19-00 online у нас будет еще один вебинар, и я приглашаю вас присоединиться! 📅 Мы поговорим про Domain-Driven Design (DDD) и создание единого языка для команды и бизнеса.
Если вы были на прошлом вебинаре про бережливую архитектуру, то знаете, как круто у нас всё прошло! Атмосфера была потрясающая, и отзывы участников — только положительные. 🙌 Если пропустили, то не переживайте — у вас есть возможность наверстать!
📌 Дата: Этот четверг
📌 Тема: DDD: проектируем через создание единого языка
📌 Формат: Online, Бесплатно, но по записи
📌 Регистрация по ссылке: Записаться на вебинар
Вебинар будет полезен:
🏗 Архитекторам и лидам
👷 Менеджерам и аналитикам
🧱 Всем, кто пропагандирует DDD или хочет узнать больше
Я расскажу и покажу, как определять понятия и термины в вашем проекте таким образом, чтобы они были понятны и однозначны для всех участников команды!
Не упустите шанс углубить свои знания в DDD и создать тот самый единый язык, который объединит вашу команду и бизнес! 💬
Буду рада видеть вас на вебинаре!
#architecture
systems.education
Бесплатный вебинар. DDD: проектируем через создание единого языка
Проектировать процессы на уровне небольших компонентов, что поможет повысить модульность и масштабируемость
👍5❤2