следующая тема »

[Jedi]

Есть такая методология работы над программными проектами, называется eXtreme Programming (XP), подробнее о ее принципах можно узнать на сайте http://xprogramming.ru/.
Важной особенностью XP является тот факт, что требования к программе определяются до начала работы не полностью, но формализуются по ходу развития проекта. Так как предполагается, что требования заказчика к системе могут и должны меняться со временем, ведь разработка может занимать значительное время, за которое, потребности заказчика в той или иной функциональности программы могут измениться. Очевидно, что при изменении требований меняются как время выполнения работ, так и их стоимость.
В связи с этим вопрос:
В каком виде должен заключаться контракт, чтобы учитывать особенности процесса разработки, но в тоже время было бы понятно, кто и что должен сделать, и сколько за это должны заплатить?

[yuriyah]

Ну, это не совсем к юристам вопрос, по-моему.
Заказчик знает результат, который ему нужен (иначе зачем платить деньги?). Приблизительно может посчитать, какие средства на это уйдут.
Предмет договора - создание программы с такими-то параметрами (требуемый результат).
Сумма - указывается приблизительная, расчетная. А потом, в случае изменения суммы, напишете дополнительное соглашение к договору. Хотя проще заложить чуть большую сумму, чем работа приблизительно стоит. Заказчик не обеднеет.

[Антон Серго]

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

[Jedi]

Как ни странно это прозвучит, но заказчик далеко не всегда знает, чего он хочет. Он представляет, что должно быть приблизительно, но четкое представление у него складывается тогда, когда он может «пощупать» программу, некоторое время будет ее использовать. Это очень важно – в XP окончательная поставка идет, когда всё будет уже сделано, но есть еще много промежуточных поставок (тестовых), которые и позволяют заказчику более четко сформулировать требования.
Я тоже думаю, что можно корректировать техническое задание во время работы, но снова встает вопрос о частоте внесения изменений. С точки зрения бизнеса необходимо, чтобы изменения вносились как можно чаще, но, подписывать каждый день какие-то бумаги, как я понимаю, что для заказчика, что для разработчика будет доставлять большие проблемы.
Самое главное, что я хочу понять – существует ли юридический механизм, допускающий многочисленные, как не значительные, так и радикальные изменения в условиях контракта, без каждодневного подписания кучи бумаг. Ведь юридические законы существуют ради бизнеса, а не бизнес ради законов. Или я не прав?  
Если есть возможность, то дайте какие-либо ссылки по данному направлению.

[Антон Серго]

Механизм, как таковой, мне не известен, но ничто не мешает Вам оговорить в договоре, что поправки в ТЗ заказчик может присылать Вам по электронной почте, а саму переписку Вы признаете юридически значимой.
Вопрос в другом, Заказчик Вам присылает письмо типа: а теперь давай все по-другому и вообще все на так, короче за теже деньги, но чтобы монитор еще и как зеркало работал.
Вы говорите, что это невозможно или очень дорого, а он Вам" а я тебе аванс дал вот и работай".
А когда существенные изменения Вы согласовываете, то (как я уже писал) заказчик подтверждает, что ему надо и он готов доплатить (при необходимости), а разработчик подписывается, что все понял и готов это сделать.

[Jedi]

Антон, Вы просто читаете мои мысли! Действительно, бывают таки беспредельщики, и от них надо страховаться.
Есть идея заключать стабильные контракты на небольшие сроки, соответственно  вся работа будет покрываться несколькими контрактами, но тут уже надо составлять шаблон. Когда работа над ним будет закончена, можно будет обсуждать более конкретно.

[yuriyah]

Верно! Либо вы заключаете ряд контрактов на ограниченное время, либо заключаетет один, но постоянно его поправляете допсоглашениями.

[Urix]

Приведу анекдот в тему:
Украли америкосы основной пакет чертежей нашего новейшего и сверхсекретнейшего самолета. Все изготовили и собрали строго по чертежам - получился паровоз. Начали выяснять, что случилось и выяснили, что забыли выкрасть еще и целый вагон дополнений.

Так надо рассматривать XP. Поэтому, с моей точки зрения, правильный ответ будет следующим: сначала заключается основной договор, как бы договор "о намерениях", а в его рамках заключаются дополнительные договоры на выполнение конкретных объемов работ в течении конкретного времени с конкретной стоимостью.

[Roman Eremin]

Вопрос, наверное, все-таки в том, за что заказчик платит деньги.

Мировая практика разработки ПО показывает, что подход, когда заказчик ставит задачу, а разработчик ее решает, на практике редко работает. На самом деле, заказчик начинает понимать свои потребности только после того, как он сможет программой воспользоваться. XP принимает это как данность. При этом методология XP предлагает метафору "пользы" или "бизнес-ценности". Другими словами, команда XP программистов через пару недель работы приносит определенную пользу бизнесу. Фактически, заказчик вкладывает свои деньги в виде времени работы команды и на каждом этапе сам определяет какую пользу он хочет получить.

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

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

[yuriyah]

Специальных нет.
Могу предложить конструкцию с обыкновенным трудовым договором на время разработки пакета программ. Тогда важен не результат, а процесс. И платить можно за время.
Хотя от злоупотреблений и это не гарантирует.