Риски проекта пример
Риски проекта примерКак не допустить, чтобы риски проекта влияли на бизнес
=== Скачать файл ===
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа. Но проектов без рисков, наверное, не существует в природе и с ними так или иначе приходится работать. О том, как это делать, можно прочесть в PMBOK , на википедии и на тематических ресурсах. В этой статье больше практики, чем теории. Ее цель — показать на примерах недорогой и эффективный подход к управлению рисками проекта. Риск менеджмент план PMBOK рекомендует управлять рисками в 4 этапа: Выявить риски, которые могут помешать целям проекта. Определить, какие из выявленных рисков наиболее опасны. Спланировать наиболее опасные риски. Поддерживать план проекта и список рисков в актуальном состоянии. Бизнес-модели авторов , публикаций. Управление персоналом автора , публикаций. Фриланс авторов , публикаций. Управление сообществом 72 автора , публикаций. Управление проектами авторов , 2,2k публикаций. Венчурные инвестиции 72 автора , публикаций. Развитие стартапа авторов , публикаций. Криптовалюта Dash приглашает… взломать свой блокчейн 1,6k Добавить в закладки Вадим Тиканов vadimdne карма. А можно поподробнее о NIST и причём тут управление рисками? Увольнение — это маленькая смерть. Как сохранить ценного специалиста решившего уволиться? Особый плюс в карму: Фактически вы описали методологию сценарного планирования , которая как раз и оценивает вероятности событий и их последствия. Я веду жж-сообщество на эту тему, запощу сейчас ссылку на вашу статью, если вы не против. Например, небрежность в оформлении. Элементарная вежливость в виде расшифровок аббревиатур при первом применении отсутствует напрочь. Вперемешку употребляются русские термины, слэнговыы словечки лиды и английские. Ну и самое главное — уверенность в том, что обобщенное описание каких-то процессов, в котором нет ни одной привязки к конкретным задачам и проблемам, кому-нибудь поможет. А при чем здесь молодые начальники? Такие ошибки коррелируют не только с начальниками: А по-поводу последнего пункта, самого главного, почему вы сами так уверены в правильности своего мнения? У других ошибки не так заметны. А с начальника и спрос другой. Ошибки совершают все, а начальники просто больше других обязаны на них ошибках учиться, что, возможно, автор статьи и делает: Я, если честно, ошибок в контексте статьи так и не увидел. Сленг местами действительно есть, но он не критичен. Картинки это скрины реального риск листа в живом проекте. В общем, если есть замечания по сути статьи, готов обсуждать, пока предмета обсуждения не вижу. PMBOK с его формулировками и обощениями, безусловно красив как академический труд. На практике управление проектами даже среднего размера, редко приходит к таким детерменированным проблемам и способам их решения. Балансирование между целями и ограниченими проекта, делает списко рисков, обычным списком проблем, а не инструментом управления. Уж лечше перечить раздел PMBOK про управление stakeholders. PMBOK это опыт полумиллиона руководителей проектов, собранный в течение 40 лет. Католическая церковь имеет более милиарда приверженцев, среди них президенты, выдающие ученые, опытные руководители проектов — это ли не аргумент в пользу верности Библейской трактовки? PMBOK не более чем академический труд, с определенной долей верности описывающий рекомендуемую общую практику. К тому же PMBOK не специализирован. Предложение по управлению проектом по разработке програмного обеспечения с помощью управления рисками, по крайней мере вызывает сомнение. Менеджмент не точная наука, к тому же связанная с управлением людьми. Работа с людьми, и их целями это чаше балансированение, чем пошаговое решение проблем. Я в управление рисками не верю. Хотя сам около года занимался этим достаточно плотно, был консультантом консультантов по управлению рисками, скажем так. Хотя в основе идеи лежат весьма здравые постулаты, но на практике результат недостижим в части отраслей и областей. Может и нигде, не знаю. Всех интересующихся отсылаю к книге Нассима Талеба ' Черный лебедь ', а от себя приведу два примера: Они описывали, выявляли и управляли рисками. МОСКВА, 12 авг — РИА Новости. Мосгорсуд в среду приговорил бывшего главу Федерального фонда обязательного медицинского страхования ФОМС Андрея Таранова к семи годам лишения свободы в колонии строгого режима и к штрафу в размере 1 миллиона рублей, передает корреспондент РИА Новости из зала суда. Остальных фигурантов громкого дела о коррупции в ФОМС, на основе ранее вынесенного обвинительного вердикта присяжных, суд приговорил на сроки от 1,5 до девяти лет лишения свободы. Этот риск учтен не был скорее всего, я деталей их кухни не знаю. Позвольте же вас спросить, как же может управлять человек, если он не только лишен возможности составить какой-нибудь план хотя бы на смехотворно короткий срок, ну, лет, скажем, в тысячу, но не может ручаться даже за свой собственный завтрашний день? Неужели вы скажете, что это он сам собою управил так? Не правильнее ли думать, что управился с ним кто-то совсем другой? Первый же серьезный неучтенный риск ломает всю эту стройную систему. Скорее искать баланс в ее использовании. В статье описан метод ее весьма глубокого внедрения, с довольно большими трудозатратами, но не раскрыты ее слабые стороны. Трудозавтраты составляют 60 часов в месяц, на команду в 15 человек. Риск-менеджмент придумали изначально большие дяди для больших корпораций. Потом средние дяди из средних компаний решили, что они не хуже. Имеет смысл занятия ради занятия. С таким отношением вам должно быть сложно переходить улицу, потому как даже если там не будет машин, все равно на голову может упасть метеорит. А раз нельзя безопасно перейти улицу черный лебедь заклюет , то и правила дорожного движения со светофорами не нужны? Почему небольшая вероятность возникновения какого-то фатального непредсказуемого риска должна заставить нас отказатся от работы с известными рисками? Талеб нынче популярен, но его теория не очень то конструктивна. Талебы как гиены существуют за счет других видов, охотясь за редкими событиями. Вы как-то слишком увлеклись законами Мёрфи и забыли про типичные вероятности. Да — кирпич на голову упасть может хоть сейчас, но вероятность этого на несколько порядков меньше, чем вероятность того, что накроется сервер в пиковый момент. Прямо анекдот какой-то развели про вероятность от мужчины и женщины с динозавром. Серьезный неучтенный, но реализовавшийся риск ломает систему. Не управляя рисками, мы имеем полное множество неучтенных рисков так как не учитываем никакие из них. Управляя рисками, мы имеем множество неучтенных рисков меньше. ИМХО, именно на это и направлено управление рисками. Но ведь риск-менеджмент не об этом, а о том, чтобы учесть хотя бы часть значимых рисков и тем самым увеличить вероятность успеха. Отрицать управление рисками — значит полностью полагаться на случай. Вот вам мой любимый пример: Вы ведь перед перекрестком притормаживаете, не так ли? Или, полагаясь на случай, педаль в пол? Если у меня будет выбор, проверить тормоза перед выездом или заняться вместо этого расчетом риска встречи с оболбанным нарком на перекрестке — я тормоза проверю. Во-вторых, уважаемый мною Т. Вообще если так рассуждать, то действительно можно совсем ничем не управлять. А просто полагаться на волю случая. Сам Таллеб пишет с одной стороны о том, что есть ассиметричность случайности и как следствие ассиметричность ожидания от этой случайности. С другой стороны о том, что предпринимая хоть какие-то действия мы увеличиваем вероятность успешного исхода событий. Да, выгода это тоже вероятность, поэтому Тостой лучший писатель, нежели миллион обезъянок. Он как трейдер предпочитает играть по стратегии положительной ассиметрии не знаю как это называется научно , а чаще всего наступает событие с глубоким отрицательным ожиданием… Вот тогда все управление рисками — в баню. Мониторинг и контроль — всего лишь 30 минут для команды из 15 человек? Вы о багтрекерах слышали? О каком управлении рисками можно говорить если вы бездумно тратите время команды на бесполезные митинги и явно ошибаетесь с оценкой на время контроля? Могу расписать подробно, но смысла не вижу. Первый абзац — вообще финиш. Чисто так для сравнения: Это — не риск. Время на сборку должно быть заложено изначально. Вы должны это делать или нет? Если должны поддерживать Mac, то время на тестирование должно быть заложено изначально. Если не должны, то вас это не должно волновать. Это — работа ваша и, иногда, лидов. Риском никак являться не может 4. Этот риск вне вашей компетенции. За это ответственен админ. Подобные вещи должны входить в резерв, который вы в любом случае обязаны закладывать. Прописывается в договоре сразу. Во-первых, узкие места не поменяются. Так что проблем тут не будет. Во-вторых, должны было быть заложено время на апгрейд сервера с самого начала. В-третьих, проблема может быть в разных конфигурациях софта серверов. В этом случае надо при старте проекта сделать схожие конфигурации. Оговаривается в договоре Это проблема тех, кто оценивал время на тестирование. Во-вторых, про ваши подсчеты: Время на митинги можно смело умножать в 2. К ним нужно готовиться, нужно прерывать текущую задачу, нужно выпить кофе после митинга, нужно включиться в работу после кофе. В зависимости от сложности проекта и опытности команды иногда случается так, что время и силы, затрачиваемые на сборку, возрастают. Вспомнить о том, что мака до сих пор нет, иногда полезно. Статус у тикетов могут не обновлять, потому что, например, есть более приоритетные тикеты. Если у команды есть подозрение, что большинство из этих тикетов не вполне соответствуют текущему состоянию дел, и можно их сильно подвинуть в приоритете — стоит их протестировать и обновить статус. Админ или тот, кто выполняет его роль может входить в команду проекта а иногда и не один ;- 5. Также, вы утверждаете, что все риски надо планировать, тогда они не случатся. Но вот беда в том, что все запланировать сразу не получится, и обязательно что то вылезет. Так вот автор нам как бы рассказывает о том, как надо строить работу, чтоб последствия от непредусмотренных ситуаций были минимальными. С этой задачей ну, как мне кажется статья тоже очень даже хорошо справляется. ПМ со стажем проектов на 50к человеко-часов смотрим профиль автора не может запланировать время на сборку? Ну приняли решение либо делать, либо не делать. Не входило в изначальную оценку? А резерв на что? Сколько времени будет обновить статусы тикетов? Это не риск, а банальная организация процесса разработки. Надо проверить статусы, тратиться время из резерва. И делается втык что статусы не поддерживаются в актуальном состоянии. Тогда админу надо дать много человеко-часов с запасом, так как в большинстве случаев он может работать параллельно команде. Я не говорю что все можно запланировать. Я говорю о том, что не надо тратить в пустую время своей команды. Ради чего тратятся эти человеко-часов в месяц? Если что-то не было учтено изначально, то будет переоценка. Я предлагаю не списывать ошибки в риски, а признавать их ошибками и переоценивать сроки. ПМ получает зарплату за то, что риски его проекта выявляются и погашаются до того, как становятся проблемами, а проект не сдвигается по датам. На погашение рисков не нужно время? Вы это самое время возьмете либо из резервов, либо измените сроки. Именно для этого вам и нужны митинги, чтобы о проблемах и что с ними делать вам сообщали разработчики. Так вот работа любого менеджера — не пинать команду постоянно, а построить процесс так, чтобы работа шла максимально без его участия. Да, придется долго вдалбливать в головы надобность сообщать о проблемах на как можно более раннем этапе. Никому не нужны вероятности. Конкретный результат к конкретному сроку. Это — не высший пилотаж. Это — непонимание целей вашего работодателя и вашего заказчика. Просто приведу небольшой пример: Если же ваша фирма — сама себе заказчик, то в любом случае есть планирование бюджета. Причем планирование не только на этот конкретный проект, а вообще на все. Если не успеть, то надо так и сказать. Либо вы можете успеть и говорите об этом, либо не можете. Я с ней полностью согласен. Но в своей статье вы отнюдь не лучшим образом предложили решить эту проблему, а примеры у вас еще хуже. Я — технический директор, девелопер в прошлом. Поэтому я привожу слабую аргументацию. Тем не менее, по вашей схеме мне бы не хотелось работать ни в роли разработчика, ни в роли вашего начальника. Для меня это самое главное. Возможно, вы просто неудачно расписали как это происходит у вас. От вашей статьи и комментариев я делаю вывод, что борьба с рисками — это ваше все. Но это — далеко не единственная задача PM. И зачастую не самая главная. Я кагбэ о том, что любой из этих пунктов может быть как риском, так и не риском — все зависит от проекта, команды и ситуации в какой то момент времени. Абсолютные оценки тут не подходят. Опять же, в зависимости от команды может быть очень даже эффективно тратить человеко-часов в месяц. И эффективно ли их тратить вообще в принципе или сколько их тратить, и тратить ли вообще — это вопрос, который в данной статье не рассматривается. Здесь говорится про то, как их тратить. Достаточно ти минутных совещаний — не тратьте час. Хотел бы добавить, что я предпочитаю сам отвечать за свои ошибки. Если проект не уложился в заложенный резерв, то отвечать за это мне. Проблема в том, что бюджет не резиновый и я не могу закладывать время на падения сервера, к примеру. И человек в любое удобное для него время без отрыва от работы это сделает. Можно все же конкретную статистику по работоспособности вашей схемы? Упомянутый мной Денис Войханский в одной из своей статей или подкастов как раз на эту тему высказал примерно следующее: Управление рисками — полезно. Но на этом свет клином не сошелся. В проектах свет клином не сошелся на одних разработчиках. Есть и другие члены команды: Их всех Вы тоже в багтрекер загоните??? Я тоже был удивлен увидев в примеров вместо рисков какие-то текущие конфигурационные проблемы. У демарко в другой книжки был генерал-ПМ, который считал одним из главных принципов управления — минимизация потерь. Тут больше такая ситуация — анализируются список текущих проблем и предлагаются решения как их улучшить. Полезно, но риск-менеджмента именно здесь не много. Единственно чего не увидел — это денежного выражения рисков. При реализации какого-то риска необходимы какие-то действия: За все это необходимо платить деньгами. Классика расчетов это определение суммы для каждого риска, которая надо на его устранение. Сумму умножаем на вероятность. Но полностью с Вами согласен, так как сам оперирую лишь трудозатратами. С умом надо использовать управление рисками. Ставить их во главу угла, мне кажется, опасно! В целом поддерживаю автора, статья адекватная! А почему не рассказали про стратегию Avoid, то есть избегание риска? А как же планирование, контроль, коммуникации? Метки лучше разделять запятой. Сейчас Вчера Неделя \\\\\\\\\\\\[UPDATED 2\\\\\\\\\\\\] Сначала они воруют, а когда ты побеждаешь, то тебя убивают 58,6k Сравнение REST и GraphQL 5,4k JavaScript как явление 33,3k Интересные публикации Хабрахабр Geektimes. Криптовалюта Dash приглашает… взломать свой блокчейн. ML Boot Camp V, история решения на 3 место. Очень легкая система мониторинга с Телеграмом и Консулом. Разбираемся в физике частиц: Как бороться с дублированием кода? Что творится с HEVC h Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
Правила перевозки сыпучих грузов автомобильным транспортом 2016
Расписание камышинский колледж
Определяемое и определяющее понятия в логике
Публичная кадастровая карта крыма 2016 официальный сайт
Гидростатические характеристики корпуса судна