Каменный ГостьКак же ясно, что в течение проекта, становятся более ясным трудозатраты, необходимые для выполнения наших обязательств перед заказчиком, и не редкость ситуация когда, за невинной строкой договора вылезает пару человеко-месяцев. Как с таким бороться?

Ситуация, которую Вы описываете, типична для проектов, где недостаточное внимание уделяется двум вещам: управлению требованиями и управлению изменениями.

По требованиям. Это фундамент, на котором стоит весь проект, и поэтому требования должны быть сформулированы таким образом, чтобы не дать никакой возможности двоякого толкования написанного. Из моей практики оптимумом является форма дерева с детализацией до такого уровня, чтобы утверждения были конечны по смыслу и бинарны, то есть отслеживались про принципу Да\Нет, выполнено или не выполнено. Вот пример.

1. На форме должна присутствовать кнопка ОК, предназначенная для подтверждения ввода пользователя в базу.
1.1 Кнопка выполнена в виде прямоугольника.
1.2 Кнопка имеет встроенную иконку в виде (описание рисунка).
1.3 Нажатие кнопки приводит к вводу имеющейся на форме информации в систему.
1.3.1 Сразу после нажатия кнопки система считывает данные содержащиеся в полях формы (перечислить, каких).
1.3.2 Считанные данные заносятся в таблицы базы данных (при необходимости перечислить, в какие таблицы).
1.3.3 При успешном завершении ввода системой выдается сообщение: "Ввод данных успешно завершен".
1.3.4 В случае возникновения ошибки при вводе системой выдается сообщение формата : "Ошибка при вводе (Код ошибки, Описание ошибки)"

Понятно, что такую детализацию сразу не получить. Поэтому при подписании договора можно предусмотреть такую схему: приложением к договору является рамочное (или концептуальное) задание, а после завершения первого этапа проекта (как правило, это обследование) подписывается новый документ, содержащий детализированные требования. Соответственно, надо обговаривать, что по завершении первого этапа сроки и бюджет могут быть скорректированы.

По изменениям. При поступлении "хотелок" клиента их надо делить на три большие группы:
1. Ошибки, то есть те случаи, когда результат отработки системы явно не такой, как прописано в требованиях.
2. Изменения, то есть работа системы соответствует требованиям, но заказчик заявил новую редакцию одного или нескольких пунктов.
3. Дополнения, то есть ситуация, когда заявленные заказчиком требования явно не коррелируют ни с одним пунктом требований.

Соответственно, по группам 2 и 3 надо обговаривать пересмотр рамок проекта, прежде всего в части сроков и денег. Очевидно, что если требования изложены нечетко или недостаточно детализированы, то провести такой анализ затруднительно, и будет крайне сложно доказать, что изменения расширяют проект.