Я устал, я ухожу ...

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

Вспомним, что прокрастинация — это маркер, защитный механизм организма. Он включается, если целей или нагрузки слишком много или мозг не понимает, зачем мы вообще это делаем. Иногда это помогает нам отдохнуть, а иногда мешает делать важное и перегружает нервную систему.
Ставьте кота 🙂, если тоже испытываете раздражение, злость или вину после эпизодов прокрастинации.

Оставим прокрастинацию как тему для отдельных холиваров, лучше поговорим про отдых и восстановление.

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

С каждым из «энергетических сосудов» нужно работать по отдельности. Если вы вымотаны, скорее всего, в случае активного отдыха вы возьмете силы у организма взаймы, а потом станет ещё тяжелее. При этом есть и взаимное влияние — полное физическое истощение практически всегда идет в комплекте с эмоциональным выгоранием, а нехватка эмоций требует вложений физических сил.

Самый сложный кейс — когда не хватает и того, и другого. Именно в такой ситуации мы можем убить вечер на скроллинг ленты, а в итоге чувствовать себя ещё более разбитыми.

📎Как быть с отдыхом?
*⃣ Не доводить себя до истощения. Вовремя остановиться, прикинуть план и остатки ресурсов потратить сначала на восстановление физических сил, а потом сделать что-то для души
*⃣ Быть внимательнее к себе. Никто лучше вас не скажет, что вас восстановит, зарядит или поможет выдохнуть. Важно с этим разобраться, собрать все инструменты, которые вы так или иначе использовали в жизни, и применять по мере необходимости
*⃣ Не требовать от себя быть сверхчеловеком. Составляйте расписание на день, рабочую неделю и выходные с учетом того, что пополнять «энергетические сосуды» отдыхом не менее важно, чем опустошать важными и нужными делами

📢 А что помогает вам отдыхать и чувствовать себя лучше?

Отпуск, отпуск, отпуск

Кажется, он мне действительно нужен…

Продолжим тему отдыха.
Отпуск позволяет полностью перезарядиться, отвлечься, расслабиться и восстановиться, чтобы вернуться к работе с новыми силами. По крайней мере, должен все это делать... 🤔

Мои взаимоотношения с отдыхом были полярными на разных ролях и разных проектах. Большую часть карьеры мне не требовалось больше двух недель отпуска в год. А иногда я даже разбивал их по одной. И этого хватало: я достаточно отдыхал в выходные, мне нравилась работа, она не выматывала.

Со временем работа стала сложнее, ответственность кратно выросла. Это вытягивало силы и изматывало, потребность в отдыхе выросла. Двух недель или пары отпусков в год стало недостаточно, захотелось уйти в отпуск на 3-4 недели.

📎Как я столкнулся с новыми административными реалиями

На прошлом месте работы я никогда не планировал отпуск на год. Достаточно было в начале года поставить в календарь двухнедельный отпуск, а остальное планировать в моменте. Было очень удобно: известил за 2-3 недели и ушел отдыхать.

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

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

Вот тут я и задумался, а почему возникает такой конфликт на почве желания отдохнуть целый месяц. Запретный плод сладок, так что теперь у меня есть большое желание попробовать четырехнедельный отпуск 😴. Ставьте кота 🙂, если у вас такой был или тоже хотите!)

📌Мои впечатления от планирования отпусков на год

Если честно, мне не понравилось) Это лишает гибкости и ощущения свободы планирования. Нужно сесть и продумать план на год: праздники, поездки, необходимость отдохнуть (её прогнозировать оказалось сложнее всего). При пересмотре планов придется договариваться и двигать ближайший отпуск.

С другой стороны, это хороший способ упорядочить work-life balance: отдыхать вовремя и превентивно, а не когда уже сгорел на работе, планировать больше поездок и активностей, регулярно снимать фокус с работы. Надеюсь, эта система ещё принесет свои плоды.

Отпуска в IT — это негласный договор между работником и работодателем: мы можем сами выбирать, когда и сколько отдыхать, но платим за это отсутствием долгих отпусков. Ниже голосовалка, поделитесь, какой формат отпуска ближе вам.

Личность VS процессы

Думаю все встречали на работе того самого человека, на котором все держится. Он сплачивает коллектив, на него завязаны процессы, это сильный лидер, причем даже необязательно руководитель. Его подход может не коррелировать с общими процессами компании, но работает отлично. В крайних случаях его личный опыт и харизма и являются основой процессов в отсутствие формальных ориентиров. Когда такой человек уходит, все моментально схлопывается и перестает работать, люди постепенно уходят за ним.

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

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

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

📎Насколько часто вам приходилось встречать железобетонные процессы, которые могли выдержать исключение из команды любого человека? И наоборот, сильно завязанные на личность мини-процессы, которые взрывались как сверхновое в случае её увольнения?

Наставничество и его признание

Я придерживаюсь весьма жестких консервативных взглядов на наставничество. Наставник должен обучать работать самостоятельно. Не поддерживаю подход, когда людям дается готовое решение и за них тыкают в ответы. Это не обучение, а сиюминутное решение проблемы, которое никак не поможет в долгосрок. Я много работал с начинающими и более опытными аналитиками, вкладывался в их развитие.

Примерно так в моем подходе выглядит идеальная модель решения проблем совместно с наставником:
📌Появляется новая/сложная проблема, на выход из которой у аналитика не хватает опыта и компетенций
📌Он собирает информацию, разбирается во всех особенностях, круге влияния, побочных проблемах
📌Предварительно формирует возможные варианты решения в формате набросков или направления мысли
📌Затем с этой фактурой обращается к наставнику за валидацией и помощью в принятии решения
📌Наставник помогает выбрать решение, подсвечивает узкие места, дает советы и рекомендации по дальнейшей работе над проблемой
📌Отлично, если наставник еще валидирует результат
📌После решения бывает полезно порефлексировать, как все прошло и что можно было сделать иначе

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

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

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

Вы часто вспоминаете своих первых менторов? Давали им какую-то обратную связь?

P.S. Катя, я тоже все помню... ❤️

Datetime 🆚 Timestamp

В очередной раз зацепился в споре по поводу использования Datetime и Timestamp (Linux Time, Epoch Time). Хочу поделиться опытом. Очень часто встречаю мнение, что Timestamp — лучшая альтернатива проблемному Datetime. На деле оба подхода — не проблема и не панацея, а инструменты со своими правилами, ограничениями, плюсами и минусами. Лично я в основном использую Datetime с указанием таймзоны (ТЗ для краткости), а к Timestamp обращаюсь только в сложных технических кейсах. Теперь подробнее о каждом из них.

Datetime ISO 8601

Это очень красивое человекочитаемое представление с указанием даты и времени вплоть до миллисекунд с регулируемой точностью и разными форматами. Пример: 2024-08-11T17:00:00+03:00.
Главная особенность DateTime — время можно указать с таймзоной: часовым поясом, который делает время конвертируемым и однозначно интерпретируемым.

С таймзонами связано много страхов из-за свойства конвертации: 15:00+03:00 и 21:00+9:00 — это один и тот же момент времени (Например, время на часах в Москве и Токио). Когда мы работаем с таймзонами, они могут свободно конвертироваться без нашего желания. Серверы, сервисы, OS и окружения могут менять ТЗ при передаче данных на ту, в которой работают. Так что если вы отправили время в ТЗ +3, по пути она преобразовалась и потребитель получил +0, это нормально.

Поэтому очень важно приводить datetime к необходимой ТЗ. Нельзя гарантировать, что ТЗ дойдет до пункта назначения без изменений. Но можно заложить получателю механизм приведения к нужному часовому поясу. Есть три основных правила конвертации:
1️⃣ Нельзя отрезать таймзону
2️⃣ При изменении ТЗ время тоже меняется
3️⃣ Обязательно приводить ТЗ к желаемой в точке отображения\обработки.

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

Главный плюс Datetime в человекочитаемости: при хранении и передаче таких данных мы четко видим время без дополнительных приседаний, можем отследить все трансформации и возможные ошибки приведения. Это экономит время на построение целостных процессов и их отладку.

Timestamp (Linux Time, Epoch Time)

❗️Не путать с Timestamp в Postgres, он на самом деле Datetime

Timestamp — это огромное целое число, количество секунд от отправной точки — 1 января 1970 года, 00:00:00 по UTC. Всегда передается в тайм-зоне +0. При передаче и хранении его значение статично. Единственное место, где его нужно будет преобразовать — в конечной точке отображения времени.

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

Главный плюс при использовании TS: он лучше управляем, меньше конвертации — меньше рисков. Минус — он не читаемый. С этими огромными числами сложно работать: нельзя даже примерно определить время или сравнить два значения на глаз. Под рукой всегда должен быть конвертер.

При работе с БД это тоже доставляет сложности. Чтобы получить события в периоде между датами A и B, вы конвертируете оба значения, затем добавляете их в запрос. И если одну из дат нужно скорректировать, придется снова и снова идти в преобразователь. Если только вы не супер человек и не делаете это в уме 😐

В итоге у нас есть два инструмента со своими особенностями. Выбор нужно делать исходя из задач и контекста конкретной ситуации. Самое главное — не навешивать ярлыки. На эту тему и был мой спор: я не согласился с позицией, что Datetime — это всегда проблемы, а Timestamp — классное универсальное решение. Проблемы возникают от неправильного использования инструментов, игнорирования контекста и последующего использования или непонимания подхода. Ещё ни разу не встречал нерешаемых проблем ни с одним из этих подходов. Мой совет — расставляйте приоритеты и принимайте взвешенные решения при выборе инструментов.

📌А какие у вас были сложные кейсы с таймзонами?

Культ гиперэффективности в IT

В каждой сфере деятельности есть культы. Самые частые в IT — гиперэффективность и переработки. Подходы сильно различаются по странам, секторам, компаниям и проектам. Но я встречал одобрение геройства в той или иной степени на всех своих работах. Я не сторонник таких культов, я за грамотное распределение времени, work-life balance и сохранение ментального здоровья. Перерабатывать, выгорать, брать на себя чужие задачи и ответственность, закрывать собой дыры — это все от лукавого.

Переработка — это всегда следствие неправильного планирования

Если только человек сам не прокрастинировал задачу днями или неделями.

А сейчас все чаще в блогах, статьях и на конференциях вижу мысли о том, как классно быть суперэффективным. Совмещать две работы, брать на себя лишние обязанности, работать 12 часов в день вместо восьми: способов много. Это одобряется и восхваляется: пока ты геройствуешь, самопожертвуешь, прыгаешь выше головы, ты молодец. Что с тобой будет потом, мало кому интересно. Потому что дальше — мало приятного: угасание интереса к работе, постоянная измотанность, желание все бросить. На выполнение простых рутинных задач будет требоваться все больше волевых усилий. Хорошо заметить это вовремя и вернуться к стандартной продуктивности, чтобы не сгореть окончательно. Но даже так в лучшем случае можно получить недовольство, мол, можешь же лучше, что с тобой случилось? А в худшем — санкции, повышение нагрузки и угрозы.

⚡️На последнем Analyst Days у меня было интересное обсуждение про кризис менеджмент как точку роста. Очень важно уметь обнаруживать и решать проблемы, это действительно дает рост и расширяет компетенции. Но в нашей работе важнее не допускать проблемы. Самый простой пример — работа тестировщиков, которая экономит уйму сил, времени и денег на отслеживание и решение проблем в готовом продукте. Мало какая ликвидация последствий научит тебя их не допускать.

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

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

Ставьте кота 🙂, если тоже считаете, что нужно работать в комфортном темпе, или огонек 🔥, если больше привыкли справляться с пожарами.

В IT мы не производим в мир ничего физического 🐱

Когда я ещё был аналитиком, у меня была очень интересная дискуссия на тимбилдинге с архитектором другого проекта. Он высказал идею, что IT бестолковая отрасль в плане производства чего-то физического в мир. Мы обсуждали заводы и производства, когда в результате работы у тебя есть конкретный физический объект. Я тогда не согласился и пытался доказать, что наша работа тоже про реальность и мы создаем то, чем пользуются люди. Пусть на экране, но тоже физическое, настоящее. Спор ничем не закончился, просто неплохо похоливарили 🙂

И вот спустя много лет я неожиданно начал понимать, о чем он говорил. Вклад в мир действительно у нас огромный, речь не об этом. А вот на психо-эмоциональном уровне отсутствие возможности «пощупать» результат своего труда действительно гложет. Да, мы видим, как операторы, пользователи или клиенты работают с нашими решениями. Да, у нас есть артефакты в виде схем и документов, хотя и в 99% случаев только на экране. Но это все не то… Сложно объяснить своему древнему мозгу, что буквы на экране имеют значение в реальном мире.

Я понял это, когда начал заниматься рукодельными хобби. Невероятное чувство — представить что-то, а потом воплотить в физическом представлении. Вот он: новый объект во вселенной, уникальный, второго такого нет. Пишу об этом, и уже мурашки бегут по спине 😇

В работе я не получаю такого выхода эмоций, но хобби — совсем другой мир. У меня это работа с кожей, деревом, эпоксидкой, конструкторы, румбоксы, каллиграфия и раскраски. Так я реализую свою творческую натуру, переключаюсь и чувствую отдачу от мира. Это заряжает. Причем для меня это не целенаправленное занятие, в котором я стремлюсь к профессионализму, а скорее интересное времяпрепровождение, игра, отдых. Главная цель — получить удовольствие от процесса и результата.

📎Недавно закончил вот такой светильник: сосна, масло, лак, полистирол и умная лампочка.

📌 Расскажите, какие хобби есть у вас? Как реализуете себя в физическом мире?

Друзья!

Уже завтра состоится первая встреча клуба анализа!
На ней мы с экспертами разберём реальный кейс из работы аналитика!
Ещё есть возможность присоединиться офлайн! А также всех будем рады видеть онлайн!

✈️ Подробнее о регистрации тут: https://t.me/analystclubru/29

Пересечение зон ответственности❓

Работа в команде предполагает пересечение с другими направлениями: тестирование, разработка, менеджмент, анализ. В процессе часто свежим взглядом видишь проблемы и узкие места. Хочется включиться и предложить помощь или совет. Если в это заиграться, получаются аналитики, которые по совместительству ещё и скрам-мастера, тестировщики или даже разработчики.

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

Как быть, если я вижу проблему и не могу пройти мимо?

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

‼️ Не путать с обратной связью и транслированием своих потребностей с целью улучшить совместную работу, это важно и полезно.

Из негативных аспектов — вы со своей позиции можете мыслить совсем другими категориями: стремиться к чистоте процессов, а не оптимальному балансу затраченных средств к результатам, фантазировать о неограниченных ресурсах, не видя реальных дыр в бюджете. У нас нет доступа к информации, фактам, цифрам и интересам участников других уровней или направлений.

✉️ К сожалению, инициативы не всегда находят отдачу. Приходится пробовать и делать выводы, с какими предложениями можно прийти и быть услышанным. Ко мне это понимание пришло только с опытом. А вы часто получали отклик на свои предложения в работе?

Друзья! 📢

Хочу поделиться с вами радостной новостью, мой доклад принят на Analyst days 21!
Со многими из вас мы познакомились именно на AD, и я буду очень рад видеть вас там снова)

В этот раз выступаю с технической темой, поговорим про партиции в БД. Обязательно приходите, будет интересно!)

📎 https://analystdays.ru/ru/talk/138362