Как ТЗ большое написать для крупного сервиса?

ТЗ не пишут, ТЗ рисуют )

Я сразу проектировал в Axure каждую страничку, для каждого блока/картинки/ссылки давал коммент.

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

Проблема распространненая, решение приходит с опытом видимо)

Полностью согласен. Ибо без такой наглядной схемы невозможно разобраться в структуре программы.

Для тех, кто пойдёт следом: с www сайт не Axure работает. Работает без www. Алексею Краснову респект за сдачу программы.

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

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

Я сейчас применяю такую практику:

1. Пишутся технические требования(TT) - это бумажка на 2-8 страниц, в которой изложено то, что заказчик хочет получить в общих чертах. Это согласовывается с заказчиком.

2. На основаниии ТТ пишутся функциональные спецификации(ФС) которые в общих чертах описывают структуру пользовательского интерфейса и детально описывают каждый сервис.

Здесь как раз можно и кейс сделать и графические представления процессов хорошо проходят.

3. Очень редко, в крупных проектах, пишется именно ТЗ. Пишет его аналитик или несколько аналитиков, и в нем уже детально прописывается вся структура данных, влоть до полей, все экраны и кпопочки на них, все сервисы для взаимодействия с другими системами.

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

Эх, не послушал я тебя.... До сих пор дописываем, а денег не взял. Уже 69 страниц плюс столько же на смежные договора. Действительно, ТЗ стоит бабок. Кодинг стоит, конечно дороже вышеуказанных процентов, но ТЗ - минимум 15% от сметы тянет.

pelvis, ты хоть раз измерял время, которое тратится на кодинг? Не на всю разработку, не на кодинг + архитектуру + отладку + доработки, а именно на кодинг? Я вот считал. У меня отладка занимает по времени всегда больше, чем кодинг. И доработка новых фич (с их отладкой) занимает больше, чем кодинг.

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

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

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

Опять таки, как ты опишешь API без ХЗ?

Так без ХЗ тоже никуда. Это документ, понятный твоему бедному богатому заказчику. Обычно люди останавливаются на написании ХЗ и называют его ТЗ. Писать ТЗ довольно проблематично: всё время кажется, что проще взять и сделать (а для простых проектов так и есть). Вот тогда он и стоит 10-15% проекта. Ну и получается ХЗ какое ТЗ 🚬

а к чему все эти обозначалова? ТЗ - внутренний документ, он описывает вывод информации, структуры БД и т.д. С этим, как раз, постановщики задач прекрасно справляются. НО Заказчик всегда принимает по ХЗ, хоть и с элементами ТЗ. И если он грамотный, то будет принимать строго по ХЗ, а не по ТЗ. И договор подпишет именно так :)

Это зависит от того, как процесс калькуляции стоимости поставить.

Мне заказчик обычно дает свое ХЗ ( Правда в нашей терминологии это Функциональные Спецификации ). Из него никогда не следует однозначного определения трудозатрат и стоимости.

Поэтому я начинаю задавать уточняющие вопросы по механизмам реализации и управления. В результате появляются Технические требования. Как раз именно их я и включаю в договор на разработку и внедрение. И только по ним производится

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