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

Была одна тема, вот посмотрите: /ru/forum/comment/3144642 Вот эти примеры прочитайте.

Спасибо! Но мне бы что то более структурированное. Можно просто оглавление, без контента.

Вот нарыл в просторах интернета. Посмотрите с 1 по 10-е.

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

Но вот последние несколько лет проекты стали более серьёзные и ёмкие, биллинги, ЦМС по работе с мобильным контентом, различные платформы и т.д. Вот так сесть и всё написать в ТЗ очень тяжело. Хотя конечно очень хочется, очень. Написать, делегировать программисту и принять потом. Без хопот. Но так не выходит. Вот так сесть и представить и описать работу большой систем тяжело, оч. тяжело. А ведь надо учесть факапы, юзабилити, лайаут, все тех. нюансы и возможности. Поэтому постоянно приходится возвращаться к другой практике, более эффективной для более ёмких проектов.

Практика такая. Для более серьёзных проектов нужен не только ТЗ, нужны графики, схемы, блоки, паспорт изделия/проекта и куча сопутствующей документации. Нужна постоянная синхронизация с программистом/программистами. Обычно разового совещания в понедельник для этого хватает. Нужно много терпения и закладывать 20-30% для того, что какие-то вещи придётся переделывать. Т.е. отказываться, возвращаться в начало и всё заново.

По самим разработкам. Джобс вывел для себя что разработчики более серьёзных проектов должны уметь работать в стрессовых ситуациях, согласен с ним на 99.99% Так и есть, чем более сложный проект - тем больше стресса, проверено. БГ вывел формулу n-1 тоже эффективно, проверено лично =) Многие оутсорсеры пишут про свои эффективные системы работы над более сложными проектами. Например связка пишущий и комментирующий программист - тоже очень эффективно работает. Есть и еще другие более эффективные связки для команд от 7-и человек с более узкой специализацией.

Уверен, что для каждого проекта надо индивидуально подбирать методы и схемы. Адекватно оценивать сложность, риски и набирать квалифицированных специалистов именно под данный проект. Не факт что кодер, написавший вам генератор сможет работать в команде и сможет справиться с более сложным проектом. Так что для более сложных и ёмких проектов просто ТЗ не обойтись. Таков мой опыт. К сожалению :(

О общего к частному надо ходить :)

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

Когда все готово - пройтись с нуля по-новой и протестить на юзабилити (после этого процентов 20-30 придется переделать).

Maximus325, лучше заплатить мастерам дела :) leonidws'у например

Не очень понимаю смысла услуги, мне же ему ка кто надо будет донести вначале тоже самое ТЗ. Тем более за 50 тр.

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

схема по которой они работают:

1. составление структуры (разделы, сервисы и т.д.)

2. верстание главной (1) и вёрста конечных страниц (около 50)

3. конечная вёрстка всего так как должно работать

4. и после всего этого описание того как оно всё работает

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

p.s. когда мне доказывали/убеждали необходимость написания ТЗ, то высылали несколько страниц написанных ими ТЗ и свёрстанную главную страницу. Если нужно/поможет - в личку.

p.s.s. нисколько не жалею что заплатил профи за написание ТЗ $2,5к

Вот поэтому оно и стоит 30-50% от всех затрат на сложный проект, а кодинг только 15-20% всех затрат.

ну раз копия буржуйского сервиса - отправь программерам ссылку на него :D