Как писать техническое задание (ТЗ) на сайт

Дмитрий Сергеев, 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 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%abhoroshee%c2%bb-tz-na-sayt.html

Адрес дурацкий, потому что Юра поленился блог настроить так, чтобы он кавычки в url не совал.

Дмитрий Сергеев, 05.09.2007 23:00

Cпасибо, эта статья уже включена в более поздний опус.

Roman, 13.03.2007 17:05

Согласен, если без карты и прототипов то это уже бриф, а не ТЗ.

Дмитрий Сергеев, 13.03.2007 17:09

То есть "не согласен"? :)

Дмитрий Сергеев, 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

Если вдруг случайно не читали Джоэля Спольски про функциональные спецификации, посмотрите. Вполне интересно. Это к вопросу о внутреннем ТЗ.

Ссылку я нашел у Ивана Сагалаева.

Дмитрий Сергеев, 11.09.2007 17:50

Брать ГОСТ за основу, или нет -- дело каждого. Иногда ТЗ лучше писать по ГОСТу, иногда -- нет. Кто-то вообще ТЗ не пишет, а разрабатывает функциональные спецификации. Здорово, когда ты можешь, ориентируясь по ситуации, комбинировать сильные стороны разных подходов.

Дмитрий Сергеев, 30.09.2007 12:59

«Идеальное» ТЗ стоит очень дорого, а кроме того пишется сложно. Вполне нормальная практика — итерационная доработка ТЗ, то есть постоянное уточнение требований. Это, кстати, не всегда ведет к усложнению проекта.

Дмитрий Сергеев, 23.10.2007 14:02

Ссылки на примеры ТЗ.