Дежурите на работе? Ну и как вам? 🫠

У меня как раз закончилась неделя дежурства, и это навеяло мысль рассказать, что это вообще такое, вдруг кто-то ещё не сталкивался.

У меня был такой опыт с дежурствами:

1️⃣ На проекте было много людей, и каждую неделю выделялись дежурные со стороны анализа, разработки и тестирования. Т.е. три человека дежурили всю неделю.

Что делала я как дежурный аналитик:
* если разработчик фиксил баг и не понимал ожидаемый результат или нужно было что-то быстро найти в документации, он шёл ко мне, и мы вместе разбирались;
* если у смежных команд возникали вопросы по работе системы, они писали мне как дежурному, а дальше мы уже подключали нужных людей.

Суть простая: не отвлекать всех подряд. Есть дежурные — идёте к ним.

2️⃣ А вот в небольшой команде всё было иначе. Вот здесь я и познала всю «прелесть» дежурств 😅. Там все члены команды были равнозначны, t-shape и всё такое.

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

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

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

3️⃣ А в некоторых местах я даже не знала, кто «официально» дежурит: какой разработчик или какой тестировщик.
Я была единственным аналитиком на проекте и просто понимала, что со стороны анализа дежурю всегда я. Каждый день. Без вариантов. Все вопросы ко мне. Жуть 😂

Как-то так.
Недели дежурств бывают разными: страшными, непредсказуемыми…
а иногда удивительно спокойными, без единого инцидента.

Желаю всем нам спокойных дежурств ❤️

А как вы относитесь к такой активности? Были истории, о которых хотелось бы забыть 😱?

Как разгрести список вопросов от коллег?
Думаю, эту боль понимает каждый 😭.

Нам пишут все:
* разработчики, тестировщики, дизайнеры, менеджеры, аналитики, смежные команды;
* по нашим задачам, по багам, просто посоветоваться;
* а кто-то умудряется прийти с вопросами о сроках, хотя мы за это вообще не отвечаем:
«когда будет готово?», «когда релиз?», «сколько осталось?», «ну, можешь поторопить всех?» 😅

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

⏸️ Необязательно заниматься вопросом сразу
Мне помогает просто дать понять, что я увидела вопрос и вернусь с ответом.
* «Вопрос увидела. Насколько срочно?»
* «Смогу посмотреть после 16:00, это терпит?»
* «Нужно время, чтобы разобраться. Вернусь с ответом завтра»
* «Давай вернёмся к этому после созвона»
Это сильно снижает давление и ожидание ответа прямо сейчас.

🧠 Мы не обязаны знать всё
И это нормально. Иногда вопрос вообще не по адресу.
Что можно сказать:
* «Это не ко мне, лучше написать Васе»
* «Я не эксперт в этой части, но могу подсказать, к кому идти»
* «С ходу не отвечу, нужно погрузиться»
* «Давай уточним контекст, без него сложно ответить»
Гораздо хуже ответить наугад и потом разгребать последствия.

📝 Это правда только вопрос или полноценная задача?
Очень часто под видом быстрого вопроса нам приносят полноценную задачу.
Мои любимые фразы:
* «Давай заведём задачу, чтобы не потерялось»
* «Это требует анализа, давай зафиксируем отдельно»
* «Можем обсудить, но это не быстрый ответ»

🚧 И да, мы не менеджеры
Если коротко: лучше не брать на себя чужую ответственность.
* «По срокам лучше уточнить у менеджера»
* «Я могу рассказать статус анализа, но не дату релиза»
* «За приоритизацию отвечает …»

А теперь вопрос к вам 👇
(я очень хочу пополнить свой «словарь аналитика» 😄)

Как вы фильтруете поток вопросов? Есть свои заготовленные фразы или лайфхаки, которые работают?

Моя самая нелюбимая фраза — «го в зум»

Только представьте...
(хотя кому я это рассказываю, вы, скорее всего, испытываете то же самое)

Сидите, наконец-то погрузились в задачу. Впереди 3 часа без созвонов, можно спокойно сосредоточиться… И тут приходит сообщение: «го в зум».
Иными словами: «мы ждём тебя, подключайся прямо сейчас».

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

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

* Как же я благодарна тем, кто хотя бы пишет: «Можем созвониться? Когда тебе удобно?»
* ставит встречу в календаре заранее
* а если ещё и с описанием и списком вопросов — это вообще идеальный коллега.

Как же я люблю предсказуемость в рабочем дне ❤️

Или я одна так реагирую на внезапный зум? 😅

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

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

И вроде звучит нормально и спокойно.
А потом видишь список из 50 задач и понимаешь масштаб 😅. По каждой нужно назвать цифру.
Конечно, можно поставить её «пальцем в небо». Но мне важно прикинуть реальный сценарий, подсветить риски и дать честную оценку.

Поэтому я открываю Confluence и начинаю раскручивать клубок:

что уже реализовано, куда придётся вносить изменения, кого это затронет, какие могут всплыть риски, нужен ли дизайн, придётся ли идти к ИБ.

И 50 задач — это не просто список в таблице, по которому можно быстро пробежаться.
По крупным задачам проходят встречи по предварительному грумингу.
Нужно заранее въехать в тему, прийти на встречу, что-то придумать, обсудить и только потом поставить оценку.
И всё бы ничего… Если бы эти встречи не шли одна за другой.

А параллельно никто не отменял и текущую задачу. Работу за тебя никто не сделает 🙃

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

Осталось два дня и можно выдохнуть ❤️
Со вторника вернётся привычный ритм

Кажется, у каждого бывают такие плотные периоды.
А у вас сейчас какая неделя?

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

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

Когда ты видишь структуру.
Когда понимаешь, какие вопросы нужно задать.
Когда чётко представляешь, чего от тебя ждут коллеги.
Когда умеешь оформить результаты анализа так, чтобы к ним не возвращались по три раза.
Когда мыслишь основными и альтернативными сценариями.
Когда не превращаешь user story в формальность ради Scrum-доски.
Когда можешь разложить любой процесс на шаги и увидеть, где он ломается.
Когда говоришь с разработчиками на одном языке.
Когда понимаешь основы БД и интеграций.

И не сидишь с мыслью: «А что вообще от меня ждут?»

За 8+ лет в системном анализе я поняла одну вещь.

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

Когда я собирала курс «Системный аналитик с нуля до старта», мне было важно закрыть именно эту основу.
Вокруг неё и построен курс: последовательно, от процесса разработки и требований до основ БД и API, с примерами из реальной практики и упражнениями.
Приглашаю всех на обучение 💪

А если хотите попрактиковаться со мной и получить развернутую обратную связь, то приглашаю на практикум.

С 1 марта 2026 года в РФ вступают в силу поправки (168-ФЗ) о приоритете русского языка в публичной информации

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

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

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

Сразу оговорюсь: я не юрист 🙂
Ниже — моё «аналитическое» понимание.

Как я бы посмотрела на это со стороны аналитика.

Про интерфейсы

Если есть явный русский аналог, безопаснее использовать его.
«SALE», «NEW» — лучше заменить на «РАСПРОДАЖА», «НОВИНКА».

Буквально вчера покупала ноты, и на карточке везде было написано «SALE». Теперь невольно обращаю на это внимание 😅

Про бренды и товарные знаки

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

Про транслитерацию

Если возникнет соблазн просто использовать транслитерацию, это вряд ли поможет 🙃
«СЕЙЛ», «АПДЕЙТ», «САППОРТ» — по сути те же иностранные слова, только русскими буквами.
Если есть понятный русский аналог, безопаснее использовать его: «Распродажа», «Обновление», «Поддержка».

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

Про технические термины

А что с техническими терминами? Какой аналог у HTTP, REST, GraphQL 🙀?

Как я понимаю, их использование допустимо, поскольку это устоявшаяся профессиональная терминология.
Чтобы снизить риски, в публичных материалах лучше при первом упоминании давать короткое русское пояснение, а затем использовать сам термин. Например:
протокол передачи данных HTTP
архитектурный стиль REST

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

Про сленг

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

Как-то так.

Теперь я невольно смотрю, где в интерфейсах написано SALE 🙂
А вы стали чаще замечать иностранные слова?

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

Мне кажется, это одна из самых популярных фраз на встречах 🥲:

Да что тут думать, просто перекрасим кнопку, это лёгкое решение.

И звучит это обычно так, будто решение уже принято.

В такие моменты полезно на секунду остановиться и спросить:
а это точно наша зона ответственности?

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

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

Кстати, с аналитиками происходит примерно то же самое. Зачастую за нас тоже легко принимают решения. Например, дают сроки по анализу:

Да что там делать, это же на пару дней.

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

В хороших командах люди стараются не принимать решения за другие роли.
Они приглашают других:
«Давайте уточним у дизайнеров»
«Нужно спросить фронтендера»
«Давайте подключим аналитика»

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

А у вас на встречах тоже бывает «ну это же легко»? 😅

Не важно, сколько ты работаешь на проекте

Бывает, открываешь задачу и не сразу понимаешь, о чём речь.
Про какую это часть системы? Что за аббревиатуры? У нас это вообще реализовано?

Я последние годы работаю на больших проектах и регулярно сталкиваюсь с кусками системы, которые вижу впервые. И иногда ловлю себя на мысли:

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

Пока я прихожу к выводу, что такой момент не настанет. Профессия у нас такая 😅

Мы чаще приходим на проекты, которые давно существуют. Не всегда удаётся что-то делать с нуля. Хотя у меня был опыт работы на 4 проектах с нуля, и там действительно знаешь систему целиком. Это такое приятное чувство 🫠

На больших продуктах всё иначе. Ты постепенно въезжаешь в отдельные куски системы и уже в них начинаешь чувствовать уверенность. Но при этом всегда останется что-то неизведанное.

И знаете, что в этом успокаивает?

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

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

А у вас как?
С чего обычно начинаете, когда открываете задачу и не понимаете, что там происходит?

Я тут на всякий случай завела канал в MAX 😅

Пока просто дублирую туда посты. Это запасной вариант, чтобы не потеряться.

Если вам удобнее читать там, можно подписаться:
https://max.ru/join/raCZMgi2Q0VA4j9Ub_cYO-9vpmp-adGhT-GhNAKrJyg

Эта неделя была из разряда «всё и сразу»
дежурила, разбиралась с багами, участвовала в собеседованиях, параллельно делала 2 задачи, проверяла домашки по курсу

Сегодня просто отдыхаю 🙂

Пошла кормить Норберту
По позе видно, что она уже ждёт своих сверчков 🦎

Хороших выходных ❤️

Разговариваю со знакомыми и сама замечаю это на собеседованиях

Аналитики забывают базу. Или не считают нужным готовиться к вопросам по ней.

Все повторяют интеграции, API, контракты, брокеры
и игнорируют тему требований.

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

Люди теряются на вопросах про требования и их документирование.

Сложно даются задачи на сбор требований: какие вопросы бы задали заказчику, над чем бы подумали?

Кто-то пренебрегает этим, кто-то считает неважным. Но по факту, это и есть наша работа.

Работать с требованиями.
* Понимать, какие вопросы задать
* Как собрать информацию
* Как её наложить на текущую работу системы
* Как это всё структурировать
Даже выбор шаблона документа уже закрывает часть вопросов, над которыми нужно подумать при проработке задачи.

Если идёте на собеседование, не забывайте об этом. Вопросы про требования тоже задают. И очень часто.
Подготовьтесь 🙂

Но, конечно, дело не только в собеседованиях.
Важно не просто натренироваться для собеса, а реально понимать, как это работает на практике.

Если узнали себя хотя бы в паре пунктов, это нормально. Это как раз тот момент, когда стоит остановиться и нормально разобраться с базой.

С этим как раз помогаю на курсе
«Системный аналитик с нуля до старта»

Он подходит тем, кто уже поработал 2–3 года, но пока не сложилась целостная картина:
что делать,
как связать артефакты между собой,
какими вопросами задаваться при проработке логики системы
и как вообще системно подходить к задачам.

Когда общаюсь с начинающими аналитиками, часто вижу одну и ту же картину

Очень часто проблема не в том, что аналитик «чего-то не знает», а в том, что у него нет целостной картины в голове.

И с этим сталкивался каждый в начале карьеры, я уверена.

Раз аналитик устроился на работу, то он уже что-то знает про API, про интеграции, базовую теорию про требования, документирование, понимает, как в принципе работают системы, как данные попадают на страницу и как хранятся.
Но когда нужно всё это связать, вот тут и начинаются вопросы.
С чего вообще начать? Что первично? Как это влияет друг на друга?
К кому пойти и что спросить у заказчика или у коллег из смежной команды?
Что разработчики вообще хотят увидеть в ТЗ? Вроде описал задачу, а всё равно получил десятки уточняющих вопросов. Почему сразу об этом не подумал?

И на самом деле всё это как раз про одно
про отсутствие целостной картины

В такие моменты у новичков часто начинается самобичевание в духе
«я некомпетентный»
«глупый»
«мне здесь не место»
«вроде прошло несколько лет, а мне всё равно сложно здесь»

Хотя по факту ты просто сидишь над задачей и не понимаешь, с чего начать и к чему должны прийти.
Смотришь на неё, перечитываешь описание несколько раз, открываешь связанные задачи, логи, документацию… и всё равно нет ощущения, что картинка сложилась.

И в голове только одно: «почему я этого не понимаю?»

Тут мне хочется сказать одну вещь:

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

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

У вас всё будет хорошо ❤️

И на этом по работе всё. Пойдёмте отдыхать, мы это заслужили.

Что вы считаете хорошим днём в будни?

У меня на удалёнке это когда день проходит спокойно и в нём есть место не только работе.

🟢 есть в одно и то же время
🟢 выйти на улицу утром или в обед и увидеть дневной свет
🟢 если ещё и солнце — это вообще лучшее, что может быть
🟢 нет внеплановых созвонов «го в зум прямо сейчас»
🟢 не отвлекают сообщениями и можно спокойно поработать
🟢 после работы прогуляться и попить латте с сиропом
🟢 пройти хотя бы 5000 шагов за день
🟢 сделать что-то нерабочее: почитать, сходить в бассейн, поиграть на пианино, порисовать
🟢 и что-то по курсу или каналу: проверить ДЗ, обновить материалы, ответить на вопросы, написать пост

Скоро добавится кормление чаек 😄
Я живу возле залива, и это самое рядовое развлечение

А у вас как?

Всем хорошей недели ❤️

Хочу поделиться с вами конференцией, которая будет 18 апреля

Я уже не первый раз слежу за «Аналитическим марафоном», у них обычно очень прикладные доклады без воды.

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

Из программы, например:
— Надёжная шина данных на Apache Kafka
— От таблиц к графам: новый инструмент для анализа отраслевого рынка
— От монолога к модели: как правильные вопросы и Event Storming спасают от бесконечных правок
— Навыки архитектурных решений
— Быстрый старт для создания ии-ассистента на кодовой базе организации для исследования приложений

Полная программа со всеми докладами ЗДЕСЬ

И ребята дали мне возможность разыграть среди вас
бесплатный билет на полный доступ 🙂

Чтобы поучаствовать, напишите в комментариях, какой доклад вам откликнулся и почему
(в комментариях ниже оставлю полный список докладов)

13 апреля с помощью рандомайзера выберем победителя

UPD: розыгрыш завершён, победителя уже выбрали 🙂