Как мне кажется перечислены ошибки (и рекомендации), которые лучше не допускать любому соискателю на ведущую позицию (тимлмдера, архитектора, менеджера) в команде/проекте? И тогда остается вопрос - в чем же особенность интервью продукт-менеджера?
Именно в этом для меня состоит самый интересный момент вокруг рисков:
кто-то думает, что замена двери пройдет гладко
а кто-то будет ожидать, что при замене обязательно что-то пойдет не так :)
Разные люди для одной и той же задачи могут озвучить разные оценки и разные риски. И, как мне кажется, это подход на основе установки "стакан наполовину полон или стакан наполовину пуст". Однако если оценивать так, то как другому человеку понять, из-за чего могут быть дополнительные работы при установке двери? :)
Такой подход единообразно для всех проектов применяется или с адаптацией в зависимости от каких-нибудь условий? И тула соответственно всегда одна и та же?
В общем и целом я согласен, что все новое - это хорошо забытое старое :)
Не часто приходилось его собирать. Воспринималось в штыки, как пустая трата времени "крутых пацанов, которые никогда не косячат".
У нас, однако, есть требования СМК связанные с ISO 9001/TL9000/CMMI и из них формальные требования к процессу управления рисками. Поэтому до какой-то степени то, что я написал - это попытка совместить реальность с формальностью :)
Такое, само собой, бывает. И чаще со стороны заказчиков. Разработчики, наоборот, часто пытаются проговорить, а что может пойти не так, однако не формулируют свои опасения как риски :)
Как мне кажется перечислены ошибки (и рекомендации), которые лучше не допускать любому соискателю на ведущую позицию (тимлмдера, архитектора, менеджера) в команде/проекте? И тогда остается вопрос - в чем же особенность интервью продукт-менеджера?
Формулировку понятия риск я действительно не включил. Или комментарий про приведенные примеры проектных рисков?
В последней версии CMMI положительные риски выделены в отдельную категорию как opportunity :)
Однако согласен, за всеми возможными и вероятными проблемами как-то забывается, что риски могут давать и положительный эффект.
Именно в этом для меня состоит самый интересный момент вокруг рисков:
кто-то думает, что замена двери пройдет гладко
а кто-то будет ожидать, что при замене обязательно что-то пойдет не так :)
Разные люди для одной и той же задачи могут озвучить разные оценки и разные риски. И, как мне кажется, это подход на основе установки "стакан наполовину полон или стакан наполовину пуст". Однако если оценивать так, то как другому человеку понять, из-за чего могут быть дополнительные работы при установке двери? :)
Спасибо, с этим уточнением могу сказать, что видел такое в одном из наших проектов через JIRA.
Звучит как перевод в другую размерность "ребята, жжем, а там что получится". Т.е. рисков как бы нет, но они как бы есть в пессимистичных оценках :)
Т.е. все риски сразу включены в пессимистичную оценку? :)
Такой подход единообразно для всех проектов применяется или с адаптацией в зависимости от каких-нибудь условий? И все проекты ведутся в OpenProject?
Такой подход единообразно для всех проектов применяется или с адаптацией в зависимости от каких-нибудь условий? И тула соответственно всегда одна и та же?
В общем и целом я согласен, что все новое - это хорошо забытое старое :)
У нас, однако, есть требования СМК связанные с ISO 9001/TL9000/CMMI и из них формальные требования к процессу управления рисками. Поэтому до какой-то степени то, что я написал - это попытка совместить реальность с формальностью :)
Имеется в виду риск как отдельная сущность в таск трекере? А реестр рисков как я понял собирается/экспортируется автоматически?
Такое, само собой, бывает. И чаще со стороны заказчиков. Разработчики, наоборот, часто пытаются проговорить, а что может пойти не так, однако не формулируют свои опасения как риски :)