Comments 9
Тут, наверное, играет роль размер проекта. Такой подход отлично подойдет для огромных проектов, и будет лишним для небольших и средних.
Когда стало понятно что будет 0.43, может лучше сразу сходить в казино всей компанией?
:)
:)
Статья заслуживает внимания, но подсчет вероятности связанных событий, как вероятности независимых, выглядит более чем странно, поэтому конечные цифры не вызывают доверия.
Вообще, смысл риск-менеджмента — предотвратить и уменьшить вероятность или тяжесть последствий риска, и проактивно ;) его мониторить. Сказать «У нас на проекте есть риск, что мы недооценили три фичи, поэтому, если что, я об этом говорил и не виноват» и на этом успокоиться — это не совсем про управление рисками. Это я типа на троллинг повёлся.
А если серьёзно, рассчёты «воронки проектов» — вещь предельно полезная для планирования.
Но в цифрах есть один нюанс:
Если разбить один большой этап на десять маленьких, вероятность успеха каждого будет выше, чем у исходного… (Ой, кажется я только что изобрёл agile). Какова вероятность сфэйлить 20-недельную «итерацию»? А 10 двухнедельных? А этапов будет аж на 9 больше.
Возможно, конечно я не понял призыв «не путать этап с итерацией». Тогда непонятно, как можно разбить задачу «Разработка дизайна домашней страницы» на несколько этапов.
А если серьёзно, рассчёты «воронки проектов» — вещь предельно полезная для планирования.
Но в цифрах есть один нюанс:
Если разбить один большой этап на десять маленьких, вероятность успеха каждого будет выше, чем у исходного… (Ой, кажется я только что изобрёл agile). Какова вероятность сфэйлить 20-недельную «итерацию»? А 10 двухнедельных? А этапов будет аж на 9 больше.
Возможно, конечно я не понял призыв «не путать этап с итерацией». Тогда непонятно, как можно разбить задачу «Разработка дизайна домашней страницы» на несколько этапов.
Даже вот это «смысл риск-менеджмента — предотвратить и уменьшить вероятность или тяжесть последствий риска, и проактивно» только половина риск-менеджмента. Так как есть еще «хорошие» риски или «положительные», или еще лучше opportunity. Вероятность которых как раз пытаются максимизировать и превратить в реальность.
Еще интересно, что имеется в виду под «крупным проектом»? Сколько это в человеко-месяцах?
Из статьи сложилось впечатление, что выполняются примерно одни и те же задачи (с функциональной точки зрения) или сильно похожие. Так как их уже было сделано какое-то количество, и набор рисков всегда примерно одинаковый, и все о них знают, то кажется, что риск-менеджмент не нужен.… хотя, руководители проектов какие-то риски наверно все равно отслеживают (есть же такие, вероятность которых не зависит от количества итераций и/или их длительности). :)
Еще интересно, что имеется в виду под «крупным проектом»? Сколько это в человеко-месяцах?
Из статьи сложилось впечатление, что выполняются примерно одни и те же задачи (с функциональной точки зрения) или сильно похожие. Так как их уже было сделано какое-то количество, и набор рисков всегда примерно одинаковый, и все о них знают, то кажется, что риск-менеджмент не нужен.… хотя, руководители проектов какие-то риски наверно все равно отслеживают (есть же такие, вероятность которых не зависит от количества итераций и/или их длительности). :)
Не совсем вероятность успеха каждого, но с направлением мысли согласен. Есть книга, Мишин, «Проектный бизнес», где он описывает этот механизм — много мелких и одинаковых по времени задачек в сумме дают меньшую ошибку по срокам (или бюджету, или отклонению от требований), чем одна большая.
Снижает риски «не уложиться в оценку» (хорошо).
Повышает риск «невыпуска» проекта в полном объеме от изначально задуманного (плохо) и добавляет тяяягомоооотины (очень-очень плохо).
А почему бы не сделать ряд этапов внутренними. То есть для клиента этапа три, а для исполнителя — девять.
С другой стороны кстати посмотрите на «риск невыпуска проекта в полном объеме». Откуда вы знаете, может быть выстрелит другой, более рентабельный проект, это раз, с другой стороны, аккаунты и аналитики в таких случаях должны работать над тем, чтобы проект пошел по новой.
Я, честно говоря, не совсем понял — в чем тут «value»?
У меня никогда не было таких этапов в контрактах — Дизайн, Верстка, Кодинг. Как то мои клиенты предпочитают функциональные этапы, типа «создание каталога товаров», «процесс оформления покупки» и т.д. И тут ничего не сократишь, потому что этапы приводят к решению бизнес-задачи заказчика, за что они и платят. А вот я, да, плачу за дизайн, верстку, код, в рамках каждого отдельного этапа.
Я стараюсь соблюдать баланс. Если в контракте все сдается одним этапом — есть риск что в конце все равно не понравится результат, хоть мы все итерации пройдем гладко. Просто у заказчика к концу срока работ могут деньги кончится, или гендир поменяется. Это тоже риски :-) Если этапов будет слишком много — нас могут замордовать на соблюдении всех бюрократических процедур по многу раз, получаться слишком большие накладные расходы. Так и живу.
PS: О да, внутри этапа agile работает суперски
У меня никогда не было таких этапов в контрактах — Дизайн, Верстка, Кодинг. Как то мои клиенты предпочитают функциональные этапы, типа «создание каталога товаров», «процесс оформления покупки» и т.д. И тут ничего не сократишь, потому что этапы приводят к решению бизнес-задачи заказчика, за что они и платят. А вот я, да, плачу за дизайн, верстку, код, в рамках каждого отдельного этапа.
Я стараюсь соблюдать баланс. Если в контракте все сдается одним этапом — есть риск что в конце все равно не понравится результат, хоть мы все итерации пройдем гладко. Просто у заказчика к концу срока работ могут деньги кончится, или гендир поменяется. Это тоже риски :-) Если этапов будет слишком много — нас могут замордовать на соблюдении всех бюрократических процедур по многу раз, получаться слишком большие накладные расходы. Так и живу.
PS: О да, внутри этапа agile работает суперски
Sign up to leave a comment.
Бизнес студии: про этапы, деньги, калькулятор и канбан