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

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

(0) ни о чем
ТЗ пишет тот, кому за это платят

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

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

(3) а почему разработчик?
ТЗ должно быть написано на языке заказчика и в терминологии понятной заказчику.
Следует разделять ТЗ и Тех проект который описывает детали реализации ТЗ.

аналитик, не?

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

(8) заказчик должен написать примерно следуещее


Термины
1.    Сделка – общность хозяйственных операций по основной деятельности компании (торговля) имеющих прогнозируемый конечный финансовый результат. Обычно сделка подразумевает продажу фиксированного списка товара/услуг в рамках одного договора или одного счета. Сделка не может быть с неизвестным финансовым результатом (например, нельзя определить финансовый результат для рамочного договора с фиксированными ценами, но без фиксированного объёма, в этом случае каждая поставка это отдельная сделка).
2.    ЦФО (Центр финансовой ответственности) – структурное подразделение (или несколько), осуществляющее определенный набор хозяйственных операций, способное оказывать непосредственное воздействие на расходы и/или доходы от этих операций и отвечающее за величину данных расходов и/или доходов. Руководитель ЦФО несет ответственность за результаты деятельности.
3.    МОЛ - Материально ответственное лицо
Цели проекта
Целью проекта является создание единой базы данных позволяющей вести:
1.    Торговые взаиморасчеты с покупателями (в рублях, валюте и УЕ) в разрезах Контрагента, Юридического лица, Договора, Сделки (в том числе и сделок с несколькими счетами). Торговые взаиморасчеты включают в себя отражение (и полная детализация) товарных и финансовых хозяйственных операций между Организацией (или его Аффилированными лицами) и Покупателями.
2.    Ведение складской деятельности в количественном и денежном исчисление в разрезах складов, номенклатуры, партий с разной себестоимостью, серийных номеров. При ведении складского учета предполагается внедрение штрихкодирования. Введение двух видов себестоимости, закупочная и полная (включая расходы на логистику) . Внедрение механизма личной ответственности менеджеров за ТМЦ перемещенных в офис или тестирование.
3.    Автоматизация планирования и ведение учета фактической рентабельности сделок и финансовых результатов менеджеров. Автоматизация расчета бонусов менеджеров, в том числе отчеты по менеджерам и сделкам.
4.    Введение удобной системы резервирования товаров и временной передачи резервов.
5.    Ведение закупочных операций в рамках товарооборота (ведение полного взаиморасчета с поставщиками сейчас не представляется возможным реализовать, возможно, это будет реализовано «потом»). По РФ полное ведение взаиморасчетов, по ВЭД только товарная часть.
6.    Ведение финансового результата  (с определенными ограничениями) по ЦФО.
7.    Контроль всех платежей, включая платежи по неторговым операциям (заявки на платежи).
8.    Обеспечение печати первичных документов по торговым сделкам в соответствии с требованиями бухгалтерии и заказчиков силами коммерческих подразделений. При этом возможно отличие печатных и учетных данных.
9.    Интеграция с бухгалтерской программой.
10.    Ведение и планирование платежного календаря.
11.    Бюджетирование деятельности компании.
12.    Учет фактических условий сделок в дополнение к договорным.

Основные прицепы учетной системы
1.    Интерфейс системы должен позволять 80% всех операций производить непосредственно с рабочего стола, при этом рабочий стол не должен иметь на себе много объектов.
2.    Для торговых операций основным объектом работы является «Сделка», сделка при этом имеет различные статусы. При отражении хозяйственных операций связанных со сделкой происходит изменении статусов сделки, а из самой сделки можно посмотреть все документы, отчеты и прочие данные связанные со сделкой.
3.    Для операций по закупке основанием всегда является сделка, или несколько сделок. Закупка вне сделок запрещена, для закупок на склад заводится специальный вид сделки. Основным объектом для операций по закупке является  два объекта «Заказ поставщику» и «Инвойс». Заказ используется для планирования, а инвойс для отражения факта отгрузки поставщиком и дальнейшей логистической обработки вплоть до оприходования на склад.
4.    Складской учет должен позволять однозначно идентифицировать, МОЛ принявшее товар (в том числе и не принадлежащий организации, например переданный в ремонт клиентом) на любом этапе перемещения или местонахождения товара. МОЛ-ом может быть менеджер получивший товар для демонстрации клиенту или экспедитор. Система не должна позволять списывать товар с одного, МОЛ без подписания документа принимающей стороной.
5.    Все первичные документы отдаваемые клиентам должны печататься только после проверки данных бухгалтерией или ПЭО. Список документов и проверяющих должен вестись в базе.
6.    Взаиморасчеты должны вестись по двум системам учета, в управленческой и в системе идентичной бухгалтерской (для корректного зачета авансов и печати документов по договорам в УЕ и валюте). Между этими двумя системами учета возможны расхождения.
7.    Жесткое разделение прав доступа, основными параметрами разделения является ЦФО, Сделка.


Этапы проекта
1.    Сбор информации, анализ, написание ТЗ
2.    Написание альфа конфигурации
3.    Пробное тестирование альфа конфигурации пользователями, доработка ТЗ на основании их замечаний
4.    Написание пилотной конфигурации
5.    Внедрение минимальной функциональности
6.    Дальнейшие доработки


Критерии оценки и приемки

1.    Минимальная функциональность – система позволяет пользователям проводить самостоятельно (без сторонней помощи и консультаций) 80% действий по торговым операциям, а именно: поступление, реализация, резервирование, перемещение, печать первичных документов, остальные 20% система позволяет делать или «неудобно», или «нештатно». Система позволяет пользователям получать самостоятельно (без сторонней помощи и консультаций) 50% требуемой им аналитической информации, остальные 50% аналитической информации может быть получена «не штатно», или дописаны механизмы ее получения в приемлемых для бизнеса временных рамках (например, к закрытию квартала).
2.    …

(0)ТЗ пишет аналитик, а вот на чьей стороне он будет безразницы

(11) а на основании этого пишется ТЗ для программистов....

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

(6) +1.
Если за ТЗ не заплатили, то работы оплачиваем по часам. И хоть вечность можно делать сферического коня в вакууме.

Как я понимаю, нигде не зафиксировано, кто пишет ТЗ.
Поэтому, пишет тот, кому это нужно

да блин, делите вы проект и ТЗ - это РАЗНЫЕ ДОКУМЕНТЫ!!!!!

проект пишет заказчик ВСЕГДА САМ !!!!

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

(16)оно (ТЗ) нужно одному-двум человекам в компании заказчика
и что ген.дир будет писать ТЗ???

(17)>>>проект пишет заказчик ВСЕГДА САМ

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

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

(0)на проекте есть роль, в рамках которой пишется ТЗ
и опять таки без разницы с чьей стороны выполниться эта роль

Я сам пишу тз в качестве исполнителя. И сам же буду по нему вредрят. Упп.

(0)это платная услуга. Если исполнитель пишет ТЗ, то на это ему должны выделять время и бюджет.

(20)стоимость работ описана в договоре и в нём же указаны работы которые будут выполняться по договору

(19) по тому, что только если сам заказчик не уверен, что ему именно это нужно - проект обречен на провал.

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

Пока нет СТОЙКОГО желания у РУКОВОДСТВА (и это руководства готово для достижения этого результата уволить часть сотрудников) что-то внедрять просто нет смысла....

обычно - совместное творчество заказчика и исполнителя проекта, причем исполнитель выполняет до 95% ХЗ..
и это правильно, ибо заказчик по незнанию может нагородить столько, что ни один франч не согласится выполнять..

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

(24) да ну, ну будет там даж проект из (11), взять п.8 и можно вечно с таким договором переделывать бухгалтерам печатные формы.

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

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

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

(28)а это уже как договор будет написан, и под чем франч подпишется

в форуме под страницей проскакивает изречение: "юзер понимает, что он требует только тогда, когда увидит результат"
надо помнить об этом

(+30) *там он у него - там он указывает что у него

(0) ТЗ нужно одному- разрабу чтобы закрыться

(31)+100500
вот тут полностью согласен

(30) повторил (17)

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

(27) какое отношение имеет из к основам проектирования 1с?? из должен писать чистый предметник

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

(40) Таким, что апетит приходит во время еды. Жадность тоже.

(40) путаешь требования и ТЗ. см (17)(30)

(7) Чушь. Заказчик пишет требования, а не ТЗ.

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

(43) чушь. знаю клиентов, у которых были сотрудники в роли аналитиков и составителей тз.

(44) и к (39) если твои ТЗ не учитывали, что проект реализуется на платформе 1с, то это были не ТЗ.

(45) ни один аналитик не может написать грамотное ТЗ....

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

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

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

(47) ТЗ описывает вообще то требования к системе.. и каким местом тут архитектор?? Если писать технический проект, который отражает специфику платформы (например 1С), тогда да - тут уже должен работать архитектор..

(45) Угу. И это сферическое в вакууме ТЗ, не учитывающее возможностей натягиваемой на предприятие системы, служит пипифаксом.

кто видел ТЗ с детальным описанием форм ??? а ведь по ГОСТУ положено :)

и интересно как можно описать "управляемые" формы, короче 1с и ТЗ понятия слабо коррелируемые

(48) Не привязанное к системе ТЗ - это прикладной миф теоретиков от ИТ.

(47) Разными масштабами мыслим, тут кое кто и аналитика в глаза не видел.

(51) тэкс... я видел... (52) уверяю, не миф.. писал(и) и пользовали для сеченовки..  привязка была не к системе, а к платформе 1С (и то частично)..

(49) на сколько я понимаю автора (0)

ТЗ - это то что дается программисту для работы....

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

Российские стандарты на разработку программных продуктов:
•ГОСТ 34.601 90
Информационная технология. Автоматизированные системы. Стадии создания.

•ГОСТ 34.602 89
Информационная технология. Техническое задание на создание автоматизированной системы.

•ГОСТ 34.201 89
Информационная технология. Виды, комплектность и обозначение документов при создании автоматизированных систем.

•РД 50 34.698 90
Автоматизированные системы. Требования к содержанию документов.

•ГОСТ 28195 89
Оценка качества программных средств. Общие положения.

•ГОСТ 34.603 92
Информационная технология. Виды испытаний автоматизированных систем.

•ГОСТ 28806 90
Качество программных средств. Термины и определения.

(55) я знаю про них)) и даже только что обновил свои сведения)).. и там, собственно, в них и написано, что ТЗ
_________
2.1. Техническое задание на создание АСУ должно содержать следующие разделы:
•введение;
•характеристика объекта управления;
•назначение АСУ;
•основные требования к АСУ;
•технико-экономические показатели АСУ;
•состав, содержание и организация работ по созданию АСУ;
•порядок приемки АСУ.
____________________
. Раздел «Основные требования к АСУ» должен содержать следующие подразделы:
•требования к системе и ее частям;
•требования к качеству выполнения функции АСУ;
•требования к видам обеспечения АСУ.

56 +, сейчас сижу и ваяю это самое тз))..

(0) Со школы ж знаем.. "Грамотное описание задачи - 50% ее решения"
Тут вопрос, кому выгодно...
Кто на сдельщине - тому и без ТЗ хорошо... Если каждая переделка оплачивается...
Кто на окладе - тому ТЗ нужно...

"ТЗ - это то что дается программисту для работы"
Вооот.
По ТЗ можно оценить объём работ, по ТЗ можно посчитать человекочасы и денежк. А без привязки к платформе это не ТЗ, потому как реализация склада на 1с и на асме для арм это две большие разницы.

(59) а если ТЗ пишется по объем денег?)))

(60) тогда там достаточно пункта "сделать чтоб было хорошо".

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

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

(62) то есть мы опять приходим к (59)

И не путайте ТЗ с проектной документацией.

(63) да, представил свой договор, куда включу и тз... это к текущим 20 страницам еще страниц 50-70... да хрен когда такой договор согласуешь. (64) при формировании ТЗ поздно считать денежки... денежки нужно считать на уровне коммерческого предложения...

(65) ога... исчо одЫн.. и с чем же не нужно путать ТЗ?? что это за проектная документация, куда ТЗ не входит??

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

(52) Отличная тема для выпиливания бюджета любого масштаба

(68) ТЗ де факто и де юре, является частью проектной документации

(68) Проектная документация описывает еще 100-ню сторон взаимоотношений на проекте

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

(68) ТЗ - один из главных проектных документов. Не совсем понимаю, почему его рассматриваете вне проекта.. (69) либо наоборот - нагибания исполнителя на (61)

(52) +1 ТЗ должен писать разработчик

(70) Я о том, что многие тут имеют в виду, что по ТЗ можно оценить объем работ. Т.е. что ТЗ включает в СЕБЯ проектную документацию. А это не так.

(75) Я по ТЗ, оцениваю объем работ на типовом функционале

а оценка бюджета - чаще всего это из области "напильники летят на север, а я хочу н-килобаксов (получить\заплатить)"

(76) ТЗ - источник необходимых данных для оценки объема работ. Но в общем случае - недостаточный.

(78) Ну в общем же случае все заказчики говорят- нам не нужны доработки- не проблема- вот сумма+ 1000 человеко часов программистов, чтобы вы понимали стоимость проекта- будет меньше- сэкономите

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

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуются техническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально).  А точнее группа специалистов АО главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.

Источник: http://chavalah.ru/?p=526
рекомендую почитать всем очень толковая статья

Пришлось из-за вас в гост лезть (ГОСТ 15_001). Все правы, можно делать как угодно, но я за то, чтоб ТЗ мог использовать кодер :).

"Конкретное содержание технического задания определяют заказчик и разработчик, а при инициативной разработке - разработчик."

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

(40) если Заказчик напишет в ТЗ "нарисуйте мне 7 перпендикулярных прямых красных линий, при этом чтобы 2 были синего цвета и 1 в форме котенка"?
ТЗ должно устраивать всех, если напишет Заказчик сферический бред то только упоротый Исполнитель возьмется за реализацию.

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

(82) Не надо путать получение результата и выполнения работ

(80) Ну это ГОСТовское определение, смысл лезть в частный журнал, когда можно почитать первоисточник

(84) для добросовестного Исполнителя путать эти вещи допускается. жуликов готовых подписаться под что угодно чтобы развести лоха на деньги - не рассматриваем.

(86) Я предпочитаю, в вещах которые не понимаю, доверять заказчику, нежели слишком умным кодерам

(83) вот именно. договорились вигвам изобразили, построили точно такой как нарисован, всех все устроило - профит.

Ессно в предельно упрощенном случае и минимальных рисках (простой внутренний проект) ТЗ может выступать документом всё-в-одном. Но чтобы не смешивать понятия имеет смысл рассматривать краевые условия.

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

(87) золотые слова... кодер - это последняя инстанция в вопросах функциональных требований

Помоему, ТЗ - это документ для прикрытия одного места у исполнителя.

На самом деле, неважно, кто пишет проектную документацию - важно, кто ее читает и визирует.

На проекте внедрения с привлечением внешнего подрядчика снаала разрабатывались "функционатльные требования" - документ, понятный пользователям. И его читало порядка 6-ти руклей со стороны заказчика. И документ получился качественным и адекватным процентов на 80%.

А вообще, рулит аджайл и т.п. Любая проектная документация в ИТ устаревает со страшной скоростью.

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

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

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

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

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

(7) + 100500

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

100

99 см 40

(90) Слушай, я сам заказчик системы, и требование к своему программеру я выдаю в 2 итерации,
1-я Чтобы выполняло такие-то функции
2-е Итоговые как надо

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

(4) Готовность программы измеряется выполнением ТЗ.

(0) ТЗ пишет тот, кому Заказчик оплачивает написание ТЗ.