Подходы к написанию технического задания на разработку сайта

11.03.2007

Рассказы о том, что никто не знает, как правильно писать техническое задание на разработку сайта, немного преувеличены. Есть ГОСТы, есть профессиональные технические писатели, есть требования, которые вполне можно выразить в письменном виде. Обычно нет времени и желания писать нудную бумажку.

Я могу себе представить три подхода к написанию технического задания.

1. Компании нужен сайт. Исполнитель еще не выбран, а требования уже сформулированы. Компания обращается в профессиональную организацию, специалисты которой занимаются написанием технической документации. Документ пишется пару месяцев, работа стоит от $ 3000.

Это утопия. Наверное, подобными вещами занимаются крупные организации. На практике я с такими случаями не сталкивался.

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

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

Пожалуй, такой сценарий — самый популярный. Иногда похожее техническое задание пишут сами разработчики и отдают заказчикам сайта. Вроде как документ есть. Можно и поругаться, если что.

Этот вариант плох тем, что разработчики обманывают сами себя, растрачивая время на бессмысленную писанину. Заказчикам тоже плохо — за составление технического задания они платят отдельно.

Думаю, что описанный подход, лучше, чем ничего. Если убрать из процесса идиотизм, получится третий вариант.

3. Заказчик и исполнитель пишут техническое задание вместе, незаметно проектируя будущий сайт. Люди учатся. Они читают ГОСТы, форумы, примеры реальных технических заданий на похожее ПО. На написание документа отводится хотя бы две-три недели. Работа нормально оплачивается.

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

Такой подход на практике я видел раза три. Остальное — за вторым вариантом.

Добавить комментарий

Комментарии

ARKAN, 11.03.2007 23:41

Где-то у меня лежала ссылка на ресурс в котором собрано огромное кол-во образцов ТЗ по различным направлениям деятельности.

В частности и сайто-строительства.
...
Блин пока писал нашел ссылку
http://www.antula.ru/tz-examples_1.htm
огромный кладезь

Ответить

Дмитрий Сергеев, 12.03.2007 00:53

Отлично, спасибо. Думаю сделать пост со ссылками в помощь пишущему ТЗ. А потом может и сам попробую «хороший» пример изобразить.

Спасибо еще раз :)

Ответить

Лёха Скрипник, 12.03.2007 07:53

Да, это было бы здорово

Ответить

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

Ссылки уже начал собирать.

Ответить

Клюев Денис, 12.03.2007 08:18

Отлично, Дмитрий!
Это как раз то, чем я в последнее время активно занимаюсь. Ещё та проблема.

Ответить

Дмитрий Сергеев, 12.03.2007 12:13

Ссылки уже начал собирать.

Ответить

Майевтик, 15.03.2007 22:54

Эх, увидев слово "подходы" я было подумал, что это они и есть - различные методики выявления требований и оформления их в ТЗ.

Ан нет, статья про то, КТО может писать ТЗ. Я тоже на эту тему думал: http://beskov.ru/2007/03/15/req_specifier/

Ответить

Дмитрий Сергеев, 15.03.2007 23:09

Понял, о чем речь. Здесь слово "подход" связано с "отношением".

Имелось ввиду, что можно подходить к делу серьезно, спустя рукава или с разумной долей стараний.

Ответить

Майевтик, 16.03.2007 08:05

По поводу 1-го варианта:
"1. Компании нужен сайт. Исполнитель еще не выбран, а требования уже сформулированы."

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

"Компания обращается в профессиональную организацию, специалисты которой занимаются написанием технической документации. Документ пишется пару месяцев, работа стоит от $ 3000."

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

Ты ошибаешься, что подход утопичен:
1) Для госпроектов используется именно такой подход;
2) Для серьёзных коммерческих проектов почти всегда имеет смысл применение такого подхода - аргументы - в статье, на которую я ссылался.
3) Даже в небольших проектах по созданию НЕТИПОВОГО, что важно, сайта, применяется такой подход, скажем, от бюджетов в 2k - и я и ряд моих знакомых работали и работаем по такой схеме (в качестве консультанта-аналитика).

Ответить

Дмитрий Сергеев, 16.03.2007 09:33

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

Наверное, в госзаказах и очень крупных проектах и не такие схемы бывают.

Если попытаться честно хотя бы изобразить подобный процесс в рамках бюджета на 2k, то на сайт денег может не остаться.

В целом согласен. Спасибо за замечания.

Ответить

Майевтик, 16.03.2007 10:04

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

Ну ты будешь мне верить или нет? :) Я не пытался "изображать" подобный процесс, я участвовал и участвую в нём. При бюджете в 2k хорошее ТЗ с макетами интерфейса может стоить порядка 400у.е., например.

Ответить

Дмитрий Сергеев, 16.03.2007 10:18

Ох уж эти конкурсы. Я пару дней назад как раз писал заявку. В рамках этой заявки под ТЗ понимается список из пяти стадий, распределенных по датам. Что тут делать... Это полстранички. Ох, и дурная схема. Как я согласен. Мне так больно :)

Про ТЗ за $ 400 верю. Наверное, у тебя дар убеждения и природная харизма «18». Если меня попросят сделать сайт незнакомые люди, и я скажу, что 20% бюджета у меня уйдет только на написание ТЗ, ко мне по меньшей мере отнесутся с подозрением. Завидую. Есть к чему стремиться.

Ответить

Майевтик, 16.03.2007 08:12

"3. Заказчик и исполнитель пишут техническое задание вместе,"
Вот это - утопия, в смысле идеальная ситуация, но обычно у заказчика нет достаточных ресурсов и навыков, чтобы написать ТЗ, т.к. работы разовые.

"незаметно проектируя будущий сайт."
А вот это уже типовая ошибка - совмещать проектирование и требования.

"Люди учатся. Они читают ГОСТы, форумы, примеры реальных технических заданий на похожее ПО. На написание документа отводится хотя бы две-три недели. Работа нормально оплачивается."
Чья работа оплачивается? :) Компания вырывает из производственного процесса линейного менеджера и говорит - "а теперь ты 2 недели будешь писать ТЗ на сайт с Разработчиками, а что твоя основная работа будет стоять - не беда, спишем на издержки" - так, что-ли? :) Представляешь, сколько они будут тыркаться по сайтам и примерам, не понимая, что хорошая структура ТЗ - это ещё не хорошие требования, а как писать хорошие требования мало где написано? :)

Ответить

Дмитрий Сергеев, 16.03.2007 09:46

Возможно, доля участия представителей заказчика немного преувеличена. Две недели по восемь часов в день проводить вместе с линейным менеджером не нужно.

Речь о том, что у «формулировщика требований» при написании ТЗ всегда должна быть возможность оперативно обсудить какие-то вопросы с представителями заказчика.

Именно «представителями», во множественном числе. Это не означает коллективные консультации. Просто должен быть доступ к нескольким фигурам, которым придется учитывать сайт в своей работе. И хорошо бы они могли два-три раза в неделю поотвечать на вопросы.

А чтобы объяснить им то, чего от них хотят, иногда придется этих людей поучить.

Опять же под «незаметным проектированием» понимается процесс детализации требований, а, как следствие, и вариантов реализации. Это будет происходить невольно. Грубо говоря, хочешь или не хочешь, в процессе написания ТЗ придется много думать. А мыслительный процесс как-то очень сильно связан с проектированием.

Всего должно быть в меру. Составитель ТЗ не должен оставаться наедине со своими представлениями о сайте. Нельзя и так сказать: «Поговорил с заказчиками час-другой, и иди пиши ТЗ. Через неделю покажешь».

Ответить

Майевтик, 16.03.2007 09:58

Про участие заказчика и возможность оперативного контакта всё верно, но это нет в статье :)

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

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

Ответить

Дмитрий Сергеев, 16.03.2007 10:12

Не всегда то, что у человека в голове, на словах становится понятно окружающим. Надо, конечно, тренироваться :)

"Поучать" -- это очень даже плохо. Речь идет об очень вежливых и терпеливых объяснениях без давления, сильных эмоций и угроз.

С фокусом понятно, но ведь лихую мысль не удержишь. Она несется вскачь, чуть что. Обуздать ее очень тяжело. Мы же не роботы...

Но приоритеты здраво нужно расставлять, это очевидно.

Ответить

RuGost, 21.08.2007 10:42

Добрый день.
Я также занимаюсь проблемой написания документации, и начал проект www.rugost.com
В нем рассматриваются именно практические примеры написания как формальных разделов документов, так и смысловых.
В данный момент описано около одной трети всех возможных документов ТП и РД.
Было бы интересно узнать Ваше мнение.

Ответить

Дмитрий Сергеев, 23.08.2007 13:45

На первый взгляд есть интересные материалы. Почитаю, спасибо.

Ответить

Отправить новый комментарий

Содержимое этого поля хранится скрыто и не будет показываться публично.
Для вопроса «сколько будет 1+1» ответом является «2».