На мой взгляд, если рассматривать разработку корпоративного сайта, то среди документации, которую готовит менеджер проекта, должен присутствовать и такой документ, как техническое задание для программиста сайта. Точнее даже не задание, а небольшая техническая записка на 1-2 страницах.
Суть её — переложение Концепции сайта, написанной специально для Заказчика, на тот язык, который более понятен программисту. Программист не будет внимательно читать объёмную Концепцию, ему надо потратить минимум времени на чтение, чтобы понять и реализовать свою задачу.
Я всегда отражаю в технической записке для программиста следующие моменты:
- Структура сайта. Только названия разделов и подразделов, чтобы программист мог создать структуру страниц и папок в системе управления контентом.
- Описание функциональных модулей. Я делаю его в виде таблицы, в которой первый столбик — это номер и название раздела структуры сайта, второй столбик — описание того, что будет находиться в этом разделе. Эта таблица помогает программисту понять, насколько сложный функционал предполагается на сайте и определиться с порядком его реализации.
Например. Модуль «АЗС». Данный модуль имеет несколько полей:
- Номер АЗС — текстовое поле
- Адрес — текстовое поле
- Телефон — текстовое поле
- Фотография — выбрать файл
- Виды топлива: 80, 92, 65, Дт, euroДТ — можно указать несколько
- Услуги: Фасованные масла, Продукты, Запчасти, Туалет, Компрессор, Кофейный аппарат, Автомойка — можно указать несколько
- Пластиковые карты: тут идёт список принимаемых пластиковых карт — можно указать несколько
- Содержание главной страницы. Программист должен знать, что ему следует вывести на главной странице.
Например. Краткая информация о компании (плюс ссылка на страницу «О компании»), новостная лента (две последние новости, плюс ссылка «Все новости», ведущая на архив новостей), список основных разделов каталога (в виде иконки и названия раздела) и т.д.
- Список требуемых «ушек» («ушки» — графические ссылки, ведущие на наиболее важные страницы сайта). Программист создаст специальный модуль, который позволит выводить «ушки» на нужных страницах.
Например. «Задай вопрос» (ведёт на страницу с формой онлайн-консультации), «Наши клиенты» (ведёт на страницу с интерактивной картой России), «Спецпредложение» (ведёт на страницу с описанием активного в данный момент спецпредложения или акции).
- Список счётчиков, обязательных для установки. Нужно так же прописать информацию, которая потребуется в процессе регистрации счётчиков — название проекта, описание, логин и пароль.
- Дальше идёт список сложных моментов, которые программист может не увидеть сразу. Чтобы не увеличивать сроки разработки тем, что программист будет переделывать уже разработанное, лучше сразу отдельно прописать все важные моменты.
Например. На странице «Контакты» при клике на схему проезда открывается отдельное окошко, в котором вместе со схемой проезда выводится адрес офиса и контактные телефоны, а также есть кнопка «Распечатать».
©
nbry.ru
А поделитесь мнением, что по-вашему должен содержать такой документ, как техническое задание для программиста сайта.
Upd Мне, по-прежнему, интересно ваше мнение, но прежде чем писать комментарий, прочтите, пожалуйста, следующее:
Под корпоративным сайтом я имею в виду сайт, который является представительством компании в Интернет. В большинстве случаев это сайт с набором стандартных функциональных модулей, таких как новостная лента, фотогалерея или каталог.
Кроме того, сайт разрабатывается на готовой cms, в которой уже есть функционал, требующий настройки под конкретные задачи.
Upd 2 Между прочим, помимо вот таких вот небольших технических записок для корпоративных сайтов, я писала и полноценные ТЗ для информационных порталов на 60 страниц текста. Так что данная статья написана под один конкретный случай (см. первый upd). Имейте это в виду.
комментарии (116)
в техническом задании для программиста должно быть написано:
Например. Модуль «АЗС». Данный модуль имеет несколько полей:
Номер АЗС — текстовое поле, обязательное/необязательное, максимальная длина значения поля, должна быть проверка на числа, ну и т.д.
Насчёт максимальной длины значения поля и проверки числа — а вы верите, что менеджеры проектов разбираются в таких тонкостях программирования? Менеджер проекта разбирается в этом, только если он сам в прошлом программист. В случае же с корпоративным сайтом менеджеру проекта совсем не обязательно иметь опыт программирования.
Вы — А почему поле необязательно?
Прог. — Так написано не было!
Вы — Это само собой разумеется… А почему в телефоне можно буквы вводить?
Прог. — Не было сказано не слова про проверки.
Вы — А разве не понятно, что в телефоне только одни цифры?
Обратная ситуация. Проект дешёвый и времени мало на его разработку. Проверки не нужны (они занимают время), но прогер реализует их (т.к. не было указано обратное) и срывает все сроки, за что ему не дают времени даже до аптеки за вазелином добежать…
Как Вы думаете, кто виноват в обеих ситуациях? Прогер виноват только в том, что он ВЗЯЛ это «ТЗ»!
Виноват всегда менеджер и не только в перечисленных ситуациях.
Что касается того, что в «телефоне можно буквы вводить». Продумывать такие моменты надо по умолчанию, не важно сколько проект стоит. Но продумывать их должен программист. Если не продумал, то должен поправить после замечания менеджера.
К слову о том же поле для телефонного номера, в разных странах формат ввода номера разный, и даже у нас, легко могут ввести что-то вроде:
+7 (495) 123–4567, доп. 1137
Так что требования к ТЗ, детально, лучше заранее уточнять с заказчиком, а если заказчик не может сформулировать требования, то помочь ему с возможными вариантами, чтобы выбрать оптимальный.
Мне кажется программист всё таки человек а не парсер ТЗ, так что сам собразить сможет.
1. Модуль АЗС
а) теде текстовые поля должны иметь ограничение по кол-ву вводимых символов
б) защита ввода дурацких знаков, если это телефон то нельзя вписать буквы
в) выбор «Виды топлива» лагочками или мульти-списком (select)?
Что на главной странице:
надо приложить макет дизайна.
про «ушки» интересно ))) но ладно.
Список счётчиков? зачем?
а) google analytic не хватит?
б) пусть сайт дольше грузиться и у нас много халявной площади
Весьма не больное ТЗ.
Что касается ошибок и доработок, они, конечно, есть, но их становится гораааздо меньше, когда появляется такой документ.
У меня были сутуации, когда из-за слишком упрощенного ТЗ результат расходился с желанием заказчика.
Простите, если у вас уже готова CMS то какие конкретно действия будет выполнять программист? Этого из ТЗ не видно. Тут может быть как натяжка верстки на систему так и доработка модулей. Или сама верстка(в маленьких конторах я работал тоже, да %) ).
В общем.
Из ТЗ должно быть видно что нужно сделать программисту. По каждому пункту действий должны иметься дополнительная информация. Как то:
Натяжка верстки на систему — макет дизайна, структура разделов, источники контента, функционал каждого раздела(в минимальном виде хотя бы).
Доработка модулей — полное описание функционала модулей(Это вообще очень широкий пункт который отправляет вас к общему ТЗ на software продукт. Там все сложнее).
И так далее… В общем понятно должно быть что делать, и как это должно работать, а не только как это должно работать. Вообще повторюсь это типично…
>структура разделов
пункт номер 1
>источники контента
работа не программиста, а человека, который забивает контент
>функционал каждого раздела
>полное описание функционала модулей
пункт номер 2
и не «в минимальном виде хотя бы», а самым подробным образом
Второе. По поводу функциональных модулей либо вы в исходном топике написали бред либо сами не совсем понимаете разницу между тем как модуль должен выглядеть и тем как он должен себя вести. Буквально… Не описание формы АЗС. А описание того как будут обрабатываться данные этой формы. С какими имеющимися модулями взаимодействовать например. Вы хоть раз реализовывали например в системе работу с базой 1С или с баллинговыми системами(хотя бы 5-ю)?
Я понимаю под функциональным модулем часть cms, автоматизирующую одну задачу — например, создание и вывод новостей. Эти модули есть в cms, но нужно произвести некоторую его настройку. Например, программист должен знать, сколько новостей выводить на первой странице, будет ли по ним поиск, нужна ли фотогалерея на странице одной новости.
Вы понимаете под функциональным модулем что-то другое?
>Вы хоть раз реализовывали например в системе работу с базой 1С или с биллинговыми системами(хотя бы 5-ю)?
С 1С так и не удалось поработать, биллинговые системы были. Но в случае проекта с биллинговыми системами, писалось полноценное техническое задание на 60 страниц.
То что вы понимаете что для проекта с нетривиальным функционалом требуется полноценное ТЗ — замечательно. Это указывает нам что вы хороший менеджер.
Но… Вы знаете мне кажется что этот ваш топик встречен так критично посколько большинство программистов имеют опыт в том что 99 процентов проектов имеют нетривиальный функционал. И даже больше. Тривиальный функционал должен реализовывать контент менеджер а не программист. К несчастью со стороны менеджеров слишком часто возникают ошибки, вида выдачи такой отписки в случае проекта в котором нестандартного функционала полно, или же выдача тривальных задач по набивке контента и настройке CMS программисту. ) Мне лично показалось что вы не очень понимаете для чего надо использовать программистов.
Поясню.
Такое ТЗ — хорошее. Но выдаваться оно должно не программисту. А контент менеджеру. Но программисты в фирме в наличии явно… И они нужны. Соответсвенно два вывода, либо вы выдаете такое ТЗ им в случае не стандартных проектов что ошибка, либо они занимаются не своим делом. что тоже кстати ошибка(Хотя и очень понятная… %) ).
А программист — тот кто умеет настраивать cms плюс, если надо, он её по ходу несколько дорабатывает. Насколько он её сможет доработать уже зависит от опыта программиста. Но это в любом случае программист, не верстальщик и не контент-менеджер.
Типовых проектов достаточно много. Посмотрите сайты региональных компаний. Разве часто в них встречается сложный функционал?..
В случае нестандартных проектов ТЗ естественно будет другим.
И на тему сайтов региональных компания и прочих корпоративных порталов… Я такие делал. Реализовывать их на «внутренней cms» — мучение. Особенно когда менеджер не понимает что не малая часть функционала — дорабатывается программистом. Именно функционала. А хороших абстрактных и полностью кустомизируемых «внутренних cms» я не видел. И вряд ли увижу потому что это слишком серьезная инвестиция для «студии средней руки».
Я не скажу что в каждом проекте присутствует сложный функционал… Но скажем так. До 40 тыр(по питерским ценам прошлого года) — реализуемо в рамках имеющегося(я внутреннюю cms тогда писал сам.), от 40 до 80 — стопроцентно присутсвуе сложностей которые придется дописывать. Тут ваше ТЗ не подойдет. От 80 — эффективнее покупать коммерческую CMS. Вопрос с какой категорие вы работаете в первую очередь. В каждой из них есть «корпоративные сайты».
в) — программист или дизайнер интерфейсов
a) и б) следует полностью описать формат данных ( ОБЬЯЗАТЕЛЬНО согласовать этот формат с заказчиком), которые будут вводится, он не должен догадыватся, а особенно если имеются ввиду специфические для заказчика данные.
в) это должен решит дизайнер (или если имеется проектировщик интерфейсов), а программист должен знать точно, каким способом этот функционал реализовывать.
Следует понимать, то что не описано — будет сделано на усмотрение программиста и на доделывание потом нужно будет потратить опять время. :)
Описывать стараюсь настолько подробно, насколько могу увидеть проект до его полной реализации.
речь идёт, вероятно, о хоумпейджах, когда время на прочтение ТЗ одного порядка со временем реализации оного.
правила постоения знает гугль
удачи вам в постижении данного ремесла — имхо оно очень полезное
PS. Лично я всегда пишу спецификацию, пусть и в сокращенном виде… пусть на 3 страницы, но обязательно.
PPS. Это позволяет сократить время на доведение системы до кондиции, а не вылавливать пожелания заказчика, ведущие к пересмотру архитектуры, уже когда система почти сделана.
Программист должен уметь решать задачи а не отрабатывать ТЗ.
Так что в технической записке просто инструкция по реализации проекта. Но это совсем не значит, что программист, который по ней работает, не умеет решать задачи.
Обычно техническое задание подготавливается менеджером проекта. Если оно неполное — разработчик вправе додумать «от себя» недостающие фрагменты.
Таким образом, чем полнее предоставленное ТЗ — тем четче будет соответствовать реализация требованию менеджера (и, в итоге, клиента). Ваше ТЗ нечеткое.
Тут хочется вспомнить забавную картинку: ekimoff.ru/download/job/1.jpg
Нормальное ТЗ на простейший сайт фирмы содержит десятки страниц со схемами, таблицами, диаграммами переходов, требованием к клиентской части, тебованиями к серверной части, список необходимого ПО и много чего еще.
Если менеджер способен родить 1-2 страницы и таблицу в два столбика — этот говноменеджер ничего не умеет и не знает.
Если для ваших программистов, значит они уже где-то описаны. Что может быть проще вставить готовое описание в документ? Программист, который работал с данным модулем, пропустит этот раздел при чтении, но зато документ будет полным, что поможет, например, если в будущем возникнет необходимость в поддержке сайта, особенно другим программистом, не знающим про «стандартные» модули.
— регистрация клиентов и работодателей
— поиск вакансий и желающих найти работу
— …
И когда что-то уже сделаем клиенты начинают уточнять свои желания. Подобие ТЗ видел лишь однажды, когда заказ был от крупной корпорации и они просто на бупаге представили внешний вид ксех страниц со всеми полями что там должны быть, а уже тип полей, размерности и т.д и т.п. — этим всегда у нас занимаются программисты.
ТЗ для программиста должно досконально описывать весь процесс взаимодействия пользователей сайта с самим сайтом.
Процесс взаимодействия пользователей сайта с самим сайтом также описывается в этом пункте.
Вот «грубый« пример. Страница «Онлайн-консультация». Онлайн-форма, поля такие-то. При клике на кнопку«Отправить» пользователь получает сообщение об успешной отправке сообщения. Сообщение отправляется на email сотрудника компании, ответственного за выбранный вид услуг.
Насчёт модального и не модального способа сообщения. Если бы я описывала реальную задачу, а не просто грубый пример, и видела, что есть какой-то определённый требующийся в данном случае способ реализации, то я бы именно её и описала. Если что-то не описано, значит подразумевается стандартный для команды, с которой я работаю, вариант реализации.
а) кто пользуется сайтом (целевая аудитория по ролям: админ, менеджер, редактор, авторы новостей, зарегистрированный пользователь, анонимный пользователь)
б) с какой целью им пользуются (посетитель — читает и генерирует рекламные показы, зарегистрированный вдобавок ставит оценки материалам и пишет комментарии, админ — создаёт разделы/страницы, рулит правами пользователей, менеджер — рулит рекламой, редактор — правит новости и решает, что выдавать «в эфир», авторы новостей — создают контент)
в) предметная область системы:
— список сущностей (блог, статья, комментарий, оценка, баннер, ушко и т.п.)
— атрибуты сущностей (например, раздел: название, ссылка, набор дефолтных тегов для статей, набор авторов для этого раздела)
— валидация атрибутов (название раздела — непустое, ссылка — уникальная для каждого раздела)
— права доступа на создание/редактирование/чтение/удаление (комменты могут создавать все, кроме анонимов, удалять разделы не может никто, кроме админа и т.п.)
г) подробное описание системных алгоритмов:
— алгоритм набора кармы пользователями
— алгоритм вывода постов на главную
— оформление заказа в магазине
— геотаргеттинг рекламных показов
— и т.п.
д) наверняка что-то забыл — потом дополню :)
имея исчерпывающую информацию по этим пунктам хороший программист вам создаст такую систему, которой будет абсолютно всё равно:
— какие в ней разделы/подразделы
— что находится на главной
— какая страница вообще главная
— сколько ушек нарисует дизайнер
— сколько счётчиков поставит менеджер
— а также то, что на странице «Контакты» при клике на схему проезда открывается отдельное окошко, в котором вместе со схемой проезда выводится адрес офиса и контактные телефоны, а также есть кнопка «Распечатать»
Пункты в и г — не нужны при разработке КОРПОРАТИВНОГО сайта. Какая может быть карма, комменты, анонимы, вывод постов на главную на КОРПОРАТИВНОМ сайте.
Мне не нужна «система, которой абсолютно всё равно», у меня уже есть выбранная и отработанная система управления контентом. Теперь мне на этой cms надо просто разработать корпоративный сайт.
по последнему предложению — увы, ваш сотрудник, которому это тз предназначается, может только тешить себя тем, что в вашей компании он называется программистом, на самом деле он или сборщик модулей в системе (на странице контактов вставь форму отправки сообщения) или же просто — контент-менеджер (создай разделы, залинкуй «ушки»)
Я не сказала, что этого там нет, я сказала, что всё это описано в концепции сайта, к которой у программиста есть доступ.
Насчёт терминов — может быть. Я называю человека, который реализует задуманный функционал сайта, программистом. Почему-то привыкла так. Возможно, тут больше подойдёт другой термин.
не стоит там описывать, что адрес электронной почты должен проверяться валидатором, а фотографии в галерею может добавлять только админ.
Я понимаю, что cms могла бы сама выдавать статистику посещения, но там, где работала я, она этого не умела. Поэтому был принято решение ставить сторонние счётчики.
А в быту часто есть CMS-ка, фичи которой уже давно вылизаны в той или иной степени и в таком случае просто нет смысла заново формулировать то, что формулировалось в ТЗ на CMS.
В итоге имеет смысл только diff-ы описывать, т.е. то, что явно отличается от имеющихся модулей. Тогда получится как раз примерно то, о чём написала Наталья. В её примере — как раз то самое:
1) структура сайта
Да, в чистой установке CMS обычно не бывает огромной структуры, так, пара страниц и админка
2) описание нестандартных модулей
Точно, модуль списка АЗС в стандартной поставке CMS редко встретишь. Чем детальнее, тем лучше — тут не поспоришь. Отсебятина в любом случае будет самой халявной в реализации, если лень, а иногда наоборот, мега-навёрнутой, если есть время и жутко прёт :)
3) компоновка главной страницы
Вопрос точной настройки шаблонов. Для главной частенько куча нюансов. Правда, чаще бывает, что все детали уже свёрстаны в статике для утверждения с заказчиком. Но текстовое повторение ещё никому не вредило
4) Про «ушки» — ну, тут вряд ли нужен спец.модуль, но зависит от CMS
5) Счётчики.
Хм, тут менеджер мог бы и сам зарегаться и дать просто уже HTML-портянку для вставки в шаблоны, а не заставлять программера регаться везде :)
6) Сложные моменты
Ну а как без них, всё правильно. Видимо, именно тут и идут отличия в стандартных модулях от того, что просит заказчик.
Короче говоря, в целом, ИМХО вполне себе бодрое рабочее ТЗ для небольшого сайта, движок для которого не нужно делать с нуля по километровым ТЗ :)
как вы с лёгкостью вложили в это понятие «сайт, на котором есть только новостная лента, фотогалерея и каталог из 15 позиций» — непонятно.
зы — microsoft.com — это корпоративный сайт?
это ваше определение корпоративного сайта?
«Корпоративный» — это юридический термин.
Google.com — это корпоративный сайт компании Google Inc. Когда кому-то не нравится выдача на сайте google.com, в суд подают на компанию Google, а не на Сергея Брина лично. Потому что google.com — корпоративный сайт, а не личная страничка Сергея.
То, что это ещё и поисковик никак не отменяет тот факт, что он корпоративный.
И то, что вы в статье назвали рекламные сайты (сайты-буклеты) корпоративными, никак не отменяет тот факт, что множество корпоративных сайтов содержит в себе гораздо больше типов сайтов, чем «простое представительство компании в сети».
У компании, в которой работает моя подруга, на корпоративном сайте некоторое количество нетривиальных внутренних сервисов. Другой пример — интерактивные рекламные кампании на корпоративном сайте. Для всего этого CMS уже мало.
У вас не получилось не ТЗ, а концепция, которая служит только обоснованием на постановку задачи для проектирования сервиса. Да и та — совсем без информации.
С таким описанием программист реализует всю свою сексуальное фантазию и будет прав, потому что выгонять нужно таких писателей. Почитайте Дениса Бескова-Доронина, например.
>А где описание интерфейса? Где описание логики обработки данных? Где границы для разработчика?
Зачем это при разработке корпоративного сайта на готовой cms?
Как по такому ТЗ можно оценить стоимость разработки? Сколько программист будет колупаться? Три часа или 20? Или корпоративному клиенту на корпоративной cms это тоже не важно?
Кинул своим разработчикам почитать. Сказали, что наказали бы вас за такое неуважение к их труду.
>Сказали, что наказали бы вас за такое неуважение к их труду.
А вот программисты, с которыми работаю я, всегда довольны тем, что имеют всю исчерпывающую информацию по проекту. Меня больше интересует их мнение.
> такого ТЗ. Потому что, если модуль новый, я подробно опишу, что он должен делать и из
> чего состоять.
В том-то и дело, что у вас только перечень объектов указан и больше ничего. Остальное, видимо, должно придти свыше. Подумайте сами, где у вас обработка ошибок? Где пояснение, куда складываются данные? Как модуль должен себя вести после заполнения данных? Какие элементы управления модулем должны быть? Откуда извлекаются, например, «услуги»? Это справочник или фиксированный набор? Вопросов очень много… Если их все не описать, то мы рискуем деньгами компании и клиента.
Понимаете, вы выложили заметку претендующую на рассказ о Настоящем Техническом Задании. А показываете заметку о небольшом кусочке концепции, прикрываясь словами о том, что программисты и так все знают, а то, что вы нам дали почитать — небольшая формальность.
> А вот программисты, с которыми работаю я, всегда довольны тем, что имеют всю
> исчерпывающую информацию по проекту. Меня больше интересует их мнение.
На безрыбье и рак рыба. Стремитесь к лучшему и не довольствуйтесь имеющимся.
>На безрыбье и рак рыба.
Вы не общались с этими людьми и не видели их работы, так что не надо никого оскорблять.
>В том-то и дело, что у вас только перечень объектов указан и больше ничего.
У меня не перечень объектов, у меня тщательное описание каждого функционального модуля сайта. Вы не вникли в суть того, о чём я писала.
> так что не надо никого оскорблять.
Я не оскорблял никого, извиняюсь, если создалось такое впечатление.
> У меня не перечень объектов, у меня тщательное описание каждого
> функционального модуля сайта.
В записке, ТЗ или в концепции? Впрочем, ладно. Работайте как удобно вам и вашим рискам =)
В приведённой в статье технической записке, пункт номер 2.
У меня, благодаря моему личному принципу работы, риски сведены к минимуму.
Данная техническая записка не упоминается в договоре.
Это перечень, а не описание. Вы перечисляете то, что там должно быть, а не то, как оно должно работать. Или где-то существует действительно подробное описание, которое вы здесь не указываете? Тогда какой смысл в статье, если самое интересное вынесено за ее пределы?
> У меня, благодаря моему личному принципу работы, риски сведены к минимуму.
Я рад, что у вас хорошие и думающие программисты, но в большой организации, где документация полностью отторгаемая, вам придется нелегко из-за особенностей коммуникации. Вы просто можете не попасть к программистам, чтобы объяснить на пальцах то, о чем вы написали слишком поверхностно.
Кроме того, у вас так и написано «список». Как на основе списка можно разрабатывать модуль ротации этих ушек? Нет ни данных, ни форматов передачи данных, ни алгоритма подстановки «ушек» с зависимостями.
рад за вас люди, что у вас все лучше!
По теме и по личному опыту полностью поддерживаю Наталию. Менеджер не должен разбераться во всех технологических тонкостях! На то он и менеджер, чтобы донести весь замысел, как до Клиента (в первую очередь), так и до Разработчиков, все отследить, проконтролировать, «присутствуя» на всех этапах разработки (и к слову дизайна, что тоже очень немаловажно). Лично я, в последнее время, использую axure rp pro, для проектирования интерфейсов и внтури прототипа устанавливаю основные связи между объектами. Мне так проще, и клиенту можно прототип показать и донести, как тут не раз повторялось, «бизнес-логику». Потом разработчикам тот же прототип, в купе с дизайном + пояснения по дополнительному функционалу и пожелания.
Полностью с Вами согласен, это более удобно чем текстовое ТЗ с блоками.
притом, спроектированный в axure прототип вполне пригоден для ТЗ, а для «тонких» моментов можно использовать комментарии.
1. Работать с контентом. Как с отображением так и с настройками CMS.
2. Реализовывать новый функционал.
3. Документировать. И что сложнее создавать структуру документации.
А теперь подумайте правильно ли это?
Очень часто крайним(виноватым) в срыве или провале проекта является менеджер, потому что именно он организовывает работу по всем направлением проекта:
— отношения с заказчиком;
— работа с программистами;
— тестирование;
— организация внедрения;
и еще куча мелких деталей…
Так вот ТЗ — документ, который (а особенно, если он подписан заказчиком) очень поможет менеджеру закончить проект, поскольку по сути является той точкой, до которой разработка ведется, т.е. является
пределом для всяких хотелок заказчика и есть тем за что можно спросить программиста…
И, как мне кажется, при составлении договора такой пункт как ТЗ, должен быть обьязательным.