Встреча после проекта - пустая трата времени?

У меня на работе были серьезные проблемы с ростом. Мы перешли от команды разработчиков от 3 до 10, и сама компания выросла на 30% в прошлом году. По большинству измерений у нас все хорошо. К сожалению, качество нашего программного обеспечения пострадало.

На сегодняшней встрече с менеджером моего подразделения я предложил провести встречу проектной команды через день или два после запуска продукта. Мы могли бы обсудить проблемы бюджета, масштаб, что пошло не так, и что пошло не так. В идеале учиться на наших ошибках. Мы создаем сайты / приложения для других людей, поэтому наше время не оплачивается. Такая встреча подпадает под последнюю.

Мой менеджер сбил его почти сразу: «Это время не оплачивается. Это заставит нас отстать от другого проекта, потому что мы теряем время в конце этого разговора об этом». Я был настолько застигнут врасплох этой логикой, что даже не удосужился сразиться с ним.

Итак, мой вопрос: я вижу ценность встреч после проекта, но он этого не делает. Есть ли документальное подтверждение того, что встречи после проекта помогают сэкономить время и деньги в долгосрочной (или краткосрочной) перспективе? Интуитивно я думаю, что это будет / будет, но он явно больше обеспокоен небольшим количеством неоплачиваемого времени из 5 человек, которые должны были быть там.

Оглядываясь назад, смотреть в будущее было бы близко к документальному подтверждению идеи. Проект Post-Mortem: Ценный инструмент для постоянного улучшения будет пост в блоге об этом.

Искусство Посмертного имеет этот пункт об идее:

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

Ваш менеджер не понимает концепцию технического долга .

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

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

По сути, это обзор после действий , который особенно полезен во многих различных контекстах, а не только в военных.

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

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

Ценность этого в простой логике и по своей сути очевидна. Как вы можете улучшить будущие проекты, если никогда не учитесь на своих ошибках предыдущих проектов?

Несмотря на то, что это не документация, проверка процесса (во время или после его завершения) является основным компонентом практически каждой известной мне системы контроля качества, особенно CMMI и Lean 6 Sigma.

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

Возможно, ваш менеджер находится под давлением бюджета. Это должно быть большой проблемой при расширении от 3 до 10 разработчиков в короткие сроки. Если это так, то, вероятно, будет хорошей идеей просто пропустить посмертные встречи и предложить их снова через несколько месяцев, когда, надеюсь, насущные проблемы бюджета не будут столь острыми.

Одна из причин, по которой качество может страдать, заключается в том, что общение между 10 людьми является гораздо более серьезной проблемой, чем общение между 3 людьми: 3! << 10 !. В то время как вы, вероятно, можете немного запутаться, но в конечном итоге вам придется внести некоторые изменения, чтобы улучшить взаимодействие между разработчиками и убедиться, что принципы, разработанные первоначальными 3 разработчиками, были распространены среди новые люди и обновлены, чтобы хорошо работать в вашей новой большой группе. Посмертные встречи проекта - один из способов сделать это; периодические проверки кода являются еще одним. Не мешало бы отметить, что посмертные встречи являются важной частью повышения качества в отраслях от медицины до производства.

Трудно представить, что ваш менеджер считает, что он может расширить свою команду разработчиков, просто наняв дополнительных людей. Там обязательно должны быть некоторые инвестиции в обучение и построение команды; без этого ваша организация рухнет под собственным весом. Если вы немного подождете, ваша организация может начать сталкиваться с некоторыми конкретными проблемами, которые напрямую связаны с плохой связью. В этот момент ваш менеджер, вероятно, скажет: «Мы должны собрать всех на одной странице! Запланируйте встречу со всеми разработчиками!» И если это кажется полезным, он, вероятно, скажет: «Мы должны делать это после каждого проекта!» ;-)

Так что будьте терпеливы, но будьте настойчивы.

Скажу тренд: я согласен с менеджером.

Я нашел постпроектные обзоры в значительной степени бессмысленными, потому что слишком поздно что-либо делать, чтобы исправить выявленные проблемы.

Что я очень рекомендую, так это периодические ретроспективы, сделанные во время проекта. Раз или два в месяц команда должна говорить о том, что прошло хорошо, а что нет; что делать больше, что делать меньше. Сделайте это во время проекта, чтобы вы могли сразу применить предложения и посмотреть, насколько хорошо они работают.

Посмотрите на фальсификацию встречи. Многие постпроектные встречи - ток-фиесты, и ваш менеджер абсолютно прав, чтобы не поддерживать их.

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

Мы используем, и я рекомендую процесс рецензирования де Боно «6 мыслящих шляп» ( см. Википидия ). Результатом является несколько (2 или 3) пунктов действий, которые собрание определяет как наиболее важный изученный урок. Первые несколько раз у нас были проблемы с выходом из стартовых блоков, но как только мы к этому привыкли, больше не вернемся.

Отсутствие послепроектной проверки обрекает вас на те же ошибки, что и в предыдущем проекте.