Инструментальный ликбез
Инструментальный ликбез Проводила в понедельник вебинар про управление продуктовыми командами, участники накидали огонечков и благодарностей, и я подумала, что раз было полезно им, будет полезно и вам некоторые темы подсветить. Например, про postmortem-анализ. Термин postmortem заимствован из медицины и означает посмертное исследование причин смерти. В управленческом и инженерном контексте он используется метафорически: команда «вскрывает» завершённый проект или инцидент, чтобы установить причинно-следственные связи и перевести полученный опыт в организационное знание. Одного конкретного автора у этого метода нет, сформировался он на пересечении нескольких практик. Во-первых, из практики After Action Review (AAR). AAR был разработан в армии США в 1970-е годы как способ учиться на выполненных действиях, разбирать ошибки и достижения и улучшать последующие операции. Во-вторых, из проектного управления, когда после завершения проекта проводят project postmortem/lessons learned session/project review, в ходе которого анализируется, как соблюдались сроки, бюджет, какое качество результата, как взаимодействовали со стейкхолдерами, какие были риски и как в целом складывалась командная работа. В-третьих, из инженерной культуры DevOps, где postmortem стал ключевым инструментом анализа сбоев, аварий, технических инцидентов и отказов систем. Главная цель postmortem-анализа - превратить отдельный опыт в организационное обучение, позволяющий понять, что какие факторы сформировали результат и как изменить систему, чтобы в будущем повысить надёжность, качество решений и согласованность командных действий. Postmortem позволяет: 1. Восстановить фактическую картину события. Команда собирает данные, хронологию, решения, коммуникации, изменения условий и точки неопределённости. 2. Понять причинно-следственные связи. Команда отвечает на вопрос: «Какие условия сделали такой исход вероятным?». 3. Выявить системные уязвимости. Например, сбои в процессы, неясные роли, перегрузка команды, недостаток информации, неработающие каналы коммуникации, технические сбои и проч. 4. Сформулировать действия по улучшению. Итогом должны быть конкретные решения: изменить процесс, доработать регламент, уточнить зоны ответственности, внедрить контрольные точки, изменить архитектуру системы, пересмотреть обучение или коммуникацию. 5. Снизить вероятность повторения ошибки. В инженерной среде postmortem часто проводится после значимых инцидентов именно для предотвращения повторных сбоев. 6. Развить культуру ответственности без страха. Вот тут напишу поподробнее, потому что настоящий postmortem – это blameless postmortem, то есть разбор полетов без поиска виновного. Важно не персонализировать ошибку! Postmortem позволяет выявлять системные факторы, приведшие к инциденту, без обвинения конкретного человека или команды. Участники команды исходно рассматриваются как действовавшие добросовестно на основании доступной им информации. Большую роль в популяризации именно blameless postmortem сыграл Джон Олспо, бывший CTO компании Etsy. В 2012 году он опубликовал в инженерном блоге Etsy текст “Blameless PostMortems and a Just Culture”, где декларировал, что инженеры должны иметь возможность подробно рассказывать о своих действиях, наблюдениях, ожиданиях и предположениях без страха наказания. Postmortem целесообразен после: • завершения крупного проекта • провала проекта или существенного отклонения от плана • технического сбоя, аварии, нарушения сервиса • кризисной ситуации • неудачного запуска продукта • конфликта между подразделениями, если он повлиял на результат • значимого управленческого решения с неожиданными последствиями • успешного проекта, чтобы понять, какие практики стоит воспроизвести. Последний пункт принципиален. В зрелой организации анализируются не только провалы, надо понимать не только причины неудач, но и источники устойчивого успеха. С вас 🔥, если полезно, с меня - продолжение темы!