Что ж, возражения принимаются :) Сам в таких проектах не учавствовал, но вполне могу себе представить ситуацию, когда это будет работать. Скорее всего речь идет о выделенной команде, которая садится надолго на какую-то оффшорно-аутсорсинговую работу? В этом случае мы просто говорим о разновидности T&M контракта, где для удобства клиент платит некую "абонентскую" плату за услуги по разработке/поддержке. В этих условиях вполне разумно.
Похоже мы не совсем правильно друг друга поняли. Мой комментарий был ответом на Ваше замечание (во всяком случае так, как я его понял) о том, что выделение в проекте нескольких этапов с определенной стоимостью приведет к такому же количеству оплат, что неверно. Здесь мы вроде во всем разобрались :)
Насчет burn rate идея понятна, но сам подход, на мой взгляд, имеет ограниченную применимость. В условиях, когда состав и загрузка команды не меняется на протяжении проекта (часто в консалтинге) - может быть. В проектах создания/внедрения IT решений у Вас вначале может работать 2-3 человека на проектировании, в середине 10-15 на реализации, в конце 3-4 на тестировании и документировании.. В этом случае подход с использованием burn rate дает очень грубое приближение и, на мой взгляд, теряет смысл - клиент будет то хронически переплачивать, то недоплачивать (пусть тогда лучше платит по факту, каждый раз пересчитывать не проще..). Если мы понимаем объем работ, куда правильнее строить схему оплат и букирования исходя из Cost Plan'а проекта. Если не понимаем, варианта два - T&M контракт (если повезет) или разделение проекта на кусочки - определение объема работ отдельно (в идеале на T&M), выполнение - отдельно на условиях, согласованных по результатам исследования.
В описанном Вами варианте также клиенту придется платить ежемесячно, против чего Вы же возражали выше.. Ничто не мешает получить одну предоплату в начале и пока ее не "закрыли" ежемесячными отчетами и актами по трудозатратам (если мы говорим о T&M контракте) или закрытием этапов (FP/FFP контракты), следующих платежей можно не делать, хотя это вопрос договоренностей - кому-то действительно может оказаться удобнее платить небольшую сумму ежемесячно.
Вопросов у меня к Вам нет, если возникнут - обязательно напишу :)
Всегда лучше иметь возможность требовать, в соответствии с грамотно составленным договором, и не пользоваться ей, потому что заказчик уж очень любимый, чем наоборот :) Проверено.
На всякий случай хочу предостеречь против типичной ошибки - не путайте платежи со стоимостью отдельных кусков работы! Они могут быть совершенно разные.
Например, платежей может быть два: 50% предоплата и 50% по финальным актам (хотя это и не самый удачный вариант). Этапов же может быть 5-7 и их стоимость может быть прописана отдельно, исходя из ваших оценок стоимости ресурсов на реализацию данного этапа.
Совсем корректный вариант - это когда вы "ни разу" не работаете на клиента за свои деньги - предоплата покрывает начало работ, как только несколько этапов, укладывающихся в эти деньги выполнены, к очередной вехе должна быть привязана следующая оплата, покрывающая несколько следующих кусков и т.п. Таким образом количество платежей и их величины могут быть подобраны так как нужно. Опять же, всегда есть возможность остановить работы, если не получена соответствующая оплата, а не кредитовать клиента из собственных средств, что вообще говоря - нонсенс, особенно в больших проектах.
Угу, причем в большом количестве :) Насколько я понял в основе идеи - весы, изменяя вес камней на одной стороне весов можно изменить громкость, на другой - частоту. Как концепт интерфейса - очень интересно, но вот как настроиться на любимую станцию в первый раз и что делать, если таких станций несколько? Похоже либо носить мешок с камнями нужного веса, либо потратить первую половину дня на пляже на перебор того, что валяется под ногами... :)
Насчет приоритета отношений: все это хорошо до тех пор пока не происходит ситуация описанная выше - смена людей в команде заказчика или поставщика решения (типично для проектов от полугода и более). Или же ситуация более типичная для отечественных заказчиков - уход в несознанку (Я такого не говорил, вы профессионалы не объяснили мне и т.п.) Если в такой ситуации документации ноль - работать становится очень некомфортно..
Мы говорим про классическую итеративную разработку или ее agile вариант? В первом случае окончательное решение всегда известно. Стоимость соответственно тоже можно определить (см. напр. RUP), в случае agile работать на fixed price в моем понимании просто невозможно.
Я бы это назвал управление ожиданиями (хотя несовпадение ожиданий - однозначно риск :)). На мой взгляд PM'у имеет смысл плавно, постепенно и постоянно готовить ключевых стейкхолдеров клиента к конечному результату и постоянно проверять обратную связь. А поняли-ли? А на контрольные вопросы как отвечают? и т.п. В этом случае полученный ими результат не будет сюрпризом и таким образом можно минимизировать тот самый риск несовпадения ожиданий.
Еще один tip насчет повышения внимания. Из моего опыта полезно в документы, типа ТЗ/спецификаций добавлять небольшой дисклеймер (большими буквами), что подписывая данный документ заказчик подтверждает, что он все прочитал, задал все вопросы, получил все ответы и согласен, что все изменения или дополнения к данному документу идут через процедуру управления изменениями со всеми вытекающими. Конечно удовлетвореность клиента проектом это гарантировать не может в том случае если он все-таки не понял, но опыт показывает, что практически ни один из клиентов мимо этой надписи просто так не проходит.. читают все-таки значит :)) Опять же, с юридической точки зрения (на самый худой конец) этот пункт опять же может подстраховать.
Подобная схема - это просто графическое представления одного из наиболее общих принципов, которым люди часто пользуются при решении более менее сложных задач - разложение сложной задачи на простые составляющие, не более того :) Как нарисовать это графически - дело десятое. Можно делать в Project, можно в MindManager, можно просто на бумажке (я, кстати, предпочитаю WBS Chart Pro, которая насквозь проинтегрирована в Project и позволяет из WBS очень быстро сделать расписание и наоборот. ИМХО Microsoft давно должен был приделать к пакету что-то аналогичное).
Более того, подобные схемы нужны далеко не только для самого первого и самого общего обзора. Выполнение оценки трудозатрат, построение расписания, возникновение каких-то более менее существенных изменений в содержании работ проекта будет всегда начинаться с пересмотра WBS (в широком смысле, не диаграммы), в каком бы виде она не была зафиксирована.
Представленная в статье диаграмма и есть WBS :) Отдельный вопрос насколько она хороша или плоха для конкретного проекта, здесь не обсуждаем.
Что касается планирования. Есть стандартный подход к планированию проекта:
1. Определение списка задач (и тут как раз обычно и формируется WBS)
2. Определение последовательности задач (Гантт в случае не очень сложного проекта или сетевые PDM или ADM схемы для каких-то громоздких проектов с многочисленными зависимостями)
3. Оценка трудозатрат/ресурсов (тип, количество)
4. Оценка длительности задач
5. И только теперь - разработка плана-графика/расписания (внешние и ресурсные ограничения и т.п.)
Так что не надо думать что WBS это и есть план-график/расписание, тем более путать ее с Ганттом. Это только один из шагов, хотя и один из наиболее важных, при создании плана проекта.
Абсолютно согласен с небольшой поправкой (+1 к сожалению не могу поставить :)): ИСР - это и есть WBS (официальный перевод на русский язык). Т.е. это одно и то же. Сроки (не совсем понимаю что имелось ввиду под срочностью), стоимость работ и т.п. все это уже дополнительная информация, которая может также использоваться на диаграммах.
В прошлом году видел похожий столик, толко он "возбуждался" от "услышанного".. :) Если за столом спокойный разговор - тихонько мерцает, если оживленный спор, начинается светопредставление.. Забавная игрушка.
А по-моему неплохая идея.. Если ребенку уже с 8 лет можно объяснить какие-то несложные алгоритмы, после чего он садится и создает что-то работоспособное - по-моему это хороший результат. На презентации этого "конструктора" в MIT один из создателей рассказывал, что у них есть целое направление работы с компьютерными клубами, где куча детишек с удовольствием что-то такое на нем творит.. Может, конечно, речь была об американских детях - наши начинуют в 5 и пишут сразу на ассемблере - но не все ж такие :)
А по-моему речь идет о довольно очевидных вещах, про которые написано много книжек, и которые так или иначе известны любому более-менее опытному руководителю проектов (взять, например, вот это: "Руководитель должен быть один" или "Проект нельзя запускать без ресурсов"). Посему, с равным успехом, эти правила можно было бы назвать правилами Иванова, Петрова и далее по списку..
Кстати, если интересуют аналогичные своды правил, почитайте еще вот это, рекомендую :)
Насчет burn rate идея понятна, но сам подход, на мой взгляд, имеет ограниченную применимость. В условиях, когда состав и загрузка команды не меняется на протяжении проекта (часто в консалтинге) - может быть. В проектах создания/внедрения IT решений у Вас вначале может работать 2-3 человека на проектировании, в середине 10-15 на реализации, в конце 3-4 на тестировании и документировании.. В этом случае подход с использованием burn rate дает очень грубое приближение и, на мой взгляд, теряет смысл - клиент будет то хронически переплачивать, то недоплачивать (пусть тогда лучше платит по факту, каждый раз пересчитывать не проще..). Если мы понимаем объем работ, куда правильнее строить схему оплат и букирования исходя из Cost Plan'а проекта. Если не понимаем, варианта два - T&M контракт (если повезет) или разделение проекта на кусочки - определение объема работ отдельно (в идеале на T&M), выполнение - отдельно на условиях, согласованных по результатам исследования.
В описанном Вами варианте также клиенту придется платить ежемесячно, против чего Вы же возражали выше.. Ничто не мешает получить одну предоплату в начале и пока ее не "закрыли" ежемесячными отчетами и актами по трудозатратам (если мы говорим о T&M контракте) или закрытием этапов (FP/FFP контракты), следующих платежей можно не делать, хотя это вопрос договоренностей - кому-то действительно может оказаться удобнее платить небольшую сумму ежемесячно.
Вопросов у меня к Вам нет, если возникнут - обязательно напишу :)
Например, платежей может быть два: 50% предоплата и 50% по финальным актам (хотя это и не самый удачный вариант). Этапов же может быть 5-7 и их стоимость может быть прописана отдельно, исходя из ваших оценок стоимости ресурсов на реализацию данного этапа.
Совсем корректный вариант - это когда вы "ни разу" не работаете на клиента за свои деньги - предоплата покрывает начало работ, как только несколько этапов, укладывающихся в эти деньги выполнены, к очередной вехе должна быть привязана следующая оплата, покрывающая несколько следующих кусков и т.п. Таким образом количество платежей и их величины могут быть подобраны так как нужно. Опять же, всегда есть возможность остановить работы, если не получена соответствующая оплата, а не кредитовать клиента из собственных средств, что вообще говоря - нонсенс, особенно в больших проектах.
Еще один tip насчет повышения внимания. Из моего опыта полезно в документы, типа ТЗ/спецификаций добавлять небольшой дисклеймер (большими буквами), что подписывая данный документ заказчик подтверждает, что он все прочитал, задал все вопросы, получил все ответы и согласен, что все изменения или дополнения к данному документу идут через процедуру управления изменениями со всеми вытекающими. Конечно удовлетвореность клиента проектом это гарантировать не может в том случае если он все-таки не понял, но опыт показывает, что практически ни один из клиентов мимо этой надписи просто так не проходит.. читают все-таки значит :)) Опять же, с юридической точки зрения (на самый худой конец) этот пункт опять же может подстраховать.
Более того, подобные схемы нужны далеко не только для самого первого и самого общего обзора. Выполнение оценки трудозатрат, построение расписания, возникновение каких-то более менее существенных изменений в содержании работ проекта будет всегда начинаться с пересмотра WBS (в широком смысле, не диаграммы), в каком бы виде она не была зафиксирована.
Что касается планирования. Есть стандартный подход к планированию проекта:
1. Определение списка задач (и тут как раз обычно и формируется WBS)
2. Определение последовательности задач (Гантт в случае не очень сложного проекта или сетевые PDM или ADM схемы для каких-то громоздких проектов с многочисленными зависимостями)
3. Оценка трудозатрат/ресурсов (тип, количество)
4. Оценка длительности задач
5. И только теперь - разработка плана-графика/расписания (внешние и ресурсные ограничения и т.п.)
Так что не надо думать что WBS это и есть план-график/расписание, тем более путать ее с Ганттом. Это только один из шагов, хотя и один из наиболее важных, при создании плана проекта.
Кстати, если интересуют аналогичные своды правил, почитайте еще вот это, рекомендую :)