Технічне завдання: як і навіщо його писати і чому без нього не обійтися

Усі вдалі IT-продукти колись були просто ідеями. І дуже часто (майже завжди) ідеї належать людям, далеким від розробки програмного та апаратного забезпечення. Вони хочуть щось покращити у своєму бізнесі, у тому напрямі діяльності, який знають досконало. Ідеї, думки, мрії – це чудово, але важливо, щоб фахівець вірно їх зрозумів і втілив у працюючий пристрій чи програму. Правильно довести ідею розробки допоможе технічне завдання. Навіщо готувати ТЗ, хто і як повинен це робити, чи можна обійтися без ТЗ і як мінімізувати витрати – про це ви дізнаєтеся з цієї статті.

Навіщо писати технічне завдання?

Технічне завдання на розробку приладу або програмного забезпечення – це документ, що визначає вимоги до IT-продукту, включаючи його призначення, функції, поведінку, компоненти, технології, інструменти розробки, що використовуються, а також порядок виконання робіт. ТЗ служить керівництвом для бізнес- та технічних груп, які займаються створенням IT-рішення. Технічне завдання однаково потрібне і замовнику, і розробнику. Специфікація є працею фахівців з різних областей і використовується клієнтом та виконавцем протягом усього періоду розробки та після закінчення проекту. Технічне завдання на проектування пристрою або написання програмного забезпечення дозволяє отримати попередню оцінку вартості розробки продукту Вартість складного пристрою або програми неможливо оцінити навскидку. Необхідно врахувати безліч моментів – витрати спеціалістів, вартість компонентів і логістики, роботи, пов'язані з сертифікацією тощо.Грамотно складений документ дозволяє і виконавцю, і замовнику бачити та оцінювати як процес розробки цілком, так і окремі його ступені. Таким чином, замовник отримає уявлення про попередню вартість кожного етапу робіт. Точніші дані будуть дані у кошторисі проекту. У ТЗ окреслюються приблизні терміни виконання замовлення. У клієнта та аутсорсингової компанії не буде розбіжностей щодо таймінгу, якщо з самого початку в документі позначено тимчасові відрізки для кожного етапу проекту. Терміни виконання робіт із проектування електроніки та створення програмного забезпечення можуть зрушуватися з різних причин. Деякі з них – наприклад, час очікування компонентів та терміни доставки – можна передбачити вже на етапі написання ТЗ. Замовнику буде простіше оцінити готове рішення – електронний пристрій, програмне забезпечення або програмно-апаратну систему, – звіривши його з описом у технічному завданні. Саме тому ТЗ має бути складено грамотно та максимально докладно. Якісно написане технічне завдання на розробку приладу або програмного забезпечення може свідчити про компетенцію та досвід фахівців. Вдумливий підхід розробників до підготовки проекту, зрозуміла та вичерпна інформація у ТЗ говорять про загальний рівень сервісу компанії. Спільна робота може бути перервана або заморожена за тими чи іншими обставинами – через фінансові та правові труднощі, геополітичну обстановку, розбіжності сторін, серйозні логістичні проблеми тощо. З добре складеним технічним завданням на розробку IT-продукту замовнику простіше повернутись до співпраці з аутсорсинговою компанією або знайти нового підрядника. У ТЗ описується сам продукт, його призначення та функціональність, а також етапи розробки, основні елементи електроніки та інструменти для створення програмного забезпечення. Таким чином, і замовник, і розробник мають повне уявлення про проектоване IT-рішення, що є страховкою від розбіжностей, непорозуміння, внесення незапланованих змін до концепції продукту. Робота над проектом йде швидше та простіше, коли команда розробників спирається на ТЗ. Немає потреби узгоджувати кожен крок, втрачаючи час. А чи можна без ТЗ? Написання ТЗ – процес непростий, що вимагає високої кваліфікації і, звичайно, грошей. Прагнучи скоротити вартість проекту, замовник може вирішити написати ТЗ своїми силами або відмовитися від написання документа. Чи можна обійтися без ТЗ – пояснити словами, показати зразок пристрою, плати чи додатки, попросити зробити за шаблоном? Будь-який, навіть зовсім невеликий типовий проект вимагає оформлення специфікації - документа, де будуть зафіксовані вимоги до рішення, порядок робіт, використовувані компоненти і т.д. Це не буде ТЗ у класичному вигляді, але без специфікації не обійтися. Клієнт може надати документ, у якому у довільній формі викладено його ідеї, побажання, бачення продукту. Компетентність клієнта у питаннях проектування та програмування буде великим плюсом, але головне – чітко та зрозуміло сформулювати свої побажання до продукту. На основі такого пояснення компанія-розробник створить повноцінне якісне ТЗ, яке буде орієнтиром у подальшій розробці.

Як написати технічне завдання

Технічна специфікація містить багато предметних даних та детальний опис процесу розробки.Чим складніше завдання, тим більше фахівців буде залучено до написання ТЗ і тим більше інформації буде у готовому документі.

Хто готує специфікацію?

Розробкою технічного завдання на проектування пристрою або створення програмного забезпечення займаються фахівці, які знають всі нюанси розробки та того, як буде виконано проект – етапи робіт, терміни, компоненти та кінцевий продукт. Це ПМи, розробники, випробувачі. Кожен із них вносить у ТЗ свою інформацію, вибудовуючи загальну картину проекту. Можна довірити написання технічного завдання спеціалістам зі штату своєї компанії, які знають, який продукт їм потрібен, і можуть детально вказати в документі бажані функції та характеристики пристрою чи програми. Але найчастіше така економія обертається подвійною роботою, втратою часу та грошей. Технічне завдання, створене компанією-розробником, враховуватиме не лише всі побажання клієнта, а й можливості підрядника (експертизу в розробці, досвід роботи з компонентами, інструменти та мови програмування тощо). Всі пункти ТЗ будуть обумовлені сторонами та схвалені замовником, щоб за підсумком співпраці клієнт отримав продукт, що задовольняє всім вимогам.

Що має бути у ТЗ?

Технічні завдання розробляються під конкретний проект і зазвичай унікальні. Тим не менш, є пункти, які в тому чи іншому вигляді присутні у всіх технічних завданнях на розробку ПЗ, електроніки та програмно-апаратних систем.

Терміни, скорочення та визначення

Терміни, що використовуються в тексті, наводяться на початку документа.Це можуть бути як IT-поняття – назви елементів, середовищ та мов програмування, технічні визначення – так і слова та позначення з тієї сфери, для якої призначається IT-рішення. Чим ретельніше буде продуманий список професійних слів, краще зрозуміють один одного виконавець і замовник.

Призначення продукту

У цьому блоці розписуються призначення IT-рішення, цілі його створення та цільова аудиторія. До основних цілей можуть належати збільшення клієнтської бази, позитивний імідж компанії, збільшення продуктивності праці, зменшення ручних операцій і т.д. Пункт також містить інформацію про завдання проекту – це може бути розробка з нуля та під ключ, участь в окремому етапі створення (наприклад, робота над програмним забезпеченням для готової апаратної частини) або удосконалення існуючого продукту. Цілі повинні бути конкретними та зрозумілими, щоб кінцевий продукт максимально відповідав вимогам та був корисний замовнику.

Вимоги до проекту

• Розробка контролера для управління пристроями замовника. Контролер повинен бути встановлений на кожному пристрої.
• Створення пульта управління пристроями, використовуючи комп'ютер на базі Linux.
• Розробка програми для віддаленого керування.
• Інтегрування пульта управління та контролера в єдину систему управління.
• Тестування.
• Можливі доопрацювання та модифікації системи.

Функціональні вимоги стосуються функцій та поведінки IT-рішення. Приклад:

1. Система повинна надсилати повідомлення про збій у роботі обладнання.
2. Система має контролювати датчики.
3. Система має передавати дані по радіоканалу.
4. Система має мати аварійну сигналізацію.
5. Система повинна керувати всіма функціями пристрою.

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

Вимоги до розробки можуть бути представлені декількома пунктами, де докладно описуються етапи робіт і компоненти та інструменти, що використовуються.

Наприклад, у ТЗ на розробку програмно-апаратного комплексу може бути пункт, що описує вимоги до розробки пристрою, протоколів зв'язку (MQTT, TCP і т.п.), додатка для управління пристроєм.

Вимоги до організації та якості робіт визначають те, як буде організована робота над проектом, комунікація між замовником та виконавцем, а також основні моменти щодо якості системи, пристрою або програмного продукту – час безперервної роботи, поведінка системи в аварійній ситуації тощо.

Вимоги до безпеки можуть містити вимоги щодо захисту коду, розмежування доступу, прав і т.д.

Крім основних пунктів, ТЗ містить індивідуальні для конкретного проекту блоки, наприклад опис ролей для розмежування доступу, вимоги до інтерфейсу, вимоги до розміру і зовнішнього вигляду пристрою.

Що таке гарне ТЗ?

Яким має бути якісне технічне завдання на розробку пристрою та ПЗ: на одну сторінку чи п'ятдесят, написане шаблонними фразами чи з використанням технічного сленгу, з картинками чи без?

Насамперед, ТЗ має бути написано простою та зрозумілою мовою, адже її вивчатимуть не лише технічні фахівці, а й менеджери відділу продажів, та команда замовника. Звичайно, без технічних термінів не обійтися, але не варто перевантажувати текст. Схеми, малюнки, таблиці не є обов'язковими, але дуже бажаними.Графічні елементи доносять інформацію у наочній та зрозумілій формі.

Розмір ТЗ залежить від масштабу та складності проекту. Чим більше проект, тим більше підготовчих документів. до балансу стислості, зрозумілості та інформативності.

Чим може обернутися несерйозний підхід до складання та вивчення специфікації? та вникнути у готовий документ.

Роботу з написання технічного завдання краще довірити професіоналам – тим, хто розроблятиме IT-рішення. До них можна прийти з ідеєю, навіть не маючи уявлення, як її втілити.

Помилки при складанні специфікації

При складанні технічного завдання важливо уникати поширених помилок.

Відсутність словника термінів

У специфікації від замовника: Віртуальний помічник забезпечує голосову взаємодію, відтворення Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna, надає інформацію про EPL, MLB, NBA, NHL і т.д.

Як має бути: Віртуальний помічник забезпечує голосову взаємодію, відтворення музики (Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna), надає інформацію про спортивні події (EPL, MLB, NBA, NHL тощо).

Музичні сервіси: Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna.

Абревіатури спортивних об'єднань:

• EPL – English Premier League
• MLB – Major League Baseball
• NBA – National Basketball Association
• NHL – National Hockey League

Розпливчасті та незрозумілі формулювання

У специфікації від замовника: Представлений у 1983 році, MIDI є стандартом для багатьох існуючих продуктів та додатків. MIDI визначає як протокол обміну музичними даними, а й апаратне з'єднання, використовуване для фізичного обміну даними. Передача MIDI даних через інше з'єднання, таке як USB, буде називатися USB-MIDI.

Як має бути: Формат MIDI (Music Instrument Digital Interface) дозволяє стандартизувати музичне обладнання різних виробників.

Протокол забезпечує передачу даних у цифровому форматі між пристроями, дозволяє відтворювати музику та керувати роботою допоміжного обладнання (піротехнічного, освітлювального тощо).

Перевантажений деталями опис

У специфікації від замовника: Формат GS - це набір рекомендацій, створених Roland для стандартизації характеристик звуковідтворювального обладнання. Він підтримує всі функції, перелічені у General MIDI System. Крім того, добре сумісний формат GS забезпечує більшу різноманітність звуків, дозволяє редагувати звук та задає численні особливості для широкого спектру додаткових функцій, таких як ефекти хорусу та реверберації.

Формат GS був створений з розрахунком на майбутнє, що спрощує додавання додаткових звуків та підтримку нових апаратних функцій у міру їхньої появи. Його можна модифікувати для роботи із системою General MIDI.У результаті формат GS компанії Roland може достовірно відтворювати партитури General MIDI, як і музичні дані GS (музичні дані, записані у форматі GS).

Як має бути: Формат Roland GS є розширення стандарту General MIDI для уніфікації характеристик звукового обладнання.

Підтримуючи всі функції, перелічені в General MIDI System, стандарт доповнено новими інструментами, ефектами та функціями.

Плутанина у функціональних та нефункціональних вимогах

У специфікації від замовника: Система повинна підтримувати температуру води в нагрівальній ємності не вище 50°.

Як має бути: Функціональні вимоги: Система повинна підтримувати температуру води, що встановлюється користувачем. Нефункціональні вимоги: Температура води в обладнанні не повинна перевищувати 50°С.

Висновок

Розроблення IT-рішення – електронного приладу, додатка, вбудованого програмного забезпечення або IoT-системи – передує написанню технічного завдання. Це може бути коротка специфікація або велике серйозне ТЗ – все залежить від масштабності та складності проекту. ТЗ дає уявлення про призначення та функції продукту, вимоги до розробки, хід робіт та порядок приймання готового рішення.

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

Технічне завдання: навіщо потрібно і як скласти

Створюємо послуги у сферах , освіти, девелопменту.

Чітке розуміння завдання без технічного завдання є лише в компаній, які працюють у рамках ГОСТів та інших загальновизнаних стандартів якості. Якщо у сфері вашої роботи немає чітких норм, для оптимального результату краще відобразити свої вимоги до продукту в технічному завданні. Про те, що це таке, кому потрібно, а кому ні, і що в ньому має бути, розповімо у статті.

Що таке технічне завдання

Технічне завдання (ТЗ) — це документ із докладним описом вимог до цифрового рішення. Розробка ТЗ допомагає замовнику сформулювати та зафіксувати, яким він хоче бачити кінцевий продукт. А команда розробників оцінює витрати на реалізацію проекту із запропонованими характеристиками та розуміє, як виглядає результат в очах замовника.

Сам термін «технічне завдання» використовують у багатьох сферах та інтерпретують так, як зручно. Наведемо приклад із звичайного життя. Фраза «Пофарбуй паркан у зелений колір» – це технічне завдання? Ні, скоріше, це загальне бачення кінцевого продукту. В даному випадку правильне ТЗ виглядатиме так: «Пофарбуй паркан фарбою фірми „Мамкін маляр“ відтінку „Юний крокодил“ у два шари завтовшки 3 мм. Починай фарбувати від хвіртки та закінчуй на стику зі стовпом. Термін висихання шарів – не менше 4 годин. Закінчення робіт – за добу».

Відповідно, технічним завданням ми називаємо документ, у якому відображено цілі, вимоги, технології та методи виконання робіт, порядок узгодження проміжних та підсумкових результатів, терміни виконання завдання, кінцеве бачення продукту від замовника.

Технічне завдання полегшує комунікацію між замовником та виконавцем, а у спірних ситуаціях дозволяє звернутися до прописаних у ТЗ вимог, щоб вирішити ситуацію. Найкраще рішення — якщо технічне завдання стане додатком до основного договору.

Коли потрібне технічне завдання

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

Якщо потрібно розробити технічно складний продукт, який передбачає серйозне фінансування, краще скласти докладне ТЗ із зазначенням усіх важливих вимог. Те саме стосується технічного завдання для творчих проектів — наприклад, дизайнерські завдання важливо зафіксувати, щоб виконавець зробив те, що потрібно замовнику.

Коли технічне завдання не потрібне

Не завжди ТЗ допомагає спростити завдання та зробити результат ефективно та в короткі терміни. Буває, що технічне завдання обмежує, заплутує та заважає підряднику.

У яких ситуаціях це можливо?

У деяких проектах замість ТЗ достатньо скласти Product Vision. Бачення продукту – відправна точка будь-якого ІТ-проекту. Воно дає уявлення про цифрове рішення, вимоги до нього, його цілі та завдання.

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

Яка користь від ТЗ для замовника

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

Оцінює бюджет. Розрахувати вартість нешаблонних цифрових рішень навскідку неможливо. Спочатку потрібно визначитися, які вимоги до продукту, і тому визначити, що потрібно розробити — сайт, додаток, сервіс або портал. Потім зрозуміти, як буде працювати і які функції виконувати. І лише на основі отриманої інформації визначити терміни та бюджет. ТЗ якраз вирішує це завдання.

Структурує інформацію. Компанія приходить по розробку з конкретними вимогами до цифрового продукту. До того ж вимоги можуть становити різні підрозділи — технічні фахівці, команда маркетингу, аналітики, комерції. І кожен підрозділ має свої цілі. Цифрове рішення має об'єднувати та виконувати всі ці вимоги. Завдяки ТЗ вся отримана інформація вибудовується у чіткі завдання та фіксується у документі.

Визначає компетентність підрядників. Через ТЗ можна «промацати» підрядника та оцінити його компетентність. Часто компанії, які звертаються за ТЗ до стороннього виконавця, планують продовжити співробітництво з ним і доручити їм реалізацію продукту. Якщо замовник бачить зрозуміле та структуроване технічне завдання, то з підрядником можна продовжити співпрацю. Якщо бачить плутанину і не розуміє, що в документі описано, це змушує задуматися про надійність компанії-розробника.

Страхує від несумлінних підрядників. Якщо компанії-замовнику не подобається робота підрядника вже на стадії реалізації товару, можна замінити команду. Нові виконавці на основі хорошого ТЗ швидко розберуться із завданням та увіллються у процес. Крім того, технічне завдання дозволяє «тримати руку на пульсі» контролюючим структурам, які можуть не мати технічного бекграунду — готову розробку можна перевірити на відповідність вимогам ТЗ.

Хто складає технічне завдання

У нашій практиці зустрічаються два основні варіанти та третій змішаний:

І ще один момент. Не обов'язково намагатися використати у ТЗ технічні формулювання, можна описати продукт своїми словами. Тут на допомогу приходить Product Vision, про який ми писали вище. Достатньо прийти з документом, де буде зафіксовано основні вимоги та побажання.

Якщо ви хочете спробувати самостійно написати технічне завдання, скористайтесь алгоритмом нашого гайда. Він буде корисним для фахівців без технічного бекграунду.

Чий обов'язок писати Технічне завдання (ТЗ)?

Як ви вважаєте, чи як це заведено у вашій організації — хто має писати ТЗ на розробку сайту?

Варіанти:
1. Менеджер з роботі з клієнтами
2. Веб-дизайнер
3. Веб-розробник

Якщо є інші варіанти, будь ласка.

За ТЗ має відповідати менеджер. Він опитує клієнта, заповнює разом із ним анкети/опросники якщо потрібно і наприкінці видає підсумковий документ.
Якщо менеджер не може описати вимоги клієнта в термінах ТЗ, то гнати такого менеджера за профнепридатність.Що він взагалі збирається "менеджити", якщо не розуміє про що проект? Йому потім із цього ТЗ розрулювати претензії та хотіли клієнта. Зрештою, розробляється не атомна електростанція. Технарі повинні залучатися до процесу написання ТЗ тільки якщо передбачається щось явно складне і не факт, що технічно реалізується за розумний час/гроші.
Так, наприкінці з боку виконавця ТЗ має переглянути технолог/старший розробник/хто там ще. По-перше щодо технічних ляпів, по-друге щодо внутрішньої оцінки складності реалізації. Дизайнер при складанні ТЗ потрібен знову ж таки рідко, йому з ТЗ потрібні підсумкові функціональні вимоги плюс фірмовий стиль/брендбук якщо вони є.

Тобто. Будь-який менеджер повинен вміти відразу описати в ТЗ архітектуру бази даних для порталу з функціями соц. мережі і розрахувати яке навантаження зможуть тримати ще не створені скрипти на такому залізі?) І це не щось позамежне для проектів за гігантські суми, а зовсім робочий момент при створенні якогось клона Хабри.

Підтримаю. У нас у компанії за ТЗ бізнес-аналітики відповідають. Це спеціальні люди, які перекладають із мови замовника на мову розробника :)

Чув від товариша про таку практику: розробник пише ТЗ (причому не безкоштовно), а потім погоджує із замовником. Тобто замовник лише ставить свій автограф, якщо його все влаштовує.

Або так, розробник (або тимлід) отримує набір вимог до ПЗ, потім пише ТЗ (не за безкоштовно природно) і затверджує/коригує із замовником. Причому у процесі уточнення вимог зазвичай і пишеться ТЗ, ітеративно.

to zizop: Ви маєте рацію. Як правило, замовник формулює функціональні вимоги, а тимлід пише ТЗ.
to berik_iushi: мій товариш виконував держ. замовлення. Я думаю, що не варто орієнтуватися на ті гроші, які крутяться там. До того, зізнатися, я не знаю, скільки це коштує.

Якщо вважати сайт — інформаційною системою, то можна спиратися на ГОСТ
За ДСТУ ТЗ розробляє виконавець за участю замовника на підставі технічних вимог.

Однозначно – це не робота менеджера чи дизайнера.
В ідеалі спеціальна людина по роботі з документацією, на практиці розробник.

Згодний з densilvio та aquarius.
Технічне завдання, за своєю суттю, це документ, що описує розробнику, що і як має працювати в готовій системі. По правильному під ТЗ повинен відводитися окремий етап у створенні.
Це досить об'ємна робота, яка має окремо оплачуватись, як дизайн, інтеграція чи кодинг.
Адже хороше ТЗ враховує специфіку бізнес процесів замовника, описує всі необхідні та можливі варіанти поведінки системи, в ньому мають бути прописані інтерфейси користувача.

В ідеалі ТЗ взагалі має створюватися третьою компанією, причому так, щоб замовник звернувся до обраного розробника і не виникло запитань.

Ну, а на практиці студії пишуть ТЗ самі для себе. І як наслідок це не повноцінний документ, а так…

Я керівник проектів (або ПМ). Пишу ТЗ сам, зрідка радиючись із програмістами та дизайнерами, т.к. маю досить великий досвід.

Варіант "ТЗ пише сам замовник" - не рекомендую. Тому що уточнення ПМ можуть в результаті зайняти більше часу, ніж написати ТЗ з нуля (ну, не зовсім з нуля, використовуючи деякі накопичені заготовки).

Деякі замовники хочуть самі писати ТЗ, а деякі навпаки просять писати виконавця. Хоча згоден, найчастіше краще самому підготувати.

Вибачте, хотів плюсанути, але промазав. Плюс пішов у карму.

У вашому випадку найімовірніше необхідно колективно за участю клієнта обговорити деталі, почути від нього побажання, а потім на основі цієї інформації написати ТЗ. Природно, що написанням ТЗ має займатися людина, яка грамотно та повно технічною мовою здатна викласти завдання на папері. Якщо це буде робити гуманітарій, будьте готові до можливих претензій з боку клієнта та переробок проекту.

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

Якщо питання поставлене саме так, то на першому етапі менеджер спільно із замовником – чорновий варіант. Далі веб-розробник доповнює та узгоджується ітеративно.

Правильний варіант. ТЗ пише замовник, його читає менеджер та уточнює. Потім ТЗ читають розробники (у Вашому випадку, веб-дизайнер та веб-розробник) і висловлюють зауваження (якщо є). Після цього менеджер погодить із замовником уточнений варіант ТЗ. Так може пройти кілька ітерацій.

Прийнятний варіант (часто він зручніший). ТЗ пише менеджер і погодить його зі своїми розробниками, а вже після цього із замовником. І може бути кілька ітерацій.

У будь-якому випадку ТЗ – це документ замовника, в ньому також зацікавлений розробник. Третя організація до ТЗ жодного відношення не може мати.Хіба що в окремих випадках, наприклад, коли одна організація замовляє, а інша оплачує.

Якщо менеджер не вирішує всі фінансові споси, то ТЗ також має перевіряти людина, яка за це відповідає.

Після підготовки та підписання кількох ТЗ, нові зазвичай готуються на базі старих.

Не згоден. Різні бувають ТЗ від замовника. Напевно, у веб-розробці так і є, як ви кажете, я з цим не стикався. А там, де я працюю, замовники цілком нормальні ТЗ пишуть.

ТЗ пишеться бізнес-аналітиком з урахуванням побажань майбутніх програмістів. Розділи ТЗ узгоджуються із замовником, щоб п'ятисотсторінковий талмуд не переписувати якщо замовнику не сподобається результат.

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

Чиї руки писатимуть — не так важливо, хоч секретар. Але відповідати за цей процес має, зрозуміло, менеджер. Іншими словами, менеджер може написати сам, може делегувати, але це його завдання

Дивлячись що мати на увазі під ТЗ.
Зазвичай це завдання (ЦА, структура, набір модулів, додатковий функціонал). Якщо йдеться про постановку завдання, то цим має займатися або аналітик, або проектувальник інтерфейсів.
Технічне завдання у класичному розумінні (архітектура, інтеграція, технологічні рішення тощо) повинен писати тех. Як правило, або архітектор, або розробник.

Створили собі шаблон. Копію шаблону передаємо менеджеру для заповнення разом із замовником.На основі заповненого шаблону менеджер створює проект ТЗ з макетами майбутнього сайту, макети створює веб-дизайнер. Цей проект узгоджується менеджером із замовником. На підставі проекту створюється дизайнером та розробниками «остаточне» ТЗ, яке стає невід'ємною частиною договору. Договір, разом із ТЗ, підписується замовником і далі, ТЗ передається на розробку.

Бувають випадки коли ТЗ (остаточне) пишуть сторонні організації, тому що:
- Іноді замовник не може (не розуміє специфіки або інші нюанси) побачити всі технічні деталі
— інколи виконавець не може до кінця зрозуміти всі аспекти проекту
- Іноді замовник, не знаючи виконавця, не довіряє складання ТЗ виконавцю

різні бувають випадки

Не хотілося б працювати за таким ТЗ, коли замовник та виконавець представляють щось своє. При здачі роботи може бути дуже добре.

Все залежить від того, як взагалі організовано процес виробництва ПЗ.

Якщо проект разовий і команда маленька, то хтось напише ТЗ — вже не важливо. Головне, щоб воно було загалом.

А якщо команда велика, добре структурована, і є окремий тим маркетологів (які і з конкретним клієнтом працюють, і ринок моніторять), і проект має не один етап, то вже справа навіть не в конкретному ТЗ. Зазвичай готується Стратегія розвитку продукту - загальний документ, що описує цілі та напрями розвитку продукту на перспективу. У рамках Стратегії для кожного конкретного етапу може готуватися Детальне Опис Продукту — докладний документ з описом версії продукту, що готується до випуску. Готує його відділ маркетингу і він його погоджує із Замовником.І коли Опис продукту для даного етапу готовий, то Developers Team Leader (DM) на його базі готує ТЗ для своєї команди. І це ТЗ можуть Замовнику навіть показувати, т.к. це, власне, внутрішній документ. Якщо DM брав активну участь у підготовці Опису Продукту (а він повинен брати участь, і його зауваження повинні бути враховані), то ТЗ вже не буде змінюватися в процесі розробки. І, до речі, за такої організації процесу Project Manager може нести тільки адміністративні функції, і взагалі не нишпорити в програмуванні.