Я не очень понял написанного Вами разделения. Что будет делаться после "сдачи программинга" и до завершения работ? Дизайн? Контент? Опытная эксплуатация?

Если работа плохо бьется на этапы, я бы предложил 40+60. Почему именно так - потому что эта схема позволяет минимизировать риски потерь для каждой из сторон.

Довольно часто выделяют внедрение, опытную эксплуатацию или подобный этап, на входе которого - принципиально устраивающее решение, на выходе - решение обкатанное, освоенное, подправленное на основе опыта эксплуатации итп. Не знаю, применимо ли это к вашему сайту, если да - можно делить так, например те же 40+30+30.

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

Так или иначе, Вы правы в том, что этапы должны быть четко отделены друг от друга, "возвраты" к уже вроде бы завершенному должны быть минимальны.

avecПосле программинга у них идет технический дизайн, верстка страниц, интеграция модулей, тестирование, наполнение и запуск сайта.
Хм. Что-то меня малость пугает этот набор умных слов :) Особенно пугает идея "напрограммируем, получим деньги, тогда приступим к тестированию". В целом.. не хочется заочно хаять

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

avecВозможно, они и бьется, но как здесь уже отмечали, это деление нужно Исполнителю, а не Заказчику. Нам нужен готовый работающий сайт.
Безусловно. А исполнителю нужны Ваши деньги. И если бы не риски, было бы абсолютно все равно, когда и как платить. Но вопрос - в рисках. Вы можете, конечно, выдвинуть условие "100% оплаты по факту", но сомневаюсь, что на 5-6 месячный проект найдете исполнителя, который согласится и при этом не задерет цену "надбавкой за риск".

Риск упущенной выгоды из-за неудачи проекта оставим в стороне - он неизбежен и не меняется от схемы финансирования. Итого, остаются риск заказчика: заплатить деньги, но не получить устраивающего продукта и риск исполнителя - вбухать трудоемкость, но не получить деньги из-за отказа заказчика. Для "одноэтапной" схемы, повторюсь, имхо оптимальна схема 40+60.

В то же время Вы не совсем правы, говоря, что Вам не нужны промежуточные результаты. Промежуточный результат - это, в зависимости от ситуации:

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

То же ТЗ, если оно хорошо написано, представляет Вам возможность дать его другому исполнителю и продолжить работу.

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

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