Проекты, Коммуникация | Олег Брагинский, Алексей Коробов
Как и положено инцидентам, они случаются не вовремя, в пятницу, когда РП исполнителя заранее сообщил о плановом отсутствии, и ничто не предвещало беды. РП заказчика решил немного поднажать на команду, чтобы перевыполнить недельный KPI. Разработчики из лучших побуждений, искренне желая помочь, ускорились.
Мы пренебрегли золотым правилом тестирования в среде разработки и начали выводить в рабочую систему слабо проверенное решение. Сработал неведомый триггер, начали плодиться системные email-уведомления, перегружающие сервер, работа интернет-магазина была остановлена.
Закон Мерфи – известное наблюдение: «Если что-то плохое может случиться – обязательно случится».
Как и с другими законами, само по себе знание не уберегает от наступления событий. С опытом проблемы появляются реже, но последствия ощущаются острее. От опытной команды ожидают безупречности: «Мы столько шишек набили, поэтому не должны ошибаться».
Обычно срабатывают риски:
- Потеря базы данных. Ответственный за бэкапы со стороны заказчика не соблюдал регламенты. Копии либо отсутствовали, либо были нерабочими, либо устаревшими. Регламент без контроля – просто бумага. Важно не только назначить ответственного, но и внедрить автоматическую проверку целостности бэкапов.
- Инцидент во время отсутствия РП исполнителя. Руководитель проекта планово отсутствовал два дня, в это время произошёл сбой. Команда не имела чёткого алгоритма эскалации, решение затянулось. Процесс эскалации должен работать автономно от конкретного человека. Прописывайте «план Б» на случай отсутствия ключевых ролей.
- Смена РП на стороне заказчика. Новый руководитель проекта формально выполнял функции, без вовлечения команды и реальных полномочий. Это приводит к снижению скорости принятия решений и росту напряжённости. При смене стейкхолдеров проводите онбординг не только по документам, но и по неформальным договорённостям и культуре взаимодействия.
Эволюция подхода, от «кто виноват?» к «что делать?»
- Как минимизировать ошибки?
- Где провести грань между эмпатией и жёстким управлением?
- Если сделать ошибку нормой – как не скатиться в разгильдяйство?
- Что является нормой – идеальное исполнение или ошибки как часть процесса?
В теории ответы очевидны: прописанные процессы, назначенные ответственные лица, проекты как наборы стандартизированных процессов.
На практике раз в год-два накапливается «идеальный шторм»:
- Разработчик заболел
- РП планово уехал на два дня
- Передача команды на аутсорс под руководство РП из другой культуры
В последний момент что-то идёт не так. Спираль напряжённости раскручивается, начинаются поиски виноватых – внутри и снаружи. Команда взрослых профессионалов переключается в позицию «ребёнка»: «Меня ничего не волнует, сделайте сегодня всё».
В момент, когда известия о проблеме дошли до меня, директора компании, – внутри хотелось рвать и метать. Задавался вопросом: сколько руководителей нужно нанять, чтобы самому не тушить пожары? Здесь важно опираться на заготовленные принципы.
На следующий день приходит осознание: «Как же так? Мы же процессная команда! Эскалация – отдельный описанный процесс, работа системы не должна нарушаться».
Три принципа работы с инцидентами
Принцип 1: Локализация в день инцидента
- Не переходить на личности – это тупик
- Не выплёскивать эмоции на коллег, даже при новых вызовах
- Сфокусироваться на том, чтобы остановить эскалацию ущерба
Принцип 2: Постмортем (разбор инцидента) без поиска виноватых
- Корректируем регламент коммуникаций и правила эскалации
- Вспоминаем о правиле – мы обсуждаем решения, а не людей
- Совершенствуем процессы эскалации и управления ожиданиями
Принцип 3: Договорённость об ошибках
На каком-то этапе у Закона Мерфи появляется глубина:
«Ошибки обязательно будут случаться. Нужно договориться с собой и с командой: как мы воспринимаем ошибки? Как определяем соотношение эффективности процесса и личного вклада руководителя?»
Простого ответа нет, проблемы важно признавать и обсуждать, помогают вопросы:
- Это системная ошибка процесса или единичный человеческий фактор?
- Что мы можем автоматизировать или стандартизировать, чтобы исключить повторение?
- Какой минимальный регламент нужен, чтобы в следующий раз РП справился без героизма?
Ожидание «сбалансированной системы» – не об отсутствии ошибок, а о лидерстве и культуре:
- Гибкую корректировку ожиданий и регламентов
- Постоянное тестирование процессов на прочность
- Восприятие ошибки как сигнала к улучшению, а не повода для наказания