Вообще я яростный противник fixed bid-проектов. Fixed bid-проект обычно оставляет и у Заказчика, и у Исполнителя чувство обоюдного проигрыша - Заказчик недополучил функционал, Исполнитель недополучил прибыль (если очень упрощенно). Для того, чтобы этого не произошло, требуется несколько заходов танцев с бубном - во-первых, нужно вдумчиво поработать над концепцией и ТЗ, используя дорогостоящего аналитика и отвлекая (тоже недешевых) ключевых специалистов Заказчика для сессий JAD; во-вторых, нужно установить процесс управления изменениями; и в-третьих, даже при всем при этом чтобы корректно посчитать этот самый fixed bid нужно иметь историю работы команды или релевантную статистику по организации - чтобы перевести полученный юзкейсы и вайрфрэймы в часы работы и календарные дни длительности (из чего и складывается в конечном итоге цена). Ну и в добавок требуется увязать это все в контракте, создав доброжелательную обставновку вооруженного перемирия и взаимного недоверия. Но проект сделать можно. Следствием такого проекта (при условии того, что оговоренный в контракте процесс не похерят в процессе работы) с весьма большой долей вероятности будет адекватная качественная система.
Так в чем проблема? Дык собственно проблемы никакой нет - при использовании подхода, указанного выше. Но давайте посмотрим - так ли на самом деле устроен изнутри типичный fixed bid-проект, в котором многи узнают проект, на котором они сейчас работают.
Заказчик прибегает и говорит - “хочу вот CRM! Сколько будет стоить?” Исполнитель отвечает - “ну это вообще сильно зависит… Что CRM должен уметь? Какие фичи нужны?” Заказчик пучит на него глаза - “Как что уметь? Натурально - управлять отношениями с клиентами! Так сколько?” Исполнитель тяжело вздыхает и начинает объяснять очевидные вещи: проектный треугольник, да риски, да план… Заказчик говорит - “Нет, ты не понял. Я тебя про проектный треугольник не спрашивал. Я спросил сколько стоит?” Исполнитель говорит “Ну давай хоть ТЗ прикинем! Мы форсированно разработаем, за пару недель!” Заказчик - “Что?!! Пару недель?!! И еще платить за Аналитика?!! Персоны-шмерсоны, проектирование интерфейса?!! И на выходе ничего кроме бумаги?!!.. Никогда!” Исполнитель хватается за голову - “Да идите вы к черту, не будем мы с вами работать!..” Заказчик отвечает “да никуда вы не денетесь, я с вашим главным водку пил, он мне обещал, мы с ним друзья детства, и вообще - вам не нужен референс одной из крупнейших компаний в отрасли? Да тут очередь желающих работать чисто за референс!..” Исполнитель крякает и говорит - “Ладно, давайте хоть в контракт включим про управление изменениями!” Заказчик делает невинные глаза - “Извините, у нас стандартная формая контракта, и изменения формы контракта не предусмотрены! Да и вообще - зачем хорошим людям контракт, правильно? Главное ведь - доверие! Вот тут подпишите пожалуйста, на листе с перечислением санкций…” Неизбывная тоска застывает в глазах Исполнителя, ибо он все это уже видел – дальше мы будем делать сферического коня в вакууме в высосанные из пальца сроки за половину денег…
Короче говоря – по факту традиционный подход “фиксированный “функционал = фиксированные деньги” не прошел. То, что вас ждет – deathmarch-проект, забег на время на петляющую дистанцию неизвестной длины. Нормальный человек говорит “спасибо, развлекайтесь сами.” А мы зачем-то беремся участвовать. Что делаем дальше? Мы садимся и думаем - “вот же … *censored*!!!” Нет, не так 
Мы садимся и думаем: “что я могу сделать для того, чтобы бежать как можно быстрее, и по возможности меньше петлять?”. Идеи приходят сами собой:
- Все формальности – к едрене фене! Поскольку мы отказались от них на уровне контракта – выкинем их и из жизни. Можешь сказать вместо того чтоб писать меморандум – скажи. Документ не входит в условия поставки? В топку! Ну и так далее.
- Если уж предстоит сделать много – давайте хоть не переделывать! Для этого надо с первого раза попадать в цель – делать функционал так, как его хочет видеть Заказчик. И укорачивать обратную связь.
- Чаще будем делать билды! И ставить их на продакшн. Чтоб была так сказать приемка самим фактом установки и использования.
- Давайте экономить на багах! А давайте. Для этого тестирование должно происходить раньше.
- Нет ТЗ – будем выспрашивать у Заказчика! Правильная мысль. Неплохо бы тогда чтоб он сидел онсайт или по крайней мере был доступен в любое время.
- Юнит-тесты помогут нам отлавливать ошибки в изменившейся бизнес-логике! С этим друдно спорить. хUnit в руки – и вперед!
Даже из этого уже торчат уши agile. Хотите иметь шансы сделать этот проект? Выберите одну из agile-методик. Пишу русским по белому и еще выделяю красным – иметь шансы. Не более того. То есть у вас по прежнему хорошая вероятность завалить проект. Но появились шансы. Большие или меньшие. А даже один шанс из шести – уже не такая маленькая вероятность, чтоб она не могла случиться.
>>5.Нет ТЗ – будем выспрашивать у Заказчика!
Денис, а был реальный опыт разработки CRM-системы без ТЗ? Если да, то на основании чего тестировали ваши QA, и как проводил приемку заказчик, если не секрет?..