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