Советы по созданию ТЗ на разработку сайта
Очень часто бывало так, что ко мне обращался потенциальный заказчик и хотел услышать от меня оценку какого-то проекта (сроки и стоимость), но при этом ТЗ у заказчика не было. Обычно такая ситуация складывается по разным причинам и в данном посте я хотел бы поделиться некоторыми простыми советами, которые помогут заказчику, даже далекому от ИТ области написать вполне пригодное для оценки ТЗ.
Немного лирики
1. Первое и самое главное, что необходимо понять — ТЗ необходимо для любого проекта, который сложнее сайта визитки. ТЗ это как архитектурный проект дома, без него вам никто вразумительно смету не посчитает и нормальный дом не построит.
2. Еще одно немаловажное замечание — показать аналог сайта, который вы хотите сделать не значит предоставить ТЗ и не значит, что разработчик сможет оценить сложность проекта. В сложных системах больше половины функционала может быть скрыто от обычного пользователя в том же административном интерфейсе, а даже если это не так, то предоставленный сайт нужно детально изучить, чем бесплатно заниматься вряд-ли кто-то будет. Скорее всего в таком случае вам просто назовут цену и сроки с потолка, естественно порядком завышенные.
Теперь непосредственно к советам
3. Разбейте ваше ТЗ на блоки функциональные блоки или модули. Например, модуль по управлению пользователями это один блок, модуль для добавления товаров другой, а для отображения этих товаров пользователям (с поиском или без) третий. Вам совершенно не нужны глубокие познания в ИТ области для того, чтобы это сделать.
4. Разбейте каждый модуль на страницы. Например, модуль для управления пользователями будет состоять как минимум из трех страницы: страница со списком пользователей, страница для добавления и страница для редактирования пользователей. В некоторых случаях последние две страницы можно будет объединить в одну.
5. Определитесь со списком основных блоков каждой страницы модуля, их расположением и назначением. Например, на странице со списком пользователей будет располагаться естественно сам список, который может быть оформлен в виде таблицы и форма для фильтрации данного списка, а на странице редактирования соответственно форма для редактирования. Полезно будет указать, если блоки должны изменяться без перезагрузки страницы, например обновление списка пользователей в зависимости от параметров фильтрации или сохранение данных пользователя через форму.
6. Составьте список основных сущностей, их атрибутов и связей между ними. Например, сущность «пользователь» может иметь следующие стандартные атрибуты: логин, пароль, ФИО и email. Этот список поможет разработчику лучше понять и прикинуть как будет работать ваша система.
7. Укажите полный список систем оплат, которые хотите внедрить в своем проекте.
8. Укажите полный список социальных сетей, через которые хотите иметь возможность для авторизации пользователей.
9. Не обязательный, но желательный пункт, это предоставление набросков интерфейса страниц. Это можно сделать даже нарисовав их от руки и отсканировав или сфотографировав получившиеся наброски, но намного проще и аккуратнее будет сделать это в каком-нибудь из множества онлайн сервисов, например: или .
Немного лирики
1. Первое и самое главное, что необходимо понять — ТЗ необходимо для любого проекта, который сложнее сайта визитки. ТЗ это как архитектурный проект дома, без него вам никто вразумительно смету не посчитает и нормальный дом не построит.
2. Еще одно немаловажное замечание — показать аналог сайта, который вы хотите сделать не значит предоставить ТЗ и не значит, что разработчик сможет оценить сложность проекта. В сложных системах больше половины функционала может быть скрыто от обычного пользователя в том же административном интерфейсе, а даже если это не так, то предоставленный сайт нужно детально изучить, чем бесплатно заниматься вряд-ли кто-то будет. Скорее всего в таком случае вам просто назовут цену и сроки с потолка, естественно порядком завышенные.
Теперь непосредственно к советам
3. Разбейте ваше ТЗ на блоки функциональные блоки или модули. Например, модуль по управлению пользователями это один блок, модуль для добавления товаров другой, а для отображения этих товаров пользователям (с поиском или без) третий. Вам совершенно не нужны глубокие познания в ИТ области для того, чтобы это сделать.
4. Разбейте каждый модуль на страницы. Например, модуль для управления пользователями будет состоять как минимум из трех страницы: страница со списком пользователей, страница для добавления и страница для редактирования пользователей. В некоторых случаях последние две страницы можно будет объединить в одну.
5. Определитесь со списком основных блоков каждой страницы модуля, их расположением и назначением. Например, на странице со списком пользователей будет располагаться естественно сам список, который может быть оформлен в виде таблицы и форма для фильтрации данного списка, а на странице редактирования соответственно форма для редактирования. Полезно будет указать, если блоки должны изменяться без перезагрузки страницы, например обновление списка пользователей в зависимости от параметров фильтрации или сохранение данных пользователя через форму.
6. Составьте список основных сущностей, их атрибутов и связей между ними. Например, сущность «пользователь» может иметь следующие стандартные атрибуты: логин, пароль, ФИО и email. Этот список поможет разработчику лучше понять и прикинуть как будет работать ваша система.
7. Укажите полный список систем оплат, которые хотите внедрить в своем проекте.
8. Укажите полный список социальных сетей, через которые хотите иметь возможность для авторизации пользователей.
9. Не обязательный, но желательный пункт, это предоставление набросков интерфейса страниц. Это можно сделать даже нарисовав их от руки и отсканировав или сфотографировав получившиеся наброски, но намного проще и аккуратнее будет сделать это в каком-нибудь из множества онлайн сервисов, например: или .