🔝 Функционал vs функциональность: термины, которые режут слух
Пожалуй, это моя сильная боль.
Студент защищает диплом. Говорит: «Функционал системы включает... Разработан следующий функционал... Основной функционал — это...». Этим грешат не только студенты, но и коллеги...
Я сижу и слышу только это слово. Остальное пролетает мимо ушей.
📖 Что говорят словари
Функционал (математический) — числовая функция, заданная на множестве функций, переменная величина, зависящая от выбора одной или нескольких функций.
Функционал (в сексологии) — одна из пяти групп гомосексуалов, согласно классификации психолога Алана Белла и социолога Мартина Вайнберга.
Функциональность — способность системы выполнять конкретные действия; набор возможностей (функций), которые предоставляет система или устройство.
Теперь представьте лицо разработчика, который читает в ТЗ про «расширенный функционал системы»...
🧠 Про жаргонизмы: где уместны, а где нет
Жаргонизмы — это сленг, понятный внутри группы. В устной речи между «своими» — пожалуйста.
«Сделай функционал такой-то» — нормально в чатике с разрабом. Все поняли. Все ок.
Но в официальной документации, резюме, ТЗ, на собеседовании — нет. Там жаргон делает вас непрофессионалом. Потому что вы общаетесь не с коллегой по курилке, а с людьми, которые ожидают точности.
🩹 Если коллеги возражают?
Бывает и так. Вы начинаете говорить «функциональность», а коллеги закатывают глаза: «Хватит душнить, все же так говорят».
Как же быть в такой ситуации спросите Вы.
1️⃣ Не спорьте в рабочем чате. Толку ноль, все только разозлятся.
2️⃣ Используйте профессиональный язык в документации, резюме, публичных выступлениях. Там ваша зона ответственности. А в устной речи — подстраивайтесь под команду. Это называется «коммуникативная гибкость».
3️⃣ Если вы руководитель или ментор — показывайте пример. Не требуйте, а сами пишите грамотно. Люди подтягиваются незаметно.
Правило простое: умеете говорить профессионально — переходите на сленг когда уместно.
‼️ Запомните
❌ Функционал — оставьте математикам и сексологам.
✅ Функциональность — когда говорите о возможностях системы.
✅ Функция — когда речь об одной конкретной задаче.
🔱 Моё резюме
В русском языке есть слово «функциональность». Оно точное, правильное и профессиональное. Используйте его.
А «функционал» оставьте тем, кому он действительно нужен. Считаю, что в ИТ ему не место. Не исключаю, что этот термин могут узаконить в ИТ, поживём - посмотрим...
#Термины #Карьера
Пожалуй, это моя сильная боль.
Студент защищает диплом. Говорит: «Функционал системы включает... Разработан следующий функционал... Основной функционал — это...». Этим грешат не только студенты, но и коллеги...
Я сижу и слышу только это слово. Остальное пролетает мимо ушей.
📖 Что говорят словари
Функционал (математический) — числовая функция, заданная на множестве функций, переменная величина, зависящая от выбора одной или нескольких функций.
Функционал (в сексологии) — одна из пяти групп гомосексуалов, согласно классификации психолога Алана Белла и социолога Мартина Вайнберга.
Функциональность — способность системы выполнять конкретные действия; набор возможностей (функций), которые предоставляет система или устройство.
Теперь представьте лицо разработчика, который читает в ТЗ про «расширенный функционал системы»...
🧠 Про жаргонизмы: где уместны, а где нет
Жаргонизмы — это сленг, понятный внутри группы. В устной речи между «своими» — пожалуйста.
«Сделай функционал такой-то» — нормально в чатике с разрабом. Все поняли. Все ок.
Но в официальной документации, резюме, ТЗ, на собеседовании — нет. Там жаргон делает вас непрофессионалом. Потому что вы общаетесь не с коллегой по курилке, а с людьми, которые ожидают точности.
🩹 Если коллеги возражают?
Бывает и так. Вы начинаете говорить «функциональность», а коллеги закатывают глаза: «Хватит душнить, все же так говорят».
Как же быть в такой ситуации спросите Вы.
1️⃣ Не спорьте в рабочем чате. Толку ноль, все только разозлятся.
2️⃣ Используйте профессиональный язык в документации, резюме, публичных выступлениях. Там ваша зона ответственности. А в устной речи — подстраивайтесь под команду. Это называется «коммуникативная гибкость».
3️⃣ Если вы руководитель или ментор — показывайте пример. Не требуйте, а сами пишите грамотно. Люди подтягиваются незаметно.
Правило простое: умеете говорить профессионально — переходите на сленг когда уместно.
‼️ Запомните
❌ Функционал — оставьте математикам и сексологам.
✅ Функциональность — когда говорите о возможностях системы.
✅ Функция — когда речь об одной конкретной задаче.
🔱 Моё резюме
В русском языке есть слово «функциональность». Оно точное, правильное и профессиональное. Используйте его.
А «функционал» оставьте тем, кому он действительно нужен. Считаю, что в ИТ ему не место. Не исключаю, что этот термин могут узаконить в ИТ, поживём - посмотрим...
#Термины #Карьера
👍5🤓3😍2👎1
🤬 Травля на работе: когда коллеги — не семья
В ИТ принято говорить «мы команда», «мы семья». Но иногда за красивыми словами прячется обычная травля. И она бывает не только сверху вниз. Руководителя тоже могут травить. Мне повезло с коллективами и там всегда была и есть дружественная атмосфера.
🕷 Травля руководителя → подчинённых
Признаки (не все):
- публичные разносы, крики, унижения
- обесценивание работы: «ты ничего не умеешь»
- завал невыполнимыми задачами без ресурсов
- угрозы увольнением за малейшую ошибку
- изоляция: не зовут на встречи, не дают информацию
Это не «жёсткий стиль управления». Это насилие.
🐀 Травля руководителя ← подчинёнными
Да, такое тоже бывает. И говорить об этом принято ещё меньше.
Признаки (не все):
- игнорирование просьб и поручений («забыл», «не успел»)
- саботаж решений: вроде согласились, но делают по-своему
- сплетни за спиной, подставы, слив информации
- публичное оспаривание авторитета при команде
- «тихий бойкот» — все делают вид, что вас не слышат
Руководитель становится изгоем в собственной команде. Студенты также занимаются травлей преподавателей.
👥 Горизонтальная травля (коллега → коллеге)
Это вообще классика «семейных» чатов.
Признаки (не все):
- постоянные подколы под видом шуток
- исключение из обеда/кофе и рабочих обсуждений
- пассивная агрессия в общих каналах
- присвоение ваших идей и перекладывание ошибок
Эту травлю легче всего замаскировать под «корпоративный юмор».
❓Как понять, что это травля, а не «сложный период»
✅ Системность: не разово, а регулярно.
✅ Неравенство сил: у одной стороны меньше ресурсов для защиты.
✅ Умысел: есть цель уничтожить, а не конструктивно критиковать.
Ошибся → указали на ошибку = работа.
Каждое утро начинается с унижения = травля.
❓Что делать, если Вы жертва
Перебрала сотни советов и поняла, что не могу сформировать список или план действий, он настолько различен в зависимости от ситуации и получается огромное дерево принятия решения. Точно поймите, причина не в Вас, причина в том, кто делает Вас жертвой.
💡Моё резюме
Не терпите травлю. И не участвуйте в ней сами. Даже если «все так делают». Если при Вас кого-то травят, а вы молчите, значит Вы согласны и тоже являетесь соучастником.
Первый шаг — перестать поддерживать молчанием.
#Карьера
В ИТ принято говорить «мы команда», «мы семья». Но иногда за красивыми словами прячется обычная травля. И она бывает не только сверху вниз. Руководителя тоже могут травить. Мне повезло с коллективами и там всегда была и есть дружественная атмосфера.
🕷 Травля руководителя → подчинённых
Признаки (не все):
- публичные разносы, крики, унижения
- обесценивание работы: «ты ничего не умеешь»
- завал невыполнимыми задачами без ресурсов
- угрозы увольнением за малейшую ошибку
- изоляция: не зовут на встречи, не дают информацию
Это не «жёсткий стиль управления». Это насилие.
🐀 Травля руководителя ← подчинёнными
Да, такое тоже бывает. И говорить об этом принято ещё меньше.
Признаки (не все):
- игнорирование просьб и поручений («забыл», «не успел»)
- саботаж решений: вроде согласились, но делают по-своему
- сплетни за спиной, подставы, слив информации
- публичное оспаривание авторитета при команде
- «тихий бойкот» — все делают вид, что вас не слышат
Руководитель становится изгоем в собственной команде. Студенты также занимаются травлей преподавателей.
👥 Горизонтальная травля (коллега → коллеге)
Это вообще классика «семейных» чатов.
Признаки (не все):
- постоянные подколы под видом шуток
- исключение из обеда/кофе и рабочих обсуждений
- пассивная агрессия в общих каналах
- присвоение ваших идей и перекладывание ошибок
Эту травлю легче всего замаскировать под «корпоративный юмор».
❓Как понять, что это травля, а не «сложный период»
✅ Системность: не разово, а регулярно.
✅ Неравенство сил: у одной стороны меньше ресурсов для защиты.
✅ Умысел: есть цель уничтожить, а не конструктивно критиковать.
Ошибся → указали на ошибку = работа.
Каждое утро начинается с унижения = травля.
❓Что делать, если Вы жертва
Перебрала сотни советов и поняла, что не могу сформировать список или план действий, он настолько различен в зависимости от ситуации и получается огромное дерево принятия решения. Точно поймите, причина не в Вас, причина в том, кто делает Вас жертвой.
💡Моё резюме
Не терпите травлю. И не участвуйте в ней сами. Даже если «все так делают». Если при Вас кого-то травят, а вы молчите, значит Вы согласны и тоже являетесь соучастником.
Первый шаг — перестать поддерживать молчанием.
#Карьера
👍7🤯1
🚀 MVP: почему не надо тащить в первую версию всё, что придумали
Термин Minimum Viable Product (MVP) придумал Фрэнк Робинсон, CEO компании SyncDev, ещё в далёком 2001 году. А популяризировали его позже Стив Бланк и Эрик Рис в своих книгах про Lean Startup.
❓ Зачем всё это?
Суть максимально прагматична: не трать годы на создание «идеального» продукта — узнай, чего на самом деле хочет пользователь, как можно раньше.
MVP — это не прототип и не макет. Это самая простая, но работающая версия продукта с минимальным набором функций, способная решить одну-единственную, но реальную проблему.
🧯Но будьте осторожны: MVP бывает разным
Model-View-Presenter (MVP): термин ИТ, архитектурный паттерн для построения пользовательских интерфейсов. Производный паттерн от MVC и призван сделать код чище, а тестирование — проще и приятнее.
Most Valuable Player (MVP): термин спортивного аналитика, самый ценный игрок. Тут всё просто — лучший из лучших в команде или на турнире. Есть и менее известный, но очень милый вариант — Most Valuable Primate (Самый ценный примат) — это звание из одного старого фильма.
Mitral Valve Prolapse (MVP): медицинский термин, который в переводе с латыни означает пролапс митрального клапана (одна из разновидностей порока сердца).
Minimum Viable Population (MVP): из области экологии и биологии, минимально жизнеспособная популяция. Это понятие используют, чтобы определить, сколько особей нужно популяции, чтобы она не вымерла.
🔏 Что можно и нельзя выкатывать в прод под видом MVP
✅ Можно
- одну ключевую функцию, которая решает одну конкретную проблему
- сырой интерфейс, но работающую логику
- костыли, если вы их осознаёте и планируете переписать
❔Возможно, но точно зная, что исправите
- «ручной» бэкенд (например, заказы на почту)
❌ Нельзя
- сырые данные без валидации (финансы, здоровье людей, персональные данные)
- костыли, которые убивают безопасность (пароли в открытом виде, открытые порты)
- недоделанную авторизацию с дырами (пользователи получат чужие аккаунты)
- API с нестабильными ответами для внешних систем
- функции, чья поломка остановит основной бизнес
🍕 Живой пример из жизни
Представьте, вы хотите открыть службу доставки пиццы.
Ошибочный подход: Годами копить деньги на супер-приложение, сайт с визуальным редактором пиццы и автопарк из 10 машин.
MVP как он есть: Сделать лендинг за полдня на коленке, разместить на нём кнопку «Заказать» и свой номер телефона. Первые заказы принимать по звонку и развозить пиццу самому.
Если на вторые сутки вам позвонят хотя бы три человека — гипотеза подтвердилась. Если нет — вы не разорились и можете спокойно придумать новую идею.
🎓 Моё резюме
MVP — это не попытка сэкономить или выпустить недоделку. Это философия бережливого стартапа: учиться быстрее, чем конкуренты, и не тратить деньги на воздух.
MVP — не синоним «сырого куска кода». Это стратегия: быстро получить обратную связь. Не перепутайте прод с песочницей.
А когда коллега скажет «выкатим MVP в прод», спросите: «Какой именно MVP? И проверили ли мы безопасность?».
#Термины
Термин Minimum Viable Product (MVP) придумал Фрэнк Робинсон, CEO компании SyncDev, ещё в далёком 2001 году. А популяризировали его позже Стив Бланк и Эрик Рис в своих книгах про Lean Startup.
❓ Зачем всё это?
Суть максимально прагматична: не трать годы на создание «идеального» продукта — узнай, чего на самом деле хочет пользователь, как можно раньше.
MVP — это не прототип и не макет. Это самая простая, но работающая версия продукта с минимальным набором функций, способная решить одну-единственную, но реальную проблему.
🧯Но будьте осторожны: MVP бывает разным
Model-View-Presenter (MVP): термин ИТ, архитектурный паттерн для построения пользовательских интерфейсов. Производный паттерн от MVC и призван сделать код чище, а тестирование — проще и приятнее.
Most Valuable Player (MVP): термин спортивного аналитика, самый ценный игрок. Тут всё просто — лучший из лучших в команде или на турнире. Есть и менее известный, но очень милый вариант — Most Valuable Primate (Самый ценный примат) — это звание из одного старого фильма.
Mitral Valve Prolapse (MVP): медицинский термин, который в переводе с латыни означает пролапс митрального клапана (одна из разновидностей порока сердца).
Minimum Viable Population (MVP): из области экологии и биологии, минимально жизнеспособная популяция. Это понятие используют, чтобы определить, сколько особей нужно популяции, чтобы она не вымерла.
🔏 Что можно и нельзя выкатывать в прод под видом MVP
✅ Можно
- одну ключевую функцию, которая решает одну конкретную проблему
- сырой интерфейс, но работающую логику
- костыли, если вы их осознаёте и планируете переписать
❔Возможно, но точно зная, что исправите
- «ручной» бэкенд (например, заказы на почту)
❌ Нельзя
- сырые данные без валидации (финансы, здоровье людей, персональные данные)
- костыли, которые убивают безопасность (пароли в открытом виде, открытые порты)
- недоделанную авторизацию с дырами (пользователи получат чужие аккаунты)
- API с нестабильными ответами для внешних систем
- функции, чья поломка остановит основной бизнес
🍕 Живой пример из жизни
Представьте, вы хотите открыть службу доставки пиццы.
Ошибочный подход: Годами копить деньги на супер-приложение, сайт с визуальным редактором пиццы и автопарк из 10 машин.
MVP как он есть: Сделать лендинг за полдня на коленке, разместить на нём кнопку «Заказать» и свой номер телефона. Первые заказы принимать по звонку и развозить пиццу самому.
Если на вторые сутки вам позвонят хотя бы три человека — гипотеза подтвердилась. Если нет — вы не разорились и можете спокойно придумать новую идею.
🎓 Моё резюме
MVP — это не попытка сэкономить или выпустить недоделку. Это философия бережливого стартапа: учиться быстрее, чем конкуренты, и не тратить деньги на воздух.
MVP — не синоним «сырого куска кода». Это стратегия: быстро получить обратную связь. Не перепутайте прод с песочницей.
А когда коллега скажет «выкатим MVP в прод», спросите: «Какой именно MVP? И проверили ли мы безопасность?».
#Термины
🤓3
ℹ️ Профстандарты в ИТ: бумажка или нет?
Есть в России такие документы — профессиональные стандарты. В ИТ они тоже есть. И вокруг них ходит много слухов. Кто-то думает, что без них не устроиться на работу. А кто-то вообще не знает, что это такое.
Давайте разберёмся.
❓Что это вообще такое
Профстандарт — это официальный документ, утверждённый Минтрудом, который описывает: как должна называться должность, какое у тебя должно быть образование, сколько опыта и какими навыками ты обязан владеть. Документ призван навести порядок в том, кто, чем и на каком уровне должен заниматься.
Для примера, в ИТ есть профстандарты для «Программиста» и «Системного аналитика». Первый был обновлён в 2022 году и вступил в силу с 1 марта 2023-го. Для системного аналитика он существует с 2014 года, а новый приказ Минтруда вступил в силу 1 сентября 2023 года и будет действовать до 1 сентября 2029 года.
✍️ Кто обязан их соблюдать
Это самый популярный вопрос. И ответ прост: почти никто.
По закону (ст. 195.3 ТК РФ) профстандарты обязательны только в двух случаях:
✅ когда требования к квалификации прямо установлены другими федеральными законами (как для учителей или врачей);
✅ если работа даёт право на льготы или пенсию по вредности.
Во всех остальных случаях они носят рекомендательный характер. Работодатель может ориентироваться на них, а может и нет. Для частных ИТ-компаний это ровным счётом ничего не значит.
🔆 Какая от них польза
➖ Официальный статус профессии. То, что у «Системного аналитика» есть свой профстандарт — это признание того, что вы занимаетесь серьёзным делом, а не придумали себе модную должность.
➖ Ориентир для резюме и развития. Заглянуть в профстандарт хотя бы раз полезно: вдруг вы узнаете, что ваша должность называется совсем не так, как вы думали. Также он может помочь структурировать информацию о своих навыках и своём грейде.
🎓 Моё резюме
Профстандарты — это не пустая бумажка. Но и не закон, который нужно исполнять любой ценой. Это удобный справочник, который государство создало для наведения порядка. Пользуйтесь им и не бойтесь.
#Инструмент #Карьера
Есть в России такие документы — профессиональные стандарты. В ИТ они тоже есть. И вокруг них ходит много слухов. Кто-то думает, что без них не устроиться на работу. А кто-то вообще не знает, что это такое.
Давайте разберёмся.
❓Что это вообще такое
Профстандарт — это официальный документ, утверждённый Минтрудом, который описывает: как должна называться должность, какое у тебя должно быть образование, сколько опыта и какими навыками ты обязан владеть. Документ призван навести порядок в том, кто, чем и на каком уровне должен заниматься.
Для примера, в ИТ есть профстандарты для «Программиста» и «Системного аналитика». Первый был обновлён в 2022 году и вступил в силу с 1 марта 2023-го. Для системного аналитика он существует с 2014 года, а новый приказ Минтруда вступил в силу 1 сентября 2023 года и будет действовать до 1 сентября 2029 года.
✍️ Кто обязан их соблюдать
Это самый популярный вопрос. И ответ прост: почти никто.
По закону (ст. 195.3 ТК РФ) профстандарты обязательны только в двух случаях:
✅ когда требования к квалификации прямо установлены другими федеральными законами (как для учителей или врачей);
✅ если работа даёт право на льготы или пенсию по вредности.
Во всех остальных случаях они носят рекомендательный характер. Работодатель может ориентироваться на них, а может и нет. Для частных ИТ-компаний это ровным счётом ничего не значит.
🔆 Какая от них польза
➖ Официальный статус профессии. То, что у «Системного аналитика» есть свой профстандарт — это признание того, что вы занимаетесь серьёзным делом, а не придумали себе модную должность.
➖ Ориентир для резюме и развития. Заглянуть в профстандарт хотя бы раз полезно: вдруг вы узнаете, что ваша должность называется совсем не так, как вы думали. Также он может помочь структурировать информацию о своих навыках и своём грейде.
🎓 Моё резюме
Профстандарты — это не пустая бумажка. Но и не закон, который нужно исполнять любой ценой. Это удобный справочник, который государство создало для наведения порядка. Пользуйтесь им и не бойтесь.
#Инструмент #Карьера
🔥5😁1
👀 Насмотренность: модное слово или рабочий инструмент?
Сейчас это слово на слуху. В дизайне, в маркетинге, в блогах. Но в разработке оно тоже работает. Только смысл немного другой.
👁 Что такое насмотренность в разработке
Не про картинки и референсы из Pinterest. Про паттерны, антипаттерны и типовые решения.
Когда вы в десятый раз видите одну и ту же архитектурную ошибку и говорите: «Стоп, это уже было, так не надо». Или наоборот — сталкиваетесь с задачей и сразу понимаете: «Ага, вот тут нужна очередь сообщений, а не синхронный вызов».
Насмотренность — это база примеров в вашей голове: что работает, а что нет, без необходимости изобретать велосипед каждый раз.
⚡️ Зачем она нужна
✅ Экономия времени. Не надо каждый раз гуглить «как спроектировать X». Вы уже видели три рабочих варианта и один провальный.
✅ Качество решений. Вы опираетесь на чужой опыт, а не на «мне кажется, так будет круто».
✅ Доверие команды. Когда вы говорите «я уже такое видел, давайте не будем наступать на те же грабли», вас слушают.
Где её брать
Источников много, и делятся они на два типа: пассивные и активные.
📚 Пассивное развитие (потребление)
➖ Книги. Классика: «Мифический человеко-месяц», «Совершенный код», «Чистая архитектура». Или, например, более узкие — про системный анализ, требования, архитектуру.
➖ Статьи и паблики. Хабр, каналы по вашей теме. Даже если читаете по диагонали — откладывайте «узелки на память».
➖ Доклады с конференций и семинаров. Не только вживую, но и в записи. YouTube, VK Видео, Rutube — много бесплатных материалов от лидеров индустрии. Особенно полезны разборы реальных кейсов.
🎤 Активное развитие (выступления)
➖ Самому выступать на конференциях, митапах, в рабочих чатах. Готовя доклад, вы структурируете опыт, ищете чужой материал, учитесь отвечать на вопросы. Это прокачивает насмотренность быстрее, чем прослушивание десятка чужих выступлений.
➖ Участвовать в дискуссиях после докладов. Спросить «а что если?», «а почему не так?» — заставляет мозг искать альтернативы и расширять паттерны.
⚠️ А теперь важное предостережение
Насмотренность без критического мышления превращается в копирование чужого мусора. «А давайте как в том проекте» — не всегда правильный путь. Потому что у того проекта были свои задачи, свои ограничения и свои бюджет. Контекст решает.
🎓 Моё резюме
Насмотренность ускоряет старт. Но не заменяет голову. Насмотренность — это про то, чтобы расширить список вариантов, а не про то, чтобы слепо копировать первый попавшийся. Насматривайтесь. Анализируйте. И всегда спрашивайте: «А подходит ли это решение под мою задачу?»
#Карьера #Инструменты
Сейчас это слово на слуху. В дизайне, в маркетинге, в блогах. Но в разработке оно тоже работает. Только смысл немного другой.
👁 Что такое насмотренность в разработке
Не про картинки и референсы из Pinterest. Про паттерны, антипаттерны и типовые решения.
Когда вы в десятый раз видите одну и ту же архитектурную ошибку и говорите: «Стоп, это уже было, так не надо». Или наоборот — сталкиваетесь с задачей и сразу понимаете: «Ага, вот тут нужна очередь сообщений, а не синхронный вызов».
Насмотренность — это база примеров в вашей голове: что работает, а что нет, без необходимости изобретать велосипед каждый раз.
⚡️ Зачем она нужна
✅ Экономия времени. Не надо каждый раз гуглить «как спроектировать X». Вы уже видели три рабочих варианта и один провальный.
✅ Качество решений. Вы опираетесь на чужой опыт, а не на «мне кажется, так будет круто».
✅ Доверие команды. Когда вы говорите «я уже такое видел, давайте не будем наступать на те же грабли», вас слушают.
Где её брать
Источников много, и делятся они на два типа: пассивные и активные.
📚 Пассивное развитие (потребление)
➖ Книги. Классика: «Мифический человеко-месяц», «Совершенный код», «Чистая архитектура». Или, например, более узкие — про системный анализ, требования, архитектуру.
➖ Статьи и паблики. Хабр, каналы по вашей теме. Даже если читаете по диагонали — откладывайте «узелки на память».
➖ Доклады с конференций и семинаров. Не только вживую, но и в записи. YouTube, VK Видео, Rutube — много бесплатных материалов от лидеров индустрии. Особенно полезны разборы реальных кейсов.
🎤 Активное развитие (выступления)
➖ Самому выступать на конференциях, митапах, в рабочих чатах. Готовя доклад, вы структурируете опыт, ищете чужой материал, учитесь отвечать на вопросы. Это прокачивает насмотренность быстрее, чем прослушивание десятка чужих выступлений.
➖ Участвовать в дискуссиях после докладов. Спросить «а что если?», «а почему не так?» — заставляет мозг искать альтернативы и расширять паттерны.
⚠️ А теперь важное предостережение
Насмотренность без критического мышления превращается в копирование чужого мусора. «А давайте как в том проекте» — не всегда правильный путь. Потому что у того проекта были свои задачи, свои ограничения и свои бюджет. Контекст решает.
🎓 Моё резюме
Насмотренность ускоряет старт. Но не заменяет голову. Насмотренность — это про то, чтобы расширить список вариантов, а не про то, чтобы слепо копировать первый попавшийся. Насматривайтесь. Анализируйте. И всегда спрашивайте: «А подходит ли это решение под мою задачу?»
#Карьера #Инструменты
🔥5🤓2
🎤 IT‑link 2026: Чувашия, безопасная разработка и 12-я конференция
Вчера 16 мая была на IT‑Link. Организатор — компания Лайм Эйс Ди с офисами в 6 странах, а продукт используют ещё в большем количестве.
И знаете, что меня удивило? Чувашская республика на 2‑м месте по рейтингу регионов по цифровой трансформации. Ребята, вы молодцы! Серьёзно.
Выступала с докладом «Безопасная разработка 2026: новые правила игры». Говорила о том, почему привычные «проверки в конце» больше не работают и что теперь требуют тенденции.
Было много крутых докладов и мастер‑классов. Это уже 12‑я конференция IT‑Link — и они растут.
Что ещё добавить? Открыла для себя ещё паттерн проектирования, средство для Doc as Code, что трата токенов волнует многих.
И да, нетворкинг удался. Поговорила с коллегами из Чебоксар, Москав и даже из Таганрога. Спросили про книгу по системному анализу — может, когда‑нибудь решусь...
Организатором благодарности за организацию, прогулке по Волге и национальным танцам.
🎓Моё резюме
Конференции нужны не для галочки. Чтобы:
· проверить свои идеи на живой аудитории,
· узнать, что происходит в регионах (Чувашия — топ!),
· и случайно найти контакты на будущий проект.
Вы были на IT‑link? Какая конференция удивила вас в этом году?
#Байки
Вчера 16 мая была на IT‑Link. Организатор — компания Лайм Эйс Ди с офисами в 6 странах, а продукт используют ещё в большем количестве.
И знаете, что меня удивило? Чувашская республика на 2‑м месте по рейтингу регионов по цифровой трансформации. Ребята, вы молодцы! Серьёзно.
Выступала с докладом «Безопасная разработка 2026: новые правила игры». Говорила о том, почему привычные «проверки в конце» больше не работают и что теперь требуют тенденции.
Было много крутых докладов и мастер‑классов. Это уже 12‑я конференция IT‑Link — и они растут.
Что ещё добавить? Открыла для себя ещё паттерн проектирования, средство для Doc as Code, что трата токенов волнует многих.
И да, нетворкинг удался. Поговорила с коллегами из Чебоксар, Москав и даже из Таганрога. Спросили про книгу по системному анализу — может, когда‑нибудь решусь...
Организатором благодарности за организацию, прогулке по Волге и национальным танцам.
🎓Моё резюме
Конференции нужны не для галочки. Чтобы:
· проверить свои идеи на живой аудитории,
· узнать, что происходит в регионах (Чувашия — топ!),
· и случайно найти контакты на будущий проект.
Вы были на IT‑link? Какая конференция удивила вас в этом году?
#Байки
❤13🔥3😁1
🤯 Vertical Slice Architecture vs Onion Architecture — не надо выбирать, берите оба
Спойлер: они про разное. И отлично уживаются вместе.
🧅 Луковая архитектура (Onion Architecture)
Придумал Джеффри Палермо в 2008.
Идея: код — как луковица, в центре бизнес-логика, вокруг слои: инфраструктура, API, базы данных.
Главное правило: зависимости только внутрь. Внешние слои знают про центр, центр — не знает про них.
Зачем:
✅ Бизнес‑логика не зависит от технологий
✅ Легко менять базу данных или API
✅ Всё можно протестировать изолированно
Минус: слоёв много. Для простой фичи приходится править файлы в трёх местах.
🍕 Вертикальные срезы/слайсы (Vertical Slice Architecture)
Продвинул Джимми Богард в 2018.
Идея: не делить код на слои (контроллеры, сервисы, репозитории), а группировать по фичам.
В одной папке лежит всё, что нужно для выполнения одного сценария: от запроса до SQL.
Зачем:
✅ Одну фичу может делать один разработчик — не конфликтуют
✅ Фичу легко удалить — просто стереть папку
✅ Не нужно лазить по всему проекту
Минус: если не следить, код дублируется в разных слайсах.
🔥 А теперь главное: как их соединять
Многие думают, что это взаимоисключающие подходы, но это не так
Схема «брак по расчёту»:
На верхнем уровне — вертикальные слайсы.
Делим проект по фичам:
Внутри каждой фичи — луковая архитектура.
Свои слои: бизнес‑логика, инфраструктура, API. Зависимости — строго внутрь.
Что получается:
Вертикальные слайсы отвечают на вопрос: Как сгруппировать код, чтобы не мешать друг другу?
Луковая архитектура отвечает на вопрос: Как организовать зависимости, чтобы бизнес‑логика не привязывалась к базе данных?
Внутри одного слайса
📦 Пример на пальцах
🎓 Моё резюме
Onion защищает бизнес‑логику от внешнего мира.
Vertical Slice защищает разработчиков друг от друга.
Не выбирайте один подход. Берите лучшее от каждого. Архитектура должна работать на проект, а не проект на архитектуру.
#Инструменты #Термины
Спойлер: они про разное. И отлично уживаются вместе.
🧅 Луковая архитектура (Onion Architecture)
Придумал Джеффри Палермо в 2008.
Идея: код — как луковица, в центре бизнес-логика, вокруг слои: инфраструктура, API, базы данных.
Главное правило: зависимости только внутрь. Внешние слои знают про центр, центр — не знает про них.
Зачем:
✅ Бизнес‑логика не зависит от технологий
✅ Легко менять базу данных или API
✅ Всё можно протестировать изолированно
Минус: слоёв много. Для простой фичи приходится править файлы в трёх местах.
🍕 Вертикальные срезы/слайсы (Vertical Slice Architecture)
Продвинул Джимми Богард в 2018.
Идея: не делить код на слои (контроллеры, сервисы, репозитории), а группировать по фичам.
В одной папке лежит всё, что нужно для выполнения одного сценария: от запроса до SQL.
Зачем:
✅ Одну фичу может делать один разработчик — не конфликтуют
✅ Фичу легко удалить — просто стереть папку
✅ Не нужно лазить по всему проекту
Минус: если не следить, код дублируется в разных слайсах.
🔥 А теперь главное: как их соединять
Многие думают, что это взаимоисключающие подходы, но это не так
Схема «брак по расчёту»:
На верхнем уровне — вертикальные слайсы.
Делим проект по фичам:
Orders, Products, Users. Каждая фича — независимая папка.Внутри каждой фичи — луковая архитектура.
Свои слои: бизнес‑логика, инфраструктура, API. Зависимости — строго внутрь.
Что получается:
Вертикальные слайсы отвечают на вопрос: Как сгруппировать код, чтобы не мешать друг другу?
Луковая архитектура отвечает на вопрос: Как организовать зависимости, чтобы бизнес‑логика не привязывалась к базе данных?
Внутри одного слайса
PlaceOrder вы можете использовать MediatR, CQRS, чёткие слои. Но соседний слайс CancelOrder об этом ничего не знает.📦 Пример на пальцах
src/
├── Features/
│ ├── Orders/
│ │ ├── PlaceOrder/ # Вертикальный слайс
│ │ │ ├── Domain/ # Луковая архитектура внутри
│ │ │ ├── Application/
│ │ │ ├── Infrastructure/
│ │ │ └── Presentation/
│ │ └── CancelOrder/ # Другой слайс
│ └── Products/
🎓 Моё резюме
Onion защищает бизнес‑логику от внешнего мира.
Vertical Slice защищает разработчиков друг от друга.
Не выбирайте один подход. Берите лучшее от каждого. Архитектура должна работать на проект, а не проект на архитектуру.
#Инструменты #Термины
👍6🤓4
🌗 Analyst Days 22: моя история в программном комитете
Впервые была в программном комитете Analyst Days. И это оказалось сложнее, чем просто приехать и выступить.
🧪 Первый спикер — Анастасия Динерштейн с «Рецептами зелий продуктивности»
Я так давно не нервничала. Честно — до тошноты.
Ты делаешь всё, что можешь: помогаешь с тезисами, структурой, советами. А потом — всё. Дальше докладчик сам перед залом.
И ты сидишь и трясёшься за него. Оказалось, это волнительно даже больше, чем выступать самой.
📊 Цифры и факты
В первый день конференции у меня выступали 3 докладчика.
Сегодня ещё впереди — 2.
Я переживала и продолжаю переживать за каждого. И за тайминг, и за технику, и за вопросы из зала. Первый день прошёл, выдохнула. В ожидании окончания второго дня.
🎭 Перформанс с Тарасом
Мы сделали не просто доклад, а представление. Для меня это был настоящий выход из зоны комфорта. Ждём публикации видео, обязательно выложу.
Обычно ты стоишь и рассказываешь. А тут — диалог, эмоции, сценарная работа. Страшно, но классно.
Кажется, получилось.
🎓 Моё резюме
Программный комитет — это не про «посмотреть доклады из первого ряда». Это про ответственность за людей, про переживания и про умение отпустить.
Но когда твои докладчики выходят и зажигают — чувствуешь гордость, как за своих студентов.
Analyst Days 22 — люблю и ненавижу одновременно. До следующего AD ❤️🔥
З.Ы. Что вы думаете о выступлении на конференции? Поделитесь опытом как докладчик или может программный комитет?
#Байки #Конференции
Впервые была в программном комитете Analyst Days. И это оказалось сложнее, чем просто приехать и выступить.
🧪 Первый спикер — Анастасия Динерштейн с «Рецептами зелий продуктивности»
Я так давно не нервничала. Честно — до тошноты.
Ты делаешь всё, что можешь: помогаешь с тезисами, структурой, советами. А потом — всё. Дальше докладчик сам перед залом.
И ты сидишь и трясёшься за него. Оказалось, это волнительно даже больше, чем выступать самой.
📊 Цифры и факты
В первый день конференции у меня выступали 3 докладчика.
Сегодня ещё впереди — 2.
Я переживала и продолжаю переживать за каждого. И за тайминг, и за технику, и за вопросы из зала. Первый день прошёл, выдохнула. В ожидании окончания второго дня.
🎭 Перформанс с Тарасом
Мы сделали не просто доклад, а представление. Для меня это был настоящий выход из зоны комфорта. Ждём публикации видео, обязательно выложу.
Обычно ты стоишь и рассказываешь. А тут — диалог, эмоции, сценарная работа. Страшно, но классно.
Кажется, получилось.
🎓 Моё резюме
Программный комитет — это не про «посмотреть доклады из первого ряда». Это про ответственность за людей, про переживания и про умение отпустить.
Но когда твои докладчики выходят и зажигают — чувствуешь гордость, как за своих студентов.
Analyst Days 22 — люблю и ненавижу одновременно. До следующего AD ❤️🔥
З.Ы. Что вы думаете о выступлении на конференции? Поделитесь опытом как докладчик или может программный комитет?
#Байки #Конференции
❤12🔥4😁2
Меня часто спрашивают: «Как ты всё успеваешь? Преподавание, ТризТех (PT), конференции, канал...».
Отвечу честно: никакой магии. Просто система. И работает она не всегда, но чаще да.
Пост по следам моего спикера Анастасии «Приготовления зелий продуктивности», ей отдельная благодарность за отличное выступление. Делюсь своей системой — и новыми ингредиентами.
✅ Списки — база
Каждый день 10–17 задач и встречи в календаре. Не в голове — меньше стресса. Как выполнила или вечером проставляю галочки и выдыхаю.
🐸 Лягушка на завтрак
Самую противную задачу — первой. Сегодня это был сложный отзыв на ВКР. Сделала — и день пошёл.
⏱️ Правило 10 минут
Не идёт задача? Завожу таймер на 10 минут и просто начинаю. Через 10 минут спрашиваю себя: «Хочу продолжать?».
Часто — да. А если нет, значит, задача реально не сегодня. Но первые 10 минут ломают лёд.
✂️ Дробление задач
Вместо «Написать отзывы на ВКР»: «Найти старый шаблон отзыва» → «Обновить шаблон отзыва» → «Написать отзыв на ВКР студента А» → «Написать отзыв на ВКР студента Б». Маленькие шаги не пугают.
🚫 WIP Limits — не брать много
Work In Progress Limits — правило: одновременно не больше 2–3 задач. Иначе мозг перегружается, и ни одна не делается до конца.
❌ Что не зашло (на данный момент)
Геймификация — превращать работу в игру не люблю.
Прогрессивная нагрузка — мой ритм и так хаотичный.
Парное присутствие — если собака спящая рядом не считается, то мне никто не нужен для работы.
Метод помодоро — с моим количеством задач и переключений 25-минутные интервалы только сбивают. Заменила на правило 10 минут + дробление.
🎓 Моё резюме
Тайм-менеджмент — это не магия. Это набор приёмов. Берите то, что работает для вас.
Мой набор сейчас: списки + лягушка + правило 10 минут + дробление задач + WIP Limits.
Какие техники помогают вам? 👇
#Карьера #Инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥7❤1🥰1🤓1
📄TypeSpec: новый язык для API или очередная мода?
На Analyst Days 22 Руслан Папенко рассказывал про TypeSpec от Microsoft. Тема действительно горячая, но в индустрии любят волны хайпа — был RAML, был API Blueprint, теперь вот TypeSpec.
Я послушала, сравнила с OpenAPI и альтернативами. Делюсь выжимкой для прагматиков.
🧐 Что такое TypeSpec
TypeSpec — это предметно-ориентированный язык (DSL) для описания API. Он не заменяет OpenAPI напрямую, а компилируется в него (и не только). Релиз — апрель 2024, Microsoft, открытый исходный код.
Синтаксис напоминает TypeScript. Вы описываете модели данных, операции, а генератор выдаёт:
➖ спецификацию OpenAPI (YAML/JSON)
➖ документацию (например, HTML/Markdown)
➖ клиентские SDK на нескольких языках (основная поддержка TypeScript, .NET, Java, Python)
➖ генерация серверных заглушек (ограничена в основном .NET и JavaScript)
Звучит круто. Но давайте по фактам.
⚔️ Почему OpenAPI уже не торт
Презентация Руслана на Analyst Days и мнения инженеров со всего мира сходятся: OpenAPI, при всей своей популярности, доставляет много боли.
❌ Проблема №1: Нечеловеческий синтаксис
OpenAPI использует YAML или JSON — форматы, удобные для машин, но не для людей. Описания получаются многословными, часто похожими на «спагетти» из вложенных блоков. А разработчики с усталостью вспоминают, что им постоянно приходится подсматривать в документацию даже для простых вещей.
❌ Проблема №2: Сложность на масштабе
Если в проекте больше пары десятков эндпоинтов, спецификация превращается в гигантский файл (условно на 2000-3000+ строк). Отладка и поддержка такой простыни становятся крайне трудоёмкими.
❌ Проблема №3: Design-First страдает
OpenAPI создавался как формат документации готового API, не спорю, что далее он уже развивалась как формат для Design first. Если мы говорим про объёмные enterprise-системы, то вносить точечные изменения в разросшиеся YAML-файлы — пытка, да — есть визуальные редакторы...
💡 Чем TypeSpec лучше
Если взять простой пример (приводить не буду, был на конференции и полно в "интернетах"), то разница очевидна, разница будет раза в 3 по количеству строк.
✅ Композиция без боли
✅ Не привязан к REST
Описав модели, можно сгенерировать не только OpenAPI, но и gRPC (protobuf), AsyncAPI для сообщений, даже GraphQL.
✅ Один источник правды
Меняете модель — перегенерировали клиента, документацию, моки. Забыли обновить документацию вручную — не ваш случай.
🔄 Полная картина: какие есть альтернативы
Вопрос рёбром: инновация или тренд? Хочу расширить контекст. TypeSpec — не единственный игрок на поле «API как код».
1️⃣ Design First
Платформы вроде Apidog или Stoplight Studio отходят от сырого YAML . Они предлагают визуальные редакторы, схемы перетаскиванием, авто-моки и документацию на лету.
Плюсы: GUI понятен даже нетехническим специалистам. Минусы: GitHub не всегда удобен для ревью тяжелых PNG.
2️⃣ Code First
Инструменты вроде Swaggo (Go) или SpringDoc (Java) парсят комментарии в коде и генерируют OpenAPI.
Плюсы: Документация всегда соответствует коду. Минусы: Код обрастает аннотациями, сложно охватить всю систему целиком.
3️⃣ Альтернативные DSL и Protocol Buffers
Если TypeSpec от Microsoft, то Smithy от Amazon (используется в AWS) существует дольше.
Protocol Buffers (protobuf) от Google — вообще тяжёлая артиллерия для микросервисов.
Плюсы: Скорость, строгая типизация, поддержка в любом языке. Минусы: Бинарный протокол, REST вы получаете через транзакцию.
🎓 Моё резюме
Инструмент действительно зрелый, но ещё не полностью готов для промышленного использования всеми командами в любом масштабе.
Пробовали уже TypeSpec? Или всё ещё на YAML? 👇
#Инструменты
На Analyst Days 22 Руслан Папенко рассказывал про TypeSpec от Microsoft. Тема действительно горячая, но в индустрии любят волны хайпа — был RAML, был API Blueprint, теперь вот TypeSpec.
Я послушала, сравнила с OpenAPI и альтернативами. Делюсь выжимкой для прагматиков.
🧐 Что такое TypeSpec
TypeSpec — это предметно-ориентированный язык (DSL) для описания API. Он не заменяет OpenAPI напрямую, а компилируется в него (и не только). Релиз — апрель 2024, Microsoft, открытый исходный код.
Синтаксис напоминает TypeScript. Вы описываете модели данных, операции, а генератор выдаёт:
➖ спецификацию OpenAPI (YAML/JSON)
➖ документацию (например, HTML/Markdown)
➖ клиентские SDK на нескольких языках (основная поддержка TypeScript, .NET, Java, Python)
➖ генерация серверных заглушек (ограничена в основном .NET и JavaScript)
Звучит круто. Но давайте по фактам.
⚔️ Почему OpenAPI уже не торт
Презентация Руслана на Analyst Days и мнения инженеров со всего мира сходятся: OpenAPI, при всей своей популярности, доставляет много боли.
❌ Проблема №1: Нечеловеческий синтаксис
OpenAPI использует YAML или JSON — форматы, удобные для машин, но не для людей. Описания получаются многословными, часто похожими на «спагетти» из вложенных блоков. А разработчики с усталостью вспоминают, что им постоянно приходится подсматривать в документацию даже для простых вещей.
❌ Проблема №2: Сложность на масштабе
Если в проекте больше пары десятков эндпоинтов, спецификация превращается в гигантский файл (условно на 2000-3000+ строк). Отладка и поддержка такой простыни становятся крайне трудоёмкими.
❌ Проблема №3: Design-First страдает
OpenAPI создавался как формат документации готового API, не спорю, что далее он уже развивалась как формат для Design first. Если мы говорим про объёмные enterprise-системы, то вносить точечные изменения в разросшиеся YAML-файлы — пытка, да — есть визуальные редакторы...
💡 Чем TypeSpec лучше
Если взять простой пример (приводить не буду, был на конференции и полно в "интернетах"), то разница очевидна, разница будет раза в 3 по количеству строк.
✅ Композиция без боли
✅ Не привязан к REST
Описав модели, можно сгенерировать не только OpenAPI, но и gRPC (protobuf), AsyncAPI для сообщений, даже GraphQL.
✅ Один источник правды
Меняете модель — перегенерировали клиента, документацию, моки. Забыли обновить документацию вручную — не ваш случай.
🔄 Полная картина: какие есть альтернативы
Вопрос рёбром: инновация или тренд? Хочу расширить контекст. TypeSpec — не единственный игрок на поле «API как код».
1️⃣ Design First
Платформы вроде Apidog или Stoplight Studio отходят от сырого YAML . Они предлагают визуальные редакторы, схемы перетаскиванием, авто-моки и документацию на лету.
Плюсы: GUI понятен даже нетехническим специалистам. Минусы: GitHub не всегда удобен для ревью тяжелых PNG.
2️⃣ Code First
Инструменты вроде Swaggo (Go) или SpringDoc (Java) парсят комментарии в коде и генерируют OpenAPI.
Плюсы: Документация всегда соответствует коду. Минусы: Код обрастает аннотациями, сложно охватить всю систему целиком.
3️⃣ Альтернативные DSL и Protocol Buffers
Если TypeSpec от Microsoft, то Smithy от Amazon (используется в AWS) существует дольше.
Protocol Buffers (protobuf) от Google — вообще тяжёлая артиллерия для микросервисов.
Плюсы: Скорость, строгая типизация, поддержка в любом языке. Минусы: Бинарный протокол, REST вы получаете через транзакцию.
🎓 Моё резюме
Инструмент действительно зрелый, но ещё не полностью готов для промышленного использования всеми командами в любом масштабе.
Пробовали уже TypeSpec? Или всё ещё на YAML? 👇
#Инструменты
❤4👍1🤓1
🔞 Work‑life balance: почему советы «выключай телефон» не работают
Бегу 4,2 км. Дыхание сбилось, ноги гудят, а в голове одна мысль: «Зачем я вообще на это подписалась?».
Параллельно вспоминаю вчерашние дедлайны, недописанные требования, несогласованные вопросы. И тут меня осеняет: баланс между работой и жизнью — это как бег. Если рвануть с места — сорвёшь дыхание. Если остановиться — не добежишь.
Вот о чём я думала на финише и какие модели из организационной психологии реально помогают не выгорать (даже когда начальник в другом часовом поясе, а дети болеют).
🧠 Модель №1. Границы не по времени, а по энергии
На забеге нельзя всё время бежать в одном темпе. Ты ускоряешься на спусках, сбавляешь на подъёмах.
Так же и с работой. Классическая ошибка — пытаться отделить работу хронологически (с 9 до 18). Но если вы вымотаны — вы не отдохнёте, даже если часы показывают 18:00.
Что делать:
Определите свои пики продуктивности и провалы. У меня утро и поздний вечер — пики (да, я сова). 14–16 часов — провал: там только механическая работа или вышивка.
Баланс — это не «сколько часов», а «восстановился ли я к следующему рабочему отрезку».
После забега я была разбита физически, но ментально отдохнула. И на следующий день работала эффективнее, чем после 8 часов сна.
🧩 Модель №2. Не «работа vs жизнь», а ролевой баланс
У вас не две сферы (работа и не‑работа), а с десяток: родитель, партнёр, друг, сотрудник, хобби-энтузиаст, бегун, человек, который спит и ест.
Проблема не в перекосе между работой и жизнью, а в том, что какая‑то роль долго недополучает внимания.
Что делать:
Раз в месяц выписывайте 5–6 ключевых ролей. Напротив каждой — оценку от 1 до 10.
Баланс — это не равенство часов, а отсутствие ролей с оценкой ниже 4 две недели подряд.
У меня роль «бегунья» иногда падает до 3 — тогда я записываюсь на забег. Роли «системный аналитик» и «работник ИТМО» почти всегда высокие — но это перекос, и тогда страдает роль «человек с книжкой».
🎯 Модель №3. Приоритеты по принципу «не больше трёх»
Модель Грега МакКеона из «Эссенциализма»: в любой момент времени у вас может быть только 3 настоящих приоритета. Остальное — делегировать, отложить или отменить.
На уровне дня: выберите 3 задачи, после которых день можно считать успешным. У меня в списке 5–7 задач, но три из них — жирным шрифтом.
На уровне жизни: выберите 3 сферы, которые развиваете прямо сейчас. Остальные — поддерживаете в фоновом режиме. Сейчас у меня: 1) канал, 2) работа, 3) здоровье.
🚫 Почему модели работают лучше популярных советов
Совет «не работайте после 20» не работает, если у вас дедлайн и пик энергии вечером. Вы будете чувствовать себя виноватым.
✅ Работают энергетические границы: поработал вечером — честно возьми выходной днём.
Совет «отдыхайте с семьёй по выходным» не работает, если выходные — единственное время на хобби.
✅ Работает ролевой баланс: «Сегодня суббота — роль "бегунья" в приоритете, семья подождёт час».
Совет «делайте список из 5–7 задач» не работает, потому что качественно вы делаете 2–3.
✅ Работает принцип трёх: 3 задачи = успех. Остальное — бонус.
📚 Моё резюме
Work‑life balance — это не расписание и не самодисциплина. Это система управления энергией, ролями и приоритетами.
Если выстроить эти три опоры, можно работать и по ночам, и по выходным — и при этом не выгорать. А без них не помогут ни тайм-блоки, ни цифровой детокс.
У меня эта система неидеальна. Я всё ещё иногда работаю до полуночи и забываю про чтение книг. Но благодаря этим моделям я знаю, что именно сломалось, и могу это починить.
А на следующем забеге я точно не буду думать о работе. Или буду, но хотя бы осознанно.
#Карьера #Инструменты
Бегу 4,2 км. Дыхание сбилось, ноги гудят, а в голове одна мысль: «Зачем я вообще на это подписалась?».
Параллельно вспоминаю вчерашние дедлайны, недописанные требования, несогласованные вопросы. И тут меня осеняет: баланс между работой и жизнью — это как бег. Если рвануть с места — сорвёшь дыхание. Если остановиться — не добежишь.
Вот о чём я думала на финише и какие модели из организационной психологии реально помогают не выгорать (даже когда начальник в другом часовом поясе, а дети болеют).
🧠 Модель №1. Границы не по времени, а по энергии
На забеге нельзя всё время бежать в одном темпе. Ты ускоряешься на спусках, сбавляешь на подъёмах.
Так же и с работой. Классическая ошибка — пытаться отделить работу хронологически (с 9 до 18). Но если вы вымотаны — вы не отдохнёте, даже если часы показывают 18:00.
Что делать:
Определите свои пики продуктивности и провалы. У меня утро и поздний вечер — пики (да, я сова). 14–16 часов — провал: там только механическая работа или вышивка.
Баланс — это не «сколько часов», а «восстановился ли я к следующему рабочему отрезку».
После забега я была разбита физически, но ментально отдохнула. И на следующий день работала эффективнее, чем после 8 часов сна.
🧩 Модель №2. Не «работа vs жизнь», а ролевой баланс
У вас не две сферы (работа и не‑работа), а с десяток: родитель, партнёр, друг, сотрудник, хобби-энтузиаст, бегун, человек, который спит и ест.
Проблема не в перекосе между работой и жизнью, а в том, что какая‑то роль долго недополучает внимания.
Что делать:
Раз в месяц выписывайте 5–6 ключевых ролей. Напротив каждой — оценку от 1 до 10.
Баланс — это не равенство часов, а отсутствие ролей с оценкой ниже 4 две недели подряд.
У меня роль «бегунья» иногда падает до 3 — тогда я записываюсь на забег. Роли «системный аналитик» и «работник ИТМО» почти всегда высокие — но это перекос, и тогда страдает роль «человек с книжкой».
🎯 Модель №3. Приоритеты по принципу «не больше трёх»
Модель Грега МакКеона из «Эссенциализма»: в любой момент времени у вас может быть только 3 настоящих приоритета. Остальное — делегировать, отложить или отменить.
На уровне дня: выберите 3 задачи, после которых день можно считать успешным. У меня в списке 5–7 задач, но три из них — жирным шрифтом.
На уровне жизни: выберите 3 сферы, которые развиваете прямо сейчас. Остальные — поддерживаете в фоновом режиме. Сейчас у меня: 1) канал, 2) работа, 3) здоровье.
🚫 Почему модели работают лучше популярных советов
Совет «не работайте после 20» не работает, если у вас дедлайн и пик энергии вечером. Вы будете чувствовать себя виноватым.
✅ Работают энергетические границы: поработал вечером — честно возьми выходной днём.
Совет «отдыхайте с семьёй по выходным» не работает, если выходные — единственное время на хобби.
✅ Работает ролевой баланс: «Сегодня суббота — роль "бегунья" в приоритете, семья подождёт час».
Совет «делайте список из 5–7 задач» не работает, потому что качественно вы делаете 2–3.
✅ Работает принцип трёх: 3 задачи = успех. Остальное — бонус.
📚 Моё резюме
Work‑life balance — это не расписание и не самодисциплина. Это система управления энергией, ролями и приоритетами.
Если выстроить эти три опоры, можно работать и по ночам, и по выходным — и при этом не выгорать. А без них не помогут ни тайм-блоки, ни цифровой детокс.
У меня эта система неидеальна. Я всё ещё иногда работаю до полуночи и забываю про чтение книг. Но благодаря этим моделям я знаю, что именно сломалось, и могу это починить.
А на следующем забеге я точно не буду думать о работе. Или буду, но хотя бы осознанно.
#Карьера #Инструменты
🔥10🤓6❤2👏1