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