Здравствуйте, Ziaw, Вы писали:

nvb>>Например, отказ заказчика оплачивать доп.изменения. Или, что одно и то же, полная апатия заказчика до окончания проекта и масса требований переделок по его завершению...

Это не одно и то же, тут я не подумал, извиняюсь.

Z>А как вообще бороться с такими рисками? Закладывать в стоимость решения? Бывают же компании с которыми уже работали и эти риски срабатывали. Как быть с ними дальше?
Z>Как исправлять ситуацию, когда видно, что риск сыграл, но сроки и цены заказчик увеличивать не желает?

Ну, для начала заказчику, совершенно открыто, показывают список проблем из прошлого проекта (если он составлен), с их себестоимостью, и предлагают это обсудить. Обычно заказчик удивляется, что они вообще существуют — он-то их не замечал, и не понимает, например, что любое, сколь угодно мелкое, изменение конфигурации влечет за собой прогон массы тестов и внесение изменений в кучу документов. И только потом предпринимается попытка перенести эти риски на заказчика через контракт. Согласитесь, что заказчик, имея такой список перед глазами, будет реагировать на предложение увеличения сроков и цены более благожелательно, чем на фразу "Вы в прошлом проекте внесли массу изменений, поэтому давайте на этом проекте увеличим цену в полтора раза".

Ну, а если не соглашается и после этого — надо считать себестоимость выполнения контракта для себя с учетом рисков из прошлого проекта, и если получается себе в убыток — решение очевидно.

Еще есть иллюзия, что себестоимость в таких случаях можно сократить за счет отказа от полнофункционального тестирования, но она обычно рассыпается, когда в проекте начинают учитывать стоимость "бесплатной" поддержки продукта у заказчика. То есть по срокам-то укладываются, а вот по деньгам — пролетают, плюс отнимают спецов из других проектов.

Если выражаться околонаучно , лучше визуализировать и оценить модель рисков в документе, поскольку, пока она существует только в голове у РМа, объяснить ее заказчику (да и своему руководству тоже) на словах — занятие трудное и неблагодарное. Они будут считать РМа — совершенно справедливо, со своей точки зрения — раздолбаем, который просто не умеет управлять проектами.

Кстати, совершенно не обязательно увеличение сроков и цены — единственный выход. Если в контракте прописана процедура внесения изменений, то для заказчика вводить изменения становится довольно-таки затратно с точки зрения времени, и он минимизирует их число до необходимого минимума, объединяет их в пакеты, сокращает количество людей, которые могут инициировать изменения и т.д. Полностью поток изменений это не прекратит, да это и невозможно, но их количество и частота сократятся резко.