Как написать тз на разработку сайта


Техническое задание на сайт / Хабр

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:


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

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

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

И вот здесь возникает конфликт, где каждая из сторон права: заказчик не получил то, что ожидал за оговоренную цену, его пытаются «прокидать»; исполнитель же считает, что сделал все в точности с заказом, а остальные «хотелки» — это попытка «прокидать» его. Этот конфликт может решиться по-разному: либо заказчик примет, то что есть, либо разработчик доделает все бесплатно, либо обе стороны пойдут на взаимные уступки. Но в любом случае, будут пострадавшие.

Так вот, задача технического задания — это свести к минимуму разницу между представлениями двух строн: заказчика и исполнителя. Хорошее ТЗ дает маленький diff, плохое ТЗ — большой.

Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.

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

Если рассматривать две крайности, когда тех. задания просто нет, нет совсем, т.е. вообще, и мы сделали фотохостинг, а заказчик желал интернет-магазин, то diff будет равен всему проекту, и его стоимость будет равна стоимости проекта (придется выкинуть наш фотохостинг и сделать магазин). При этом стоимость ТЗ равна нулю. Другая крайность, это когда техническое задание и есть сам реализованный проект, т.е. оно детализировано полностью, т.е. до строк кода, переменных и стилей css. В этом случае diff равен нулю, а стоимость ТЗ равна стоимости проекта (т.к. ТЗ уже является реализацией). А между этими крайностями находится реальность, которая отражена на этом графике:

Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

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

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

2. Что в нем должно быть и чего нет. Формулировки

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

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

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

Вообще, ТЗ надо писать так, как будто вы с заказчиком не сошлись во мнениях и ваш спор будут разбирать в суде, основываясь на тексте тех. задания. А у вас в ТЗ написано «сделать дизайн, который понравится заказчику». Судья спрашивает: «Заказчик, Вам нравится дизайн?». Заказчик: «Нет, Ваша честь!». Судья: «Исполнитель, присуждаю — 2 года уборки снега в Сибири за невыполнение условий ТЗ!».

Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».

«Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат. Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия. Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать).

Тех. задание — это документ, который нам дает заказчик (Не важно, что его пишем мы. По смыслу это задание, техническое задание, а задание дает заказчик исполнителю, т.е. нам). А из этого следует, что в ТЗ должны быть формулировки, которые указывают нам, что делать (типа «сайт должен содержать», «должна быть возможность»). В некоторых ТЗ я видел, формулировки вида «на сайте будет то-то и то-то» — это неверная формулировка, это какое-то уведомление заказчика, что будет сделано, но документ-то называется «задание», а не «уведомление».

3. Разделы ТЗ

3.1 Общие слова

Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.
3.2 Эксплуатационное. назначение

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

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

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

3.4 Термины и определения

Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же.
Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.

Во втором случае, как правило, не нужно описывать термины специфичные для предметной области, но не имеющие отношения к реализации проекта. Например, для магазина торгующего запчастями для парусных судов, не стоит выносить в термины такое, как стаксель и ванты. Здесь нужны расшифровки терминов, которыми оперирует заказчик и вкладывает в них некий смысл, который может быть нами истолкован неверно. Какие-то простые слова, но в данном контексте, принимающие особое значение. Например, заказчик говорит: «Сеанс работы с сайтом стоит 100 тугриков». Фраза «сеанс работы с сайтом» — претендент на описание. Этот термин может означать продолжительность времени от входа на сайт до выхода, или же период работы пока на счету пользователя не закончатся деньги. Т.е. нам нужно точно знать, что такое «Сеанс работы». Ошибочное понимание такого простого термина может создать реальную проблему.

3.5 Данные и списки

Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.

Данные

Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.

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

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации

Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

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

3.6 Страницы с описанием

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

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

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

Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе.
Т.е. если на иллюстрации новость имеет «Категорию новости», а в разделе «Данные и списки» новость не имеет ее, то это проблема. Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.

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

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

3.7 Требования к надежности

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

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

3.8 Требования к хостингу

Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают..., у меня другого хостинга нет, надо переделывать на PHP».

Помимо таких очевидных проблем есть проблемы и потоньше. Например, для нормальной работы нужен cron, а хостер его не предоставляет (абсолютно реальный случай из моей практики). Или, скажем, специфический сайт, который не может работать на shared хостинге, ему нужен только VPS или VDS.

Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

3.9 Наполнение контентом

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

Если мы должны, например, залить в каталог 500 фотографий, предварительно их обработав, то это следует описать именно тут.

Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

3.10 Сдача и приемка

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

Возможны варианты, например, перенос на хостинг заказчика после 100% оплаты. Или же оплата после переноса на сайт заказчика плюс неделя на обкатку.

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

Заключение

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

Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.

Руководство по написанию документов спецификации веб-сайтов (обновлено в 2019 г.)

Структура контента или информационная архитектура (IA) состоит из различных частей и будет зависеть от сложности и размера контента вашего веб-сайта.

Карта сайта

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

Пример базовой карты сайта

Существуют отличные инструменты для создания карт сайта.Мы любим Gloomaps.

Типы контента

Веб-сайт может содержать множество различных типов контента. В самом основном, это обычно записи и страницы. Страница - это вневременной контент, например «О нас», тогда как запись ведется в хронологическом порядке, например новости или сообщения в блоге.

Вот некоторые другие общие примеры типов контента:

  • Люди
  • Продукты
  • Отзывы
Данные типа контента

Для каждого типа контента должны быть перечислены данные, связанные с этим типом контента.Например, если был тип контента «Человек», им могли бы потребоваться следующие данные:

  • Имя
  • Фамилия
  • Должность
  • Bio
  • Адрес электронной почты
  • Номер телефона

Таксономия

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

Например, если у вас есть веб-сайт с рецептами, вам может потребоваться таксономия «обедов», в которой термины таксономии будут «завтрак», «обед», «ужин», «закуски», «десерт» и т. Д.Вы также можете составить таксономию «кухни» с такими терминами, как «индийская», «британская», «французская» и т. Д.

В блогах наиболее распространенными двумя таксономиями являются «Категории» и «Теги».

Существует два основных типа таксономии:

  1. Иерархическая - например, «Категории»
  2. Неиерархический - например, «Теги»

Другим примером может быть таксономия «Отрасль», которую вы можете назначить своим типам контента «Блог», «Клиент», «Пример использования» и «Услуга».

Шаблоны страниц

Шаблон страницы - это определенный формат информации. Например, ваша «Домашняя страница», вероятно, будет выглядеть иначе, чем ваша страница «Контакты».

Ниже приведены некоторые примеры общих шаблонов страниц:

  • На главную
  • Запись в блоге
  • «Наша команда»
  • Архив новостей - список всех новостных сообщений сайтов в обратном хронологическом порядке.
  • Контакты - могут иметь карту и form

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

.

Практическое руководство по написанию технических спецификаций

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

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

В этой статье я расскажу, как написать техническую спецификацию, обеспечивающую надежность продукта.

Что такое техническая спецификация?

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

Почему так важно написать техническую спецификацию?

Технические спецификации

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

Преимущества для инженеров

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

Благодаря этому хорошо продуманному решению ваши технические характеристики избавят вас от необходимости постоянно объяснять свой дизайн нескольким товарищам по команде и заинтересованным сторонам.Но никто не идеален; ваши коллеги и более опытные инженеры могут показать вам новые вещи от них о дизайне, новых технологиях, инженерных методах, альтернативных решениях и т. д., о которых вы, возможно, не сталкивались или не думали раньше. Они могут поймать исключительные случаи решения, которым вы, возможно, пренебрегли, уменьшив вашу ответственность. Чем больше у вас будет глаз, тем лучше.

Преимущества для команды

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

Преимущества проекта

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

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

Что нужно сделать перед написанием технического задания

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

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

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

Содержание ТУ

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

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

1. Фасад

  • Заголовок
  • Автор (ы)
  • Команда
  • Рецензент (и)
  • Создано на
  • Последнее обновление
  • Ссылка на эпик, тикет, проблему или трекер задач

2.Введение

а. Обзор, описание проблемы, сводка или реферат

  • Краткое изложение проблемы (с точки зрения пользователя), контекст, предлагаемое решение и заинтересованные стороны.

б. Глоссарий или терминология

  • Новые термины, с которыми вы сталкиваетесь при исследовании своего дизайна, или термины, о которых вы можете подозревать, что ваши читатели / заинтересованные стороны не знают.

с. Контекст или фон

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

d.Цели или продукт и технические требования

  • Требования к продукту в форме пользовательских историй
  • Технические требования

e. Нецелевые или выходящие за рамки

  • Требования к продукции и технические требования, которые не будут приняты во внимание

f. Будущие цели

  • Продукт и технические требования на будущее

г. Допущения

  • Условия и ресурсы, которые должны присутствовать и быть доступны для того, чтобы решение работало, как описано.

3. Решения

а. Текущее или существующее решение / проект

  • Описание текущего решения
  • Плюсы и минусы текущего решения

б. Предлагаемое или предлагаемое решение / дизайн

  • Внешние компоненты, с которыми решение будет взаимодействовать и которые оно изменит
  • Зависимости текущего решения
  • Плюсы и минусы предлагаемого решения
  • Изменения модели данных / схемы
    • Определения схемы
    • Новые модели данных
    • Модифицированные модели данных
    • Методы проверки данных
  • Business Logic
    • Изменения API
    • Псевдокод
    • Блок-схемы
    • Состояния ошибок
    • Сценарии отказов
    • Условия, которые приводят к ошибкам и сбоям
    • Ограничения
  • Уровень презентации
    • Требования пользователя
    • Изменения пользовательского интерфейса
    • Изменения пользовательского интерфейса
    • Каркасы с описаниями
    • Ссылки на работы дизайнера пользовательского интерфейса / пользовательского интерфейса
    • Мобильные проблемы
    • Веб-проблемы
    • Состояния пользовательского интерфейса
    • Обработка ошибок
    900 50
  • Другие вопросы, на которые необходимо ответить
    • Как будет масштабироваться решение?
    • Каковы ограничения решения?
    • Как он будет восстанавливаться в случае сбоя?
    • Как он будет соответствовать будущим требованиям?

с.План тестирования

  • Объяснение того, как тесты будут обеспечивать выполнение требований пользователя
  • Модульные тесты
  • Интеграционные тесты
  • QA

d. План мониторинга и оповещения

  • План и инструменты ведения журнала
  • План и инструменты мониторинга
  • Метрики, используемые для измерения состояния здоровья
  • Как обеспечить наблюдаемость
  • План и инструменты оповещения

e. План выпуска / развертывания и развертывания

  • Архитектура развертывания
  • Среды развертывания
  • План поэтапного развертывания e.грамм. использование флагов функций
  • План, описывающий, как сообщать пользователям об изменениях, например, с помощью примечаний к выпуску

f. План отката

  • Подробные и конкретные обязательства
  • План по сокращению обязательств
  • План, описывающий, как предотвратить влияние на другие компоненты, службы и системы

g. Альтернативные решения / конструкции

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

4.Дополнительные соображения

а. Влияние на другие команды

  • Как это увеличит работу других людей?

б. Рекомендации по использованию сторонних сервисов и платформ

  • Действительно ли оно того стоит по сравнению с построением службы собственными силами?
  • Какие проблемы безопасности и конфиденциальности связаны с услугами / платформами?
  • Сколько это будет стоить?
  • Как это будет масштабироваться?
  • Какие возможные проблемы в будущем ожидаются?

с.Анализ затрат

  • Сколько стоит использовать решение в день?
  • Сколько стоит его развертывание?

г. Соображения безопасности

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

e. Соображения о конфиденциальности

  • Соответствует ли решение местным законам и юридическим политикам в отношении конфиденциальности данных?
  • Как решение защищает конфиденциальность данных пользователей?
  • Какие компромиссы между персонализацией и конфиденциальностью в решении?

ф.Региональные особенности

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

г. Соображения доступности

  • Насколько доступно решение?
  • Какие инструменты вы будете использовать для оценки доступности?

ч.Рекомендации по эксплуатации

  • Вызывает ли это решение неблагоприятное последействие?
  • Как данные будут восстанавливаться в случае сбоя?
  • Как решение восстановится в случае сбоя?
  • Как будут сохраняться низкие эксплуатационные расходы при увеличении ценности для пользователей?

i. Риски

  • Какие риски несет это решение?
  • Есть ли риски, от которых нельзя отказаться?
  • Каков анализ затрат и выгод от принятия этих рисков?

Дж.Рекомендации по поддержке

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

5. Оценка успеха

а.Ударная

  • Влияние на безопасность
  • Влияние на производительность
  • Влияние на стоимость
  • Влияние на другие компоненты и услуги

b. Метрики

  • Список показателей для сбора данных
  • Инструменты для сбора и измерения показателей

6. Работа

а. Смета и сроки работ

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

b.Приоритезация

  • Распределение задач по срочности и степени воздействия

c. Вехи

  • Датированные контрольные точки, когда будут завершены значительные объемы работы
  • Показатели, указывающие на прохождение контрольной точки

d. Будущая работа

  • Список задач, которые будут выполнены в будущем

7. Обсуждение

а. Обсуждение

  • Элементы решения, с которыми члены группы не согласны и требуют дальнейшего обсуждения для достижения консенсуса.

б. Открытые вопросы

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

8. Конечное дело

а. Сопутствующие работы

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

б. Каталожные номера

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

с. Благодарности

  • Отметьте людей, которые внесли свой вклад в дизайн, который вы хотите отметить.

После того, как вы написали свою техническую спецификацию

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

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

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

Теги: бюллетень, stackoverflow, технические характеристики.

10 ключевых пунктов о том, как написать спецификацию веб-сайта

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

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

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

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

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

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

Необходимые элементы и вопросы для создания спецификации:

1. Общая информация о компании или физическом лице / покупателе

Общая информация представляет собой элементарное введение для спецификации и предоставляет соответствующую информацию о:

  • Какая компания это ( Название компании)
  • Деятельность компании
  • Количество сотрудников
  • Конкурс (ссылка на веб-сайты конкурсов)

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

2. Это полностью новый проект или это редизайн / перепрограммирование существующего?

Конкретные вопросы, на которые клиент должен дать ответ:

  • Есть ли у вас в настоящее время веб-сайт?
  • Какой у этого веб-сайта адрес?
  • Вы хотите изменить дизайн сайта или полностью новый сайт?

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

3. Что конкретно вы ожидаете от веб-сайта?

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

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

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

4. К какому типу относится ваш веб-сайт?

Типы веб-сайтов:

  • Корпоративная презентация компании
  • Персональная страница
  • Интернет-магазин (сайты электронной коммерции)
  • Веб-приложение
  • Социальная сеть
  • Портфолио
  • Блог
  • Веб-сайт с особыми функциями

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

5. Структура веб-сайта

  • Какое количество веб-страниц?
  • Карта сайта очень полезна
  • Сколько разных типов страниц / макетов (Домашняя страница, О нас, Портфолио / Галерея, Контактная страница)
  • Это одноязычный или многоязычный веб-сайт и какое количество языков?

Это не одно и то же, если вам нужен веб-сайт с 4 страницами или веб-сайт с тысячами страниц.Сайт с 4 страницами также может быть очень сложным с точки зрения уделения внимания каждой детали на странице и высокого качества дизайна.

Веб-пакеты - не лучшее решение для клиентов.

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

Если в веб-пакете указано, что количество страниц не ограничено или 50+, и вы подписываете договор, то не определено, сколько вам действительно нужно работать.

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

Домашняя страница является доминирующей страницей, но она необходима, чтобы уделять внимание всем остальным страницам.

6. Статический или динамический веб-сайт

  • Кто будет импортировать контент на веб-сайт (покупатель или агентство)?
  • Нужна ли сайту система CMS, чтобы покупатель мог импортировать контент?
  • Как часто вы планируете изменения на сайте и какие элементы вы бы изменили?

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

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

7. Функциональность веб-сайта

Это один из важнейших пунктов.

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

Пример 1:

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

Итак, каждая функциональность и этап / поток объяснены, и на основе этого можно создать предложение и в итоге дополнительные вопросы.

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

Пример 2:

Необходимо указать 10 компаний / Депутаты на сайте, и для каждой компании есть 3 категории и 2 подкатегории.Я также хочу, чтобы вы создали полную функциональность, категории и подкатегории, а мы добавим продукты. Оплата будет производиться доставкой, кредитными картами, PayPal…

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

8. Бюджет

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

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

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

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

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

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

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

9. Сроки

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

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

Определение проекта напрямую связано с проектной документацией, и в 99% случаев агентство веб-дизайна является тем, кто устанавливает приблизительный срок для этого проекта.

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

10. Дополнительная информация

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

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

  • Скачать бланк заказа / проектной документации -
  • Скачать заполненный заказ / проектную документацию -

Основатель PopArt Studio d.o.o.

Последние сообщения от Dejan Popović (посмотреть все).

Как написать спецификацию веб-сайта

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

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

Решите, зачем вам сайт

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

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

«Мы хотим, чтобы люди нашли» означает, что на этом сайте должны быть хорошие рейтинг в поисковых системах. Около 90% трафика на этот сайт поступает из поиск, где наша запись появляется в первых 5 записях. Последующий баллы могут быть включены в спецификацию:

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

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

Трудно указать точное требование, но вы могли бы добавить следующие к спецификации:

  • Дизайнер должен отдельно включить бюджет для построения ссылок.

и / или

  • Дизайнер должен помочь создать рекламный аккаунт (например, Google Adwords) для привлечения трафика на сайт.

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

Узнайте больше в нашей поисковой системе раздел оптимизации.

Стиль письма

Спецификация должна быть написана в определенных терминах. Не пишите "Если возможно, на странице "список виджетов" должно быть поле поиска, которое посетители можно использовать для поиска по всем продуктам ". Вместо этого напишите" Список страница виджетов будет содержать окно поиска, которое посетители могут использовать для поиск по всем продуктам ».Если это невозможно, ваш веб-дизайнер расскажу, а можно внести поправку в спецификацию.

Определите основное содержание вашего сайта

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

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

Домашняя страница: Обзор того, что ваша компания делает и какие продукты и услуги предоставляет.

Продукт 1: Подробная информация об ассортименте 1, включая цены, технические данные, иллюстрации и т. д.

Продукт 2: Ассортимент продукции 2 и т. Д. ...

Свяжитесь с нами: страница с полной контактной информацией и, возможно, карту.

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

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

Определите вторичное содержание

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

Примеры из практики: короткие статьи, описывающие, как наши услуги принесли пользу клиентам.

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

статей: Статьи по специальностям которые передадут ваш опыт вашим посетителям.

Рекомендуется включать дополнительные страницы, чтобы привлечь посетителей на свой сайт. Мы включили страницу о восстановлении MGB в страницу, специализирующуюся на в частях МГБ и сел, чтобы посмотреть файлы журнала. 95 процентов людей, которые прочитал статью также посмотрел страницы запчастей MG.

Функциональность и удобство использования

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

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

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

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

Стиль и верстка

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

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

Дополнительные требования

Доступность

В Великобритании дискриминация по инвалидности Закон (DDA) требует, чтобы вы приложили разумные усилия к тому, чтобы любая предоставляемая вами услуга доступна для людей с ограниченными возможностями.С октября 2004 г. DDA будет специально включать веб-сайты как услуги. Вы, вероятно, будете хотите включить в свою спецификацию следующую строку:

  • Сайт должен соответствовать W3C WAI (World Wide Web Consortium Web Accessibility Инициатива) уровень А. Рекомендации.

Если вы проживаете в США и финансируетесь государством, тогда ваш сайт должен соответствовать Разделу 508 Рекомендации:

  • Сайт должен соответствовать требованиям US Section 508 Accessibility Guidelines.

Проверка кода

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

  • Весь код на сайте должен быть подтвержден консорциумом W3C (World Wide Web Consortium) технические характеристики.

Техническое обслуживание

После запуска веб-сайта необходимо будет обновить его новой информацией. или вы найдете какую-то область, которую хотите изменить.Большинство веб-дизайнеров предлагают контракты на обслуживание, но, возможно, вы захотите обновить свой сайт самостоятельно, используя недорогой пакет, такой как Macromedia Contribute. Ты мог добавьте в свою спецификацию следующую строку:

  • У нас должна быть возможность обновлять содержимое сайта с помощью недорогой программный комплекс.
  • Веб-дизайнер проведет обучение на месте для 2 наших сотрудников в как использовать этот программный пакет.

Хостинг

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

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

Опора

На очень сложном сайте иногда возникает небольшая ошибка. через процесс проверки. Вам понадобится постоянная поддержка со стороны вашего дизайнер:

  • Любые ошибки или ошибки, обнаруженные на сайте после запуска, будут исправлены. бесплатно.

Далее: An пример спецификации сайта

.

Смотрите также

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Одноклассники
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий