Що таке гарне тз на сайт cms magazine

Навіщо складати технічне завдання (ТЗ) на сайт?
Яку б методику розробки ви не використали, і якого б розміру не був ваш сайт, ви в будь-якому випадку зіткнетеся з питанням: "А коли ми будемо закінчувати роботу, то як ми зрозуміємо, що ми її дійсно закінчили?" У розробці як ПО. так і будь-якого сайту часта проблема - ніхто не бачить кінцевої точки. З одного боку можна сказати, що кінцевим баченням проекту повинен володіти проектний менеджер. Але якщо кінцевий продукт співпаде з образом менеджера, але не співпаде з очікуваннями клієнта? А якщо за час проекту змінюється 3 менеджера?

Слідство закону Паркінсона "дев'яносто-дев'яносто":
Перші 90% коду віднімають 90% часу розробки. Решта 10% коду віднімають другі 90% часу розробки.
З книги А.Купера "Психбольница в руках пацієнтів".

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

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

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

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

По суті, товщина документів залежить від складності процесу в більшій мірі, ніж від розмірів проекту.

Ми будемо слідувати самому складному шляху.

ТЗ відповідає на питання

ТЗ спочатку створюється для декількох учасників розробки:

Розробники проекту (дизайнери і програмісти).
Проект менеджер.
Клієнт.
Бюрократи (вони можуть не брати участь в проекті, але на них теж треба розраховувати).

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

Для кого створюється сайт і для чого?

Як будуть вирішені завдання замовника і користувачів?

Як буде проходити створення проекту?

Що буде прийматися на виході?

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

Що потрібно для подальшого запуску проекту?

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

З чого складається ТЗ

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

Загальна інформація

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

Загальна інформація включає в себе:

Ця інформація збирається в рамки проекту.

рамки проекту

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

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

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

Інформаційна архітектура і інтерфейс

Для опису ІА потрібно описувати зверху вниз:

Структуру сайту. Це так звані високорівневі прототипи.
Шаблони сторінок. Низькорівневі прототипи, що описують безпосередньо інтерфейс сайту.
Опис контенту. Табличне опис змісту кожної сторінки сайту.

структура сайту

Карта сайту виконується графічним способом в одній з відомих нотацій: Visio або Garrett. Я раджу саме малювати карту сайту, тому що в цьому випадку отримана структура виходить найбільш наочною і зручною в подальшому використанні. З одного боку може здатися, що у вигляді списку написати карту сайту буде куди простіше, але коли ви самі задумаєтеся над зв'язками різних областей сайту між собою, ви волею неволею почнете чиркати квадратики на папері.

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

Не забувайте привласнювати номер кожної окремої сторінці карти сайту. Це потрібно на етапі опису контенту.

Корисні поради при малюванні карти сайту:

Не шкодуйте місця. Намагайтеся розташовувати блоки так, щоб вони були відокремлені один від одного. Це допоможе Новомосковскбельності карти.
Чи не дрібнити. Прочитати текст, надрукований 4 кеглем, в принципі можна, але це вже причина для ненависті.
Вирівнюйте "квадратики" сторінок відносно один одного, вибудовуючи в лінії. Це поліпшить сприйняття рівнів вкладеності сторінок.
Чи не перетинайте лінії. Намагайтеся уникати великої кількості перетинів ліній зв'язків. Якщо вони перетинаються, то повинні "перескакувати" одна над іншою. Хто займався кресленням функціональних схем в університеті, мене зрозуміє.
Підписуйте карту. Підпишіть саму карту, а також окремі блоки. Це дозволить менше плутатися в подальшому.
Частіше зберігайте файл. Банально, але треба просто пам'ятати про це. Не варто зайвий раз згадувати родичів розробників програми Visio, по суті, вони ні в чому не винні.

Приклад карти сайту.

Карту сайту я зазвичай ставлю в розділ "Додатки". Як правило, вона на стільки велика, що помістити її посередині ТЗ стає не реально.

шаблони сторінок

На рівні карти сайту кожна сторінка представляє для нас тільки "квадратик" на аркуші паперу. Для дизайнера, верстальника і програміста цього недостатньо, щоб розробити сайт. Треба ще знати наявність і розташування блоків інформації і функцій на сторінках сайту. Тому ми переходимо до шаблонів сайту. В ідеалі кожен квадратик повинен бути деталізований до схеми кожної окремої сторінки. Це прототипирование сайту. Використання прототипирования залежить від прийнятої схеми роботи в компанії-розробника, але варто визнати, що це стає для замовника вкрай недешево.

Для спрощення виділяють ряд шаблонів інтерфейсу сайту, які описуються слідом за картою сайту.

Опис шаблонів складається з 3х частин:

Перелік шаблонів. Виявляються основні типи сторінок і описується їх використання.
Типовий шаблон. Основні блоки. Описуються основні блоки сторінок з метою зменшити повторюваність інформації.
Опис кожного шаблону згідно переліку. Шаблони отрісовиваємих в будь-якому графічному пакеті (Adobe Illustrator, Adobe InDesign, MS Visio і ін.), А потім доповнюються коротким описом.

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

Приклад розвороту з ТЗ з описом шаблону інтерфейсу (вайрфрейма).

опис контенту

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

Хороший опис контенту заставу спланованої роботи на етапі запуску сайту та внесення інформації.

функціонал

Опис функціоналу сайту в технічному завданні один із ключових розділів. Особливо це стосується сайтів з великим відсотком програмних робіт: електронна комерція, онлайн-сервіси і т.п.

Хороший приклад опису функціоналу дає ГОСТ. Рекомендую триматися стандарту при описі функціонала розроблювального в рамках сайту програм. Повинні бути описані: загальна система, загальні функціональності підсистем і модулів, взаємозв'язок підсистем і модулів між собою і, нарешті, перерахування всіх функцій модулів з більш-менш докладним описом їх роботи. Для кожного модуля повинні бути розписані об'єкти, які створюються або використовуються в роботі програми.

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

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

вимоги

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

Технічні вимоги до системи;
Вимоги до персоналу;
Вимоги до надійності;
Вимоги до ергономіки та технічної естетики;
Вимоги до захисту інформації від несанкціонованого доступу;
Вимоги щодо збереження інформації при аваріях;
Вимоги до видів забезпечення;
Вимоги до програмних засобів;
Вимоги до інформаційного забезпечення;
Вимоги до технічних засобів;

Може бути також ряд специфічних вимог.

Всі вимоги необхідно чітко формулювати і намагатися не забути нічого з аспектів розробки вашого проекту.

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

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

Що далі?

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

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

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

У сухому залишку

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

Сподіваюся, що інформація буде корисна широкому колу Новомосковсктелей.