Перейти к содержимому

Фотография

Как организовать post-mortem процесс?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 Murlika

Murlika

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • Город:Латвия

Отправлено 10 июля 2008 - 20:40

Посоветуйте, пожалуйста, как можно организовать post-mortem процесс.

Работаю в крупной международной компании, управляю релизами. Релиз представляет собой сборку из 60-70 проектов и 100-300 исправлений продукционных ошибок. Релизы ставятся в среднем каждые 5-6 недель в трех странах. Часть проектов локальные для страны, часть международные.
Над релизом работают более 200 человек из трех стран из порядка 25 различных отделов. В такой ситуации организовать post-mortem довольно проблематично.

Хотелось бы узнать, сталкивался ли кто-нибудь с подобными проблемами, когда проект очень большой и на нем работают много людей. Как в таком случае проводится post-mortem? Так же было бы приятно получить какие-то советы по проведению совещания, post-mortem review meeting, и по процессу вообще.
  • 0

#2 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 11 июля 2008 - 08:53

Murlika,

Ваш случай - это типичный вариант организации работы распределенной команды. Размер команды увеличивает сложность задач управления. Но не влияет на принципы работы. Их много, но можно выделить основные (на мой взгляд):
1. делегирование полномочий на местах
2. централизация процесса
3. унификация процесса

1. Делегирование полномочий.
Вам нет смысла и необходимости собирать всех разработчиков по всем проектам в одно время для проведения пост-мортен митинга. Ну может быть один раз, что бы все получили представление о глобальности.

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

Так же полезно участие в таких митингах непосредственных заказчиков или владельцев разрабатываемых систем.

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

2. Централизация процесса.
Не знаю, как это организовано у вас, но всегда эффективнее и дешевле управлять централизованными ресурсами. Желательно, что бы код хранился в одном дата-центре и его обслуживала одна команда саппорта.

3. Унификация процесса.
Должны быть единые для всех правила. Другими словами, каждый проект должен иметь однотипную структуру. По возможности обрабатываться одним инструментарием и по одним организационным правилам. Результаты сборки должны публиковаться для всеобщего обозрения участников процесса. И в случае сбоя должны применяться единые правила исправления ситуации.

Унификация позволяет иметь один процесс на все проекты. Это позволяет минимизировать затраты на поддержку процесса и в любой момент времени знать, что именно происходит на каждом из проектов.
  • 0
Гринкевич Сергей

#3 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 11 июля 2008 - 16:15

Посоветуйте, пожалуйста, как можно организовать post-mortem процесс.

Работаю в крупной международной компании, управляю релизами. Релиз представляет собой сборку из 60-70 проектов и 100-300 исправлений продукционных ошибок. Релизы ставятся в среднем каждые 5-6 недель в трех странах. Часть проектов локальные для страны, часть международные.
Над релизом работают более 200 человек из трех стран из порядка 25 различных отделов. В такой ситуации организовать post-mortem довольно проблематично.

Хотелось бы узнать, сталкивался ли кто-нибудь с подобными проблемами, когда проект очень большой и на нем работают много людей. Как в таком случае проводится post-mortem? Так же было бы приятно получить какие-то советы по проведению совещания, post-mortem review meeting, и по процессу вообще.

Murlika, было бы интересно узнать, какие типы проблем обсуждаются на пост-мортеме. От этого может что-то поменяться и в процесе.
В принципе, если обсуждаемые на пост-мортем митинге темы интересны всем отделам, то могу предложить такой алгоритм. Мы используем похожую схему, правда команда у нас хоть порой и распределенная, но небольшая, да и проекты прямо скажем не гигантские. Итак:
1. Кто-то Отвественный за пост-мортем митинг, еще до завершения работы над релизом (но когда уже конец работы виден), рассылает примерные темы для обсуждения на всех участников и просит в ответ предложить свои темы/проблемы/достижения. Назначает дату, когда надо все это прислать - вероятно уже после завершения работы над релизом, но за несколько дней до митинга, чтобы информацию можно было бы обработать.
2. Главный, в каждом подразделении, проводит локальный опрос своих коллег (локальный пост-мортем) и предоставляет темы к назначеному сроку Отвественному за митинг. Естественно, если кому-то нечего сказать - ничего не присылают и впоследствии могут в митинге не участвовать.
3. Отвественный, обрабатывает информацию, расставляет приоритеты и рассылает агенду.
4. В час Ч, устраивается митинг, на котором от каждого подразделения присутствует не более одного человека, дабы не устраивать базар-вокзал. Тут все зависит от возможностей компании, как технических, так и денежных. Можно всем однодневную командировку в головной офис сделать (но наверное, раз в 5-6 недель это излишне) можно видео-конференцию устроить, можно телефоный митинг (у нас так), можно еще как-нибудь, например десктоп удаленный расшарить на котором материалы демонстрировать, а общаться по телефону.
5. По результатам митинга, Отвественный, рассылает всем информацию о принятых решениях.

Если тем для обсуждения много, можно сделать несколько митингов, каждый по своей тематике - разработка, тестирования, удовлетворение пользователей и тд.
  • 0
Regards,
Alexey

#4 Murlika

Murlika

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • Город:Латвия

Отправлено 11 июля 2008 - 18:32

Добрый вечер, Green.

Спасибо за ответ. Давайте проверим, что я Вас правильно поняла.

Во-первых, процесс post-mortem`a должен быть централизованным и унифицированным. (На другие процессы, кроме релиза, я особо влиять не могу, поэтому их опускаем).

Во-вторых, собирать информацию для post-mortem`a необходимо с руководителей подразделений, которые работают с релизом (к примеру администраторы, тестировщики и т.д.). Они уже получают эту информацию от своих людей теми способами, которые считают нужными.

Когда вся информация собрана локально в каждой стране, организовывается митинг с руководителями подразделений и с ними обсуждается как это будет исправляться. После этого публикуется post-mortem отчет.

Примерно так?

Если да, то все выглядит отлично. Так у нас это и происходит. Единственное что на митинг приглашаются не все руководители (специфика производства, руководство считает что больше 7 человек на митинг приглашать нельзя и пытаются его провести за полтора часа). Но отчет рассылается всем.
Вот только это все не работает.
После каждого релиза мы собираем информацию, в "главной" стране делается митинг, обсуждаются проблемы. Но результата не видно.
Мы с завидной регулярностью встаем на одни и те же грабли. Стандартная проблема - в билде к заказанным проектам добавляется бонус в виде 4-5 проектов или рефакторингов или еще чего-нибудь. Это происходит почти в каждом релизе вот уже несколько лет.

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

Из-за это и возникает вопрос - как организовать post-mortem, чтобы его рекомендации начали выполнять?
  • 0

#5 Murlika

Murlika

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • Город:Латвия

Отправлено 11 июля 2008 - 18:56

Murlika, было бы интересно узнать, какие типы проблем обсуждаются на пост-мортеме. От этого может что-то поменяться и в процесе.


Процесс релиза у нас состоит из планирования что войдет в релиз (в релиз входят только готовые проекты, которые закончили девелопмент и проектный тест), сборки релиза, тестирования и инсталяции на продукцию. И график у нас очень жесткий, потому что релизы идут часто. Соответственно проблемы на этих этапах мы и обсуждаем.
Например тестовая среда была не доступна из-за проблем с железом - надо добавить память; тестовая среда и продукционная слишком разные, тесты некачественные; на продукции найдены критические ошибки, что надо поменять в тестовых сценариях, чтобы такие ошибки больше не пропускались; некачественный анализ/девелопмент/проектный тест.

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

Наш процесс я примерно описала в предыдущем посте.
Честно говоря, "главная" страна, в которой проводится митинг у нас Эстония. И как именно они его проводят я точно не знаю. На сколько я вижу из final post-mortem report`a, они договариваются все ли согласны с тем кто "виноват" и что рекомендуется исправить. Они это согласовывают на митинге, чтобы ни у кого не было претензий. Где возможно, ставят action point`s. А вот дальше идет мертвая зона. Процессы не исправляются, ничего не делается.
Но как нужно провести митинг так, чтобы этими проблемами кто-то занялся мне представить немного сложно.

Есть мысль делать follow-up с предыдущего митинга. Проходить через все таски которые тогда раздавали. У вас такое делается?
  • 0

#6 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 15 июля 2008 - 09:02

Честно говоря, "главная" страна, в которой проводится митинг у нас Эстония. И как именно они его проводят я точно не знаю. На сколько я вижу из final post-mortem report`a, они договариваются все ли согласны с тем кто "виноват" и что рекомендуется исправить. Они это согласовывают на митинге, чтобы ни у кого не было претензий. Где возможно, ставят action point`s. А вот дальше идет мертвая зона. Процессы не исправляются, ничего не делается.
Но как нужно провести митинг так, чтобы этими проблемами кто-то занялся мне представить немного сложно.


Murlika,

то, что Вы описали - это не проблема посмортена. Это проблема управления. Причем, достаточно распространенная. Любое управленческое воздействие должно заканчиваться контролем.

Судя по Вашему описанию, его нет. Обычно причина лежит в том, что не правильно (или отсутствует) сформулирована цель. У вас цель заключается в том, чтобы соблюсти "бумажный" процесс. А там написано, что нужно собраться, обсудить и выпустить бумажку. В бумажке нужно отразить ... И далее идет перечень пунктов.

В итоге. Все собираются. Обсуждают, что должно быть написано в бумажке и поручают секретарю написать. Процесс соблюден. Бумажка написана. Все довольны.

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

Из целей можно навскидку предложить следующие:
1. Совершенствование процессов
2. Повышение уровня качества
3. Риск менеджмент

Каждая из целей требует своей реализации.

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

И так по каждой цели.
  • 0
Гринкевич Сергей

#7 Murlika

Murlika

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • Город:Латвия

Отправлено 15 июля 2008 - 17:34

Green, спасибо. Вы правы, что проблема в управлении.

Но я обнаружила проблемы и в самом пост-мортеме, который мы писали.

Проблемы, которые мы описывали в отчете на самом деле являлись последствиями реальных проблем. К примеру описывалась проблема "Релиз не проинсталлирован вовремя на тестовую среду", причиной указывалось "слишком много ошибок найдено в deployment тесте" (deployment test - проверка инсталяции релиза на виртуальной тестовой среде). Как ответственное лицо указывался человек который делал deployment тест. Но на самом деле проблема заключается в плохом качестве билда, из-за которого инсталяция не проходит, а причина в плохом коде.
Я попробовала поменять последний постмортем отчет, правильно указав проблему и причину, и показала одному из менеджеров. Он сказал, что теперь этим можно пользоваться, потому что видно какие проблемы он должен решать.

Кроме этого я поменяла формат самого отчета. Раньше мы писали все проблемы в хронологическом порядке. Я разбила их по отделам, которые ответственны за эти проблемы, и менеджеры сказали что стало гораздо удобней. Теперь они легко могут найти проблемы, которые относятся к ним и которые они должны решать.

Так же я добавила поле impact to release. Эффект оказался потрясающим. Стало видно сколько дней тестирования мы потеряли на какой проблеме. (На одной из проблем мы потеряли полторы недели тестирования для крупного проекта). Такая информация заставляет менеджеров подразделений почувствовать последствия проблем, которые они нам организовывают.

Сейчас мы прорабатываем какие статистики можно добавить в постмортем чтобы показать продуктивность работы отделов. Может что-то можете посоветовать?

А остальное действительно решается управлением. Я смогла договориться с частью менеджеров о пост-мортем митинге после следующего релиза, где мы бы прошли через проблемы, договорились о задачах и датах их выполнения. А потом на каждом следующем митинге делали бы follow-up. Хотя мой непосредственный менеджер против этого митинга :(

В качестве целей мы поставили улучшение процессов и качества. О риск менеджменте я как-то не подумала. Не могли бы вы немного поподробней описать, что Вы имеете в виду?
  • 0

#8 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 16 июля 2008 - 07:36

О риск менеджменте я как-то не подумала. Не могли бы вы немного поподробней описать, что Вы имеете в виду?


Это как раз то, что Вы описали - проблема, ее проявление и степень влияния на результат.

Только такую работу проводят не по факту свершившегося, а до начала работ. Пользуясь предыдущим опытом, делается список наиболее вероятных проблем. Для каждой проблемы указывается три параметра:
1. Степень вероятности проявления
2. Степень влияния на ход работ
3. Что можно сделать, что бы предотвратить проблему, либо минимизировать степень ее влияния на проект (в случае проявления)

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

Приведу пример.
В тестирование поступает сборка низкого качества.

Как видно из Вашего поста, проблема весьма вероятна. Ставим вероятность - высокая (из высокая, средняя и низкая).
Определяем степень влияния на результат. Опять же по Вашей информации - высокая (простой в работе отдела тестирования до 1,5 недель).
Получили параметры - высокая, высокая. Следовательно, нужно что-то делать.

Наши возможные действия.

1. Предотвратить передачу "битой" сборки в тестирование. Для этого факт битости нужно выявлять до того, как билд поступит в тестирование. Это могут сделать сами разработчики. Нужно ввести в практику следующий прием. Билд собирается днем и в течение 2-х часов разработчики сами тестят билд (каждый проверяет свой кусок). Если выявляются серьезные проблемы и билд оказывается не тестопригодным, значит его тут же пересобирают (с исправлениями). Дальше процесс проверки повторяется до тех пор (и никто не уходит домой), пока билд не станет нормальным.

Я встречал практику, когда в проекте нет выделенного релиз-менеджера (делающего сборку), а сборку делают по очереди члены команды. При этом ответственным за сборку назначается тот разработчик, который "запорол" предыдущий билд. Это очень стимулирует народ не допускать ошибки в билде, что бы потом не отвечать за сборку.

2. Проводить смоук-тест билда на входе в процесс тестирования. Если билд битый, то сразу же заворачивать его на доработку.
Как я понял, Вы так и делаете. Фокус заключается в том, что бы всегда иметь на такой случай полезный объем работ для отдела тестирования, что бы исключить или максимально уменьшить простой в работе.
  • 0
Гринкевич Сергей


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных