ITKatya: культурные паттерны в IT
1.73K subscribers
366 photos
32 videos
17 files
298 links
Я - Катя Лысенко. Техлид/Техменеджер с 15+ летним опытом в сферах fintech, e-grocery, и TIS.
Знаю как «сработать» IT команды и биздев, делюсь практическим опытом в финтехе - менторю, провожу мастер-классы и обучения.
Для сотрудничества @eslysenko
Download Telegram
🔥 Фестиваль "Рупор лида 2" завершен – и я хочу рассказать, что это было для меня 🔥

Вот и все! 6 дней, 6 спикеров, 500+ участников. Обсуждения, споры, инсайты, новые знакомства и множество сообщений в чате. И я, если честно, немного опустошена, но бесконечно счастлива.

Когда ты организуешь мероприятие, в голове постоянно звучит одно: а получится ли? а зайдет ли тема? а успеем ли мы всё подготовить? а вдруг будет скучно? а вдруг никто не придёт?

Но в какой-то момент ты заходишь в чат, смотришь на дискуссии, вовлеченность, эмоции, благодарности – и понимаешь, что да, оно того стоило.

Почему именно выгорание?
Когда я выбирала тему фестиваля, я чувствовала, что она важна. Но я не думала, что она настолько ВАЖНА.
Выгорание – это не просто усталость. Это про встречу со своим личным ДЕМЕНТОРОМ!
И это касается не только лидов, но и всех, кто сталкивается с постоянной нагрузкой, дедлайнами, сложными решениями и ожиданиями, которые висят над тобой, как облако грозы.

Что для меня было особенно ценным?
🔥 Наши спикеры – я бесконечно благодарна каждому, кто откликнулся, кто пришел и делился своей экспертизой. Без вас этот фестиваль не был бы таким крутым!
🔥 Ваши вопросы, обсуждения, несогласие, поддержка – я читала чат и понимала, насколько важно, что все это происходит!

А теперь, самая честная исповедь организатора:
Организовать даже on-line мероприятие на 500+ человек очень волнительно, а значит эмоционально СЛОЖНО!

Но, завтра я "воскресну" и начну планировать и готовиться к следующим мероприятиям!

Так что до встречи на следующей неделе!
14👍4🔥4
📚 Документация: продукт, проект или просто боль?

Существует несколько подходов к ведению документации, и чаще всего их приходится комбинировать. Но главное — понимать: документация не высечена в камне, она меняется вместе с продуктом. Почему же так сложно выстроить грамотную систему работы с ней? Давайте разберемся!

🔹 Продуктовый подход:
фиксируем суть
Этот вариант документации описывает сам продукт, его ценность и ключевые особенности:
— Для кого он создается?
— Какие у него основные функции?
— Какие есть конкурентные преимущества?

По сути, это основа, которая важна на старте, но и дальше должна обновляться. Мы же не говорим, что код нельзя менять? Почему тогда документация должна оставаться статичной?

🔹 Проектный подход: все в одном месте (но на время существования места)
Документирование вокруг конкретных проектов удобно, когда нужно зафиксировать, как происходят изменения. Например:
— Добавляется новая система лояльности к уже существующей.
— Расширяется платежная система, добавляется новый способ оплаты.

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

Можно ли сочетать продуктовый и проектный подход? Да, например, создавая кросс-документацию:
✔️В базе знаний остаются продуктовые страницы где поддерживается описание работы продукта в текущий момент.
✔️ Внутри — ссылки на проекты с изменениями, где описано, как они повлияли на систему.
Но здесь важно задать структуру заранее, иначе очень быстро получится каша.

🔹 Документация пост-фактум: инциденты, разборы, ошибки
Почему-то многие считают, что документация — это только про запланированное. Но часто ценные знания появляются после проблем:
📌 Инцидент случился? Фиксируем, что пошло не так и как этого избежать.
📌 Провели пост-мортем? Добавляем информацию в базу знаний, а не оставляем в разрозненных отчетах.
📌 Обнаружили ошибку в логике продукта? Обновляем документацию, а не просто исправляем код.

Без этого документация превращается в музей устаревших артефактов, а ошибки повторяются снова и снова.

🔹 Документация для R&D и исследовательских задач
А вот еще одна проблема — считать, что документация нужна только тому, что уходит в прод. Но ведь исследования, тестирования и проработки концепций тоже требуют фиксации:
📌 Разбираетесь, какие данные можно передавать в API? Запишите.
📌 Исследуете, как новая система интегрируется с вашей? Сделайте описание.
📌 Проверяете, как реагирует сервис на нестандартные запросы? Это тоже часть документации!

Когда подобные вещи фиксируются не в голове и не в разрозненных тасках в Jira, а в удобном формате, они превращаются в ценный источник информации для всей команды.

🔹 Кто отвечает за документацию?
Есть ощущение, что компании осознали:
✔️ Нужны DevOps-инженеры для инфраструктуры.
✔️ Нужны архитекторы, чтобы проектировать систему.
✔️ Нужны админы, чтобы все работало.

Но когда речь заходит про документацию — вдруг оказывается, что ей никто не должен заниматься системно. 🤷‍♀️

В итоге:
— Вся документация хранится в голове у «того самого Васи».
— База знаний — это просто свалка документов без структуры.
— Новый человек тратит месяцы, чтобы разобраться, что вообще происходит.


Кто должен заниматься документацией?
📌 Knowledge-менеджеры — это такие же важные люди, как и архитекторы, если вы строите продукт = база знаний.
📌 Технические писатели — если компания осознает важность удобной и актуальной документации, и готова тратить время на ее поддержку и актуализацию.

📌 Итог: документируете или просто пишете заметки?
Если у вас нет структуры и процессов работы с документацией, то это не база знаний, а просто записи “на память”.

🚀 Подумайте:
✔️ Как у вас сейчас ведется документация?
✔️ Кто отвечает за базу знаний?
✔️ Можно ли по ней легко найти нужную информацию?


А может, у вас все еще действует принцип «спроси у Васи»? 😏

#architecture #project_management
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍42😁1
📚 ГОСТ или нет? А что, если это справочник?

Вчера мы говорили про подходы к документации в компаниях. И под постом всплыл закономерный комментарий: «Зачем придумывать что-то новое, если есть ГОСТ?»

С одной стороны, да, ГОСТ — рабочая штука. Но рабочая ли она везде?

Давайте будем честны ГОСТ, а чаще (в срезе документации) это именно ЕСКД, ЕСПД — это подходы, которые разработали около 50 лет назад, когда ритм разработки был совершенно другим. Сегодня мы живем в мире, где:
✔️ Продукты обновляются быстрее.
✔️ Требуется постоянная актуализация данных.
✔️ Документация не может быть зацементированной.

📌 И тут ГОСТ начинает нас ограничивать. Он хорош, когда нужно сдать проект или запаковать документацию под поставку железа. Но в динамично развивающемся ПО — вызывает вопросы. А главное, если предлагать разработчикам писать документацию по ГОСТу, они взвоют и начнут прятаться.

Но окей, с этим более-менее разобрались. А что делать экспертам, которые хотят передать знания?

В компаниях хотя бы понятны правила игры: продуктовая документация, база знаний, регламенты. А если ты сам по себе и хочешь написать что-то полезное для других?

Например, мы с Мишей сейчас работаем над справочником по финтеху. И столкнулись с двумя большими проблемами:
1️⃣ Как передавать знания, если читатель не может задать уточняющие вопросы?
Когда ты консультируешь, всегда есть диалог. Но в справочнике нет места вопросам. Значит, надо формулировать материал так, чтобы он был однозначно понятен и применим.
2️⃣ Как структурировать накопленные знания, если они изначально записывались "для себя"?
Если у вас когда-нибудь была папка с заметками, в которой вроде бы есть ВСЁ, но ничего нельзя найти — вы понимаете боль. 🤯

В корпоративных базах знаний эту проблему решают knowledge-менеджеры. Но когда ты делаешь личный справочник, ты остаешься один на один с хаосом своих мыслей.

И тут спасибо компании ОНТИКО за наше счастливое детство 😂: я осознала, что сама с этим не справлюсь и пошла к ПК KnowledgeConf — ребятам, которые как раз занимаются систематизацией знаний.

🔔 Уже в эту пятницу в 18:00 (МСК)
мы стартуем, возможно, целую серию встреч, где будем разбираться:
✔️ Как экспертам правильно выстраивать личные базы знаний?
✔️ Как систематизировать контент, чтобы его можно было использовать вне контекста создателя?
✔️ С чего вообще начинать, если хочется написать свой справочник?

Если вам это важно и интересно — welcome, присоединяйтесь! 📝

❗️PS Ссылка на эфир будет за час до мероприятия. Встреча будет в GoogleMeet.
👍9🔥5
И напоминаю, что сегодня в 19-00 по МСК уже будет эфир!
Регистрация через ботика, участие бесплатное!

Приходите холиварить, а еще поддержать меня на первом в моей жизни выступлении в стиле TED :)
2
🤔 Запутались в проекте? Не знаете, с чего начать?

Даже опытные тимлиды сталкиваются с трудностями оценки эффективности своих решений. Три простых вопроса помогут вам структурировать мышление и принимать более эффективные решения, от мелких баг-фиксов до глобальных стратегий!

Обсудим эту и другие сложности вместе с Екатериной Лысенко, TechProduct с 15+ летним опытом в fintech, e-grocery и TIS, автором телеграм-канала «ITKatya: культурные паттерны в IT», на нашем митапе 26 февраля!

Тема: Подход от ценностей или как не предать себя (и свой продукт)»!

➡️ Регистрируйтесь по ссылке!
👍31
💸 Почему баллы, а не рубли? Разбираем секреты программ лояльности!

Недавно ко мне пришли за консультацией по вопросу реализации программ лояльности. И основной вопрос звучал так:
Почему компании используют баллы в программах лояльности, а не валюту (рубли, например)? Ведь рубли понятнее и привычнее. Почему не дают пользователям рубли, которые можно потратить, только определенным способом?


Давайте разбираться в начислении лояльности и что за этим скрыто бизнесово:
🔹 Двойная конвертация — это гибкость и выгода
Вот как это работает:
💵 Рубли в баллы: потратили 100 рублей — получили 10 баллов.
💱 Баллы в рубли: накопили 100 баллов — получили 500 рублей скидки.
Эти курсы можно легко настроить под стратегию компании.
Хотите простимулировать определенных клиентов?
Добавьте уровни лояльности, где измените курсы конвертаций по уровням: — на первом уровне 100 рублей = 10 баллов;
— на втором 100 рублей = 15 баллов;
— и так далее....

🔹 Баллы = фантики, а не деньги
Баллы не считаются реальными деньгами. Это значит:
1️⃣ Компания не обязана получать банковскую лицензию для хранения этих «средств». А это очень большая экономия и СИЛЬНО МЕНЬШЕ ПРОБЛЕМ!
2️⃣ Баллы можно «протухать» (устанавливать срок действия), чтобы стимулировать клиентов использовать их быстрее.

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

🔹 Персонализация и мотивация клиентов

С помощью системы уровней и изменяемых курсов компания может мотивировать пользователей тратить больше. И тут не обязательно играть с курсами получения баллов, но и просто "докинуть" клиенту "фантиков" 🎉, например в честь Дня рождения клиента или Компании!

🔹 Кэшбек - просто, но не очень выгодно! (особенно, если вы маленький мерчант)
Кэшбек — это удобно и понятно: клиенту возвращаются рублики на карту после покупки. Просто, приятно, и главное — клиенты любят это. Но вот нюанс: полученные деньги клиент может потратить где угодно, а не обязательно у вас.
Для крупных сетей магазинов с активными покупателями это работает отлично. Например: возврат 10% кэшбеком становится аналогом скидки, которая "зарабатывается" только через покупку, помогая привлекать и удерживать клиентов.
Но если вы маленький магазин или ваши клиенты совершают покупки раз в год, как в случае со спортивным инвентарем, важно проверить, выгодно ли такое решение с точки зрения экономики. Иногда кэшбек может не окупиться.

🔹 Купоны: проще, но будьте осторожны!
Если вам нужно раздать условные «500 рублей» 🎟 на покупку, правильнее сделать это в формате купона со сроком действия. Купон = скидка, а не деньги, и это юридически безопаснее.
НО❗️ Однако важно помнить, что купоны — это фрод, поэтому: привязывайте купоны сразу к личному кабинету клиента или создайте нормальную систему защиты от мошенничества, иначе рискуете разориться.

💡 Итог:
— Баллы дают больше гибкости и свободы для настройки программы лояльности.
— Курс обмена и уровни можно легко адаптировать для разных сегментов клиентов.
— Лояльность на «фантиках» безопаснее и выгоднее, чем работа с реальными деньгами.

💬Так что это пост про базовые вещи из системы лояльности со стороны финтех взгляда. Если есть вопросы по лояльности или хотите поделиться интересным схемами лояльности - welcome в комменты!

‼️PS где-то тут «красной нитью» проходит мысль, что поста могло бы не быть, если бы был справочник, но для этого нужно понимать подход, а это мы будем обсуждать только завтра на круглом столе! Информация про круглый стол ➡️ тут

#architecture #fintech
Please open Telegram to view this post
VIEW IN TELEGRAM
👍82
Как делиться знаниями, не прилагая себя в комплекте? 📚

Ох, что же сегодня будет… Мы собираемся обсудить вопрос, который волнует всех экспертов, кто хоть раз пытался передавать знания!

📌 Как структурировать информацию так, чтобы она была полезна без личного участия?
📌 Как превратить свою «сокровищницу знаний» в работающий инструмент?
📌 Как не превращать передачу опыта в личный саппорт 24/7?

И самое главное – это будет не просто «четыре дамы вечерком знаний ресерч вели за чайком» 🍵, а живая дискуссия, куда можете подключиться и вы!

💡 Формат:
🔹 Обсуждаем, как работать с экспертизой и знаниями.
🔹 Разбираем примеры и сложности.
🔹 Я – лабораторная мышка 🐭, которая уже идет по этому пути (если сами пока не решаетесь, можно посмотреть на мои ошибки 😆).
🔹 Отвечаем на ваши вопросы!

Когда? Сегодня в 18:00 (МСК) в Google Meet.
🔗 Ссылку пришлю за час до начала.

Если у вас уже есть вопросы – кидайте сюда!

А пока, если пропустили, вот подробности 👉 ПОСТ.
This media is not supported in your browser
VIEW IN TELEGRAM
Сегодня все ушли на КАРНАВАЛ!!!

В Лимассоле гранд-парад! Главный городской праздник! И это было офигенно!!!

Делюсь с вами кусочком дня!
14🤩7🦄7
🤢 Когда душил "тараканов", а они стали сильнее! 🐞

Я как-то писала пост про борьбу с неизбежным... Но иногда, ты борешься-борешься, а в итоге тебя настигает эффект пестицида. 🤦‍♀️

Эффект пестицида — это явление, при котором со временем применение пестицидов становится менее эффективным из-за адаптации вредителей.

В биологии это означает, что чем больше мы травим вредителей, тем лучше они адаптируются. В проектировании (разработке) все аналогично: если долгое время использовать одни и те же подходы без адаптации, то они перестают решать реальные проблемы и создают новые.

У эффекта пестицида есть 4 механизма, которые приближают сам эффект.

🦠 Развитие устойчивости
Архитектурные паттерны, которые раньше работали, больше не приносят пользы.
Решили, что микросервисы – это круто, и спроектировали систему на их основе. Первые пару лет все отлично, но со временем оказывается, что зависимости между сервисами усложнились, а сопровождать стало дороже, чем монолит.

Что делать?
- Регулярно пересматривать архитектурные решения, а не следовать трендам.
- Оценивать границы применимости паттернов (что хорошо для одного проекта, может сломать другой).
- Закладывать гибкость в архитектуру вместо слепого следования модным подходам (да, про бережливое проектирование).

🌍 Нарушение экосистемного баланса
Фокусируясь на одной части системы, мы создаем проблемы в другой
Добавили кэшированную базу, в которую льются данные из баз в разных ДЦ. Получили единство данных... Но внезапно выяснилось, что теперь сервис ведет себя непредсказуемо из-за несогласованности данных между кэшем и основной БД.

Что делать?
- Принимать архитектурные решения системно, а не точечно.
- Оценивать потенциальные побочные эффекты изменений.
- Всегда задавать вопрос: «А что может сломаться?»

🔄 Эффект возврата
Рефакторинг вместо улучшения возвращает старые проблемы.
Когда-то приняли решение разделить модули системы на независимые сервисы, но спустя пару лет решили «упростить» поддержку и свести все обратно в монолит, но без этапа реинжениринга. В результате возвращаемся к тем же проблемам, которые изначально пытались решить.

Что делать?
- Фиксировать причины архитектурных решений (ADR).
- Помнить, что нет универсальных решений – любое проектное решение имеет trade-offs.

⚠️ Необходимость усиленной обработки
Чем больше усложняем архитектуру, тем сложнее ее поддерживать.
Решили использовать слоистую архитектуру и строго разграничили уровни. Все красиво! Но теперь каждая правка требует изменения на нужных уровнях… А еще нужны разработчики, которые из этого не сделают "болотце"!

Что делать?
- Оценивать реальную стоимость усложнения архитектуры.
- Балансировать между гибкостью и простотой.
- Не вводить паттерны, если они не решают конкретную проблему.
- Не вводить паттерны, которые не соразмерны навыкам команды.

Мораль (какая-то дурацкая): думай и думай в разных направлениях :)

И знаете, маленькое признание: я очень боюсь оказаться в ситуации, когда сама ВЫРАЩУ НЕУБИВАЕМОГО ТАРАКАНА-МУТАНТА! 🪲И в этом страхе, мне очень жаль, что для айтишников не придумали супервизоров, как у психологов и психотерапевтов! Я б пошла!

А вопросов у меня к вам 2:
1️⃣ Встречались ли вы с последствиями воздействия пестицидов?
2️⃣Нужен ли вам "супервизор"? А может быть вы нашли уже его... ПОДЕЛИТЕСЬ!

#architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
👍61
🎙 Подкасты и материалы, про которые я забыла (но исправляюсь!)

Я, конечно, блогер так себе – постоянно забываю рассказать о каких-то активностях, которые остаются за скобками. И вот сегодня настало время признаться, что у меня уже накопился целый пул подкастов и записей, про которые я даже не писала!

🎥 Завтра вечером меня снова позвали на запись подкаста! Будем обсуждать релокацию и работу на Кипре – когда выйдет, обязательно поделюсь. Но можно принять очное участие, так как будет эфир в канале Ирина Велиган: Карьера в IT за рубежом
🗓Дата: 06/03/25
Время: 19-00 по МСК
💬Место: Tg канал "Карьера в IT за рубежом"


🔹 А вот что уже вышло, но я об этом не писала (или не прикладывала video):
💰 Подкаст Котелова «Алло, ну как там с деньгами?» – обсуждаем, за что можно ненавидеть финтех (по следам моего доклада на Highload). Ссылка на rutube
🏗 Мой доклад с ArchDays – про доменных экспертов, доменное проектирование и как их правильно выращивать (тема огонь, рекомендую!). Ссылка на youtube
🎤 Выступление на MVP TED от агентства PENA – запись вышла на платформе VK, и там я говорю о глубинных вопросах проектирования, ценностях и архитектуре (welcome к просмотру!).
👩‍💻 Вебинар для WomenInTech – MentorInTech 6.0 – «Развитие команды. Практическое использование инструмента StarMap». Запись уже на YouTube, и если вам интересно, как структурно подходить к развитию команды – это точно для вас!

🔹 В марте обещают еще одну новинку – подкаст с TeamLeadConf, который мы записывали вместе с DevOps Community for Love. Это был прям полноценный IT-стендап-брейншторм, так что ждем-с!

Короче, если иногда кажется, что меня мало – знайте, я просто не успеваю (ЗАБЫВАЮ и ЛЕНЮСЬ) обо всем рассказывать! 😆

#my_life #fintech #architecture #people_management
👍4🔥3🦄1
🎭 Иллюзии мозга, которые мешают нам быть лидерами

Сегодня делюсь с вами материалом, который некоторое время был доступен только участникам фестиваля Рупор Лида! Это статья-размышление, вдохновленная выступлением Жени Кузовлева на TeamLead Conf, дополненная реальными кейсами о когнитивных искажениях, ловушках мышления и ошибках восприятия, которые мы себе позволяем.

💡 Самое интересное, что в ней есть
👉 Осознание того, как часто мы сами становимся жертвами иллюзий, которые нам подкидывает мозг.
👉 Почему, оказавшись в роли лида, менеджера или руководителя, важно не только управлять командой, но и останавливать себя, проверяя, не попали ли вы в ловушку мышления?
👉 Как каждый четвертый человек (!) вокруг нас живет с комплексом самозванца, боясь, что «вот-вот» его разоблачат. И это касается даже топ-руководителей, вплоть до C-level!

🔎 А что, если бы у нас был институт супервизии?
В одном из прошлых постов я поднимала вопрос о супервизии – механизме, который мог бы помочь лидерам и управленцам разбираться в себе и видеть свои слепые зоны. Кажется, эта тема все еще актуальна. Возможно, нам стоит думать в сторону ее реализации?

Прочитать статью можно тут:
🔗 на Хабре

💬 А вы сталкивались с когнитивными искажениями, которые мешают принимать решения?

#people_management
👍8🤔1
🎭 «Но сейчас идет другая драма»: как я завалила подкаст про релокацию

Есть темы, в которых я могу говорить часами, страстно жестикулируя, приводя примеры и погружая всех в водоворот обсуждения. А есть темы, на которых я ловлю себя на том, что мне нечего сказать. Вернее, сказать-то можно многое, но звучит это не так, как должно.

И вчера был именно такой день.

Меня позвали на запись подкаста/эфира про релокацию, работу на Кипре, переезд — и я согласилась. Казалось бы, я прошла через весь этот путь, у меня есть опыт, я точно могу что-то рассказать. Но уже в процессе стало ясно: я — худший гость для такого подкаста.

И тут я хочу сразу принести извинения Ирине @it_career_abroad . Она — прекрасный ведущий, сильный HR, человек, который очень круто разбирается в релокации, знает, как помочь людям с поиском работы и адаптацией. Если вам когда-нибудь понадобится консультация по этим вопросам — бегите к ней, Ира невероятно крута.

А теперь о том, почему моя роль в этом выпуске оказалась провальной.

1️⃣ Разговор вышел бессистемным и размытым
Я не понимала, какую основную мысль мне нужно донести, как направить диалог. Вроде бы был план, мы его придерживались, но это не помогло. В итоге разговор напоминал путешествие без карты — вроде бы идешь, но куда?

2️⃣ Я не чувствую себя экспертом в «переезде»
Я не тот человек, который может драматично рассказывать, как мы уезжали с одним чемоданом и пробирались через тысячу сложностей. Да, было тяжело, но это не было катастрофой. Да, были моменты неопределенности, но мы их решали. Я могу рассказать, какие документы нужны, на что смотреть при поиске жилья, как вести переговоры о релокации с работодателем. Но эмоциональной, вдохновляющей истории про «как я с нуля построила жизнь в другой стране» у меня нет.

3️⃣ Мне сложно обсуждать релокацию без контекста
Я не люблю говорить про эмиграцию в отрыве от событий, которые ее спровоцировали. Мне тяжело делать вид, что это просто переезд, что это не связано с глобальными изменениями в мире и в жизни каждого из нас. А делать подкаст в формате «ну вот мы переехали, тут тепло, вот такие условия» — для меня это как будто слишком поверхностно. А делать "шоу на TV" еще хуже!

4️⃣ Моя история релокации звучит... скучно
Ну правда. Мы переехали, потому что так сложились обстоятельства. Мы выбрали Кипр, потому что он был нам знаком, потому что мы уже рассматривали ранее идею работы и релокации именно сюда, потому что климат нам подходил. Да, были сложности — оформление документов, поиск жилья, новые контракты. Но это все решаемо.

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

🎤 О чем бы я могла рассказать лучше?
Как подготовиться к релокации практически (чек-лист документов, договоренности с работодателем, адаптация к новому рынку)
Как переезд влияет на профессиональное развитие (новые возможности, карьерные изменения)
Как оценить перспективы работы в другой стране, какие компании предлагают релокацию и что реально входит в пакет
— тут я бы говорила уверенно, потому что это структурная информация, которую можно систематизировать.

Но опять же, скорее не в формате подкаста, а в формате инстукций, "Делай - ожидай - будет"...

Что теперь?
Этот подкаст ИМХО был неудачным. Но я не жалею, что попробовала. Не жалею, что увидела свою слабую сторону в таких разговорах. Я поняла, что мне некомфортно обсуждать переезд в формате «истории жизни», но комфортно говорить о нем в формате практических рекомендаций.

Так что если вам нужен список документов, инструкции, нюансы переговоров с работодателями — приходите, я все расскажу.

И, Ир, прости, я не смогла стать интересны интервьюируемым для тебя!

#my_life
8🔥3🥰3🤗1
📚 Лучше поздно, чем... или итоги круглого стола про экспертов и базу знаний 📚

Аж неделю назад, 28 февраля, был прямой эфир — круглый стол про то, как эксперту формировать свою базу знаний. Мы собрались с членами ПК KnowledgeConf, и это была, правда, очень крутая беседа!

Но тут случилось неожиданное...
Google Meet, за который я плачу 30+ евро в месяц, отказался записывать видео. Поддержка? Ну, ее как будто бы и нет (ответ на письмо так и не пришел). Пришлось искать обходные пути, и внезапно оказалось, что есть целая индустрия сервисов для конспектирования и расшифровки аудио.

🔹 Что я сделала?
1️⃣ Записала встречу через сторонние сервисы.
2️⃣ В расшифровке мне очень помог сервис 👉 Grain – удобный инструмент для работы с голосовыми заметками.
3️⃣ Сделала полную текстовую расшифровку и оформила это в статью в формате диалога — проще, понятнее, удобнее.

📌 Я сама чаще выбираю текстовые материалы, чем видео или аудио. Почему?
— Можно быстро пробежаться глазами и найти нужный момент.
— Легче вернуться к конкретной информации, особенно если материал объемный.
— Можно цитировать, сохранять, использовать в работе.
— И да, иногда смотреть видео просто долго. Особенно если ты хочешь вытащить конкретную мысль, а не слушать 90 минут эфира.

А дальше я решила поэкспериментировать:
🔹 Выложила текст на VC — все прошло отлично, статья там уже доступна.
🔹 Попыталась на Хабре... и вот тут случился облом. Мне отказали, написав, что такой формат не соответствует требованиям. То есть лонгриды — ок, но диалоговый лонгрид Хабр не переваривает. Имейте в виду, если вдруг решите выкладывать что-то подобное. (Хотя тег "интервью" есть и он был проставлен)

📌 Теперь мне нужна ваша помощь!
Как вам такой формат? Вам удобнее слушать/смотреть или читать такие материалы?

👀 А пока — статья здесь:
👉 VC: Как эксперту создать свою базу знаний: боль, практика и неожиданные инсайты

Если тема полезна, присоединяйтесь к обсуждению! Я пошла дальше разбираться, что это у меня там получается — база знаний или все-таки книга? 😏

#toolkit
🔥10👏1
🏃‍♂️Аналитический марафон – скоро! 🧠

Есть конференции, с которыми у меня сложились особые отношения. Аналитический марафон – как раз такая. Я уже рассказывала о ней раньше, и знаю, что среди вас есть те, кому доклады оттуда импонируют и находят отклик.

📢 Что важно?
📌 Следующий Analyst Marathon уже скоро – 5 апреля!
📌 Темы – как всегда, на стыке хард и софт-скиллов для аналитиков.
📌 Формат – онлайн, доступно из любой точки мира.

Я в этот раз не выступаю – сейчас у меня активная подготовка к DevOpsConf, да еще и старт рядом = 7 апреля, где у меня воркшоп и круглый стол. Плюс на работе кипит движ, ну и менторинг, консалтинг – как обычно.

Но! Это не отменяет того, что Аналитический марафон – место, где можно словить кучу полезного контента, особенно если вы в аналитике или рядом с ней.

📝 Что будет на конференции?

💡 Как совмещать роли бизнес-аналитика и системного аналитика?
💡 Экспресс-инструменты для анализа – что реально работает?
💡 Как аналитикам учиться эффективно?
💡 Стратегии работы аналитиков в 2025 году – автономность или четкая функциональная определенность?
💡 Менторство, софт-скиллы, развитие в аналитике.

📌 Когда: 5 апреля, с 10:00 до 17:00 (МСК)
📌 Где: Онлайн
📌 Сколько стоит: как всегда демократично
📌 Спикеры и билеты: 🔥 На лендинге конференции

PS и это внезапно не реклама, а рекомендация и поддержка ребят!
🔥2👍1