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

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

Слова для поиска: RUP, итеративная разработка, экстремальное программирование.

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

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

Они хотят конкретно знать: Что получат в результате. Срок исполнения. Бюджет.

Мэкс, согласен :)

Итеративная разработка - крен на идеального заказчика (коим и является фирма, делающая проекты для себя).

кстати, отнесение доработок на следующий этап - это примитивный вариант интерактивной разработки :)

Да, конечно пожелания клиента адаптируются и описание базовой фунциональности - делается один раз...

Сейчас думаю, что такой 50 страничный текст будет выглядеть пугающе :D

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

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

Ну и чтобы клиенту не жалко было заплатить xxx$ за этот подготовительный этап - предоставить ему возможность потом использовать этот самый стандарнтый шаблон для отдельных сайтов в системе (для подразделений, филиалов.. если такие у него будут).

Конечно, это все относится только к определенному типу сайтов (корп. сайты с сотнями страниц, новостные проекты)

Я видела образец такого ТЗ (Индивид). Неподготовленный человек именно что пугается.

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

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

Я сейчас стараюсь вообще поэтапно считать.

1. ТЗ, Структура, схемы страниц

2. Дизайн + верстка

3. Система управления ( в вашем случае - предоплата за программирование)

4. Натягивание структуры и шаблона на нее.

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

Реальные схемы оплаты обычно проще, но идеал такой :)

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

Так делают не только буржуи. И не только в больших проектах.

В последнее время убеждаюсь, что заказчику в 90% случаев достаточно перечислить функциональные возможности работы сайта, избегая при описании фраз типа "объект", "наследие", "тип данных" и т.д. Все равно эти слова в одно ухо влетели - в другое вылетели :)

Бывает, что клиенту достаточно сказать:

1. У вас будет система новостей с выводом 3 анонсов на главную страницу.

2. Каталог товаров с рубрикатором с возможностью свободно изменять количество и наименование рубрик, их порядок следования и содержимое.

3. Страница с контактными данными, заносимыми в удобном виде через специальные поля.

4. Баннерная система для размещения рекламы своих товаров и услуг или партнеров с возможностью ротации так-то и так-то.

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

А уж полноценное ТЗ - это скорее для самих разработчиков. :) Вот. Имхо.