bas,
наше с Вами видение вопросов, оказывается, различается.
Раз уж Вы прокомментировали мои тезисы, то и мне для сопоставления придется.
1. Противоречие интересов "производства" (разработчик, аналитик) и "продажи" (менеджер, директор клиента) при оценке влияния.
Я здесь скорее имел в виду ситуации, когда команда разработки дает оценку "по верхней границе", закладывая риски, организационные нестыковки, большие объемы тестирования и т.п. А менеджер/сейл понимает, что продать заказчику это изменение "задорого" невозможно, и даже попытка выкатить озвученную "производством" оценку может спровоцировать большие разборки. Ситуация обостряется, если идет поток изменений, и проблема несоответствия оценок "производства" ожиданиям заказчика носит системный характер. Т.е. тут возникает ситуация внутренних переговоров, предшествующих собственно переговорам с заказчиком. Эту отдельную тему можно тоже во многих красках расписывать, учитывая разницу (как правило) в мотивации исполнителей и менеджеров/сейлов.
2. Формат договорных отношений с заказчиком, делающий осмысленным/бессмысленным "биллинг" отдельных замечаний.
Может, "делать отдельные Договора на разные этапы проекта" и лучше, только неочевидно, что заказчик будет в таком виде это подписывать. Во многих случаях играется конкурс на проект целиком, и компания-исполнитель, выигравшая конкурс, не может в договоре уменьшить объем обязательств по сравнению с тем, что зафиксировано в условиях конкурса.
Я здесь скорее имел в виду аспекты:
- если у заказчика фиксированный бюджет, и он не располагает возможностью привлекать дополнительные деньги, то есть ли смысл ему счета за изменения выставлять?
- если у вас есть чейндж-реквест на 100$, согласованный менеджером проекта со стороны заказчика, но в вашем договоре нет пункта об оплате дополнительных работ, вы будете запускать на согласование дополнительное соглашение на эту сумму?
- что надо написать в договоре, чтобы зарезервировать бюджет под будущие изменения, но при этом заказчик был бы также заинтересован в наличии такой строки в бюджете, а не был бы напуган, что с него заранее берут деньги за будущие ошибки исполнителей?
Ну и т.п.
3. Методы "сужения" или "расширения" потока замечаний и запросов на изменение.
Тут проще примеры привести.
Кейс 1. Вы делаете коробочный продукт. Внедряете на группе альфа-тестеров. Их замечания вам крайне важны для понимания, что улучшать в продукте, как его развивать. Вы заинтересованы в том, чтобы собрать как можно больше замечаний, вы будете искать пути, как облегчить для пользователей выдачу вам замечаний и запросов.
Кейс 2. Вы делаете программный продукт под заказ в условиях крайне ограниченного бюджета и для заказчика, перспективы дальнейшей работы с которым совершенно неочевидны. Думаю, Вы будете заинтересованы в том, чтобы максимально уменьшить поток замечаний, и всякие "хотелки" отсечь еще на этапе сбора, чтобы они и до регистрации, по возможности, не доходили.
Какие существуют еще ситуации, в которых надо канал сбора запросов на изменения расширять или сужать? Какими методами его можно расширять или сужать?
4. Зависимость решений по изменениям от фазы проекта.
Тезис "чем раньше проект, тем гибкость ближе, чем старше проект, тем гибкость ниже" не исчерпывает ответ на данный вопрос. Часто я сталкивался с ситуациями, когда пользователи, пока не начинали реально работать с системой (после предварительных демонстраций, например), выдавали замечания весьма поверхностного характера, но весьма радикальные по форме ("пока они это не исправят, я с этим работать не буду!"). Когда же начиналась реальная эксплуатация системы (хотя бы опытная), то замечания становились более глубокие, и степень радикальности формы выдачи значительно снижалась (пользователи понимали, что если руководство подписало приказ о начале ОЭ, то деваться им некуда - работать в системе придется - и просто бузить бессмысленно). При этом оказывалось, что многие из тех замечаний, которые пользователи генерировали до начала эксплуатации, позже признавались ими как неправильные, или, по крайней мере, как незначащие.
Поэтому то, что гибкость проекта на начальных фазах высока - это, конечно, да. Но это совсем не означает, что только по этой причине надо вносить как можно больше изменений сразу же на этих начальных фазах.
В общем, тема, на мой взгляд, очень сложная и глубокая. Факторов, влияющих на решение, огромное количество. Их даже проанализировать сложно, не говоря уже о том, чтобы влиять на них. Поэтому я бы предостерег от упрощения ситуации. Классики, конечно, общую схему нам описали - фиксируем запрос, делаем анализ влияния, сообщаем оценку заказчику - и аллес гуд. Но в жизни столько вариаций.....
Управление изменениями в реальной практике