Шаблон технического задания для разработки дополнения

Как составляются ТЗ? Есть ли у кого нибудь шаблон на разработку именно дополнения? Есть ли у кого нибудь анкета с вопросами для клиента или как это все происходит?

Вот на пример накидал за 15 минут. Но это я так понимаю не то?

@spartak, каждый пункт должен быть разжеван, в идеале плюс еще прорисован, тогда у сторон не будет двойного толкования.

@spartak, каждый пункт должен быть разжеван, в идеале плюс еще прорисован, тогда у сторон не будет двойного толкования.

Неужели никто так и не создал шаблон универсальный)

Обычно с начало выявляем потребность и логику работы в разговоре он-лайн.

Обычно с начало выявляем потребность и логику работы в разговоре он-лайн.

Это понятно. Интервью… вот на пример интервью для сайта есть у меня такое
yadi.sk/i/WO_8Q1nb3HXpGX

А вообще в моем старом блоге 34.templateinstant.ru/faq/6-zachem-nuzhno-tz.html там есть над чем поразмышлять)))
Кто должен писать техническое задание?
Ответ на этот вопрос однозначен — разработчик. Другого не дано. Только он способен грамотно представить цели, сформулировать задачи.
Мой личный опыт показал, что есть категории исполнителей, неспособных писать технические задания. Я это отношу к специфике занятий и людей.

Неужели никто так и не создал шаблон универсальный

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

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

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

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

В общем универсального ТЗ на разработку компонентов быть не может. Каждый заказ надо рассматривать отдельно, так как один и тот же заказ от разных заказчиков, будет выглядеть совсем по разному. Даже разные исполнители могу предлагать разные варианты исполнения, исходя из личного опыта работы в данном направлении. Например тут, заказчик попросил выводить помимо общего рейтинга, ещё и рейтинг разделённый по полю из профиля. Естественно, имея или зная о такой возможности, исполнитель предложит заказчику такую опцию. Согласится заказчик с данной опцией или нет, это всё и надо выяснять в ТЗ.

В итоге обсуждения формируется ясное представление того, что хочет сам заказчик и само ТЗ — список того, за что платит заказчик и что должен сделать исполнитель.

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

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

ТЗ и как-то заранее оговаривать их возможное количество, чтобы ТЗ не стало бесконечным

угу. И совсем отлично, когда заказчик добавляя новые хотелки добавляет "понимаю, что хотелки появились уже после обсуждения суммы и готов к ее увеличению". Потому как ТЗ не может обрастать новыми хотелками бесконечно и без увеличения стоимости.

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

сторона проверяет что исполнение соответствует заказанному и тогда производится оплата выполненной работы.

Только вот никто процент от сделки Арбитражу не желает платить😊А так рассудить и быть гарантами сделки легко.