Написання хорошого ТЗ для розробки сайту ще та проблема, і я поділюся своїм досвідом по створенню “людино-зрозумілого” опису для замовника для розробника.
Почну з далека, не судіть строго…
Крок нуль. Замовник.
Маніпулювання.
Почнемо з першої зустрічі з замовником. Справити враження серйозної людини, з яким можна і потрібно працювати – ось Ваша основна задача – так що відкладіть Ваш улюблений костюм кольору хакі – джинси і сорочка – буде саме воно.
Місце зустрічі теж дуже важливо – 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 нам продиктує фреймворк.
А ось приблизний нарис БД це завжди будь ласка (знову ж особливо не заморочуючись на подробиці):
Крок другий. Оцінка проекту.
Про даному етапі раджу прочитати статтю “Оцінюємо проекти” (правда, я скромний?)
Висновок
Я дуже сподіваюся, що дана стаття допоможе Вам уникнути помилок на першому етапі проекту, найчастіше саме непорозуміння розробником ТЗ за проектом веде до збільшення вартості розробки, затягування строків, а так само до більш серйозних наслідків…
