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

Но‏ ‎инструкции ‎не‏ ‎работают.

Если ‎бы ‎они ‎работали,‏ ‎не‏ ‎было ‎бы‏ ‎проблем ‎с‏ ‎делегированием.

Если ‎вы ‎верите ‎в ‎инструкции‏ ‎—‏ ‎раздайте ‎их‏ ‎своим ‎подчиненным‏ ‎и ‎коллегам, ‎после ‎чего ‎отправляйтесь‏ ‎спать.‏ ‎Что‏ ‎может ‎пойти‏ ‎не ‎так?

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

Есть‏ ‎задача ‎обучения.

Но‏ ‎она ‎тоже‏ ‎не ‎сводится ‎к ‎инструкциям. ‎Учат‏ ‎ооооочень‏ ‎доооооооолго. ‎В‏ ‎инструкции ‎не‏ ‎заложен ‎фидбек, ‎как ‎в ‎обучение.‏ ‎Нет‏ ‎контроля,‏ ‎правильно ‎ли‏ ‎ты ‎понял.

То‏ ‎есть ‎доклад‏ ‎на‏ ‎конференции ‎—‏ ‎это ‎не ‎инструкция ‎и ‎не‏ ‎обучение. ‎А‏ ‎что‏ ‎же ‎это?

Повышение ‎осведомленности‏ ‎+ ‎Развлечение‏ ‎аудитории

с ‎целью ‎получения ‎неких‏ ‎выгод

Одна‏ ‎из ‎выгод‏ ‎— ‎привлечение‏ ‎трафика ‎на ‎свои ‎паблики. ‎Поэтому‏ ‎лёгкая‏ ‎недосказанность ‎должна‏ ‎присутствовать ‎в‏ ‎сочетании ‎со ‎ссылкой, ‎где ‎лежит‏ ‎остальное.

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

… И ‎вашей ‎харизмой,‏ ‎поставленной‏ ‎речью, ‎классным‏ ‎реквизитом ‎(слайдами)

Развлечение‏ ‎аудитории ‎— ‎важная ‎часть ‎задачи‏ ‎выступления.‏ ‎Её ‎не‏ ‎стоит ‎игнорировать‏ ‎при ‎постановке ‎задачи. ‎И ‎это‏ ‎довольно‏ ‎интересная‏ ‎часть ‎всего‏ ‎процесса. ‎Реализовывая‏ ‎такую ‎задачу,‏ ‎вы‏ ‎превращаете ‎информацию‏ ‎в ‎искусство.

Повышение ‎осведомленности ‎— ‎задача‏ ‎очень ‎лёгкая.‏ ‎Но‏ ‎только ‎если ‎ты‏ ‎определился ‎какой‏ ‎стороной ‎повернуть ‎айсберг ‎к‏ ‎небу.

Удачи‏ ‎на ‎выступлениях‏ ‎этой ‎осенью!

Кирилл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

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

18.08.24