Як правильно скласти ТЗ для програміста. Основи взаєморозуміння

Опубліковано: 23.04.2015 |
Автор: Олег Галеня |

Призначення, цілі ТЗ

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

 

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

 

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

 

За своїм обсягом ТЗ може бути досить великим документом. Web-компанії часто пропонують допомогу щодо складання ТЗ окремою послугою, як правило, 10-20% від вартості всієї розробки сайту.

 

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

 

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

 

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

 

Загальні рекомендації з написання ТЗ

 

  • Проста істина – чим складніше проект, тим деталізованішим має бути ТЗ.
  • Серед можливих варіантів можна назвати ТЗ, що описує головні сторінки інтерфейсу з усією сукупністю елементів на них і описом їх поведінки. Або ж це може бути лаконічний опис декількох сторінок для сайту-візитки і т.п.
  • У ТЗ для програміста не повинен згадуватися дизайн елементів або звучати побажання з дизайну. Завдання все ж таки для програміста.
  • Описи завдань в окремих частинах ТЗ повинні мати межу. Що це означає? Потрібно чітко позначати кінець конкретного пункту завдання. В ТЗ не повинно бути абстрактних фраз типу «Повинна бути зручна навігація». Це суб'єктивні ознаки: одним зручно, іншим – незручно, й зрозуміти, чи  виконаний  даний пункт буває складно через нечіткість положень ТЗ. Тому це необхідно контролювати.
  • Для нескладних сайтів, де потрібно описати який-небудь функціональний модуль, щоб знову не винаходити велосипед, потрібно проаналізувати сайти зі схожим функціоналом, так би мовити, провести аналіз конкурентів; зберегти гіперпосилання на сторінки з необхідними елементами інтерфейсу і функціями, і включити їх в ТЗ з розширеними поясненнями, що саме робити. Також необхідно в обов'язковому порядку зробити скріншоти з потрібних сторінок, на випадок, якщо сайт через певний проміжок часу буде недоступним. При цьому можна ставити свої позначки на зображеннях (дякувати, сервісів зараз багато для цього – Сlip2net, Awesome, Screenshot, Joxi тощо).
  • Якщо дизайну для сторінок немає або він не такий важливий у рамках якогось проекту, скажімо, замовник вирішив заощадити на дизайні адмін-панелі сайту, в цьому випадку програміст цілком може використовувати прототипи.

Довідка

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

Серед популярних можна виокремити: 
– Серед безкоштовних: iPlotz, MockFlow, Mockup Builder, Cacoo; 
– Серед платних: Creately, ProtoShare, Adobe Fireworks, Axure. 
Можливостей загалом багато – вибирай, освоюй, малюй.

Загальна структура ТЗ. Від абстракції до конкретики

Одна з можливих структур сайту, підкреслюю – можливих, виглядає приблизно так:

 

1. Загальна інформація про сайт
2. Функціональне призначення сайту
3. Поняття й терміни
4. Опис модулів сайту
5. Функціональні характеристики
6. Опис сторінок
7. Резервування й надійність
8. Хостинг для сайту

 

1. Загальна інформація про сайт 

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

 

2. Функціональне призначення сайту 

Тут короткий перелік того, якими технічними засобами або інструментами повинен володіти сайт, виходячи із загальної мети. Поясню на прикладі. Для сайту-візитки це може бути банально: форма зворотного зв'язку, перелік основних сторінок, наприклад, «Про компанію», «Контакти» та інші.

 

3. Поняття та терміни 

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

 

4. Опис модулів сайту

Цей розділ включає перелік модулів, які використовуються на сайті. Це цілком, наприклад, може бути згадувана вище форма зворотного зв'язку (ФЗЗ). Але, що дуже важливо, не можна просто писати «Повинна бути ФЗЗ». Кожна сутність вимагає визначення своїх атрибутів! В даному випадку атрибути можуть бути такими:

 

  • Поле «Ваш ім'я»
  • Поле «Ваш е-mail»
  • Поле «Ваше питання»
  • Поле введення капчі для захисту від спам-роботів

 

І все це має бути чітко прописаним, щоб потім не виникло запитань: «…а де перелік вибору категорії питання?» Або щось такого типу.

 

5. Функціональні характеристики 

Сюди можна віднести, наприклад, перелік браузерів, де сайт повинен коректно відображатися та працювати. Наприклад, деякі замовники можуть вимагати, щоб їхній сайт працював коректно й у відомому Internet Explorer 6, щоб не втрачати хоч і невелику, але частку можливих відвідувачів. 

 

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

 

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

 

6. Опис сторінок сайту

Це досить великий пункт, де промальовуються всі сторінки сайту й пишуться коментарі до їхньої роботи. 

 

Також може наводитися загальна структура сторінок сайту. Так звані «високорівневі» прототипи. Наприклад, для простого сайту-каталогу це може бути:

1

Для кожної конкретної сторінки можуть малюватися прототипи з докладними коментарями по кожному з елементів інтерфейсу та їхньою поведінкою. 

 

Сторінки, що використовуються для адмін-панелі, зазвичай вказуються окремо від публічних сторінок. Ці два розділи в свою чергу можуть групуватися в свої окремі підрозділи. Тут варто стежити, щоб прототипи не конфліктували з їх описом і не виникало ніяких суперечливих понять. Прикладом прототипу певної сторінки сайту може бути:
2Решта сторінок 

 

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

 

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

В кінець ТЗ в обов'язковому порядку потрібно внести інформацію про те, що всі роботи, не описані в цьому ТЗ, виконуються на розсуд програміста з очевидних причин. Це наша «маленька гарантія» від можливих доопрацювань і переробок, що виходять за рамки ТЗ.

 

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

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

 

Вдалих вам проектів і людського взаєморозуміння! 

 

Автор: Олег Галеня

 

Оригінал статті: http://siteclinic.ru/blog/technical-aspects/tz-dlya-programmista/