Мысли о техзадании

Не, только проектировщик, который имеет представление о возможностях остальных членов команды. Ну и менеджер проекта, естественно.

Этого идеала никогда не удается добиться.Чем меньше ограничений в ТЗ, тем больше возможностей для маневра.

При недовольном заказчике ничто дело не спасает. Успешным может быть только любовь :))))

MaxApex, согласен со всем. Только осталось убедить в этом клиентов, ибо большинство все ещё делают сайт для галочки и строчки на визитке. :(

По началу тяжело читалось. Зато потом начинаешь осознавать, почему "тут" делал такую группировку, а "там" - другую :) Сейчас пытаюсь внедрять полученные знания на практике. Надеюсь на положительный результат.

А так же больше последующего геммороя. Потому что в итоге "кто в лес, кто по дрова". А вот возможности для маневра закладываются архитектором и техническими возможностями ПО (CMS). Имхо.

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

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

Вот вот самый большой геморрой в CMS

Назовите мне хорошего оптимизатора (только не на уровне специалиста по покупке морд), по техзаданию которого была сделана хоть одна CMS.

Не поняль :) При чем тут оптимизатор?

Потому что CMS пишутся для чайников, а не оптимизаторов.

И когда оптимизатор натыкается у очередного клиента на очередную CMS он крестится и умножает бюджет продвижения вдвое (особливо когда "комплексное" :)))) продвижение сайта)

Я не говорю о самых жирных клиентах, а о самых массовых.

А когда Вы клиенту начинаете часто намекать на текст ТЗ и текст договора, он нутром начинает чувствовать, что его, как чайника, раскручивают и он начинает звереть.

Последнее время у меня возникает ситуация, когда надо требования и хотелки заказчика переложить на язык возможностей готовой системы

и понять, как сделать это оптимально, где заказчика можно обидеть (сказать "это будет ТАК и никак иначе"),

и где\что придется доделывать и, самое главное, будет ли заказчик счастлив с CMS (т.е. не возникнет ли "вдруг" тема, что де слишком сложный BackEnd, что все не так, как мы ожидали и т.п)

Речь идет об обычных корпоративных и новостных сайтах, т.е. в общем укладывающихся в фунциональность CMS, но имеющих некие особенности.

Идеальных решения приходит в голову три:

1. Номальное ТЗ на 50-100 страниц со скриншотами админ интерфейса

+ демо + согласования

бюджет на это конечно - xxx$

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

3. Пилотный проект с бюджетом xxx$

Все это относится именно к "средним" проектам - когда "на стороне заказчика" сидят 1-3 специалиста (а не фин. директор напару со студентом-сисадмином).

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

Понятно, что работы все равно много, но в этом варианте достаточно много можно взять из рыбы, с пилотным проектом так не получится.

А не надо намекать. Надо просто ссылаться. Причем в письменном виде ( ICQ, лучше E-mail, с сохранением в теле прошлой переписки).

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