Comments 25
Берите выше, управление рисками на проектах часто вообще отсутствует как понятие.
Вместо этого "ребята, жжем, а там что получится".
Такое, само собой, бывает. И чаще со стороны заказчиков. Разработчики, наоборот, часто пытаются проговорить, а что может пойти не так, однако не формулируют свои опасения как риски :)
Я стараюсь три оценки давать: если всё как по маслу, экспертную (более реальную), и если всё пошло совсем не так. Это оптимистичная, экспертная, и пессимистичная оценка.
Пессимистичная оценка обычно очень страшная, и менеджеры боятся её брать, потому что с ней все сроки вот выходят.)
Т.е. все риски сразу включены в пессимистичную оценку? :)
Максимум из всего, что можно предположить.
Звучит как перевод в другую размерность "ребята, жжем, а там что получится". Т.е. рисков как бы нет, но они как бы есть в пессимистичных оценках :)
Вот, например, надо дверь в машине поменять. На такую же, только новую.
Делов то, открутить и прикрутить.
Это оптимистичная оценка.
По опыту знаем, что там может быть мелочь, которая не даст нормально снять дверь, и это еще +1 день работы. Это реалистичная оценка.
По факту с завода может прийти дверь нового образца, а там могут быть и отверстия не те, и соединения не как надо, и придется брать болгарку, резать, варить, полировать, красить, и так далее. Это пессимистичная оценка.
Так вот, есть здесь риски в пессимистичной оценке, или нет?)
Если не закладывать эти риски, то это необработанный риск и срок может улететь в отдельных сценариях.
Именно в этом для меня состоит самый интересный момент вокруг рисков:
кто-то думает, что замена двери пройдет гладко
а кто-то будет ожидать, что при замене обязательно что-то пойдет не так :)
Разные люди для одной и той же задачи могут озвучить разные оценки и разные риски. И, как мне кажется, это подход на основе установки "стакан наполовину полон или стакан наполовину пуст". Однако если оценивать так, то как другому человеку понять, из-за чего могут быть дополнительные работы при установке двери? :)
Т.е. рисков как бы нет, но они как бы есть в пессимистичных оценках :)
Не совсем верно. Риски есть двух типов: положительные и отрицательные.
Положительные, если сделали раньше, быстрее и получили какой-то ресурсный "профит".
Отрицательные, если позже, большими ресурсами или вообще не сделали.
В принципе как положительные так и отрицательные риски "не есть хорошо", особенно если "неожиданные" и говорят о не качественном планировании.
Хотим посидеть по человечески и отдохнуть без приключений - это идеальный план.
Положительный риски - один не пришел, бухло осталось, и еще осталась закусь и все отрубились\ужрались.
Отрицательный риск - закусь закончилась раньше бухла и все ужрались в хлам закусывая одной печенькой.
Общий реестр рисков: бухать нельзя по закону, нет бабла, негде купить бухло или закусь (время), негде бухнуть, не пришел кто-то, нет закуси, нет бухла. не хватит бухла, не хватит закуси, аллергия на закусь, антибиотики, здоровье, кто-то "выжрет" в одно рыло,и т.д. все-что-придет-в-голову.
Как-то так :)
В последней версии CMMI положительные риски выделены в отдельную категорию как opportunity :)
Однако согласен, за всеми возможными и вероятными проблемами как-то забывается, что риски могут давать и положительный эффект.
Вы сравниваете реальные получившиеся цифры с оценкой, и называете это "положительные" и "отрицательные" риски = успели, или нет.
Риск это всегда минус. Если он срабатывает, он занимает время. В противном случае это не риск, а оптимистичный сценарий, а остальное уже остановится рисками )
Вобщем, переверните картинку, всё сильно проще J
Давно пришел к трактовке риска как антипода Feature, все в беклоге, все с привязками к эпикам и все задачи которые так или иначи влияют на риск - имеют явно указанную с ними связь через Task Relations. Risk Register никуда не делся, Risk Evaluation и Risk Mitigation регулярно пересортируют риск по влиянию и вероятности с учетом принятых на текущий момент времени мероприятий и уточненных сведений. Custom Fields и импорт/экспорт в Эксель для OpenProject.org решают.
Имеется в виду риск как отдельная сущность в таск трекере? А реестр рисков как я понял собирается/экспортируется автоматически?
Имеется в виду риск как отдельная сущность в таск трекере?
Мы делали отдельную сущность риск, и к ней привязывали Task. Тогда можно было объяснить, откуда взялся Task и почему на него ресурсы списываются. Иначе получается Task из "астрала"...
Для Gap делали так же, для багов делали так же. Свой процесс.
А реестр рисков как я понял собирается/экспортируется автоматически?
По сути ничем не отличаются от "Feature". Импорт экспорт зависит от системы управления. А собираются риски "руками". Отдельная задача процесса.
Так точно.
Такой подход единообразно для всех проектов применяется или с адаптацией в зависимости от каких-нибудь условий? И все проекты ведутся в OpenProject?
OpenProject или нет не столь важно, проекты могут быть и в JIRA, и в ProjectPlace, и Wrike, и ASANA. Суть лишь в том, что риск порождает задачи и влияет на эпики. Из OpenProject очень удобно экспортировать в эксель, который всем так приятен и знаком. OpenProject Community Edition не просит денег сразу, а лишь потом, когда подрастешь можно думать об Enterprice Edition. И самое приятное, у всех участников есть простой и понятный To-Do List ввязанный в иерархию проекта со всеми необходимыми связями.
управление рисками на проектах часто вообще отсутствует как понятие.
Просто не догадываются о таком понятии, не говоря уже о процессе.
Практика показывает, что во многих проектах, особенно работающих по методологии Agile, традиционный подход с полноценными выделенными шагами по идентификации, анализу, планированию, мониторингу и контролю рисков, не пользуется популярностью.
Вообще-то умными людьми он встроен в процесс в виде "покера"
In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
Это не сильно отличается от комбинации методов "метода экспертной оценки"+"прецедентов" + частично "Business impact analysis". Однако особо "одаренные" личности такие нюансы выкидывают нафиг. И получается что получается.
Как говорится - учите мат часть.
Пишите в комментариях, приходилось ли вам упрощать ваш реестр рисков и как.
Не часто приходилось его собирать. Воспринималось в штыки, как пустая трата времени "крутых пацанов, которые никогда не косячат".
Как говорится - учите мат часть
В общем и целом я согласен, что все новое - это хорошо забытое старое :)
Не часто приходилось его собирать. Воспринималось в штыки, как пустая трата времени "крутых пацанов, которые никогда не косячат".
У нас, однако, есть требования СМК связанные с ISO 9001/TL9000/CMMI и из них формальные требования к процессу управления рисками. Поэтому до какой-то степени то, что я написал - это попытка совместить реальность с формальностью :)
У Вас нет формулировки понятия "риск". Все, что вы включили в перечень "рисков" к рискам никакого отношения не имеет. Это обычные технические и организационные проблемы. Впрочем, их даже проблемами назвать трудно, так как они связаны с плохим управлением проектом или даже просто с разгильдяйством сотрудников и, в первую очередь, руководителя проекта (РП).
В Вашем случае риск один - РП не хватает квалификации.
Формулировку понятия риск я действительно не включил. Или комментарий про приведенные примеры проектных рисков?
Ну, так включите. И тогда Вы поймете, что написали не о рисках, а о каких-то текущих проблемах. Отличие: риск - это события во внешней среде (обычно), на которую Вы можете оказать небольшое влияние. А проблемы - это события в Вашей обстановке, которую Вы сами формируете. Риски надо обходить, а проблемы - решать и желательно до начала проекта.
И не надо "упрощать реестр рисков" - попробуйте их не придумывать.
Возможно ли отказаться от использования классического risk register?