Основой технического задания (далее по тексту — ТЗ) на разработку сайта могут стать ГОСТы, кто бы что ни говорил. Спешу развеять главный миф: ГОСТы — это вовсе не длиннющие пыльные манускрипты, которые невозможно читать из-за устаревшего формального языка. Их сочиняли разумные люди. Что важно — они избегали «воды».
Структуру и содержание ТЗ на сайт можно почерпнуть из двух ГОСТов:
* для информационной системы с богатой функциональностью подойдет ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» (15 страниц),
* для «обычных» сайтов без ярко выраженной автоматизации каких-то процессов есть ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» (3 страницы).
Замечу, что пятнадцатистраничный стандарт интереснее. Я им периодически пользуюсь и вполне доволен.
ГОСТы по сути являются костяком ТЗ. В них описаны основные разделы и подразделы ТЗ и даны небольшие комментарии по их наполнению.
Главная проблема ГОСТов, по-моему, в том, что из-за попытки охватить всё ПО в целом, в них не отражена специфика разработки сайтов. Это потому что в те времена, когда стандарты составлялись, и сайтов-то, наверное, не было.
Еще раз повторюсь: шаблон из ГОСТов получается очень даже хороший. Структура документа продумана и поддается расширению.
Как-то раз мне на глаза попалась статья «Как писать техническое задание?!». Она больше ориентирована на технических писателей, составляющих серьезные документы с тонким подтекстом, да и не про сайты, но любому, кто пишет ТЗ, почитать полезно.
В комментариях ко вчерашнему посту про подходы к написанию ТЗ ARKAN щедро поделился ссылкой на коллекцию ТЗ на разработку сайтов. Я просмотрел несколько штук — они далеки от совершенства.
Но если держать под рукой оба ГОСТа, прочитать вышеуказанную статью и изучить несколько примеров, у вас вполне может получиться дельное ТЗ.
Если у вас есть толковые ссылки по теме, поделитесь, пожалуйста, в комментариях. У меня тоже кое-что припасено, так что в ближайшее время список будет пополняться.
Дмитрий Сергеев, 26 лет, разрабатываю сайты на Drupal, управляю интернет-проектами
Комментарии
Номер один, 12.03.2007 15:38
Ну, набор ссылок с типовыми ТЗ полная лажа. ГОСТЫ давно хотел посмотреть, любопытно.
Дмитрий Сергеев, 12.03.2007 15:45
Поэтому я, пожалуй, соберусь и напишу пример ТЗ получше. Есть идеи предметной области для небольшого сайта?
Ларс, 22.09.2007 22:07
Я создаем веб-радио. Такая предметная область подойдет?
Дмитрий Сергеев, 23.09.2007 01:33
Жаль, что вы не написали это полгода назад: я тогда интересовался ТЗ, и попробовал бы написать про радио. Сейчас я к этой теме охладел. Но спасибо за идею, может как-нибудь :)
ARKAN, 12.03.2007 22:08
Думаю не стоит быть настолько критичным. Если человек имеет довольно смутное представление о ТЗ как таковом, то готовые примеры с пояснением будут очень кстати. И подобные вещи для того и делают, чтобы человек понял что и для чего.
А вот если его сразу грузонуть 15-ти страничным гостом, так он тебя пошлет куда подальше.
Так, что ко всему нужно подходить с умом и не кидатся в крайности.
Дмитрий Сергеев, 12.03.2007 22:46
Существует некоторый дефицит на материалы о написании технических заданий. Глупо не учитывать опыт других людей.
Евгений, 12.03.2007 16:34
За ГОСТы спасибо!
netklon, 12.03.2007 19:39
ГОСТы - это полное убожество. Написать понятное ТЗ по ним невозможно. В Александра Шиляева была неплохая статья про написание современного ТЗ на разработку сайта. Если кратко, то оно состоит следующих компонентов:
1. Цели разработки сайта
2. Аудитория
3. Конкуррентный анализ
4. Карта сайта
5. Прототипы страниц
6. Описание интеракций
7. Функциональные требования
8. План приемочного тестирования
9. Требования к обслуживающему персоналу
10. Требования к программному и аппаратному обеспечению
Дмитрий Сергеев, 12.03.2007 21:10
Большая часть из перечисленного упоминается и в ГОСТах, как это ни странно :) А если учесть, что они писались в те времена, когда такого интернета еще не было, то составителей этих текстов можно назвать удачливыми провидцами.
Кстати, я не уверен, что в рамках ТЗ разрабатываются прототипы страниц. Насколько я понимаю, ТЗ -- это лишь задание на разработку сайта. Написать ТЗ -- не значит спроектировать сайт. Хотя связь очевидно присутствует :)
То же самое относится и к карте сайта. Как можно рисовать эту карту, если на момент написания ТЗ нет представления об информационной архитектуре.
Что обязательно должно быть в ТЗ, так это требования. Самые разные, начиная от требований к языкам программирования и кончая организационным обеспечением. Этому в ГОСТах уделяется первостепенное внимание.
Я ни в коем случае не призываю писать ТЗ на сайты только на основе старинных ГОСТов, отбрасывая всякие новшества. Но всё-таки это хорошее подспорье.
Я видел как-то ссылку на упомянутую статью Александра Шиляева, но она была битая. Попробую поискать получше и добавить в список, если рекомендуете.
netklon, 14.03.2007 17:42
Карта сайта и информационная архитектура - это такие же требования, как и функциональные.
Я как-то сравнивал советские ГОСТы с западными шаблонами Software Requirements Specification. Западные во-первых, сильнее повернуты в сторону визуализации (те же Use Case диаграммы), а во-вторых более ориентированы на быстрый обзор системы, а уже потом более глубокий анализ.
Советские и российские ГОСТы мне кажутся больше бумагомаранием и попыткой защититься от заказчиков с ежечасно меняющимися требованиями.
ARKAN, 14.03.2007 18:07
Это еще не плохо когда заказчик меняет хотелки каждый месяц.
Хуже когда каждую неделю. Причем хотелки порой расходятся по разным напрвлениям :-)
Так, что бумаго-марательство иногда помогает себя защитить.
Дмитрий Сергеев, 14.03.2007 19:00
Мне кажется это больше теория. Я когда учился на первых курсах, удивлялся, почему преподаватели меняют требования к заданиям в процессе сдачи на противоположные. Приносишь им диаграмму, показываешь, они тебе говорят, добавь «бочоночки». Приносишь с «бочоночками», злятся и требуют, чтобы ты их убрал.
У меня тогда были мысли записывать все их высказывания на бумагу и заставлять подписываться. А потом я понял, что с первого раза никто никогда ничего не принимает. Не солидно. Отсюда и капризы.
Это не совсем относится к делу, так, вспомнилось.
Я к тому, что если хочешь, чтобы бумажка тебя защитила -- нанимай юриста или профессионального техписа, который учтет миллион тонкостей.
Дмитрий Сергеев, 14.03.2007 18:51
Мне кажется, я понял в чем дело: многие разработчики стремятся сделать техническое задание единственным проектным документом по сайту и включают в него всё, что только можно.
А в ГОСТах другой подход: в них ТЗ -- одно звено из огромной вереницы бумаг. Есть даже специальный стандарт «Виды, комплектность и обозначение документов при создании автоматизированных систем» (ГОСТ 34.201-89). То есть разные схемы и описания, не относящиеся непосредственно к заданию, выносятся в отдельные документы.
В этом есть смысл, поскольку проектирование иногда занимает несколько недель и порождает множество новых материалов. Но по идее оно должно делаться уже по ТЗ. Если всё включать в ТЗ, то его нужно писать после хотя бы эскизного проектирования.
Дмитрий Сергеев, 12.03.2007 21:18
Кстати, может автор статьи всё таки Юрий Шиляев? Хотя даже так не находится что-то :(
netklon, 14.03.2007 17:35
Возможно и Юрий. Статья погибла вместе с блогом во время падения хостинга.
Alex Shilyaev, 16.03.2007 15:27
Статью про ТЗ на сайты когда-то писал Юра. Я точно не писал. Можете попробовать у него спросить, даже если она и погибла с хостингом, где-то в виде дока она у него должна быть.
Дмитрий Сергеев, 16.03.2007 15:32
Попробую спросить, спасибо.
a.sysoev, 05.09.2007 21:06
Он мне ее когда-то в вордовском файле высылал.
Вот она на его блоге:
http://yuri.shilyaev.com/archives/2007/03/21/356/chto-takoe-%c2%abhorosh...
Адрес дурацкий, потому что Юра поленился блог настроить так, чтобы он кавычки в url не совал.
Дмитрий Сергеев, 05.09.2007 23:00
Cпасибо, эта статья уже включена в более поздний опус.
Roman, 13.03.2007 17:05
Согласен, если без карты и прототипов то это уже бриф, а не ТЗ.
Дмитрий Сергеев, 13.03.2007 17:09
То есть "не согласен"? :)
Untosh, 11.04.2007 10:55
Всё-таки не совсем понятно о каком ТЗ ведётся речь.
Если ТЗ составляется для внутреннего использования (постановка задач программисту, верстальщику, контент-менеджеру и т.д.) - это одно. В нём естесственно многие вещи будут абсолютно лишними.
А если ТЗ составляется для утверждения заказчиком, тут уж, извините, просто необходимы подробнейшие объяснения всего-всего-всего наиболее простым языком и непременно с иллюстрациями (где возможно) , с подробнейшим описанием всех этапов разработки и прямым указанием на то, что любой прямо не описанный в ТЗ функционал выполнен не будет.
Естесственно, заказчики как правило очень далеки от технических терминов. И, думаю, ТЗ по ГОСТу для них будет непонятной бумажкой и не более.
Прежде всего - они люди бизнеса, и в своей практике при составлении "внешнего" ТЗ я лично опираюсь в большей степени на права и обязанности сторон (Исполнитель-заказчик). Соответственно и выглядит оно более как юридический документ, скажем некий договор подряда, только с очень и очень подробным описанием предстоящих работ.
В этом плане статья Юрия Шиляева - действительно будет гораздо более полезна. Хотя и в ней по многим пунктам можно поспорить. :)
Дмитрий Сергеев, 11.04.2007 11:06
Для внутреннего пользования, по-моему, лучше ограничиться техническими и функциональными спецификациями.
Если разработчик планирует к моменту сдачи «внешнего» ТЗ уже разделаться с проектированием, в этом случае оно может быть очень подробным.
Но вообще-то ТЗ задумывалось не как всеобъемлющий проектный документ, а именно как задание на проектирование или разработку. Его составитель не должен проводить масштабные инженерные работы ;)
Изначальная сильная детализация -- не очень хорошая идея, поскольку в процессе разработки конструкторские решения несомненно будут изменяться и придется переписывать ТЗ и перезаключать договор. Иначе получится ловушка для обеих сторон.
Untosh, 11.04.2007 11:44
Я говорю не о масштабных инженерных работах. Не должно ни заказчика, ни руководителя разработки конкретного веб-проекта волновать какими именно операторами PHP программист решит ту или иную задачу. Это несомненно.
Возможно мы просто говорим о разных уровнях разработки.
Представьте себе крупную компанию у которой ежемесячно появляется несколько десятков заказов на довольно серьёзные веб-сайты с неплохим функционалом. И представьте себе заказчика, скажем пожилого отставного полковника внутренних войск, решившего заняться собственным бизнесом. Вы - связующее звено между ним и Вашей компанией. Ваша задача - выполнить определённый (на этапе проектирования и составления ТЗ) объём работ, исходя из определённого бюджета.
Я твёрдо уверен, что гораздо легче потратить несколько часов на составление подробного Тех.Задания перед стартом работ, чем потратить многие недели и месяцы рабочего времени (и своего и тех. отдела и руководства) на бесконечные разъяснения, увиливания, споры, компромиссы и т.д. и т.п. Не говоря уже о том, что такой проект становится просто убыточным для компании.
Опишите как (и не иначе) будет выглядеть и работать на сайте форма отправки письма на почтовый ящик. В этом нет ничего сложного, однако этим вы оградите себя от десятков вопросов и требований наподобие:
"А почему я к письму не могу файл прикрепить?... В ТЗ не было написано, что не смогу, а в любой почтовой программе - можно! Так делайте!"
Это наиболее безобидный пример из практики. :)
Поверьте, чем серьёзнее функционал, тем подобных вопросов больше. Так почему бы на этапе составления ТЗ не написать в нём - "простая форма отправки ТЕКСТОВОГО сообщения, не предусматривающего вложений файлов".
Заказчика это заинтересует, или нет. В первом случае он спросит - "Хорошо, а сколько будет стоить сделать с прикреплением файлов?.."
Надеюсь, мысль ясна. :) Экономьте время и деньги Вашей компании и ограждайте себя от больного воображения заказчика заранее, до начала работ, а не в момент сдачи сайта.
Составить грамотное и подробное ТЗ не так уж сложно. И никогда не лишне. Это Вы сильны в технологиях, а не они. И Ваша задача - заработать деньги, а не исполнять прихоти безвоздмездно.
Дмитрий Сергеев, 11.04.2007 11:57
Я согласен, да :) Глупо говорить об уровнях детализации без примеров. ТЗ должно быть не слишком водянистым, но и не слишком подробным. А баланс каждый ищет для себя сам.
Untosh, 11.04.2007 12:07
Верно. Недостаток детализации вполне нормально регулируется (с юридической точки зрения) отдельным пунктом "внешнего" ТЗ - "Обязательства сторон". Примерно такого содержания:
"
Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ, либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это явно не указано в настоящем Техническом Задании.
Все неоднозначности, выявленные в настоящем Техническом Задании после его подписания, трактуются в пользу Исполнителя. В рамках текущего Договора Заказчик не вправе требовать от Исполнителя переделки разработанного продукта, равно как и любых его модулей и подсистем, мотивируя это требование неоднозначностью прочтения Технического Задания. "
Копирайт не знаю чей, взял на вооружение давно. :)
P.S. Со всеми высказываниями по поводу внутреннего ТЗ абсолютно согласен.
Дмитрий Сергеев, 11.04.2007 12:18
Если вдруг случайно не читали Джоэля Спольски про функциональные спецификации, посмотрите. Вполне интересно. Это к вопросу о внутреннем ТЗ.
Ссылку я нашел у Ивана Сагалаева.
Братислав Андреевич, 28.05.2007 18:52
Untosh,
Вы не забывайте кто платит деньги!
Подобная формулировка отпугнет заказчика - он платит он вправе спрашивать за это. А если все оговоренно это и понятно, что допы это допы. Так что повторятся ни к чему. Очень плохо что программисты до сих пор не придумали "единого" документа на ТЗ сайта.
Валдер, 10.09.2007 17:49
Весь тред не осилил, поэтому извините если повторюсь.
ГОСТ, в данном случае — абсолютная чушь, на мой взгляд. Он только с толку сбивает. Другое дело — ГОСТ на оформление деловой документации.
Что касается эталона ТЗ, то его нет и быть не может, ведь все индивидуально. Я лично за основу ТЗ взял вариант Алексея Молова (с lessio.ru).
А вообще, все эти ГОСТ'ы и другие документы советских времен настолько мудрёные, что аж жутко становится.
Дмитрий Сергеев, 11.09.2007 17:50
Брать ГОСТ за основу, или нет -- дело каждого. Иногда ТЗ лучше писать по ГОСТу, иногда -- нет. Кто-то вообще ТЗ не пишет, а разрабатывает функциональные спецификации. Здорово, когда ты можешь, ориентируясь по ситуации, комбинировать сильные стороны разных подходов.
gfljyjr, 28.09.2007 15:17
Дураку и .* стекло, он и руки порежет и .* сломает.
ТЗ должно быть в первую очередь написано толковым специалистом, для специалистов которые ему будут следовать. Тогда ГОСТ'ы действительно кладезь, иначе имеем поделку на коленке которую постоянно переделывают дописывают. Называется это якобы поддержка, хотя поддержка это совсем другое. Ни одного инструмента даже для себя не создаем, потому что если что можно быстро написать. Пишем на коленке, ТЗ написано инопланетянами, ну и имеем соответственно...
Дмитрий Сергеев, 30.09.2007 12:59
«Идеальное» ТЗ стоит очень дорого, а кроме того пишется сложно. Вполне нормальная практика — итерационная доработка ТЗ, то есть постоянное уточнение требований. Это, кстати, не всегда ведет к усложнению проекта.
Катенок, 22.10.2007 21:26
Товарищи, пришлите, пожалуйста, ссылки на примеры. В универе задали написать тз, а с чего начать даже не знаю!
Дмитрий Сергеев, 23.10.2007 14:02
Ссылки на примеры ТЗ.
Гость, 17.04.2008 23:41
http://www.mixsystems.com.ua/Content/For-clients/tz_examples/