Проектирование сайтов - Подходы к написанию технического задания на разработку сайта / requirements specification approach - Comments

На первый

Дмитрий Сергеев — Thu, 23 Aug 2007 13:45:02 +0400

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

Добрый день. Я

RuGost — Tue, 21 Aug 2007 10:42:28 +0400

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

Ох уж эти

Дмитрий Сергеев — Fri, 16 Mar 2007 10:18:12 +0300

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

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

Не всегда то,

Дмитрий Сергеев — Fri, 16 Mar 2007 10:12:35 +0300

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

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

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

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

В госпроектах,

Майевтик — Fri, 16 Mar 2007 10:04:38 +0300

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

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

Про участие

Майевтик — Fri, 16 Mar 2007 09:58:40 +0300

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

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

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

Возможно, доля

Дмитрий Сергеев — Fri, 16 Mar 2007 09:46:12 +0300

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

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

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

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

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

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

Скажем так, в

Дмитрий Сергеев — Fri, 16 Mar 2007 09:33:12 +0300

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

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

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

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

"3. Заказчик и

Майевтик — Fri, 16 Mar 2007 08:12:36 +0300

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

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

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

По поводу 1-го

Майевтик — Fri, 16 Mar 2007 08:05:32 +0300

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

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

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

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

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

Понял, о чем

Дмитрий Сергеев — Thu, 15 Mar 2007 23:09:43 +0300

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

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

Эх, увидев

Майевтик — Thu, 15 Mar 2007 22:54:55 +0300

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

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

Ссылки уже

Дмитрий Сергеев — Mon, 12 Mar 2007 12:13:08 +0300

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

Ссылки уже

Дмитрий Сергеев — Mon, 12 Mar 2007 12:12:50 +0300

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

Отлично,

Клюев Денис — Mon, 12 Mar 2007 08:18:08 +0300

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

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

Дмитрий Сергеев — Sun, 11 Mar 2007 22:06:13 +0300

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

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