Комментарии 15
Непонятно, почему нельзя выбрать несколько пунктов. Я бы отметил и "После завершения каждого проекта" и "Провожу по ходу проекта".
Текущий регулярный анализ в ходе проекта абсолютно необходимая вещь. Иначе процесс просто выходит из под контроля.
Суммарный анализ после завершения единственный способ не повторить совершенные ошибки в будущем.
Текущий регулярный анализ в ходе проекта абсолютно необходимая вещь. Иначе процесс просто выходит из под контроля.
Суммарный анализ после завершения единственный способ не повторить совершенные ошибки в будущем.
Согласен. Но как показывает практика, составленный документ по завершению проекта – редкость.
Поскольку лично с меня никто документ не требует я его не составляю. Но в органайзерах у меня по каждому проекта последних 6 (сейчас проверил) лет есть "финишные" записи: что лично я сделал хорошо/плохо, на что обратить внимание в следующем проекте. Примерно по 20 органайзерных страничек на проект.
Поскольку составляется для внутреннего использования, можно позволить себе более жесткий анализ. :)
Поскольку составляется для внутреннего использования, можно позволить себе более жесткий анализ. :)
Стараемся проводить после завершения, но не всегда получается
А если не секрет, почему?
Большой поток проектов или просто не принято?
Большой поток проектов или просто не принято?
обычно следующий проект недаёт его провести/подготовить, время уходит, и потом уже становится неактуально
А опыт может быть лишним или ошибки - не актуальными?
Я не в коем случае не придираюсь к словам.
С подобными ситуациями приходится сталкиваться очень часто.
Я не в коем случае не придираюсь к словам.
С подобными ситуациями приходится сталкиваться очень часто.
Ошибки актуальны, и выводы для себя думаю каждый делает сам
но сораться командой, провести совещание, свести это в формальный документ не всегда получается
я считаю что это нужно делать
но сораться командой, провести совещание, свести это в формальный документ не всегда получается
я считаю что это нужно делать
>> но сораться
но собраться
но собраться
Согласен, но при таком подходе есть одна проблема.
При отсутствии документа, с менеджерами из компании будет уходить и их опыт, которым не всегда можно поделиться при сдаче-приеме дел. В итоге процесс развития в управлении может двигаться крайне медленно. И на старых ошибках никто уже не сможет научиться.
При отсутствии документа, с менеджерами из компании будет уходить и их опыт, которым не всегда можно поделиться при сдаче-приеме дел. В итоге процесс развития в управлении может двигаться крайне медленно. И на старых ошибках никто уже не сможет научиться.
В ряде фирм для этого создается отдел, целью которого является настройка процессов внутри компании.
При формально прописанном процессе знания действительно накапливаются при условии, что эта группа заставляет всерьез относиться к составлению послепроектных отчетов и постоянно использует эти отчеты при подстройке процессов.
При формально прописанном процессе знания действительно накапливаются при условии, что эта группа заставляет всерьез относиться к составлению послепроектных отчетов и постоянно использует эти отчеты при подстройке процессов.
Да, мы еще с клиентами беседуем, что было хорошо, что плохо.
post mortem (так мы называем это собрание) в компании проводятся. Жалоко, что еще не удается вовремя и четко прописывать какие были допущены отклонения по срокам, а это очень часто является следствием удачных или не совсем нововведений и достижений.
Зачастую происходит так, что проект уже вроде бы как сдан, но по нему еще необходимо провести доработки, что усложняет проведение собраний.
По-моему, идеальным вариантом является учет менеджера всех проблем на проекте и как они решались, учет как нововведения повлияли на разработку. Это и стоит обсуждать.
Главное, все таки, спрашивать всех членов команды чего им не хватало, что понравилось, что хотелось бы изменить. Они то лучше всех знают, что нужно, что мешало и что нужно добавить. На это и советую всем обращать первоочередное внимание.
Зачастую происходит так, что проект уже вроде бы как сдан, но по нему еще необходимо провести доработки, что усложняет проведение собраний.
По-моему, идеальным вариантом является учет менеджера всех проблем на проекте и как они решались, учет как нововведения повлияли на разработку. Это и стоит обсуждать.
Главное, все таки, спрашивать всех членов команды чего им не хватало, что понравилось, что хотелось бы изменить. Они то лучше всех знают, что нужно, что мешало и что нужно добавить. На это и советую всем обращать первоочередное внимание.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проводите ли вы анализ проекта после его завершения (риски, ошибки, удачные решения)?