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

Заказчик (если не может сам — нанимает техписателя).

>Кто должен писать ТЗ к заданию: исполнитель или заказчик?

В идеале - совместно. Заказчик часто не знает, что и как можно сделать, а что - нельзя. Исполнитель же не может знать всех нюансов работы заказчика.

И как у вас самих обстоит с этим на работе?

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

И я так считаю. Но мне утверждают обратное. Сейчас буду ТЗ дописывать )

Ну, а затраты на корректировку ТЗ включают в стоимость работ, не ?))

>И я так считаю. Но мне утверждают обратное. Сейчас буду ТЗ дописывать )

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

Аналитик должен писать ТЗ.

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

Написание ТЗ это всегда совместная работа заказчика и исполнителя. При этом во многих случаях будет перекос в сторону исполнителя.

Это платная работа, 10-15 процентов от предполгаемого обема работ. Делать ТЗ бесплатно от проекта за лям - верх кретинизма.

Совместно. Фактически процесс написания ТЗ, это согласовывание позиций сторон: заказчика (мне за пять копеет что б все крутилось и мигало) и исполнителя (за пару лямов мы вам слабаем окошкой с одной кнопкой). Желательно убедиться, что обе стороны гооврят об одном и том же;-)

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

>Это платная работа, 10-15 процентов от предполгаемого обема работ. Делать ТЗ бесплатно от проекта за лям - верх кретинизма.

Бесплатность создания ТЗ - понятие условно. Те, кто активно делают это вместе с заказчиком, включают это в стоимость работ. Просто кто-то про это пишет, а кто-то - нет.

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

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

Кто должен писать ТЗ к заданию: исполнитель или заказчик?

Вместе.

Заказчик, но на практике бывает по-разному.

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

Если речь идет о ТЗ на автоматизированные системы, то ТЗ разрабатывается исполнителем при содействии заказчика. Об этом в ГОСТ 34.602-89 (Техническое задание на создание автоматизированной системы) написано в приложении:

ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).

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

Должен исполнитель.

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

И вообще считается что тз - зло, в той форме когда оно пишется до начала разработки и не меняется в процессе.

Писатель ТЗ же.

очевидно, что в тесном сотрудничестве с заказчиком

Кто должен писать ТЗ к заданию: исполнитель или заказчик?

Собственно, сабж.

только совместно, тогда есть шанс родить что-нибудь вменяемое :)

считается что тз - зло, в той форме когда оно пишется до начала разработки и не меняется в процессе.

так считают только те кто пишет корявые ТЗ в которых прописывает сразу архитектуру системы до последнего «гвоздя», ТЗ - это декларация о намерениях (список фич, если хотите), пакт о том что и в каком объёме должно быть сделано, какими средствами и за какой срок, а совсем не то что должны стоять 2 «цыски» и 3 сервера ibm такой-то конфигурации

и да, есть же механизм дополнительных соглашений к ТЗ, для настоящих джедаев

> разрабатывает организация-разработчик системы

ой блин, ты еще глянь что называют «системой» по гостам

>так считают только те кто пишет корявые ТЗ

Я нежно но сильно порву твой шаблон, ибо не пишу ТЗ вообще.

ТЗ - это декларация о намерениях (список фич, если хотите), пакт о том что и в каком объёме должно быть сделано, какими средствами и за какой срок, а совсем не то что должны стоять 2 «цыски» и 3 сервера ibm такой-то конфигурации

Бугага сисадмин это диагноз. Тебя не посетила мысль что сей вопрос в development находится неспроста?

>ой блин, ты еще глянь что называют «системой» по гостам

Совершенно не важно, что называют «системой» по ГОСТам. Принцип разработки и принятия ТЗ не зависит от времени принятия ГОСТа и этих определений. То, что сегодня 2011-й год, а не 1980-й не отменяет того, что разработчик имеет более полную картину своих возможностей и технических деталей, чем заказчик.

> Совершенно не важно, что называют «системой» по ГОСТам.

Не, важно. Важно отличать: систему, комплекс, устройство, прибор ...

Для систем НИИ пробили себе кормушку в виде ГОСТов.

>Не, важно. Важно отличать: систему, комплекс, устройство, прибор ...

А откуда эта важность в разрезе вопроса ТС? В каком из этих случаев ТЗ должен разрабатывать заказчик, а не исполнитель или головная организация-исполнитель? Вот когда речь идет о НИР или ОКР, то тут роль заказчика в разработке ТЗ возрастает.

>так считают только те кто пишет корявые ТЗ

Я нежно но сильно порву твой шаблон, ибо не пишу ТЗ вообще.

на воре и шапка горит :) сможете показать место где я указывал конкретно на Вас?

>ТЗ - это декларация о намерениях (список фич, если хотите), пакт о том что и в каком объёме должно быть сделано, какими средствами и за какой срок, а совсем не то что должны стоять 2 «цыски» и 3 сервера ibm такой-то конфигурации

Бугага сисадмин это диагноз. Тебя не посетила мысль что сей вопрос в development находится неспроста?

1. бугага - это диагноз

2. для человека который «не пишет ТЗ вообще» не считаете что Ваши сентенции чересчур пафосные?

3. и почему сразу сисадмин? может у кого-то просто отсутствие способности к абстрактному мышлению

4. некоторые «умные» товарищи включают в ТЗ на софт и конкретное оборудование

Причем в ГОСТ речь идет об *проекте* ТЗ. Этот проект ТЗ, потом совместно с заказчиком дорабатывается и превращается в документ.

>на воре и шапка горит сможете показать место где я указывал конкретно на Вас?

С удовольствием ткну завравшегося тролля носом в егоже фекалии: «так считают только те кто пишет корявые ТЗ». Даже идиот догадается о чем речь, но вы конечно не догадались 8)

бугага - это диагноз

Показательно.

для человека который «не пишет ТЗ вообще» не считаете что Ваши сентенции чересчур пафосные?

Мне даже не кажется, но я знаю что вас задел.

и почему сразу сисадмин? может у кого-то просто отсутствие способности к абстрактному мышлению

Не вам свой диагноз лучше знать.

некоторые «умные» товарищи включают в ТЗ на софт и конкретное оборудование

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

уровень системы не задача уровня LTD. Гост в СССР разрабатывался.
это определяется уровенем сертификации и методик, прочей всякой муры,
и о которой мало кто любит думать сразу.

>на воре и шапка горит сможете показать место где я указывал конкретно на Вас?

С удовольствием ткну [..]: «так считают только те кто пишет корявые ТЗ».

странно, что Вы приводите именно эту фразу в обоснование своей позиции, потому что ранее Вы писали:

Я [..] не пишу ТЗ вообще.

предлагаю Вам определиться таки: Вы пишете ТЗ или всё же нет?

>некоторые «умные» товарищи включают в ТЗ на софт и конкретное оборудование

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

действительно «и что», и что сказать-то хотели?

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

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

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

Ты неправильный инструмент/алгоритм можешь выбрать имея хоть сто ТЗ.