Комментарии 64
Уважаемый автор, хотелось бы вот такое дополнение увидеть.

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

По каким критериям можно выделить заказчиков, чтобы определиться, предлагать им ТЗ или нет?

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

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

P.S. ТЗ правильная вещь, правильно "вопспитывать" и тренировать заказчика. Но все-таки, не всегда применимая...
ТЗ правильная и всегда применимая вещь - надо только воспитывать - вот именно так должна звучать фраза :)

Предлагать ТЗ нужно всегда - этот вопрос даже не обсуждается... даже если мегапортал стоит 1 рубль. Если заказчик не знает сколько стоит данная работа - то ТЗ даст ему четкую картину всех временных и денежных расходов - хотя бы в первом приближении.

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

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

Также зависит от задач, которые стоят перед заказчиком (ведь это не всегда Бизнес заказчик, где ТЗ можно привязать к его бизнес целям для понимания например)...

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

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

в конце концов ТЗ это не аналог бренд-бука... (хотя некоторое сходство есть)...
>Станислав считает этот вариант самым приемлимым, особенно для начинающих заказчиков

Я забыл добавить, что как правило даю таким заказчикам пример ТЗ, плана которого я хотел бы получить и только тогда я этот вариант считаю более приемлимым. Сейчас поправлю в статье.
На практике мы поступаем примерно также, только начинаем с мини опросника, которым пытаемся "идентифицировать/классифицировать" заказчика. Готовимся к первой встрече, если есть "контакт" и минимальный уровень адекватности, под конец предлагаем сделать ТЗ (дабы не испугать), рассказав о всех плюсах и показав простой пример. Для большинства, делаем ТЗ сами...тратим на это ресурсы (время) и частенько, деньги за это получить не удается.

Но как правило, такие усилия дают реальные плюсы ходу проекта.
Если я не ошибаюсь вы уже выкладывали его..и кажется здесь на Хабре - там вопросов около 40-а.. или это Новиков постарался... или Овчинников... что-то немогу найти
оно!!! :))) нашёл у себя в закладках :)))
всем читать и учиться - я даже не нашёл что добавить
Пожалуй еще разок напишу
Ссылка на хороший пример ТЗ
http://mdesign.ru/services/docs
- Технический писатель отношения к ТЗ не имеет.
- ТЗ пишет аналитик.
- Заказчик никогда не напишет ТЗ если только он не является профессиональным разработчиком систем. Но, заказчик способен написать список своих пожеланий. Осмыслить его и сделать технически грамотный текст (требования и ТЗ) - дело аналитика.

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

заказчик вполне напишет ТЗ если:
- у него не первый успешный проект
- у него в штате есть тех писатель/постановщик задачи/системный аналитик (если Вам угодно)
- он просто грамотный человек (я например напишу ТЗ безх проблем - хотя до сих пор сам заказчиком никогда не был)
В учебниках написано. Постановщик задач, в большинстве случаев есть русский синоним западного термина системный аналитик.
а можно ссылки на учебники - не принципа ради - а исключительно ради самообразования
мне действительно интересно - насколько на западе формализовано понятие ТЗ - кстати никто не в курсе - какой термин у них применяется?
С ходу не скажу. Системный анализ это моя профессия и образование. Книг было прочитано много и разных. Понятие ТЗ на западе сформировано достаточно хорошо. В любой книге по UML, RUP(Rational Unified Process) вы увидите все эти этапы. Названия есть разные в зависимости от используемой методологии. Business requirements, Functional Requirements, Use Cases...
Привет, меня зовут Анатолий, я технический писатель и пишу ТЗ :)

Имхо, "докрайтер" этим не занимается, а "технический писатель" уже фактически устоявшееся название для тех, кто разрабатывает ТЗ. Если посмотреть вакансии, то практически везде это входит в должностные обязанности технического писателя. Будем с этим бороться? Мне лично нравится название "технический писатель" =).
Технический писатель это человек, который что-то документирует. Аналитик - это человек который продумывает. Если он патологически не способен писать - ему в помощь нужен технический писатель. Только я не уверен, что человек не умеющий чётко формулировать мысли способен быть системным аналитиком.

У себя в компании вы можете грушу называть апельсином. Это скорее будут проблемы компании, а не апельсина.
Я клоню к тому, что это не в одной моей компании, а в большинстве русских компаний.
А я клоню к тому, что так называют это в тех компаниях, где ТЗ пишется для галочки/бумажки. А фактически, затем разработчики сами пишут его в своей голове как могут. В таких случаях и происходит ситуация вида - Эй, Толя, ты у нас графоман и способен внятно складывать слова, у нас тут положен документ какой-то под названием ТЗ. Намалякай-ка нам что-то умное листиков на 10, а мы приложим к проекту.

Для небольших проектов, ТЗ часто пишет архитектор системы или ведущий разработчик. Это действительно приемлимо. Ибо они владеют технологиями и знают что можно, как можно, и что нельзя.
Согласен, бывает и такое :). Только правильный тех.писатель, это человек, который сам был и разработчиком и архитектором. Только кроме знания технологий разработки, у него еще есть навыки понять заказчика, а главное кратко и ёмко это отразить в документации. Он не настолько оторван от действительности, как программисты :). Образование его должно быть широким, а опыт огромным, тогда как раз и получается правильное ТЗ, по которому можно сделать замечательную программу/сайт.

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

В общем, несмотря на сложившееся у некоторых мнение, что техписатель, это человек, умеющий "внятно складывать слова", я буду отстаивать точку зрения, что техписатель — это мегамонстр, настоящий кентавр, лучший из гуманитариев и лучший из технарей. Просто настоящих техписателей единицы ;).
И этот мегамонстр, в компаниях, правильно владеющих терминологией, называется Бизнес-аналитик. Или системный аналитик (аналист) или постановщик задач.
Технический писатель это совершенно из другой оперы. Хотя человек также должен быть крайне грамотным.
ты опять за своё

название профессии и роли должно отражать наиболее существенную составляющую деятельности человека

иначе можно программиста называть «писателем кода»
Ну ладно, ладно... Буду системным техническим писателем-аналитиком :) Можно просто, сисписатель :)
Между прочим - технический писатель, как никто другой должен понимать, что неправильное использование терминов и названий крайне запутывает текст и делает его непонятным. :-)
Ага, поэтому я и предлагаю использовать термин "техписатель", потому что очень многие к этому привыкли. А что такое аналитик, да еще и системный, да чем он отличается от бизнес-аналитика, большая часть встреченных мною заказчиков просто не представляла :).

Не уверен, конечно, но по-моему, когда компьютеры были ещё большими, те люди, которые создавали проектную документацию всё-таки обзывались техписателями (разработчиками технической документации), а не системными аналитиками. Если это не так, то окончательно соглашусь с противной мне точкой зрения :).
Вы пытаетесь переопределить на удобный вам лад термины которым много лет. Упрощённо говоря вы исходите из того, что раз чел что-то пишет, то он уже и есть технический писатель. Это совершенно не так. Всё зависит от того, что этот человек пишет.

Если это детали устройства проекта, то написание документа, часто есть часть процесса проектирование и человек который его пишет это, к примеру, архитектор продукта.

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

Если же следовать Вашей терминологии, то техническим писателем является любой человек открывший текстовый редактор. Бухгалтер, пишущий пояснение к балансу - техписатель. Аналитик, собирающий и систематизирующий требования пользователя - техписатель. И вот уже все люди, пользующиеся компьютерами, превратились в техписателей, ибо все часто чего-то там пишут в текстовых редакторах. :-)
ТЗ разрабатывает проектировщик. Технический писатель занимается написанием документации.
Если ТЗ пишет заказчик, это все равно что если бы покупатель придумывал бы внешний вид автомобиля;)
Вы делаете типичную ошибку. Заказ - это не покупка ГОТОВОГО автомобиля.

Но это только одна проблема.

Вторая - пусть пишет заказчик, всегда все можно обсудить и выкинуть то, что написано глупо с точки зрения разработчика (конечно это прийдется доступно и популярно объяснить, но это совсем другая проблема).
Нет никакой ошибки. У NikitaOFF всё написано правильно. Заказчик не способен написать ТЗ на уровне достаточном для проектирования. Он способен лишь пожелать что бы авто разгонялся как Порше соседа слева, имел багажник как Пассат соседа справа и цвет как волосы жены друга. Переварить всю эту кашу до уровня стартовой точки работы архитектора уже есть дело профессионала.
Еще раз: покупка готовой машины не равноценно заказу, который выполняется индивидуально.

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

Большинство заказчиков МОЖЕТ на достаточно понятном уровне пояснить, что им нужно от исполнителя и что они хотят получить на выходе. Неадекватов в расчет не берем.
Верно. Может. Но называется это всё списком пожеланий заказчика, а не ТЗ разработчику. На готовую машину вообще ТЗ не пишется. Там обходятся перечислением желательных опций из списка возможных для данной модели. ТЗ это документ другого уровня, который учитывает вещи о наличии которых заказчик вообще может понятия не иметь.
Предлагаю это с точки зрения исполнителя называть не ТЗ, а wishlist (ну чтобы у вас не возникало иллюзий, что заказчики пишут полноценные ТЗ для разработчика), на основании которого исполнитель делает заказ, утрясая изначально все с заказчиком по поводу конечного результата.
ну это вы загнули...
если уж так все любят автомобили - то тут уместнее представить выбор комплектации автомобиля - заказчик (покупатель) даёт техническое задание - хоту черный, двухдверный, бензиновый и т.д. - а вот задача разработчика (продавца) - указать заказчику что допустим на мусоре у нас пока автомобилей нет... но!!! если у вас есть много-много денег - это можно организовать... через определённый промежуток времени :)))
...хоту черный, двухдверный, бензиновый...
------------------------------------------
Это не ТЗ, это список пожеланий. ТЗ разработчику (конструктору авто, технологу...) выглядит абсолютно иначе. Цвет в чистом виде там скорее всего не фигурирует. :-)
Мне кажеться вы тогда путает ТЗ и опросный лист клиента, одно дело если он напишет что он хочет видеть, а другое дело когда он пишет что и как надо делать, по моим соображениям в ТЗ как раз пишется то, как должно все работать и выглядеть, а не просто то что хочет видеть Заказчик=)
ну если пошла такая пьянка.... в данной ситуации - кого вы виде в качестве заказчика - человека, который хочет сделать автомобиль с нуля.. или покупателя, который ориентируется на возможности рынка автомобилей?
если разговор об автомобиле с нуля - да.. нужен грамотный инженер (и зачастую не один.. и даже не сто) чтобы написать как всё должно работать, из чего это сделать, какие технологии литья, сварки и т.д. применять...

если разговор о покупателе - то в данном случае ТЗ на ПОКУПКУ автомобиля выглядит именно так как я написал - и помочь составить адекватное ТЗ может любой грамотный менеджер автосалона (возможно потребуются рекомендации хорошего автомеханика) - не более.... и если человек покупает автомобиль не в первый раз (а в сотый например) - он сможет обойтись без менеджера и автомеханика очень даже легко...

так вот - к чему это я - создание сайтов - это скорее аналог покупки автомобиля - потому что набор технологий и возможностей вообщем-то ограничен (как и комплектующих)... вот если вы создаёте новый алгоритм кодирования видеосигнала - то скорее это первый вариант.
Создание сайта - это создание сайта. И ТЗ для этого ближе к ТЗ создания автомобиля. А покупка сайта, это покупка сайта. Если бы речь шла о ТЗ на покупку сайта, то оно действительно могло бы быть сформулировано просто - типа купите мне сайт посвященный такой-то тематикой, который поддерживает известная студия и что бы он имел столько-то уников в день.
Мне кажеться это как раз выглядит как разработка нового авто
Мы же создаем сайт с нуля, а не берем готовый макет, в котором заказчик выбирает только Цвет текста;)
Даже если смотреть с точки зрения набора технологий, мы же пишем новый код, создаем, новые картинки, автомобили же то же делаются из одного материала, с примерно одинаковой технологией двигателя и т.д.
ТЗ - это то, чем должен руководствоваться разработчик при выполнении работ, это некий самоконтроль, исключающий ненужный полет фантазии.
ТЗ - это то, что даст ясную картину заказчику о том, что он получит в итоге и какую сумму на каком этапе он потратит.

Веб-термины необходимо расшифровывать, расшифровки всегда можно вынести в приложение.

ТЗ должно быть написано разработчиком, читано и правлено заказчиком и так несколько итераций.
ТЗ должно быть всегда и должно быть согласовано и подписано обеими сторонами. (В конце концов, это не позволит ебать мозг друг другу по поводу перевыполнения или недовыполнения.)
"ТЗ должно быть написано разработчиком, читано и правлено заказчиком и так несколько итераций." - ну собственно этой мыслью и должна была быть пропитана данная статья :) - у меня не получилось?
По-моему, более правильная мысль, что этим должны заниматься: разработчик ← техписатель → заказчик.
Статья пронизана тем, что нужно выбрать универсальный вариант на все случаи жизни. Более-менее подходящий и самый употребляемый, на мой взгляд, я привел. Привлечение техписателя или написание ТЗ кому-то одному из пары "заказчик - исполнитель" - это частные случаи. Если не оглядываться на внешний мир, то в нашей стране клиент всегда прав, но тупой и с удовольствием трахает мозг, поэтому согласовывать с ним ТЗ просто необходимо, а доверять писать ему его самому нельзя. При всем этом довольно часто за разработку и написание ТЗ исполнитель проекта берет деньги, здесь вообще парадокс получается - вроде и подход неправильный, но вроде бы и время, и силы потрачены.
И самое главное, о чем все чаще всего забывают - ТЗ чаще всего устаревает быстрее, чем бывает до конца согласовано и дописано. Особенно в маленьких проектах. Впрочем, смотря что называть ТЗ. Просто есть любители расписывать все подробности в документе, вместо того, чтобы при тех же временных и ресурсных затратах сделать реальный прототип. Читавшие Getting Real и понявшие о чем там речь, знают, что лучше создавать сам продукт, чем что-то, что описывает продукт (бумажки, ТЗшки, другая писанина). Прототипы, интерфейсы - вот что реально применимо, как на этапе создания (если речь идет о сайтах или системах), так и для конечного результата.

Есть, конечно, и подводные камни - нужно особо договариваться с заказчиками о таком адаптивном способе работы, когда конечный результат не ясен до мелочей, пока до этих мелочей, собственно, не дошли.
ну это уже отдельная тема для разговора.. в статье Станислава и моём дополнении речь идёт всё-таки о том кто именно должен это самое ТЗ писать... и почему...
Ну вполне возможно. К тому же есть проекты, которые без ТЗ никак не сделать.
Тогда речь поднимается о детальности проработки ТЗ.
Прототип - это трюк, выполняемый для того, что бы получить максимально точное ТЗ. Большинство обычных людей, не способно точно сформулировать свои пожеляния, не увидив как окна проекта выглядят воочию. Не все обладают достаточным уровнем абстрактного мышления и зрительной фантазии. И во многих случаях уместнее сделать прототип, как визуальный прообраз будущего проекта. Дабы получить более точный срез пожеланий заказчика. Никакого отношения к согласованию и устареванию это не имеет. Но красивый и грамотный прототип часто вселяет уверенность в заказчика, что исполнитель есть толковый и способен выполнить проект.
Есть такая замечательная книга - "Мифический человеко месяц".
Если я не ошибаюсь, то именно в ней, наряду с прочим, объясняется, почему роли "постановщик", "тестировщик" и "разработчик" ни в коем случае нельзя совмещать в одном лице. Поэтому вариант 2 ИМХО надо выбросить.
а кто говорит про одно лицо?...опять же.. не смешиваем все темы в одну...
разбираем ситуацию - "кто составляет ТЗ?". Я считаю что заказчик-новичёк не должен обращаться к третьему лицу для написания ТЗ... ибо это потеря времени-денег-нервов при общении с конечным разработчиком.
:)
Я не смешиваю темы.
Просто в предложенной ситуаци "кто составляет ТЗ?" п.2 некорректен с т.з. обеспечения качества.
Госты определяют все, не вводите других в заблуждение:
Для примера: http://www.nist.ru/hr/doc/gost/34-602-89.htm
ещё раз... ГОСт определяет перечень необходимой информации для составления ТЗ.. но кто может гарантировать что пункт Описание - написан профессионально... критериец оценки профессиональности нет... я говорил именно об этом. Как заказчик может определить качество (не полноту - а качество!) написанного ТЗ? Ведь ему могут сказать в фирме-разработчике что ТЗ конечно есть.. и пункты вроде все по госту присутствуют - но написан полный бред.

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

Тоже составлял всегда ТЗ, но народ всегда спрашивает:„Эта чё?“, и тут начинаются свистопляски-объяснялки, в итоге люди их даже не читают, просто подписывают — что хочешь там, то и пиши. Люди хотят результат быстрее и, как кто-то заметил выше, макет — лучшая вещь в данном случае.
В итоге однажды за написанием очередного такого ТЗ понял что пишу я их для себя, а они мне нафиг не нужны. Я понимаю в большой студии, где сайт проходит через десятки рук, ТЗ необходим чтобы не терять цель из виду, а в маленькой студии в несколько человек он не нужен ИМХО.

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

А «прозрачный фон на закруглённых углах» тоже важная вещь, казалось бы — мелочь, а меняет восприятие кардинально (дизайнеры меня поймут =)
Нет - не перегибаю... ТЗ и впрям наше всё.. особенно если вы разработчик.
ТЗ позволяет избежать многих ненужных разговоров на этапе сдачи проекта - потому-что каждая из сторон четко представляет что и как надо было сделать - и что и как сделано.

ТЗ должно быть подписано сторонами и приложена к основному договору
Абсолютно согласен.
Должна быть конечная цель работы - это суть и есть ТЗ.
Иначе будет вечный кайф с бесконечными доработками :)
Думаю тут надо оценивать что за заказчик и какое впечатление производит. Чаще всего люди попадаются нормальные и внести небольшие изменения мы не отказываемся, только просят этого редко. Опять же зависит от нашего же с вами профессионализма: если вы можете обосновать любую точку в конечном продукте, то у заказчика стимулов к изменениям не появляется.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.