Привет! На связи Андрей.
Сегодня я хочу поговорить с вами о No blame culture (культуре без обвинений) и о том, как строить по-настоящему устойчивый продукт.
У моей команды на прошлой неделе случилось сразу несколько инцидентов различного характера. Был релиз, который закатился только с третьего раза. Была краткосрочная, но довольно острая авария на трубопроводах данных. В процессе разбора аварии, мы обнаружили, что на самом деле одна из веток трубопровода уже давно имела проблемы, но им удавалось прятаться от нашего мониторинга.
О том, почему все перечисленное очень слабо повлияло на клиентский опыт, я расскажу в следующий раз. А также о том, какую очень конкретную бизнес-метрику мы увеличиваем, когда работаем над устойчивостью и мониторингом (это не сокращение количества аварий).
Сегодня хочу сказать о самом важном, на мой взгляд факторе безопасности и устойчивости цифровых продуктов: культуре отсутствия вины (No blame culture).
Интуитивно кажется, что для предотвращения ошибок нужно внушать человеку чувство ответственности: это важно, проверяй все тщательно! А если случилось что-то плохое, то нужно дать негативный фидбэк: это плохо, не делайте так больше!
Проблема в том, что ни один из этих методов на практике не работает. Ни ответственность, ни страх перед негативными последствиями.
Как же тогда обеспечивается устойчивость современных цифровых продуктов? Вот тезисы:
1. В продукте будут баги, что бы вы ни делали. Никакой QA и никакое интеграционное тестирование полностью их не исключат.
2. Значит наша стратегия изначально должна быть нацелена не на искоренение проблем, а на скорость их обнаружения и устранения, а также на сокращение ущерба.
3. Произошла авария? Причиной никогда не может быть человек, который что-то сделал не так. Причина всегда в процессах и отсутствии необходимой защиты.
4. Любая проблема может случиться, но только один раз.
5. Залог успеха этой стратегии в том, чтобы ваши коллеги без опасений максимально открыто рассказывали о проблемах и честно исследовали их причины без игры в корпоративный футбол и “проблема не на нашей стороне”.
6. Чтобы честно и открыто исследовать причины проблем и делать выводы, ни у кого не должно быть страха, что его в чем-то обвинят.
Поэтому при обнаружении проблемы ваша задача (как продакта) сразу настроить всю группу на то, чтобы обсуждать как нужно изменить процессы и инфраструктуру, чтобы такого больше не происходило. Вот вопросы которые надо задать:
1. Что произошло?
2. Какие последствия?
3. Как быстро мы обнаружили проблему?
4. Как ее устранили?
5. Что нужно сделать, чтобы мы могли обнаружить проблему быстрее?
6. Что можно сделать, чтобы сократить потенциальный ущерб?
7. Можно ли полностью искоренить такую проблему?
Если тема вам интересна, то слушайте больше деталей о том, как это устроено на практике в нашем утреннем подкасте. И бейте по рукам всех менеджеров, которые начинают разговаривать в негативном или обвинительном тоне после аварий.
Сегодня я хочу поговорить с вами о No blame culture (культуре без обвинений) и о том, как строить по-настоящему устойчивый продукт.
У моей команды на прошлой неделе случилось сразу несколько инцидентов различного характера. Был релиз, который закатился только с третьего раза. Была краткосрочная, но довольно острая авария на трубопроводах данных. В процессе разбора аварии, мы обнаружили, что на самом деле одна из веток трубопровода уже давно имела проблемы, но им удавалось прятаться от нашего мониторинга.
О том, почему все перечисленное очень слабо повлияло на клиентский опыт, я расскажу в следующий раз. А также о том, какую очень конкретную бизнес-метрику мы увеличиваем, когда работаем над устойчивостью и мониторингом (это не сокращение количества аварий).
Сегодня хочу сказать о самом важном, на мой взгляд факторе безопасности и устойчивости цифровых продуктов: культуре отсутствия вины (No blame culture).
Интуитивно кажется, что для предотвращения ошибок нужно внушать человеку чувство ответственности: это важно, проверяй все тщательно! А если случилось что-то плохое, то нужно дать негативный фидбэк: это плохо, не делайте так больше!
Проблема в том, что ни один из этих методов на практике не работает. Ни ответственность, ни страх перед негативными последствиями.
Как же тогда обеспечивается устойчивость современных цифровых продуктов? Вот тезисы:
1. В продукте будут баги, что бы вы ни делали. Никакой QA и никакое интеграционное тестирование полностью их не исключат.
2. Значит наша стратегия изначально должна быть нацелена не на искоренение проблем, а на скорость их обнаружения и устранения, а также на сокращение ущерба.
3. Произошла авария? Причиной никогда не может быть человек, который что-то сделал не так. Причина всегда в процессах и отсутствии необходимой защиты.
4. Любая проблема может случиться, но только один раз.
5. Залог успеха этой стратегии в том, чтобы ваши коллеги без опасений максимально открыто рассказывали о проблемах и честно исследовали их причины без игры в корпоративный футбол и “проблема не на нашей стороне”.
6. Чтобы честно и открыто исследовать причины проблем и делать выводы, ни у кого не должно быть страха, что его в чем-то обвинят.
Поэтому при обнаружении проблемы ваша задача (как продакта) сразу настроить всю группу на то, чтобы обсуждать как нужно изменить процессы и инфраструктуру, чтобы такого больше не происходило. Вот вопросы которые надо задать:
1. Что произошло?
2. Какие последствия?
3. Как быстро мы обнаружили проблему?
4. Как ее устранили?
5. Что нужно сделать, чтобы мы могли обнаружить проблему быстрее?
6. Что можно сделать, чтобы сократить потенциальный ущерб?
7. Можно ли полностью искоренить такую проблему?
Если тема вам интересна, то слушайте больше деталей о том, как это устроено на практике в нашем утреннем подкасте. И бейте по рукам всех менеджеров, которые начинают разговаривать в негативном или обвинительном тоне после аварий.