Техническое задание
Сегодняшняя статья - юбилейная, но об этом позже - в конце. Итак, речь пойдёт о Техническом задании (ТЗ). О том, как написать технические задание, какие разделы должно содержать техническое задание, что должно отражать технические задание. Поговорим об особенностях написания технических заданий в тех или иных областях разработок.
Техническое задание - закон для разработчика. В процессе разработки - основной документ, которым он должен руководствоваться. Этот документ призван:
- описать цель работы. И разработчик, и заказчик должны чётко понимать, к чему они стремятся, за что один платит деньги, а другой - тратит время и напрягает мозги;
- описать задачи. Прежде чем начинать работу, необходимо прикинуть, насколько она затянется, сколько потребует ресурсов. Круг задач должен быть посильным разработчику, а заказчик должен представлять, чем разработчик будет заниматься, за что платить;
- регламентировать отношения. Один из самых важных моментов! Заказчик и исполнитель регламентируют объёмы, сроки, денежные суммы, порядок приёмки, форматы исходных и выходных данных и ещё множество условий, которые необходимо прописать во избежание конфликтных ситуаций.
По сути, техническое задание - договор между исполнителем и заказчиком. Договор, естественно, должен быть в рамках законодательства, иначе его можно будет признать ничтожным. Стороны, создающие и подписывающие договор (техническое задание) должны полностью осознавать все его пункты и вправе вносить любые свои требования, которые сочтут нужными.
Всё, что я сказал выше - результат моего собственного опыта и накопленных знаний. Я попытался сформулировать своё понимание сути технического задания. То, как я вижу этот документ в реальных современных условиях. Далее попытаюсь прокомментировать сказанное и проанализировать ошибки разработчиков и заказчиков, вызванные непониманием сути Технического задания (ТЗ).
Зачем нужно ТЗ?
В своей практике я нередко сталкивался с мнением, что техническое задание не нужно, что оно будет только мешать и тормозить процесс разработки, сковывать его. Считаю это крайне неверной позицией. Это позиция людей некомпетентных, непрофессиональных. Почему таким людям (это, как правило, разработчики) выгодно отсутствие ТЗ? А вот почему:
- Это скрывает отсутствие опыта, слабое представление сути дела, за которое берётся разработчик;
- Это даёт возможность затянуть разработку и увеличить бюджет;
- Это позволит недобросовестному исполнителю безнаказанно урезать объёмы работ, ухудшать характеристики;
- Это позволит исполнителю “левачить” - заниматься другой разработкой в то время, пока заказчик ему платит. Разработчик может выполнять часть работ, якобы нужных для проекта, а потом сдавать их на сторону.
Отсутствие технического задания во взаимоотношениях заказчика и исполнителя - беззаконие. А беззаконие, как вы знаете, рождает хаос, неразбериху, становится причиной жульничества и надувательства. Так что знайте, уважаемые граждане, что тот, кто предлагает работать без оформления отношений, не совсем честен с вами.
Как аргументируют отказ от оформления ТЗ?
Вообще, это забавная тема. Согласитесь, действия ушлых или недалёких персонажей всегда выглядят комично. Отсутствие логики или прямое надувательство, подмена одного другим часто встречаются в жизни, но не сразу распознаются. Возможно, некоторое из того, что я сейчас опишу, вам уже встречалось. Согласитесь, случаи типичны.
Итак, поводов к тому, чтобы отказаться оформлять ТЗ, можно услышать множество:
- Задача такая сложная и такая “творческая”, что её невозможно загнать в рамки ТЗ!
Глупость… Вы знаете, что технические задания составляются даже на произведения искусства? На памятники, рисунки, логотипы, мелодии, даже на мультяшные персонажи. И в этом нет ничего удивительного. Всё поддаётся формализации и описанию. Лишь непрофессиональный человек не сможет описать свою работу или создаваемый продукт.
- Написание ТЗ займёт много времени и ресурсов. Уж лучше взяться потихонечку за работу, а там - определимся!
Отговорка нерадивого человека… Профи потратит на ТЗ от одного до нескольких дней. Где надо - заложит ресурсы на изыскания, а где - чётко определит выполняемое. Только плохо разбирающийся в проблеме человек не сможет заранее всё предугадать.
- ТЗ не нужно, поскольку задача слишком очевидна и проста!
Ловушка, поставленная профессиональным лентяем… Ну если там всё так просто, то опиши, дорогой, эту простоту на 1-2 листах! “Дорогой” сразу же сникнет, поскольку станет очевидно, что выползет множество нюансов, требующих уточнения. И элементарная проблема в ходе детальной проработки сразу станет сложной и серьёзной. Кстати, такой ход используется для того, чтобы потом растянуть сроки, вытянуть больше денег, когда возникнут “непредвиденные трудности”.
Увы, чаще всего встречал подобные “отговорки” среди программистов. За всю свою практику исключение составил всего один человек. Он - крупный специалист в своей области. Без обсуждений взялся за написание ТЗ и составил его лаконично, грамотно, определённо. Человек, почти полтора десятка лет занимающийся программированием, составил безупречное ТЗ на сложнейший программный продукт.
Приведу другой пример, когда один “крупный деятель”, применяя все приведённые выше отговорки, так затянул процесс разработки программного обеспечения, что все окружающие просто диву давались! Отмечу, что проект, начатый более трёх лет тому назад, до сих пор не закончен. И непонятно, на какой стадии находится эта разработка. Удивительное попустительство работодателя в вопросе составления ТЗ и написания планов практически похоронило проект и громадную кучу денег. А тот “крупный деятель” занимается попутным самообразованием за счёт работодателя и откровенным бездельем.
Кто должен писать техническое задание?
Ответ на этот вопрос однозначен - разработчик. Другого не дано. Только он способен грамотно представить цели, сформулировать задачи. Если цели неясны, то происходит итеративный процесс написания ТЗ - разработчик постепенно формирует цель в глазах заказчика, пытается понять его субъективный взгляд на проблему. Это трудный и длительный процесс, но он поможет избежать двусмысленностей и непонимания.
Но из правил есть исключения. Мой личный опыт показал, что есть категории исполнителей, неспособных писать технические задания. Я это отношу к специфике занятий и людей. И хоть ты расшибись, но эти категории граждан вам ТЗ не родят. Не обижайтесь, перечисляю в порядке убывания способности НЕ написать техническое задание:
- Дизайнеры;
- Web-программисты;
- Программисты.
Это те категории работников, с которыми мне довелось столкнуться. Скорее всего, уважаемые читатели смогут продолжить список или откорректировать его по-своему. Кому захочется это сделать - прошу комментировать статью или высказываться на Форуме Берлоги Инженера.
Как довод, приведу ссылку на статью “Жизнь без технического задания” (Олег Бунин, Компьютерра). В статье даже приводятся пути решения задач без оформления ТЗ. Надо сказать, интересный подход, но, как мне кажется, таящий в себе массу выше описанных проблем.
Или вот, жизненный пример - советы и рекомендации по составлению технического задания. Люди, занимающиеся созданием сайтов, предлагают решать заказчику следующие задачи:
1. Постановка задачи: какие задачи должен решать сайт.
2. Определение общего бюджета финансирования: сколько денег Заказчик может или готов заплатить за сайт.
3. Подготовка материалов для сайта.
4. Разработка технического задания на создание сайта.
Далее специалисты приводят последовательность действий, которую должен осуществить заказчик. Вдумайтесь в написанное! В конце рекомендаций специалисты дают примечание:
Профессиональному Разработчику техническое задание, как таковое, не требуется: он и без него знает, как создать сайт.
Но Разработчик будет создавать дизайн сайта, руководствуясь принципом “клиент всегда прав”.
Тем более что деньги платит клиент. Разработчик не несет ответственности за несоответствие сайта эстетическим ожиданиям Заказчика при условии выполнения технического задания на разработку дизайна сайта.
Следовательно, техническое задание требуется, в первую очередь, для самого Заказчика. Именно на основании утвержденного им технического задания он и должен производить приёмку готового сайта.
Не правда ли, гениально?!?! “ТЗ нужно заказчику, а не разработчику” “Разработчик не несёт ответственности…”
Вот более конструктивный подход: Как правильно составить техническое задание? Не очень много, но по делу.
Надеюсь, уважаемые читатели всё поняли. Когда встаёт вопрос о сложной технической разработке, за написание ТЗ берётся исполнитель. Чем “проще тема”, тем труднее исполнителю составить ТЗ. Это нужно понимать. Лично я допускаю, что на некоторые виды работ техническое задание должно писаться заказчиком, иначе последний рискует потерять много денег и не получить того, что хотел.
Что должно содержать техническое задание?
Определённых рекомендаций по тому, что должно содержать ТЗ, нет. Для тех ТЗ, которые пишутся исполнителем, (технические разработки) существует ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.
Нет стандарта, который бы описывал создание ТЗ для других систем (не автоматизированных). Но ряд исследователей всё равно предлагает отталкиваться именно от указанного стандарта при написании технических заданий в других областях человеческой деятельности (в частности, на программные продукты).
Как видно, стандарт этот был принят в стране, которой уже нет, в строе, которого уже не существует, людьми, которые не были знакомы с современными реалиями. Не спорю, стандарт конструктивен и написан достаточно обобщённо, поэтому его вполне можно применить для написания ТЗ (если этого требует госзаказчик).
Но ведь к вам никто не придёт и не оштрафует за то, что в своей организации вы составили ТЗ по собственной, удобной для вас форме! Нужно учитывать специфику своего предприятия, законодательства, рыночных условий. Поэтому постарайтесь подойти к написанию ТЗ как можно более серьёзно, возможно, с привлечением юриста.
Отмечу ряд требований, которые, по моему мнению, должны выполняться в техническом задании:
- Полнота - как можно более полное описание системы, целей и задач;
- Логичность - описания не должны быть противоречивыми
- Правильность - отсутствие ошибок, которые могут вести к двусмысленности или некорректности;
- Связность - структура документа должна быть подчинена одной цели.
Состав разделов разработчик должен выработать сам, с годами и опытом. Но обращу внимание на основные разделы технического задания, которые в той или иной степени должны быть отражены:
- Технические требования и стандарты;
- Структура;
- Функциональное содержание отдельных структурных элементов;
- Состав работ и сроки выполнения;
- Стоимость работ.
Если в техническом задании были описаны указанные моменты, то его можно считать достаточно полным.
Как уже говорилось выше, исключений много. Есть ряд сфер деятельности, в которых к написанию ТЗ нужно подходить по-особому. Кому интересно, советую прочесть статью Техническое задание для дизайнера. Название статьи говорит само за себя.
Проблема технических заданий - интересный пример постановки задачи при составлении ТЗ на сайт.
Составление технического задания сайта - содержание технического задания с комментариями по каждому разделу. Обстоятельно, подробно.
Очень большой список примеров технических заданий на разработку сайтов. Посмотрите, но относитесь к приведённому критически, с осознанием того, что идеального шаблона для вашего конкретного случая не существует.
Статья лежит в разделе Справочники. Но прошу относиться к информации, приведённой в ней, как к информации для размышления, а не прямому руководству к действию. Оценку примеров и материалов по ссылкам автор оставляет на суд читателя. Сами решайте, “что такое хорошо, а что такое плохо”.
Теперь о юбилеях.
Обратите внимание на индекс статьи - 200 - круглое число! 
Статьи у нас на Берлоге идут не по порядку, но индекс в некоторой степени говорит о том, сколько статей было написано.
Недавно с удивлением обнаружил, что эта статья - сотая моя статья в Берлоге. Учитывая основное направление своих статей - аналитическое и репортажное (в меньшей степени - информационное), должен отметить довольно большую работу, проведённую со времён основания ресурса.
Кроме того, совсем недавно у меня был юбилей.
Поскольку удивительным образом во времени и пространстве сошлись все эти круглые даты и числа, я решил отметить случившееся именно ЭТОЙ статьёй на серьёзную и важную для каждого разработчика тему.
Мира вам! Удач и успехов во всех начинаниях, коллеги! До новых встреч в Берлоге инженера.
С уважением,
Владимир
Рекомендуйте на news2.ru
Занесите в del.icio.us
Читайте также:
No related posts
Январь 22nd, 2007 at 8:53
Владимир, поздравляю вас от всей души с праздниками и юбилеями!
Я сам напарывался на проблему отстутствия ТЗ, но уже с другой стороны, а именно со стороны злоупотребления заказчиком отстутствия чёткости..
Программисты могут попасть в так называемую долговую яму, когда заказчик просит дописать и доработать ещё функционала на, казалось бы, уже законченную работу. И программистам приходится работать намного больше и дольше, затягивая проект, а реально выполняя всё больше и больше работы, чем это подразумевалось в самом начале, постоянно находясь в состоянии дедлайна. И против ТЗ выступал сам заказчик…
Дальше мне интересна тема, если над проектом работает не один человек, то вероятно стоит написать ещё и ТД (Техническую диррективу) в которой следует указывать все ньюансы в вопросах программирования. Как именовать переменные, как будут расположены исходники в каталогах, как называть файлы, какая шапка должна быть в исходниках и в какой кодировке писать.. Продолжать дальше можно до бесконечности, но этот файл жизненно необходим для тех, кто работает не в одиночку и этот документ с каждым проектом требует лишь минимальных изменений.
И напоследок, хотелось бы напомнить что есть софт для удобного ведения списка дел, что требуется выполнить в проекте. Это различные Todo-списки и Gant-проекты. (К сожалению не смог найти ссылку на форуме Берлоги, как я помню этот софт уже обсуждался)
Январь 22nd, 2007 at 10:28
Спасибо, Максим!
Вы дали очень правильные замечания. Действительно, я мало осветил проблему со стороны “минусов разработчику”. Но все минусы, что Вы описали, вызваны отсутствием ТЗ. А ТЗ ДОЛЖЕН написать разработчик. То есть всё равно, вопрос замыкается на том, что необходимо сделать разработчику, хочет того заказчик или нет. В описанной Вами ситуации исполнитель попадает в положение “сам виноват”. Увы, такое бывает.
Вопрос “Технической директивы” мы, возможно, разовьём ещё на страницах Берлоги. Действительно, нужен документ, регламентирующий корпоративный стиль оформления. Или порядок взаимодействия. Мне приходилось писать такие документы. Отмечу, что они очень хорошо помогают в работе.
Софт для планирования работ приводится в этой теме:
http://beta.delta-z.com/cgi-bin/yabb2/YaBB.pl?num=1157481581
Полезно расписать сроки и задачи, приведённые в ТЗ в каком-нибудь планировщике проектов, а потом самому следить за ходом выполнения. Считаю, что это является признаком высокого профессионализма в работе. К этому нужно стремиться.
Ещё раз благодарю за ценные замечания.
Январь 22nd, 2007 at 14:47
А вот, кстати, вопрос. Неоднократно в различных сообществах обсуждалось предложение, чтобы разработка ТЗ шла отдельным пунктом в перечне работ и оплачивалось отдельно, поскольку это есть тоже в какой-то мере продукт.
Это предлагалось для исключения недобросовестного поведения заказчика, который, получив ТЗ, просто уйдет с ним к другому исполнителю, не заплатив.
Примечание: речь шла о ТЗ на серьёзный большой продукт.
Кто что по этому поводу думает?
Январь 22nd, 2007 at 15:28
“Для того, чтобы правильно поставить вопрос, нужно знать половину ответа.” Составляя ТЗ, разработчик иногда проводит серьёзную проработку темы, если оная слишком сложна или эксклюзивна.
Однозначно, ЗА РАЗРАБОТКУ ТЗ НУЖНО БРАТЬ (ПЛАТИТЬ) ДЕНЬГИ.
Почему дизайнеры и web-программисты не очень охотно идут на то, чтобы писать ТЗ? Отчасти потому, что это большая проблема - вытянуть из клиента то, что он хочет. Так что “пусть сам пишет как знает”. /*Кстати, этот документ, что требуют вышеназванные специалисты, будет называться уже не ТЗ, а Требования или “Технические требования (ТТ). То, что ТРЕБУЕТСЯ заказчику.*/
Лично я сталкивался с тем, что за ТЗ платили. А потом - платили за саму разработку. Считаю это нормальной практикой.
Январь 23rd, 2007 at 23:40
Кстати да.. Мне тоже кажеться что за ТЗ следует оплачивать, как за разработку. Тут я полностью согласен с Владимиром.
Плюс стоит учесть тот факт, что в ТЗ реально прорабатываются все ньюансы вопроса..
Т.е. по любому должна быть предоплата, в которую прежде всего будет включаться ТЗ и для веб-дизайнеров - дизайн сайта..
Февраль 23rd, 2007 at 12:03
Данной статьей тема ТЗ почти закрыта
Чтобы прикрыть ее окончательно и бесповоротно, могу предложить ознакомиться с парой статей:
- http://authorit.ru/?c=8&b=9 - сведения о «тайных подлостях» технического задания, соображения о том, кому доверить разработку технического задания, разбор вариантов, анализ последствий;
- http://authorit.ru/?c=8&b=3 - статья для совсем уж начинающих.
Есть на сайте готовые разделы ТЗ по ГОСТ 34.602-89, в разделе “Применение ГОСТ 34″.
ЗЫ. Читая статью г-на Бунина в компьютерре, не знал, смеяться или плакать. Товарищ совершенно не в теме, при этом с легкостью необыкновенной берется за “крупные формы”. Цирк
Февраль 28th, 2007 at 13:32
Как говорится, многа букаф ниачём: простое перечисление очевидных фактов + несколько субъективных наблюдений. Всё в духе: “Прежде чем подойти к входной двери, обязательно проверьте не занята ли у вас рука каким-либо предметом. Если она занята - вы не сможете эффективно открыть дверь, поэтому загодя положите предмет в карман или в сумку. Дверь открывать лучше за ручку - здесь для достижения цели применяется минимум сил.” и т. д.
И ещё абсолютно непонятно для кого сатья: профессионалы давно всё знают и, пожалуй, найдут в этой статье массу недостатков; новички получат отличную информацию из лекций или книг. Ничего нового, что являлось бы хорошим дополнением к опыту или теории, в статье нет.
Март 1st, 2007 at 1:56
[…] Данный пост прольёт свет то, что из себя представляет ТЗ, кто должен писать его и что оно должно содержать. Вобщем, статья суперская рекоммендую к прочтению. […]
Март 1st, 2007 at 23:05
Такие темы нужны прежде всего тем, кто не решил, надо ли ему писать ТЗ или нет.. Как не крутите, но существует огромное количество людей, которые не относятся к новичкам уже читающим маны по составлению ТЗ, так и не являющиеся проффесионалами в области Технического Задания..
И именно для этих людей данный пост и был написан.
Я тоже читал книги из разряда “всё обо всём”, и часто был очень рад тому, что эта книга не претендует на серию “для профессионалов” или “читать только экспертам”, потому что эти книги давали мне вводный курс в технологию о которой раньше я никогда и не задумывался.. Например : экстремальное программирование.
PS Все мы только со временем познаём Дзен. “И Билл Гейтс был маленьким и сопливым!” (с) Вроде с БОРа..
Март 14th, 2007 at 1:39
“Кто должен писать техническое задание?
Ответ на этот вопрос однозначен - разработчик”
Есть аргументированное опровержение:
“Техническое задание пишет системный аналитик из 3-й организации - компании-эксперта”
http://community.livejournal.com/ru_bsa/10586.html
Март 16th, 2007 at 14:08
2 Денис Бесков-Доронин:
Интересный, аргументированный подход к написанию технического задания. Но, боюсь, редко встречающийся. Как это проверить? Приведите, пожалуйста, ссылки на организации, профессионально занимающиеся написанием ТЗ…
Честно говоря, таких я не встречал. Безусловно, такие есть, но их на пару порядков меньше тех, кто непосредственно сам разрабатывает и под себя пишет ТЗ (для написания качественного ТЗ всё же нужно знать технологию, особенности производства исполнителя, особенности его “кухни”).
Но рациональное зерно есть. И очень большое. Считаю полезным привлечь стороннюю экспертную компанию для ТЕХНИЧЕСКОЙ ЭКСПЕРТИЗЫ составленных документов или для составления ТТ (технических требований).
Конечно, это более затратный путь, но и очень эффективный, менее “ошибочный”. На этапе ТЗ такой путь позволит действительно избежать “зашоренности” и “ушлости” разработчиков.
Вопрос. Сколько будут стоить услуги эксперта? Это будет сумма, соизмеримая со стоимостью написания ТЗ.
Тогда другой вариант развития событий… А если привлечь не дополнительных экспертов, а ДРУГИХ разработчиков? Такая практика давно существует и называется ТЕНДЕР. Подобный путь позволит вам “за те же деньги” поиметь два или более ТЗ, а кроме того, более эффективно выбрать компанию-исполнителя.
Март 16th, 2007 at 15:08
“Приведите, пожалуйста, ссылки на организации, профессионально занимающиеся написанием ТЗ”.
Любая консалтинговая компания в сфере IT и бизнеса.
http://www.google.ru/search?q=%D0%BA%D0%BE%D0%BD%D1%81%D0%B0%D0%BB%D1%82%D0%B8%D0%BD%D0%B3+IT
“Безусловно, такие есть, но их на пару порядков меньше тех, кто непосредственно сам разрабатывает”
Проектных институтов тоже меньше, чем СМУ - и что? Нетиповые ТЗ делают эксперты, типовые - по шаблону делает сам исполнитель.
“Вопрос. Сколько будут стоить услуги эксперта? Это будет сумма, соизмеримая со стоимостью написания ТЗ.”
Вот именно, тогда почему его сразу не привлечь?
“А если привлечь не дополнительных экспертов, а ДРУГИХ разработчиков? Такая практика давно существует и называется ТЕНДЕР. Подобный путь позволит вам “за те же деньги” поиметь два или более ТЗ, а кроме того, более эффективно выбрать компанию-исполнителя.”
Если задача типовая, хорошо понятная, то конкурирование типовых же ТЗ разных Исполнителей вполне оправдано, но таких проектов очень мало - везде нужен учёт специфики заказчика.
Если задача инновационная, а следовательно, ТЗ пишется по результатам более-менее серьёзного обследования/исследования, то получается, вам нужно выделить в 2 раза больше ресурсов на передачу информации 2-м потенциальным разработчикам. Тендер ТЗ на инновационную задачу без предварительного исследования - это абсурд.
Март 16th, 2007 at 15:12
“Интересный, аргументированный подход к написанию технического задания. Но, боюсь, редко встречающийся…”
Вам шашечки или ехать?
В смысле - вас интересуют популярные подходы (как принято) или эффективные (как делают лучшие)?
Март 16th, 2007 at 15:38
2 Майевтик:
Зашёл, посмотрел. Специально сходил по ссылкам, порылся… Что-то ни у кого не обнаружил такой услуги: написание ТЗ. Если Вас не затруднит, дайте пожалуйста конкретную ссылку на конкретную организацию. Желательно в Москве. Желательно, специализирующуюся в области электроники. Не поленюсь, позвоню. Кто знает, может быть у меня с ними завяжется долгое плодотворное сотрудничество!
… ??? Наверное я чего-то не понимаю.
ТЗ пишется по результатам более-менее серьёзного обследования/исследования… Речь идёт об исследовательских работах или о написании ТЗ?
Вы предлагаете и разработчику и эксперту заказать “предварительное исследование”?
Если Вас не затруднит, приведите пожалуйста пример из жизни (на примере какого-либо конкретного проекта или изделия), где так была поставлена работа - с разработчиком и с экспертом. Какие функции были возложены на одного и на другого? Как примерно соотносились средства между ними?
Хочется вникнуть поглубже в описанную Вами методику написания ТЗ с привлечением эксперта.
Март 16th, 2007 at 19:12
Мне кажется в http://philosoft.ru/ профессионально пишут ТЗ и любую другую классическую документацию.
Статья хоть и длинная, но какая-то размытая что ли. Такой общий обзор. А хочется чего-нибудь конкретного и качественного
Март 16th, 2007 at 19:30
дело в том, что каждый более-менее серьезный продукт имеет некие тонкости/особенности реализации. Для качественной реализации многих “фич” до начала разработки следует провесри именно исследование на предмет того, как это можно качественно реализовать и как избежать ошибок, которые уже были выявленны предшественниками. ТЗ на серьезные продукты просто так из головы не пишуться. Мало того, хорошее ТЗ должно содержать информацию о способах и методах реализации, следовательно найти оптимальные алгоритмы -тоже немаловажная задача. Отсюда и вытекает достаточно большие обемы работы для создания хорошего ТЗ, которое действиельно может помоч в работе, а не становиться обузой….
По поводу того, кто должен писать ТЗ– абослютно не согласна с утверждениями, что это должен делать разработчик или заказчик. Как показывает практика ни тот ни другой не смогут сделать качественное ТЗ. у них разные уровни абстракции. Для этого должена на мой взгял в проекте отведена быть отдельная роль, как то аналитик, или технический менеджер, который мог бы понимать и “картинки”(вижен)которым мыслит среднестатистический заказчик, так и диаграммы классов, которые представляет себе среднестатистический разработчик, когда речь идет о вопросах реализации
Март 16th, 2007 at 23:34
2 Дмитрий Сергеев:
Думаю, с philosoft Вы немного погорячились. Они, как видно, предпочитают оформлять то, что уже сделано - пользовательская и эксплуатационная документация. О ТЗ на их сайте в разделе “услуги” не говорится ничего. Но не сомневаюсь, если обратиться к ним, ТЗ на сайт или что-то ещё подобное они напишут.
2 Aleshka
Полностью согласен с Вами в плане того, что ТЗ - в какой-то степени техническая проработка проекта.
А в какой сфере деятельности Вам показала практика, что ТЗ не может сделать ни заказчик, ни разработчик? “Аналитик или Менеджер” - представитель сторонней организации?
Мне кажется, у нас с Вами разное понимание разработчика и заказчика. Под разработчиком я имел ввиду организацию-разработчика. Уж кто там именно занимается написанием этой бумаги - дело другое. Скорее всего, будет привлёчён именно разработчик как эксперт, как человек, которому подписываться под тем, что будет сделано (это логично), но сам документ может (и должен) делаться менеджером. Это более справедливо. Именно менеджер более качественно сделает тайм-планинг, рассчитает ресурсы (как людские, так и финансовые). А разработчик (программист или инженер), действительно, сделать этого качественно не сможет.
Простите, если не совсем точно дал понять в тексте статьи, кто такой разработчик.
Март 16th, 2007 at 23:41
Ну и ладно, бог с ним, с “Философтом”
Кстати сказать, я сегодня читал ТЗ на сайты от “Ланита” и “IBS” http://www.dserg.com/requirements-specifications-links-2007-03-16.html
Март 19th, 2007 at 11:43
2Vladimir
да, вы правы, я рассматривала статью исключительно со стороны IT технологий.. в этой сфере дефствительно написание ТЗ заказчиком и(или)разработчиком практически не возможно… однако, в др сферах, не исключено, что это весьма рабочий вариант…
В моем предыдущем комментарии действительно рассматривала “разработчика” как одну из ролей в IT проекте.. поєтому видимо и вышло непонимание
Март 20th, 2007 at 14:37
[quote]Зашёл, посмотрел. Специально сходил по ссылкам, порылся… Что-то ни у кого не обнаружил такой услуги: написание ТЗ. Если Вас не затруднит, дайте пожалуйста конкретную ссылку на конкретную организацию. Желательно в Москве. Желательно, специализирующуюся в области электроники. Не поленюсь, позвоню. Кто знает, может быть у меня с ними завяжется долгое плодотворное сотрудничество! [/quote]
Какие проблемы? Все будет в лучшем виде, а заодно и по ГОСТ - пишите. Лицо как физическое, так и юридическое. Вот кусочек “портфолио” -
[quote]На договорной основе (с применением библиотеки) в разное время были разработаны:
- техническое задание и технический проект (14 взаимоувязанных документов объемом в пределах тысячи страниц) «Развитие … … сферы образования» в рамках программы «Электронная Россия», сроки разработки составили две недели;
- техническое задание на платежную интернет-систему, аналог webmoney - три дня;
- техническое задание и проектная документация (23 взаимоувязанных документа общим свыше тысячи страниц) на АИИС КУЭ «Энскэнерго», более двадцати энергообъектов, свыше двухсот точек учета - две недели;
- технико-экономическое обоснование и техническое задание на проект информационного портала г. Энска, в рамках долгосрочной комплексной целевой программы «Электронный Энск» - четыре дня.[/quote]
Март 20th, 2007 at 14:44
Что я говорил
Март 20th, 2007 at 15:01
В ТЗ от IBS:
1. частично неправильно сформулированы цели создания системы - как всегда, попутали цели и задачи;
2. неправильно сформулирован п. 2.3;
3. пп. 3.1 и 3.2;
4. …
П. 5.1 тиснули слово в слово из http://authorit.ru/?c=3&b=7 - даже табличка с синими границами осталась. Правильно, кстати, поступили, только надо было весь раздел забрать.
П. 4.1.6 - с эргономикай автор опасно поступил
Не должно быть слов “легко”, “адекватно”, “приемлемо”, “минимум усилий”. Не только в подразделе, но и в ТЗ в целом. Так и попасть можно при сдаче. Опять же, есть ГОСТы по эргономике и человеко-машинному взаимодействию.
“Доступность: информация должна быть представлена в такой форме, чтобы ею могло воспользоваться наибольшее число пользователей” - сразу вызывает много вопросов.
В-общем, написано неплохо, но очень неосторожно. В части функционала все более-менее понятно, даже при поверхностном чтении. Не хватает некольких важных разделов.
Март 20th, 2007 at 15:08
authorit, что вы человека дезориентируете, так и пишите, что занимались сборкой и оформлением ТЗ, а не созданием требований. 1000 страниц за 2 недели - это 12 страниц в час. Выявлять, фиксировать, согласовывать и т.д. требования с такой скоростью просто невозможно.
Vladimir:
“Не обнаружил такой услуги: написание ТЗ.”
Это потому, что такая услуга плохо осознана, нет на нее спроса, вот компании и не пишут - но делают.
“Если Вас не затруднит, дайте пожалуйста конкретную ссылку на конкретную организацию. Желательно в Москве. Желательно, специализирующуюся в области электроники.”
Я с электроникой не работал, возможно, это очень узкий рынок - надо смотреть. Я говорил про связку “отраслевой бизнес - информационные системы и консалтинг”.
“Речь идёт об исследовательских работах или о написании ТЗ?
Вы предлагаете и разработчику и эксперту заказать “предварительное исследование”?
Если вы понимаете под “написанием ТЗ” только оформление уже имеющихся требований, как это, похоже, делают authorit - то да, для этого никаких исследований не нужно. Но суть работы по РАЗРАБОТКЕ ТЗ - это выявление, сбор, фиксация, структуризация требований, выявление и разрешение противоречий и т.д - это серьёзная непростая работа, иногда невозможнаяя без предварительного исследования. Какой смысл писать в ТЗ требование “Дискрявые фурчалки должны пирогамить дисперционально”, если нигде в документе и приложениях не проработано, что означает каждый из терминов, как он связан с другими, как ведут себя объекты, обозначаемые этими терминами и т.д. - т.е. то, что называется логикой предметной области? Да, если разработчику ТЗ Предметная область хорошо известна, то время на иссследование сокращается, но всё равно, если создаваемая система или продукт связаны со спецификой заказчика (бизнес-процессы, бизнес-правила), то их нужно изучать, прежде чем писать ТЗ.
“Если Вас не затруднит, приведите пожалуйста пример из жизни (на примере какого-либо конкретного проекта или изделия), где так была поставлена работа - с разработчиком и с экспертом. Какие функции были возложены на одного и на другого? Как примерно соотносились средства между ними?”
Стоимость ТЗ в IT-проектах по такой схеме в среднем составляет от 20 до 40% всех работ в зависимости от сложности проекта. Функции расписаны по ссылке выше. За подробностями приходите в ICQ 6319839.
Март 20th, 2007 at 15:21
authorit, что вы человека дезориентируете, так и пишите, что занимались сборкой и оформлением ТЗ, а не созданием требований. 1000 страниц за 2 недели - это 12 страниц в час. Выявлять, фиксировать, согласовывать и т.д. требования с такой скоростью просто невозможно.
Мне всегда казалось, что сбор, анализ, формализация, систематизация и структуризация требований проводятся на ПРЕДПРОЕКТНЫХ СТАДИЯХ по ГОСТ 34.601-89 - http://www.nist.ru/hr/doc/gost/34-601-90.htm ГОСТ, наверное, безнадежно устарел 
_________________________________________________
Все возможно, когда технология отработана. Требования, кстати, не создают, а формулируют. Если речь идет о ТЗ.
——————————————————
Если вы понимаете под “написанием ТЗ” только оформление уже имеющихся требований, как это, похоже, делают authorit - то да, для этого никаких исследований не нужно. Но суть работы по РАЗРАБОТКЕ ТЗ - это выявление, сбор, фиксация, структуризация требований, выявление и разрешение противоречий и т.д - это серьёзная непростая работа, иногда невозможнаяя без предварительного исследования.
———————————————————————————
Не знал, извиняйте
Март 20th, 2007 at 15:30
Майевтик, примите извинения выпускнику 2002 года от выпускника 1986 года
Просто нас по-разному (и разному) учили 
—————————————————————–
“Если Вас не затруднит, приведите пожалуйста пример из жизни (на примере какого-либо конкретного проекта или изделия), где так была поставлена работа - с разработчиком и с экспертом. Какие функции были возложены на одного и на другого? Как примерно соотносились средства между ними?”
——————————————————————
Проекты АИИС КУЭ оптового рынка - все без исключения согласовываются с НП “АТС”, энергонадзорами, смежными субъектами и т.д. Перечисленные организации проводят как техническую и “документальную” экспертизу, так и метрологическую.
Март 20th, 2007 at 15:48
>”Не знал, извиняйте
Мне всегда казалось, что сбор, анализ,
> формализация, систематизация и структуризация требований
> проводятся на
> ПРЕДПРОЕКТНЫХ СТАДИЯХ по ГОСТ 34.601-89 -
> http://www.nist.ru/hr/doc/gost/34-601-90.htm ”
Хотите по ГОСТу, давайте по ГОСТу. Цитирую ГОСТ 34.602-89:
“1.1. ТЗ на АС является основным документом, определяющим ТРЕБОВАНИЯ и порядок создания (развития или модернизации - далее создания) автоматизированной системы”.
На этапе “Формирование требований к АС” по ГОСТ происходит лишь формулировка первичных требований Закзачика, фактически задание на исследование. А это далеко не то же самое, что полные требования к системе, задающие пространство решений для проектирования/конструирования.
> “ГОСТ, наверное, безнадежно устарел :)”
ГОСТ не безнадёжно устарел, а требует дополнения в конкретных категориях проектов. Что обычно и делается, например для сферы автоматизации бизнеса: http://beskov.ru/2006/01/31/obzor-protsessa-razrabotki-is/
Например, этапы/фазы 1 “Организационно-стратегический уровень” (”Постановка бизнес-задачи”), 2 “Бизнес-анализ” и 3 “Концептуальное преоктирование” примерно соотвествует “Формированию требований к АС” и “Разработка концепции АС” из ГОСТа.
Март 20th, 2007 at 16:13
Вы не тот ГОСТ смОтрите - смотрИте 601. Там, как минимум, предполагается два отчета и концепция. В них требования формулируются далеко не “рамочно”.
Стадии
Этапы работ
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС.
2.1. Изучение объекта.
2.2. Проведение необходимых научно-исследовательских работ.
2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.
2.4. Оформление отчёта о выполненной работе.
3. Техническое задание.
Разработка и утверждение технического задания на создание АС.
Март 22nd, 2007 at 15:30
authorit
Я знаю разницу между 601 и 602. Но если идёт речь о конкретной работе, то надо смотреть более специализированный документ, правильно?
Что же тогда входит в состав ТЗ (какие понятийные конструкты) по вашему, и откуда они берутся?
Vladimir Says:
“Зашёл, посмотрел. Специально сходил по ссылкам, порылся… Что-то ни у кого не обнаружил такой услуги: написание ТЗ. Если Вас не затруднит, дайте пожалуйста конкретную ссылку на конкретную организацию.”
Смотрите по словам “требования к ИС”:
http://www.itplus.ru/itconsulting/ittreb.htm
http://www.aksionbkg.com/services/it/requirement/
http://www.novosoft.ru/consulting/is_development.shtml
http://www.rdtex.ru/win/root/development_technical_project.html
http://www.infosys.mallenom.ru/inform_system_sale.php
http://www.bital.ru/it-consult.html
http://www.consulting.ibs.ru/content/consulting/115/1154-article.asp
http://itmanage.ru/
Апрель 4th, 2007 at 23:26
[…] создания хорошего ТЗ, предлагаю ознакомиться со статьей на ту же тему, размещенной на сайте Берлога Инженера. […]
Май 5th, 2007 at 11:07
Возвращаясь к “кладу” - ТЗ от IBS и Ланита. На самом деле, в этих ТЗ - “прокол на проколе”.
Разумеется, речь не идет о функциональных требованиях. Проколы типовые, относящиеся, в основном, к разделам “Требования к системе в целом”, “Требования к видам обеспечения” и ко всем без исключения нижележащим.
Если найду время - подготовлю статью с разбором ошибок одного из перечисленных ТЗ.
К “кладам” рекомендую относиться с большой осторожностью. Формальное наполнение разделов ТЗ еще не означает, что разделы наполнены правильно.
Июль 2nd, 2007 at 17:24
[…] (authorit.ru) Составление технического задания сайта (lessio.ru) Техническое задание («Берлога […]
Август 21st, 2007 at 9:21
Добрый день.
Я также занимаюсь проблемой написания документации, и начал проект www.rugost.com
В нем рассматриваются именно практические примеры написания как формальных разделов документов, так и смысловых.
В данный момент описано около одной трети всех возможных документов ТП и РД.
Было бы интересно узнать Ваше мнение.
Сентябрь 12th, 2007 at 14:46
Достаточно беспредметны как статья, так и комментарии.
При крнкретизации объекта технического задания возникает столько “ветвлений”, что черт ногу сломит.
Участвовал в разработке технического задания (со стороны Заказчика) и последующем внедрении системы управления механосборочным цехом (в 80-х). Это был уровень ГОСТов (тогда еще 24.ххх).
Сегодня “хозяин”, наворовав у людей и государства $1 млн, запускает производство с оборотом $80 тыс. в сутки. Этим “пароходом” нужно как-то управлять. Буду ли я писать ТЗ на свою разработку - НЕТ. Я оценю его готовность платить за выполненные этапы и буду поэтапно ПРОДАВАТЬ результат. Он не будет знать концепции - а он и не хочет ее знать. Он еще не готов это понять. Процесс прервется в момент сдачи неоплаченного этапа. Для разработчика потеря не критична (при правильном разбаении на этапы), а у Заказчика внедренное будет работать. Все потеряли немного.
В статье основной упор делается на недобросовестность разработчиков. Разработчики, почему-то молчат. Они умные. Они знают, что процессы (решение проблем автоматизации чего-либо) идут самостоятельно, а подобные статьи - следом.
Февраль 19th, 2008 at 18:01
Советы как создавать сайты:
http://www.web-creative.ru/doc/doc.php?id=10
Несколько советов о том, как правильно подойти к проблеме создания сайта, работы с заказчиком сайта, как корректно определиться с заданием на создание сайта (в конечном итоге).