Написання хорошого ТЗ для розробки сайту ще та проблема, і я поділюся своїм досвідом по створенню “людино-зрозумілого” опису для замовника для розробника.

Почну з далека, не судіть строго…

Крок нуль. Замовник.

Маніпулювання.

Почнемо з першої зустрічі з замовником. Справити враження серйозної людини, з яким можна і потрібно працювати – ось Ваша основна задача – так що відкладіть Ваш улюблений костюм кольору хакі – джинси і сорочка – буде саме воно.
Місце зустрічі теж дуже важливо – Mcdonald’s – не кращий вибір – особисто я вибираю кав’ярні – тиха спокійна обстановка диспонує до продуктивної розмови. До речі – тут Вам і перший дзвіночок – якщо замовник пригощає – це добре, інакше – працюйте по передоплаті.
На цій першій зустрічі Ви повинні переконати замовника в тому, що з Вас двох саме Ви професіонал, і саме Ви знаєте чого він хоче. Беріть ініціативу на себе під час ділових зустрічей та переговорів. Не соромтеся давати підказки замовнику, наводьте приклади, але тільки такі, які Вам подобаються, і Вам вони вигідні (приміром лежить у Вас в заначці готовий сайтец). Не справа якщо замовник сяде Вам на голову – може він десь і директор, але тільки не з Вами – для Вас він просто один із багатьох.

Аналоги.

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

Гроші.

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

ТЗ.

Під час розмови записуйте важливі моменти – не сподівайтеся на пам’ять – обов’язково проколитесь. Якщо у Вас виникають питання – задавайте їх, відповіді знову ж варто записувати. По закінченню бесіди перед Вами повинен лежати чернетка ТЗ.

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

Крок перший. ТЗ.

Письменство.

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

Невеликий ліричний відступ почали шляху – імхо, вважаю що одне із найбільш правильних способів подачі інформації є графічний, тобто краще один раз побачити, ніж сто разів почути. Так що будемо малювати макети (mock-ир’и) сторінок – для цього підійде навіть MS Word (хоча звичайно краще скористатися чимось на зразок Axure RP Pro):

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

Як Ви бачите – це головна сторінка сайту, на її “малювання” у мене пішло трохи менше 5-ти хвилин, тепер можна спробувати описати словами:

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

Ух, опис звичайно – багато буків, і багато питань, макетик більш однозначний. Гаразд, поїхали далі, ближче до суті.

Для початку необхідно виділити сутності, ролі користувачів і визначити рівні доступу (буду лаконічним – наведу таблицю):

Роль/Сутність
Користувач
Оголошення
Коментарі до оголошень
Новини
Коментарі до новин
Гість

Користувач

Адміністратор

реєстрація R R,W* R R,W*
E* R,W R,W R R,W
X M M X M

Де:

  • R – читання
  • W – створення
  • E – редагування
  • X – повний доступ (створення/редагування/видалення)
  • M – модерування (редагування/видалення)
  • * – особливості реалізації відображені в документації

Тепер перед нами стоїть наступне завдання:

  • Для всіх R – створити макети сторінок
  • Для всіх W, E – описати повністю форми – тобто які поля редактируемы, і за якими правилами
  • Для всіх X, M – mock ир’и сторінок з навігацією + форми створення/редагування

Почнемо з простого – R – для оголошень:

І для новин:

Далі наведу приклад опис форми для коментарів (W):

  • Ім’я – літери кирилиці та латиниці, цифри, символ підкреслення та дефіс, обов’язкове
  • E-mail – у відповідності зі стандартом RFC-2822, обов’язкове
  • Посилання на Сайт – у відповідності зі стандартом RFC-2616
  • Текст – непорожня полі більше 3-х не пробільних символів
  • CAPTCHA – тест Тюрінга для захисту від спаму, обов’язкове

І відповідний mock up:

Як бачите – подібні макети досить інформативні, а так само готують замовника до майбутнього продукту.

Так само не забудьте приготувати шаблони листів (ось вам приклад):

Ще пригодиться діаграма прецедентів (цілком імовірно, Ви могли її намалювати ще на етапі обговорення проекту з замовником):

Проектування архітектури і БД.

Чому я включив сюди цей пункт? Все дуже просто – зі свого досвіду скажу – коли документація за проектом заходить у відділ і починається розробка архітектури та БД, то виникає дуже багато питань, про які навіть думки не виникало при прочитанні доки. У підсумку проектна команда простоює, поки менеджер, красно перед замовником, з’ясовує ці нюанси. Було б набагато логічніше бути на крок попереду, і накидати архітектуру і БД вже на цьому етапі – це 3-4 години роботи, яка зможе заощадити і час, і гроші, і нерви (звичайно архітектура в такому варіанті буде занадто сиру, але вже зможе виявити кілька підводних каменів).

Архітектуру я описувати не буду – так як в даному прикладі особливо і проектувати нічого, а low-level нам продиктує фреймворк.

А ось приблизний нарис БД це завжди будь ласка (знову ж особливо не заморочуючись на подробиці):

Крок другий. Оцінка проекту.

Про даному етапі раджу прочитати статтю “Оцінюємо проекти” (правда, я скромний?)

Висновок

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