18 августа 2024 в 20:46 МСК
Читать 10 мин

Дополнения к докладу и что не вошло. Как руководителю снижать стресс для себя и команды, YACAMP 10.08.24

Какие стрессогенерирующие ситуации я ещё хотела взять в доклад, но не стала:

  1. Подготовка к аудитам/проверкам.
  2. Инциденты в проде и хотфиксы.

Сначала написала несколько дополнений к тем ситуациям, которые были в докладе. Что было в докладе не пишу, пишу только дополнения. Потому что это не замена доклада, а именно дополнения.


Адаптация нового сотрудника


  • Иметь стартовый гайд для новых сотрудников.

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

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

  • Сразу частично распределить адаптацию на команду.

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


Срочное и внезапное


Это невозможно пролечить на 100%, но:

  • Можно снизить само количество внезапного.
  • Можно выработать процессы, правила и реакции так, чтобы лучше справляться.
  • И то, что не упомянула: можно методично расчищать дорогу для подобных ситуаций, чтобы не спотыкаться на одних и тех же препятствиях в проекте каждый раз. Это намёк на работу с техдолгом.

Из «Что можно сделать»:

  • Искать и лечить причины.

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

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

Собирать проблемы в каждой отдельной ситуации, обращать на них внимание, методично по чуть-чуть лечить и в один прекрасный день проблем станет намного меньше.

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

  • Вести себя спокойно в экстренных ситуациях.

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

И ещё: люди бессознательно копируют поведение, перенимают эмоции. Чаще у тех, у кого в их глазах больше авторитета. Эмоции — вообще штука заразная. И если руководитель спокоен, а кто-то пришёл в панике, то человек с большей вероятностью переймёт спокойствие, а не панику.


***


Теперь что совсем не трогала в докладе.


Подготовка к аудитам/проверкам


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

Варианты причин стресса:

  • Нужно сделать большой объём работы за короткий срок.
  • Непонятно к чему готовиться. Что именно будут проверять и о чём спрашивать?
  • Как готовиться?

Что делать — тут максимально очевидные действия, но по моим наблюдениям максимально очевидное часто игнорируется, слишком просто и очевидно. Поэтому мне не неловко об этом писать))

Что можно сделать?

  • В период между аудитами методично делать то, что нужно для аудита.

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

Самая кэп-рекомендация: если что-то можно сделать заранее, лучше сделать заранее.

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

То же самое можно сделать не только с аудитами по безопасности, но и любыми другими, и даже с не аудитами.

  • Сохранять ссылки и заметки на всё, что нужно к аудиту, в единое место.

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

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

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

Ещё я сделала график задач по тегу безопасности: сколько заведено и сколько закрыто. Чтобы эта динамика всегда была у меня на виду: я хочу явно видеть, что задачи берутся регулярно и не складируются.

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

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

Такие волшебные заметки хорошо работают со всем редким.

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

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

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

  • Приходить с вопросами первыми.

Обычно с аудитами/проверками помогает кто-то вне команды. Кто-то из СИБ. Если знаете, в каком месяце будет аудит, можно выгодно всех опередить и прийти с вопросами первым, например, за пару месяцев.

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

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

А ещё СИБ будет рад, что мы им помогаем и сами приходим: они одни, а нас у них много)


Инциденты в проде и хотфиксы


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

Инцидент — это поломка в продакшене. Что-то пошло не так и нужно оперативно починить. Проду плохо.

Что можно сделать?

  • Собрать базу знаний что делать и что где находится.

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

Например, у нас в документации фронтенд-разработки есть отдельная страница с несколькими частотными сценариями: как опознать и что делать. Ещё есть документация на алерты: что делать по шагам и куда смотреть, если загорелся какой-либо алерт. Очень классно помогает.

Алертов много, контекстов много. Если в моменте нужно оперативно среагировать на ситуацию, с которой прежде не сталкивался, — шаги «что сделать и куда посмотреть» помогают и ускоряют процесс.

  • Проводить учебные инциденты.

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

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

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

  • Сначала человек читает документацию по работе с инцидентами.
  • Затем проговариваю, что скоро будет учебный инцидент именно для него.
  • Ищу в календаре место под учебный инцидент, но это одна из моих скрытых встреч: инцидент хоть и учебный, но для большей приближённости к реальности должен быть внезапным. Провожу в рабочее время, конечно.
  • Заранее предупреждаю лидов сервиса, когда будет учебный инцидент.
  • Начинаю сообщение с «УЧЕБНЫЙ ИНЦИДЕНТ», чтобы никто не переживал и не тратил своё время. Призываю всех фронтенд-разработчиков. Всех, потому что для одного конкретного это первый инцидент, а остальные — кто-то опытный и подключится просто понаблюдать, возможно подсказать фишки, возможно узнать фишки от кого-то другого, а кому-то ещё предстоит пройти учебный инцидент, для него полезно понаблюдать.

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

Только после этого подключаю в ротацию вспомогательных дежурных. А спустя ещё некоторое время — в ротацию основных дежурных.

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

И частично это про «быть рядом первые N раз».


***


Ссылка на доклад в виде статьи, он в Тимлидской подписке.

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


18.08.24

Бесплатный
Комментарии
Здесь будут комментарии к публикации