franzolka Сообщение 07/11/2011 08:03 Копия темы
Что такое ТЗ, как сделать его хорошо и как с ним правильно работать Без технического задания веб-проекты не делаются и это правильно.
Но каким оно должно быть ТЗ, кто его должен писать, и как следуя ему, не сделать "вместо слона – лошадь"?

 
I. Первое и самое главное что должен знать любой заказчик: написание ТЗ – это не его задача.

Если программист или менеджер проектов или дизайнер просят потенциального клиента написать ТЗ – значит они еще не научились работать на результат, и значит заказчик может с практически полной уверенностью ожидать что получит лошадь вместо слона.
Может быть исключительная ситуация когда сам заказчик является программистом/менеджером проектов/дизайнером, но тогда эти советы не для него, он и сам все умеет и сможет объяснить.

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

II. Техническое задание должно служить руководством, на протяжении всего времени работы над проектом – поэтому оно должно легко читаться и при необходимости быть гибким к изменениям.

Большинство пишут ТЗ в .doc либо в .pdf, часто даже по всем правилам оформления этого "документа". Это актуально, если вы делаете серьезных гос. проект и не можете не соблюдать эти правила. Но даже в этом случаем не стоит забывать первичное назначение этого документа, и оно заключается не в том, чтобы написанная по всем правилам бумажка прилагалась к договору и в случае чего каждая сторона могла "натыкать носом" в нужный параграф другую, в котором все на столько размыто написано, как в наших законах, что может трактоваться как угодно.

ТЗ должно быть читабельно, структурировано, легко редактироваться и масштабироваться. 

Уже два года я использую в качестве формата для технического задания документы MindMap. Благодаря их структуре в них легко ориентироваться, даже если вы описываете огромный портал, в них легко добавлять описание новых функций и редактировать старые, помечать что уже сделано, что нужно сделать в первую очередь, а что во вторую или третью, какие функции планируется монетизировать, какие идеи появились в процессе работы и сейчас на рассмотрении и многое другое, что невероятно неудобно делать в любом текстовом формате типа .doc или .pdf 

III. Третье и последнее, что нужно знать чтобы в полную мощь использовать техническое задание – это не алгоритм точных и не поддающихся изменениям действий.

ТЗ это руководство, которому нужно следовать. Но в ТЗ можно и нужно добавлять новые идеи, определяя их приоритет, а также изменять уже прописанные функции, если в процессе работы они стали неактуальны (особенно это важно для больших и растянутых во времени проектов). 

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

ТЗ это как пошаговый рецепт – если прочитать его в самом начале и в процессе готовки в него ни разу не заглянуть, можно забыть и перепутать половину ингредиентов, поэтому заглядывать в ТЗ нужно часто, чтобы по настоящему "вкусно готовить" проекты :)

dezain Сообщение 07/11/2011 08:41 Копия темы

franzolka Сообщение 07/11/2011 10:46 Копия темы
Уважаемые Юрий Смирнов и другие коллеги, если у вас есть свое мнение, которое отличается от моего – прошу к обсуждению. 
Если же смысл ваших комментариев – самопиар за счет чужого труда в духе "и я того же мнения" и дальше описание из каких пунктов состоит ваше ТЗ  – пишите об этом в своем личном блоге или в разделе информации своего профиля.

dezain Сообщение 07/11/2011 10:53 Копия темы
Уважаемая, Анжелика Романенко, я лишь поделился своим опытом по данному вопросу. И если в вашем топике не разрешено комментировать, тогда пользуйтесь функцией "Запретить комментирование". Всего вам доброго!

franzolka Сообщение 07/11/2011 11:07 Копия темы
В моих топиках разрешено комментировать и обсуждать, но считается некрасивым вставлять откровенную рекламу собственных услуг. 
Самореклама в чужом личном блоге, без согласия автора и без подтверждения им ваших слов, недостойна и некорректна как по отношению к самому автору так и по отношению к другим пользователям, которые ориентируются на его мнение в выборе исполнителя.
Спасибо что читаете мой блог и вам всего доброго!

dezain Сообщение 07/11/2011 11:13 Копия темы
Извините, реклама каких услуг))) То, что я перечислил основные пункты тех. задания, которые использую в своей работе? Девушка, это не реклама, это называется делиться опытом. Просто ваша тема не расскрыта, потомучто многие не знают как должно выглядеть тех. задание и что в нем должно содержаться. И я уже сожалею что ответил на ваш топик, не думал что встречу такую агрессию с вашей стороны.

franzolka Сообщение 07/11/2011 11:49 Копия темы
Те пункты что вы перечислили есть в любом ТЗ, все о них знают только вот не знают как они должны выглядеть 
- в этом вы абсолютно правы. 
И то, что вы их перечислили с заголовком "Основные разделы моего тех. задания" никоим образом не помогло бы ни мне, не другим заказчикам и исполнителям, приведите пример своего ТЗ, дайте ссылку на него, которая будет доступна для ознакомления, чтобы можно было увидеть вашу работу, а не сухой список тезисов "что на ваш взгляд" должно быть в ТЗ описано.

Ваш комментарий был больше похож именно на рекламу того, что вы тоже пишите ТЗ и готовы предоставить эти услуги, а то как вы его пишите – сплошным текстом в .doc или оформляете другой, более удобной форме, как вы потом работаете с этим ТЗ, что происходит с документом после утверждения заказчиком и т.п. вопросы, которые описаны в моем топике вы проигнорировали. 

Я уже жалею что удалила ваш первый комментарий, он очень хорошо отражает суть, как работает большинство студим и исполнителей – цитирую "Поэтому слушаем клиента, с его слов пишем тех. задание и показываем ему на утверждение."
 
1. "Слушаем клиента" – не общаемся с клиентом, не вникаем в проект, не советуем, а именно "слушаем"
2. "Пишем с его слов тех. задание" – не предлагаем решения, не обсуждаем возможности, а именно "пишем с его слов"
3. "Показываем ему на утверждение" – не приходимся еще раз по всему документу вместе выясняя что упущено, а что возможно лишнее, а "показываем на утверждение". 

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

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

Молодой человек, спасибо что разъяснили мне что называет "делиться опытом" и спасибо что добавили в мою тему несколько своих строк, которые раскрыли ее суть в полной мере, я пожалуй верну эти строки дабы не слыть излишне агрессивной :) 

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

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

Основные разделы моего тех. задания: 

1. Описание – для понимания самого проекта 
2. Для кого и зачем предназначен проект – позволяет понять аудиторию проекта 
3. Конкуренты – ссылки с пояснениями что у них удачно, а что нет 
4. Основные разделы – список разделов и их описания 
5. Техническая реализация – список технологий и требований 
6. Интерфейс – описание, требования и ссылки на хорошие примеры 
7. Технические ресурсы – что потребуется для реализации

dezain Сообщение 07/11/2011 12:03 Копия темы
Анжелика, я не пишу тех. задания на заказ как вы, поэтому данную услугу я не рекламирую. Но каждый проект я начинаю с его описания ввиде тех. задания в свободной форме, затрагивая основные моменты. И да. я в первую очередь слушаю клиента, чтобы он был услышан и понят правильно. В процессе постановки задач все пункты обсуждаются и при этом даются рекоммендации с моей стороны. Спорить с вами у меня нет и не было желания, и продолжать дальше не вижу смысла. А вам желаю немного позитива! Пока!

franzolka Сообщение 07/11/2011 12:17 Копия темы
Спасибо за разъяснение и ваше мнение. 
Странно, конечно, что вы сначала расписываете четко по пунктам из каких частей состоит ваше ТЗ, а потом говорите о "свободной форме и основных моментах", но приятно что есть специалисты, которые пишут тех. задание не за деньги. 
И вам побольше позитива и немного больше свободного времени для общения, потому как высказав свое мнение нужно иметь возможности и силы его описать более детально. Пока, удачи!