Пример техническое задание для сайта: полное руководство + шаблон (уникальный) – Образец технического задания на разработку сайта

Мой подход к созданию ТЗ на шаблонные сайты / Habr


Вместо эпиграфа.

Поймал дед золотую рыбку. Она ему говорит:
— Чего тебе, дед?
— Хочу чтоб мой аппарат был длиной до колен.
Взяла рыбка и укоротила деду ноги.
Мораль: ставьте корректно техническое задание.

Добрый день великий и могучий Хабр.
Некоторое время назад было несколько постов о технических заданиях (Как поставить задачу для простого (шаблонного) сайта, Почему мы никогда не составляем ТЗ. А что взамен?, Правила технического задания), которые хотелось бы продолжить и рассказать про мой подход к написанию ТЗ на шаблонные сайты.

Мы делаем сайты с кастомным дизайном, никакой перекраски логотипов, в качестве основы используется фреймворк, сначала это было самописное изделие, затем перешли на CakePHP. Несмотря на то, что сайты кастомные, большинство из них очень и очень похожи по функционалу.

ТЗ мы пишем сами и никогда не просим заказчика. Мы можем его расспросить, попросить показать примеры, похожие сайты и выполнить прочие действия, которые помогут нам понять что думает и хочет заказчик, понять предметную область, а потом выразить это в тексте техзадания. В этом я солидарен с высказанным Altunik в его посте Как поставить задачу для простого (шаблонного) сайта.

Наш процесс выглядит так:

  1. Нашли заказчика, пообщались, пришли к общему пониманию, что будем делать сайт, масштаб цен озвучили.
  2. Работа по дизайну и программированию распадаются на две параллельные ветки — дизайн и программирование. На дизайн ТЗ не пишется. Я лично не представляю как вообще может быть написано ТЗ на внешний вид. Нет, можно сказать, что мол три колонки, баннер сверху и зеленый логотип, но только такое описание может включать в себя как шедевр дизайностроения так и полный отстой и соответственно огорчить заказчика. Т.е. такое ТЗ не может гарантировать, что на выходе будет что-либо хорошее, в отличие от ТЗ на программную часть, где ТЗ может дать гарантию, что мы получим то, что заказали (по крайней мере теоретически может). Делать ТЗ на дизайн, это как ТЗ на мелодию: «нота ля не более 8 раз, барабаны и что бы весело» — бред.
  3. Вторая ветвь работы — программная часть, сюда входят программирование, верстка и сопряженные с этим работы. Как правило этот процесс стартует чуть позже дизайна, когда уже есть первые макеты.
  4. Соединяем все вместе и результат выкладываем на хостинг.

На заре нашей работы над сайтами ТЗ никто не писал, а просто собирались пожелания заказчика, по ним делалась оценка сроков и денег и начиналась работа над сайтом. Должен сказать — это было не очень хорошо, т.к. заканчивалось щедрым потоком хотелок заказчика и мои попытки пресечь хотелки наталкивались на труднопреодолимые возражения типа «вы меня не так поняли» или «я об этом говорил, но вы забыли». Как результат, объем работ и сроки вырастали, мы были козлами, которые испортили все полимеры, количество заработанных денег падало и все стороны оставались недовольны.

Мои первые попытки написания ТЗ были неуклюжими, часто у меня получалось недоТЗ, наполовину написанный документ, который так никому и не показывался, но вместе с этим документом я начал каждый раз рисовать схему сайта примерно такого вида:

При всей несложности и незатратности по времени на создание такой схемы она оказалось очень полезной в качестве некой замены ТЗ.

Эта схема, согласованная с заказчиком, позволила легко отсечь ряд хотелок. Например, после демонстрации (законченного, по нашему мнению) сайта заказчику он спрашивает:

— А где карта проезда на сайте?
— Сейчас посмотрим схему сайта… Так, вот «Главная страница», вот «Новости», «О проекте»… хм, Кулверстукаса нет! А страницы «Карта проезда» и не должно было быть. Но если вы хотите, мы можем завершить работу по согласованной схеме и потом за недорого вернуться и сделать карту проезда.

Кроме этого схема позволила решить еще одну, на этот раз внутреннюю проблему. У нас достаточно часто было, что дизайнер после согласования и утверждения дизайнов прорисовывал ключевые страницы сайта, но забывал о некоторых второстепенных. Этот момент оказывался непроконтролированным, дизайны уходили в порезку, а затем к программистам, которые сообщали:
— А где порезка страницы «404»?
— А нету. Забыли…

И круг начинался снова: дизайнер дорисовывает, верстальщик нарезает, программисты натягивают, но в результате такой забывчивости терялось драгоценное время. Выход из ситуации оказался очень прост. В схему, по мере присылания дизайнером файлов, вносились имена файлов с дизайнами:

Так сразу было видно что прорисовано, а что нет, какие дизайны есть, а каких нет.

Таким образом, схема сайта имеет такие преимущества:

  • просто
  • быстро
  • четко задает набор страниц сайта, отсекая все хотелки, которые могли бы привести к изменению состава страниц, а это очень, очень большой класс хотелок

Недостаток схемы:
  • она не описывает множество других особенностей сайта и как следствие, не отсекает другие типы хотелок, влияющих на функционал, но не влияющих на состав страниц. Например, вдруг захотелось, чтоб у товара в магазине была возможность отображать не только цену, но и указывать старую и новую цену, например как тут:

Такой класс хотелок отсекается описанием сущностей, присутствующих на сайте. Например «Новость» это:

  • Название — строка длиной до 255 символов
  • Анонс — текст с анонсом новости, длина до 200 символов
  • Текст — текст новости, длина до 5000 символов
  • Дата публикации

По сути это эквивалентно описанию полей базы данных, только человеческим языком.
И если заказчик говорит «хочу, чтоб для разных типов новостей были иконки», то мы открываем утвержденное описание новости и читаем, что там написано.

Однако с таким описанием, без нормального ТЗ, одной схемой уже не обойтись и нужно садиться его писать.

Как я говорил выше в ТЗ мы не вносили ни слова о внешнем виде, отдавая это на откуп дизайнеру. В ТЗ шла только техническая часть сайта. Не скажу, что наше ТЗ было сделано по ГОСТу, но в его основу лег именно ГОСТ 19.201-78, после некоторой творческой переработки и переосмысления.

Содержание такого ТЗ имело примерно следующий вид:

СОДЕРЖАНИЕ
1. Введение
2. Основание для разработки
3. Назначение разработки
3.1. Функциональное назначение
3.2. Эксплуатационное назначение
4. Требования к программе или программному изделию
4.1. Требования к функциональным характеристикам публичной части сайта
4.1.1 Общие положения
4.1.2 Страницы сайта
4.1.2.1 Раздел «Главная страница»
4.1.2.3 Раздел «Страница с заключением и комментариями»
4.1.2.4 Разделы «Разработка концепции проекта», «Консультирование и сопровождение проектов», «Маркетинговый аудит», «Продвижение объекта на рынке», «Продажи компанией», «Управление продажами»
4.2 Требования к функциональным характеристикам приватной части сайта (админке)
4.2.1 Общие положения
4.2.2 Страница управления общими настройками
4.2.3 Страница управления разделом «Главная страница»
4.2.4 Страница управления разделом «Страница с контактами»
4.2.5 Страница управления разделом «Страница с комментариями»
4.2.5 Страница управления разделами «Разработка концепции проекта», «Консультирование и сопровождение проектов», «Маркетинговый аудит», «Продвижение объекта на рынке», «Продажи компанией», «Управление продажами»
4.2.6 Страница управления разделом «Заключения»
4.4. Условия эксплуатации
4.5. Требования к составу и параметрам технических средств и программного обеспечения
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению
5. Наполнение сайта
6. Порядок контроля и приёмки

Несмотря на то, что это не идеальное ТЗ и в нем можно было найти дырки, неоднозначные трактовки и недосказанные места оно позволило свести к приемлемому уровню все спорные вопросы, так что и заказчик и исполнитель оставались довольны. И если и возникали хотелки, их было не много и такие, что быстрее было сделать чем спорить. В результате заказчик доволен, а нам обеспечен крепкий сон и хороший аппетит.

Однако оказалось, что с ТЗ есть другая проблема. Написание ТЗ — скучное занятие, которое как и тяжелый физический труд на свежем воздухе скотинит человека.

Лично меня написание ТЗ очень утомляет. Во-первых — это скучный сухой текст. Во-вторых — все ТЗ похожи друг на друга и как правило имеют не так много отличий, никакого тебе творчества. Но эти отличия, как на зло, не позволяют использовать одно и тоже задание в разных проектах. В-третьих — пишется ТЗ, когда ты для себя уже всё понял о будущем сайте, а когда ты всё понял, почему-то писать это не очень-то хочется.

Как я говорил, с одной стороны все ТЗ одинаковые, а с другой все разные. Вроде и пишешь одно и то же, но и просто скопировать не выходит. Напрашивается решение сделать некий генератор техзаданий. Изучение интернета на предмет генераторов ТЗ показало, что вменяемого решения нет, по крайней мере я не обнаружил такового.

Мириться с таким положением дел я совершенно не хотел и решил сделать свой

велогенератор. Как известно, когда перед программистом стоит задача на один час, он тратит этот час на написание программы, которая решит задачу за одну секунду. По этому пути пошел и я и начал потихоньку делать веб-сервис для веб-разработчиков, но в первую очередь для себя лично.

Итак, я хотел редактор схемы сайта, который позволял бы оперативно рисовать схему сайта прямо в браузере, и желательно чтоб была возможность подключать заготовленные куски для типовых частей. Например «Новости» есть почти на всех сайтах, и они мало чем различаются между собой: глупо каждый раз рисовать под них схему. А надо так: сказал, что тут в схеме новости и все сопутствующие страницы добавились в схему за один раз. Сами. Без посторонней помощи.

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

Естественно хотелось то, ради чего всё затевалось — техзадание.

Хотелось еще много чего…

То, что у меня получилось проще показать, чем объяснять словами.
Вот трехминутный ролик, который коротко демонстрирует то, что у меня получилось.

Конечно, все особенности работы в обзорном ролике я передать не могу, поэтому если будет интерес— могу пояснить в комментариях, либо сделать еще пост или даже несколько, т.к. тема достаточно обширная.

Должен также отметить, что сервис еще не готов для массового использования и находится в режиме тестирования. Поэтому регистрация по приглашениям. Если есть желающие с устойчивой психикой потестировать проект— милости прошу за инвайтами.

Надеюсь, вам будет полезен и мой опыт, и мой сервис.

UPD. Если вы не пользователь хабра, и хотите инвайт, на сайте есть форма обратной связи.
UPD2. Прямая ссылка на сервис. azalo.net

Пример техзадания на сайт. Сэкономит время и нервы / НеВсем corporate blog / Habr

Сайт – всегда компромисс между разработчиком и владельцем, каждый из которых – профессионал в своей области.

Точек зрения на то, каким должен быть сайт, много: у программиста одна, у дизайнера – другая, у интернет-маркетолога – третья, у владельца…

На самом деле, точка зрения – всего одна – у конечного пользователя ресурса. И именно это в первую очередь нужно учитывать. Естественно, принимая во внимание удобство обслуживания сайта администратором.

В чем преимущества грамотно написанного технического задания:

  • однозначное понимание всеми участниками проекта того, как и что должно работать
  • экономия времени на разработке и всяческих уточнениях
  • возможность еще до начала работы оценить сложность проекта и продумать тонкие моменты
  • возможность после завершения работы отследить, все ли было сделано так, как задумывалось
  • возможность рассчитать окончательную стоимость проекта до начала работы
  • возможность распределить ответственности обеих сторон

Пример концепции сайта: narod.ru/disk/7515328001/konc_orbita.doc.html (doc, 3,5МБ)

Что включает приведенный файл примера концепции сайта одной из региональных компаний (кусок, который может самостоятельно сделать будущий владелец сайта):
1. Анализ целевой аудитории.
2. Потребность ЦА в определенных материалах.
3. Действия, которые должны совершить на сайте посетители.

Исходя из п.1-3 мы понимаем, какой должна быть структура сайта, какими должны быть тексты, и расположение элементов навигации.

4. Продуманные тексты для страниц сайта.
5. Отрисованные шаблоны страниц (не дизайн, но уже руководство к действию для дизайнера) с написанными текстами.
6. Текстовые пояснения к лайаутам страниц.
7. Краткий анализ статистики посещений старой версии сайта.
8. Основные требования к админке сайта.

Что не включает:
1. Вопросы оптимизации сайта.
2. Вопросы привлечения аудитории.
3. Требования к дизайну.
4. Требования к хостингу.
5. Аудит старой версии сайта и сайтов конкурентов.

По сути, это даже не часть ТЗ, а кусок общей концепции одного из сайтов, который мы продумывали совместно с заказчиком. Она написана в свободной форме и служит в качестве основного документа, необходимого для понимания того, как должен работать ресурс.

В итоге по техническому заданию, которое было написано на основе этой концепции, одна из студий нашего города сделала сайт. Некоторые моменты заказчик и исполнитель пересмотрели в процессе работы.
Очень интересно ваше мнение по содержанию документа.

Если есть подобные примеры, поделитесь!

Пример Технического задания на создание сайта


2. Название сайта.
Сайт Компании ООО "Канцелярские товары". Далее - Фирма.

3. Назначение сайта (цель создания сайта).

3.1. Представление Фирмы в Интернет: информация о Фирме, история фирмы, режим работы, цены на товары, справочная информация, сопроводительные графические рисунки, юридический адрес, почтовый адрес, схема проезда, контактная информация.

3.2. Обеспечение возможности доступа к информации о товарах и услугах, предлагаемых фирмой, всем заинтересованным лицам, вне зависимости от их местонахождения.

3.3. Увеличение объёма и расширение региона сбыта имеющихся товаров.

4. Язык сайта.
Русский.

5. Объём и состав текстовой информации.
Согласно Приложению 1.

6. Основные ключевые слова, которые наиболее точно отражают суть предлагаемых товаров и услуг.
Согласно Приложению 1.

Примечание.

Перечень ключевых слов для веб-дизайнера носит справочный характер и не входит в число обязательных параметров, подлежащих проверке при приемке сайта.

Занимаемые сайтом позиции в рейтингах, каталогах и поисковых системах не оговариваются.

7. Объём и состав графической информации.
Согласно Приложению 2.

8. Объём и состав текстовой и графической информации в электронном виде.
Согласно Приложению 3.

9. Предполагаемая возрастная аудитория сайта.
От 18 лет и старше.

9.1. Предполагаемое возрастное ядро аудитории от 18 до 45 лет.
9.2. Данная информация носит рекомендательный характер. Цифровые показатели контролю и проверке при приёмке сайта не подлежат.

10. Количество страниц сайта.
Сайт должен содержать следующие обязательные html страницы: 1 - Главная (домашняя) страница; 2 - О фирме; 3 - 50 - Перечень товаров и услуг, предлагаемых фирмой ;  51 - 60 - Прайс-лист; 61 - схема проезда; 62 - Предварительный заказ товара и услуги; 63 - Типовой договор; 64 - Вопросы и ответы; 65 - Новости; 66 - 68 - Справочная информация; 69 - Содержание.

Количество html страниц сайта определяется веб-дизайнером самостоятельно, исходя из объёма представленных материалов согласно Приложению 3.

11. Кнопки управления (навигация сайта).
Определяются веб-дизайнером самостоятельно.

С каждой страницы сайта должен быть обеспечен переход (установлена гиперссылка) на главную страницу сайта. Сайт должен содержать страницу "Содержание" (карта сайта).

12. Блок схема сайта.
Определяется веб-дизайнером самостоятельно.

Головная (начальная) страница сайта должна содержать гиперссылки, обеспечивающие переход с нее на не менее чем 95% страниц сайта, но не более чем 200 гиперссылок.

13. Объём сайта, Мб.
Не оговаривается.

14. Оформление рисунков.
Все рисунки объемом более 1 Кб должны быть выполнены с замещающим текстом. Рисунки размером более 12 Кб должны быть выполнены с предпросмотром. Формат всех рисунков gif или jpg (jpeg).

15. Пропускная способность линии связи.
Среднее время загрузки страниц не должно превышать 35 секунд при скорости соединения 28.8 Кбит/сек. Допускается увеличение времени загрузки отдельных страниц до 50 секунд, но не более чем на 20% числа страниц сайта. Головная (начальная) страница должна иметь время загрузки не более 55 секунд.

Примечание:
Во всех случаях не учитывается время загрузки подгружаемых элементов (счетчики, баннеры, информеры и т.д.).

16. Основной диапазон разрешения мониторов, на которых будет просматриваться сайт.
От 600х800 до 1240х1024 пикселей (от 15" ЭЛТ до 19" ЭЛТ или 17" LCD).

Основное разрешение, на которое оптимизируется сайт: 1024х768 пикселей (17" ЭЛТ или 15" LCD).

17. Минимальное разрешение монитора, в котором будет просматриваться сайт.
600 х 800 пикселей (15" ЭЛТ).

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

18. Основной браузер, которым будет просматриваться сайт, и его минимальная версия.
Mozilla Firefox, Opera, IE 6.0 и выше.

19. Цветовая палитра.
Основной режим мониторов, на которых будет просматриваться сайт: 15 разрядов цветов и выше (число цветов 65536 и выше).

При разработке сайта должен быть обеспечена возможность его просмотра при использовании безопасной цветовой палитры (разрядность цветов 8). Изменения оттенков цветов, при просмотре сайта с использованием безопасной цветовой палитры, не оговариваются.

20. Общий фон сайта.
a) Общий фон сайта светлый (белый). Допускается использование светлого фонового рисунка.
б) Общий фон сайта темный (с указанием примерного, или точного по SMYK цвета).

Оптимизация изображений сайта - подгонка фонов рисунка под цвет фона оговаривается отдельно

21. Размер и вид шрифта сайта.
Размер шрифта сайта для оформления текста - 10. Размер шрифта для оформления заголовков, названия страниц и т.д. не оговаривается. Вид (название) шрифта не оговаривается.

22. Регистрация сайта в каталогах, рейтингах, топах и пр.
Оговаривается дополнительно.

23. Проведение рекламной кампании по раскрутке сайта.
Раскрутка сайта определяется отдельным ТЗ. В настоящем ТЗ раскрутка сайта не оговаривается и не входит в состав выполняемых работ (услуг).

24. Срок разработки сайта.
Четыре недели с момента оплаты 50% от оговоренной суммы.

25. Порядок передачи сайта.
Веб-дизайнер передает доступ в админку сайта, с правами администратора,  а также логин, пароль и название (код передачи данных) по протоколу ftp.

Заказчик обязан проверить наличие грамматических, орфографических и смысловых ошибок на сайте в течение трёх рабочих дней. Обнаруженные ошибки веб-дизайнер обязан устранить в течение трёх рабочих дней.

26. Сопровождение сайта.
Сопровождение сайта определяется отдельным ТЗ. В настоящем ТЗ сопровождение сайта не оговаривается и не входит в состав выполняемых работ (услуг).

27. Дополнительные условия.
Каждая страница сайта должна содержать логотип и название Фирмы.
Внизу на каждой странице сайта должна быть указана контактная информация.

Сайт должен содержать не менее трёх счетчиков подсчета посетителей. Счётчики устанавливаются на каждой странице сайта.

Приложение:
1. Текстовая информация на 150л.
2. Графическая информация на 450л.
3. Текстовая (формат Word) и графическая информация (формат jpeg и gif), представленные в Приложении 1 и 2 на CD ROM.

Примечание:

1. Названия и имена вымышленные. Любые совпадения случайны.
2. Задание на сайт может быть изменено с учетом конкретных требований.
3. Задание на сайт предназначено для русскоязычных сайтов, объемом не более 100 html страниц. Если сайт имеет версию на иностранном языке или версию для просмотра на мобильных устройствах, задание на сайт должно быть дополнено соответствующими пунктами.
4. Веб-дизайнер не несет ответственности за несоответствие сайта эстетическим ожиданиям заказчика при условии выполнения технического задания на сайт.
8. При наличии всего контента сайта, техническое задание на сайт мы можем оперативно согласовать в вашем присутствии. Контент - первооснова для определения того, каким будет сайт: количество html страниц, структура, компоновка, система навигации и т.д.

 

Как правильно составить техническое задание на разработку сайта

В современном мире очень важно оправдывать надежды клиента, когда выполняешь для него услугу. Иначе чревато скандалом и плохой репутацией. Особенно это касается технического задания на создание сайтов. Если человек хотел создать форум собаководов, а получил сайт для цветоводов. Разработчик в этом случае потратил время впустую, не угадив требованиям.

ТЗ на создание сайта

Для профессиональных разработчиков не секрет, как выглядит ТЗ на создание сайта. Но обычным обывателям это тайна покрытая мраком. Любое ТЗ начинается с того, что выбирается конечная цель. Например, сайт посвященный торговле, блог и т.д. Далее выбирается дизайн согласно цели сайта.

Оценивая всё на начальном этапе, решается то, что сайт должен делать внутри. Какую информацию и когда показывать, когда её сохранять, регистрация клиентов на сайте, что показывать незарегистрированному клиенту и многое другое. Так же рассматривается вопрос о том, что ухудшает поведенческие факторы на сайте и как это скорректировать.

Только после этого можно начать разрабатывать ТЗ. Клиенту требуется четко описать то, как он хочет видеть свой будущий сайт. После чего изменять ничего нельзя. Исполнителю иногда дается воля в исполнении работы, но это всё за отдельную плату. Если заказчик хочет сэкономить, то ему потребуется самому сделать начальный макет, по итогам которого и будет создано ТЗ.

Техническое задание на создание сайта: пример

Вообще, примеров технических заданий на создание сайта, на данный момент, очень много в Интернет-ресурсах. Для того, чтобы оказать комплекс услуг по разработке креативной платформы бренда, коммуникационной стратегии, нейминга объекта, айдентики, рендеров и сайта объекта заключается договор между клиентом и исполнителем.

После чего ставится четкая задача. Например, создание реалистичных изображений (рендеров) объекта, сайта объекта. Многие бизнес идеи для мужчин, производство которых основывается в интернете, заказывают ТЗ.

Исполнитель разрабатывает креативную концепцию фирменного стиля. Сюда входит название для объекта, логотип, логобук и дизайн. Конечно, он предоставляет не по одному варианту, а сразу несколько, чтобы можно было выбрать то, что нравится больше.

Далее идет дизайн брошюры проекта, включая копирайтинг, изображения из фотобанка. Разрабатывается дизайн-макет брошюры с учетом фирменного стиля и согласно креативной концепции. Брошюру готовят в печать. Текст пишет исполнитель на основе переданных заказчиком исходных материалов (драфта). Окончательно согласовывается сторонами после утверждения рекламной концепции, отобранных изображений проекта, исходя из дизайна буклета.

После этого создают прототип сайта. Исполнитель разрабатывает сайт на основании утвержденной дизайн-концепции, адаптивной верстки, обеспечивающей корректную работу сайта на всех компьютерных и мобильных устройствах.

Потом он предоставляет заказчику полную резервную копию рабочей версии сайта, при этом запускает сайт на сервере собственными силами. Полезно будет сразу узнать, сколько стоит Яндекс Директ, для того чтобы сразу занять лидирующую позицию в поисковой оптимизации.

ТЗ на создание интернет-магазина: пример

Пример ТЗ на создание интернет-магазина по сути не отличается от того, что мы упомянули выше. Однако, создать его немного сложнее. Поскольку потребуется создать раздел с новинками, акциями, хитами продаж и распродажи.

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

Система управления контентом должна иметь стандартный для Windows интерфейс, отвечающий следующим требованиям:

реализация в графическом оконном режиме;
единый стиль оформления;
интуитивно понятное назначение элементов интерфейса;
отображение на экране только тех возможностей, которые доступны конкретному пользователю;
диалог с пользователем должен быть оптимизирован для выполнения типовых и часто используемых операций и т.д.

Типовые страницы могут изменяться, редактироваться или дополняться в административной части сайта. Исполнителя также просят заниматься настройкой и ведением контекстной рекламы, если это не противоречит заключенному договору.

Делать техническое задание на создание сайта очень кропотливый и трудоёмкий процесс. Поэтому следует запастись терпением и следовать уже имеющимся методикам. А что Вы думаете по этому поводу?

ТЗ для web-разработчика / Habr


Написание хорошего ТЗ для разработки сайта еще та проблема, и я поделюсь своим опытом по созданию «человеко-понятного» описания для заказчика для разработчика.

Начну из далека, не судите строго (все картинки кликабельны)…

Шаг ноль. Заказчик.


Манипулирование.

Начнем с первой встречи с заказчиком. Произвести впечатление серьезного человека, с которым можно и нужно работать — вот Ваша основная задача — так что отложите Ваш любимый костюм цвета хаки — джинсы и рубашечка — будет самое оно.
Место встречи тоже очень важно — MacDonalds — не лучший выбор — лично я выбираю кофейни — тихая спокойная обстановка распологает к продуктивной беседе. Кстати — тут Вам и первый звоночек — если заказчик угощает — это хорошо, иначе — работайте по предоплате.
На этой первой встречи Вы должны убедить заказчика в том, что из Вас двоих именно Вы профессионал, и именно Вы знаете чего он хочет. Берите инициативу на себя во время деловых встреч и переговоров. Не стесняйтесь давать подсказки заказчику, приводите примеры, но только такие какие Вам нравятся, и Вам они выгодны (к примеру лежит у Вас в заначке готовый сайтец). Не дело если заказчик сядет Вам на голову — может он где-то и директор, но только не с Вами — для Вас он просто один из многих.

Аналоги.

Добейтесь от заказчика аналогов его детища (я сильно сомневаюсь в уникальности идеи, такие встречаются крайне редко), так вы быстрее поймете суть того чего от вас добиваются. Очень хорошо если у Вас есть ноут с доступом в и-нет, и Вы сможете все сразу посмотреть. (раскошельтесь на PCMCIA GSM модем — это производит впечатление).

Деньги.

Тут нужно быть очень внимательным — Вы должны точно понять и уяснить каким образом проект будет зарабатывать (пусть и в перспективе). Понятно, что на сайты-визитки это не распространяется.

ТЗ.


Во время разговора записывайте важные моменты — не надейтесь на память — обязательно проколитесь. Если у Вас возникают вопросы — задавайте их, ответы опять же стоит записывать. По окончанию беседы перед Вами должен лежать черновик ТЗ.

А теперь наступает самый трудный момент — Вы должны убедить заказчика в том, что именно Вы пишите ТЗ, и он за него должен заплатить. Если таковое не получилось — пришлите ему образец — пусть помучается, в итоге, если он ценит своё время — он таки согласиться на Ваши услуги.

Шаг первый. ТЗ.


Писательство.

Перед началом работы над ТЗ Вы должны твердо уяснить для себя — данный документ должен трактоваться однозначно не только Вами и заказчиком, но и любым другим разработчиком, и это достаточно сложная задача.

Небольшое лирическое отступление в начали пути — имхо, считаю что одно из самых правильных способов подачи информации есть графический, т.е. лучше один раз увидеть, чем сто раз услышать. Так что будем рисовать макеты (mock-up'ы) страниц — для этого подойдет даже 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 up'ы страниц с навигацией + формы создания/редактирования

Начнем с простого — R — для объявлений:

И для новостей:

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

  • Имя – буквы кирилицы и латиницы, цифры, символ подчеркивания и дефис, обязательное
  • E-mail — в соответствии со стандартом RFC-2822, обязательное
  • Ссылка на Сайт — в соответствии со стандартом RFC-2616
  • Текст – непустое поле больше 3-х не пробельных символов
  • CAPTCHA — тест Тьюринга для защиты от спама, обязательное

И соответствующий mock up:

Как видите — подобные макеты достаточно информативны, а так же подготавливают заказчика к будущему продукту.

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

Еще пригодится диаграмма прецедентов (вполне вероятно, Вы могли её нарисовать еще на этапе обсуждения проекта с заказчиком):

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

Почему я включил сюда этот пункт? Всё очень просто — по своему опыту скажу — когда документация по проекту заходит в отдел и начинается разработка архитектуры и БД, то возникает очень много вопросов, о которых даже мысли не возникало при прочтении доки. В итоге проектная команда простаивает, пока менеджер, краснее перед заказчиком, выясняет эти нюансы. Было бы намного логичнее быть на шаг впереди, и набросать архитектуру и БД уже на этом этапе — это часа 3-4 работы, которая сможет сэкономить и время, и деньги, и нервы (конечно архитектура в таком варианте будет слишком сыра, но уже сможет выявить несколько подводных камней).

Архитектуру я описывать не буду — так как в данном примере особо и проектировать нечего, а low-level нам продиктует фреймворк.

А вот приблизительный набросок БД это всегда пожалуйста (опять же особо не заморачиваясь на подробности):

Шаг второй. Оценка проекта.

О данном этапе советую прочитать статью "Оцениваем проекты"

Вывод

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

Таки кросс-пост: ТЗ для web-разработчика

Полезное и Краткое ТЗ на создание сайта

Полезное Краткое ТЗ - стоит использовать если вам необходимо создания сайта визитки или несложного корпоративного сайта. Подходит для запроса стоимости создания сайта у веб-студии.

Такое ТЗ не подходит для сложных проектов и не всегда подходит для интернет магазинов.

Пример ТЗ для сайта визитки

О нас: ТОВ "Название компании".
Мы предоставляем услуги бухгалтерского аутсорса.
Нам нужен простой сайт для нашей компании.
Нравится сайт http://www.profaspect.com.ua

Основные разделы сайта
- О нас
- Новости
- Услуги
- Ведение бухгалтерского учета
- Восстановление бухгалтерского учета
- Контакты

Дополнительно надо
- Форма обратной связи
- Счетчик посещений

Скачать образец Полезного и Краткого ТЗ для сайта для заполнения.

Разбираем ТЗ подробно

Вид деятельности - очень важно указать чем занимается компания. Вид деятельности очень сильно влияет на структуру сайта и его дизайнерское оформление.

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

Пример сайта - желательно. Дизайнеру понятно, на что ориентироваться в разработке дизайна сайта. Понятна примерная сложность, тематика и атмосфера будущего решения.

Основные разделы сайта - это очень важная часть ТЗ. Обязательно указывайте не только основные разделы, но и подразделы, как в нашем примере технического задания. Это самый важный раздел нашего ТЗ.

Дополнительная информация - вы перечисляете все дополнительные возможности, которые должны быть на сайте.

Для несложных сайтов такого технического задания вполне достаточно, чтобы оценить стоимость работы, сроки и обсуждать проект уже по сути.

Техническое задание на сайт - это необязательно сложный и объемный документ. Вам необходимо четко сформулировать задачу и описать исходные данные для работы. Задание помещается на одну страницу, написание занимает от силы 30 минут.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *