Содержание

Как составить ТЗ для разработчика и веб-дизайнера

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

Что такое ТЗ и кому оно нужно

ТЗ — это документ, в котором прописаны все требования к создаваемому продукту. В нашем случае — к сайту или интернет-магазину. Помните поговорку “без внятного ТЗ — результата ХЗ”? Вот это оно и есть: если задание будет малоинформативным, размытым, непонятным — такой же сайт вы в итоге получите. Если вообще получите: хорошие веб-дизайнеры не возьмутся за работу, пока все детали не будут четко обговорены. Никому не хочется работать телепатом и угадывать желания заказчика. Никому не хочется тратить время и выполнить работу, которая потом не понравится и не будет оплачена. В то же время, если ТЗ не выполнит исполнитель, у заказчика появляется законное право напомнить ему обязательства и потребовать внесения правок.

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

. Даже если в процессе работы исполнитель поменяется — ТЗ никуда не денется, его можно дать следующему дизайнеру.

Кто должен составлять ТЗ?

Есть мнение, что ТЗ должен делать заказчик. На первый взгляд это логично: задание-то дается исполнителю, надо ему рассказать, что да как. Однако заказчики часто не знают, что должно быть в ТЗ, какие моменты нужно осветить, на что сделать акцент и так далее. Они могут сказать: “хочу сайт как у Х.”, или “придумайте что-то современное”, или “мне нужно больше продаж”.

И правильно делают! Больше того: клиентам и не нужно знать об основных правилах веб-дизайна или способов повышения конверсии. Они не маркетологи, не продажники, не пиарщики. Они — владельцы бизнеса, которые заказывают услугу по разработке сайта. За свои деньги заказчики хотят получить крутой продающий сайт и вовсе не обязаны знать, КАК это будет сделано. Именно поэтому

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

задание проекта

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

Итак, что в ТЗ должен написать клиент?

  • рассказать о главной цели создания сайта: привлечь трафик, повысить продажи, увеличить число клиентов;
  • познакомить веб-дизайнера с миссией компании, продуктах, которые она производит или реализует, целевой аудитории;
  • рассказать, каким образом происходит общение с клиентами;
  • объяснить, хотя бы на пальцах, что он хочет получить в итоге;
  • дать примеры других сайтов и дизайна, которые ему нравятся;
  • познакомить с фирменным стилем компании (если он есть), рассказать о желаемых корпоративных цветах, шрифтах, слоганах;
  • обговорить, входит ли в работу написание контента. Если да — то какого;
  • если есть наработки, тексты, фото или видео, логотип бренда — отлично, давайте все сюда, будем изучать.

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

структура сайта

Что должен указать исполнитель?

  • описать требования к хостингу, систему управления сайтом, инструменты, на которых будет проходить работа. В общем, вся техническая сторона;
  • структура сайта — чем подробнее, тем лучше. Хорошие спецы продумывают структуру каждой страницы вплоть до отдельных элементов. Можно составить прототипы, чтобы наглядно показать заказчику, что его ждет;
  • дизайн сайта: типографика, основные цвета, шрифты, фоны;
  • рекламные баннеры и место их размещения;
  • интерактивные элементы и их расположение;
  • список контента, если это входит в ТЗ;
  • отдельным пунктом можно указать словарь терминов, которые использовались в ТЗ. Лучше упростить и объяснить все простыми словами, но в крайнем случае можно сделать сноски и пояснения.

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

Теперь давайте подробнее рассмотрим основные пункты ТЗ

1. Информация о компании

Это все, что относится к вашей компании и может повлиять на особенности создания сайта. Если разработана миссия и корпоративная культура — можно отобразить это на главной странице. Если сформирован коллектив профессионалов — можно создать раздел “Лица”, поместить фотографии сотрудников и коротко рассказать о каждом. Если четко определена целевая аудитория — нужно делать сайт и дизайн конкретно под нее. Каждая информация может стать ниточкой, потянув за которую, у разработчика может возникнуть огненная идея.

2. Технические требования

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

3. Адаптивная версия

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

адаптивный сайт

4. Структура сайта

Пожалуй, это самый подробный этап работы исполнителя.

В структуре должны быть отражены:

  • пункты меню (если это интернет-магазин — главная страница, “О компании”, “Условия оплаты и доставки”, “Политика конфиденциальности”, блок вопросов-ответов;
  • каталог товаров — категории, подкатегории, фильтры, метки или теги;
  • основные интерактивные элементы (кнопка корзины, иконки соцсетей, виджет обратной связи, сервис товарных рекомендаций и другие фишки).

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

5. Возможные сценарии

Сайт — это не простая линейная структура, но и цепочки взаимодействия с посетителями. Вот и нужно написать, как все это работает. Например, посетитель смотрит карточку товара, кладет его в корзину. Затем сайт предлагает посмотреть рекомендованные товары — отлично, пользователь переходит на другую страницу, опять наполняет корзину. Видит кнопку “Перейти в корзину”, идет туда и жмет на кнопку “Оформить заказ”. И далее по плану.

6. Контент на сайте

Если заказчик заказывает еще и контент — это обговаривается отдельно. Контент — это тексты, фото, видео, анимация — любая информация, которая дается посетителю. Исполнители пишут обычно текст на главную, новости, страницу “Услуги”, часто задаваемые вопросы и ответы на них, карточки товаров, статьи для блога.

7. Дизайн сайта

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

дизайн сайта

Каким должно быть ТЗ? Базовые правила для заказчика и исполнителя

На что нужно обратить внимание, чтобы облегчить жизнь и себе, и исполнителю?

1. Не пишите размыто. “Сделать сайт круче, чем у…” — весьма достойная цель, но что входит в понятие “круче”? Когда вы составляете бизнес-план на ближайший год, вы же не пишете в нем “стать еще круче, чем были”, а указываете точные цифры: “увеличить годовой оборот на 10 %”, “расширить ассортимент на три категории” и “заключить договоры с поставщиками М и Ж”. Да и оцениваете эффективность бизнеса и рекламного продвижения вы не по пятибалльной шкале, а с помощью специальных показателей. Так и здесь: ставьте четкие цели и задачи: добиться конверсии не менее 5-10%; привлечь дополнительную ЦА — молодежь и студентов, отбить часть рынка у таких-то конкурентов.

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

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

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

макет сайта

3. Дайте всего да побольше. Знаете, каких собеседников любят журналисты? Разговорчивых. Пусть наговорит всего и побольше — из этого проще сделать классное интервью, чем из односложных ответов молчуна. Так и здесь: не умалчивайте информацию, давайте ее как можно больше. Когда в ТЗ входит наполнение сайта контентом — пришлите все, что у вас есть. Если даже добрая половина не войдет в итоговый вариант сайта — ну и что, пусть будет. Профессионал выберет из горы информации лучшее.

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

А если ТЗ не нравится?

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

А что потом?

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

Когда сайт будет готов, можно еще раз свериться с ТЗ и запускать его в работу. А дальше все зависит от вас и вашей команды. Удачи в продвижении!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Техническое задание

Что такое техническое задание? Как его делать и для чего оно нужно? Примеры, образцы, советы и рекомендации.

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

Проблема восприятия информации, вечная. Эффект “сломанного телефона”, частое явление. А что говорить о том, если ты просто не умеешь ставить задачу? Да, такое тоже бывает и с этим нужно как-то работать, но как? Для того чтобы результаты задач, которые вы ставите, соответствовали вашим ожиданиям, пишите техническое задание.

Что такое техническое задание

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

Конструкторское бюро

Документ этот может занимать, как одну страницу А4, так и целый том, все зависит от задач и пожеланий которые в него входят. К примеру, вы можете написать техническое задание на небольшой landing page (одностраничный сайт) или же на сложное программное обеспечение с машинным обучением и прочими фишками.

Для чего нужно техническое задание

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

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

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

По факту, это серьезный документ, который составляется заказчиком и исполнителем. Вплоть до того, что прописываются неустойки и обязательства сторон. Существует целый ряд ГОСТ-ов, более подробно читайте на Хабре.

Разработка технического задания

Если мы говорим об игре “по-взрослому”, например, техническое задание на разработку мобильного приложения или сайта, то это отдельная работа, за которую платятся немалые деньги. Вы привлекаете человека, как правило, это бывший или действующий технический директор (Chief Technical Officer) и просите его помочь вам.

Наличие бороды необязательно

В зависимости от объемов проекта/задач этот человек собирает все ваши “хотелки”, переводит их в технический язык, может быть готовит эскизы (как должно приблизительно выглядеть) и отдает вам готовый документ. Далее вы этот документ передаете исполнителям (команде внутри вашей компании или на аутсорс), договариваетесь по деньгам, срокам и приступаете к работе.

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

Из чего состоит техническое задание

Все будет зависеть от шаблона, который вы выберете (чуть дальше я дам несколько ссылок на шаблоны/примеры), но есть базовые блоки, которые входят в техническое задание:

  1. Описание проекта/задачи. Кратко пишем, что за проект или задача, которую нужно выполнить.
  2. Назначение и цели. Какие цели стоят перед проектом.
  3. Требования. Дизайн, функции, технологии, которые необходимы.
  4. Описание работ. Что, когда и как будет выполнено.
  5. Порядок контроля и приемки. Как будут приниматься работы, что можно считать выполненным.
  6. Приложения. Эскизы, наброски, прототипы.

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

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

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

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

Пример одного из моих ТЗ на апдейт приложения Smart TV. Задания на более сложные и комплексные продукты составлялись уже с помощью коллег из тех.департамента. Не стесняйтесь обращаться за помощью к своим соратникам, вовлекайте их в процесс как можно чаще. И не забывайте давать обратную связь! Нет ничего хуже, чем вложить силы и время во что-либо без информации о результатах. Расскажите, как пригодился совет человека в вашей работе, в противном случае, это игра в одни ворота.

Далее будут приведены примеры тех.задачний из интернета.

ТЗ на разработку интернет магазина
ТЗ на разработку мобильного приложения
ТЗ на сайт
ТЗ на сервисы/обновления

Если нужно больше образцов, просто погуглите.

Рекомендации и советы

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

Вот так надо

Мои первые зачатки по написанию ТЗ начали появляться несколько лет назад. Я работал с дизайнерами и ставил задачу на создание креативов для рекламных кампаний. Бессвязное хочу это и это превращалось в кучу потраченного времени и объяснений. Со временем постановка задач начала превращаться в какие-то смысловые блоки, а потом уже и в подобие технического задания.

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

Например для задачи “Кнопка лайк на сайте”:
  1. Описание: необходимо создать кнопку “Лайк” на нашем сайте.
  2. Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
  3. Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
  4. Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17),  разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
  5. Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
  6. Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.

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

Ну вот

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

Алексей А.


Читайте также:


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

 

Вконтакте

Facebook

Twitter

Google+

Загрузка…

Как грамотно составить ТЗ для программиста

telegram channel

Назначение, цели ТЗ

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.

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

Общие рекомендации по написанию ТЗ

  • Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
  • Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
  • В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
  • Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит?  Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно  и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
  • Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести  анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
  • Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

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

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
—  среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

  1. Общая информация о сайте.
  2. Функциональное назначение сайта.
  3. Понятия и термины
  4. Описание модулей сайта
  5. Функциональные характеристики
  6. Описание страниц.
  7. Резервирование и надежность.
  8. Хостинг для сайта.

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

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

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

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

  • Поле «Ваш имя»;
  • Поле «Ваш е-mail»;
  • Поле «Ваш вопрос»;
  • Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в  небезызвестном  Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и  по настройке сервера.

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

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

Структура сайта

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

Прототип сайта

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Подписаться на рассылку

Еще по теме:


Прототип сайта

Олег Галеня

Middle PHP Developer

Оцените мою статью: 

Есть вопросы?

Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.

Siteclinic logo

Как сделать простое техническое задание и не потерять деньги и нервы / Хабр

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

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



Что было раньше


Мы небольшая региональная компания, занимающаяся заказной веб-разработкой, которая, как и многие другие, в самом начале бралась за проекты, не особо представляя как их делать. Но подобный “вынужденный рост” крайне положительно сказался на членах команды, благодаря огромному желанию развиваться, и помог прокачать и скилы, и голову. Разработка становилась все качественнее, но техническое задание оставалось на самом низком уровне. Как и большинство начинающих студий, мы использовали обычный описательный подход к ТЗ: какие страницы, что должно отображаться, некоторые технические моменты, да и все, пожалуй.

На многих проектах это выливалось в следующие проблемы:

  1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
  2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
  3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.

Новый подход


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

ТЗ состоит из следующих разделов:

  1. Введение
  2. Статика
  3. Динамика
  4. Задачи
  5. Административная панель
  6. Общие технические требования

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

Введение и подготовка к реализации

  • Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
  • Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
  • Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

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

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.

Помимо страниц Статика включает в себя описание pop-up и письма. На мой взгляд их нет смысла выносить в отдельный большой раздел и раздувать структуру.

Динамика

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

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

Задачи

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

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

Общие технические требования

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

  1. SEO-требования к тегам и микроразметке
  2. Правила транслитерации
  3. Ручное и автоматическое тестирование
  4. Поддерживаемые браузеры

Новые версии


При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.

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

Пример


Давайте для наглядности разберем структуру ТЗ на основе упрощенной страницы раздела каталога.

Статика


Страница “Раздел каталога”

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

Интегрируется следующий функционал:

  1. “Хлебные крошки”
  2. “Дерево каталога”
  3. “Фильтрация. Общие положения”
  4. “Фильтрация. Текст”
  5. “Фильтрация. Текст и изображение”
  6. “Фильтрация. Диапазон”
  7. “Сортировка. По умолчанию”
  8. “Сортировка. По возрастанию цены“
  9. “Сортировка. По убыванию цены”
  10. “Превью товара. Плитка”
  11. “Пагинация. Постраничная”
  12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

URL: /c/1745-name, где 1745- id текущей категории каталога, а name — транслитерированное название этой категории.

Динамика


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

Функционал “Фильтрация. Общие положения”

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

  • выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
  • название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
  • цвет кнопки фильтра меняется на вид используемого фильтра
  • в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
  • у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
  • пагинация сбрасывается

Если хотя бы один фильтр активен, после всех кнопок с фильтрами появляется кнопка “сбросить фильтры”, при клике на которую значению всех фильтров сбрасываются.

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

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

  1. Цена (целое число в рублях РФ)
  2. Название товара
  3. Метка “В магазине” или “С витрины”
  4. Изображение
  5. Размер
  6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
  7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

При клике на любую область превью, кроме кнопки “В корзину” осуществляется переход на страницу товара.

На одной строке должно помещаться 3-4 плитки с превью товара.

Как вы видите, в данный функционал интегрируется другой, что позволяет делать очень удобные разбиения. Например, “Добавить в корзину” и “Добавить в избранное” используются и в карте товара.

Административная панель


Одна страница требует большого количества разделов АП, опишу один из них.

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

  1. Название (текст)
  2. Бренд (радио)
  3. Изображения
  4. Цена (целое число)
  5. Описание (текстовый блок)
  6. Тип (магазин/витрина, радио)
  7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
  8. Статус. Возможны варианты:
    1. на продаже
    2. на модерации
    3. на доработке
    4. отклонен
    5. продан
    6. не прошел проверку
    7. отменен Продавцом
  9. Размер с бирки (необязательное). Текстовое поле без валидации

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

Выводы


Плюсы нового подхода:
  1. Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
  2. Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
  3. Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
  4. Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
  5. Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
  6. Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

Минусы:
  1. Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
  2. Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
  3. Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

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

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

Ликбез по техническому заданию / Хабр

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве


Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.


Жутко правда? Бюджет уже потрачен и срок истек.

Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве


Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.

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

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ


Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
  • Концептуальная модель
  • Функциональная карта
  • Путь пользователя
  • Пользовательский интерфейс
  • Программные интерфейсы
  • Нефункциональные требования

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

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

image

Концептуальная модель


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

Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.

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

Стоит рассказать о типах пользователей и их ключевых отличиях.

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

И в завершении расскажите о компонентах вашего продукта.

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

Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.

Функциональная карта


Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.

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

image

Путь пользователя


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

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

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

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

image

image

Пользовательский интерфейс


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

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

image

Программные интерфейсы


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

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

image

Нефункциональные требования


Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.

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

Советы


  1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
  2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
  3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
  4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
  5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
  6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

4 причины, по которым вам следует написать техническое задание

Во-первых, прежде чем вы спросите: «Зачем мне нужно техническое задание для моего бизнеса», вы можете спросить: «Что вообще такое техническое задание для проекта?»

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

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

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

К вашему сведению: Хотите узнать стоимость вашей веб-разработки? Попробуйте наш веб-калькулятор.

Значение написания технического задания

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

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

Подробнее о назначении ТЗ читайте в нашей статье.

Создание документов технических спецификаций: шаги и формат

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

Таким образом, ваш документ TS должен включать следующее:

  • Оглавление: обычно техническая документация представляет собой объемный документ, поэтому оглавление помогает сориентироваться в нем.
  • Написание актуальных спецификаций
  • Присвоение титулов (подписные блоки для органов власти)
  • Определение используемых терминов

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

Оценка

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

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

Требования

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

Стиль письма имеет решающее значение при подготовке.

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

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

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

Сборка документа

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

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

.

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

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

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

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

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

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

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

website specification

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

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. Сроки

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

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

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

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

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

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

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

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

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

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

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

Джори МакКей

Джори — писатель, контент-стратег и отмеченный наградами редактор Unsplash Book. Он вносит свой вклад в Inc., Fast Company, Quartz и другие.

15 ноября 2018 г. · 11 мин чтения

🎁 Бонусный материал: шаблон технической документации



Пока у нас есть инструменты, в использовании которых нам нужна помощь (и язык для общения друг с другом), мы » у меня была техническая документация.(Не верите? Первый пример технического письма на английском языке восходит к средневековью, когда Чосер написал руководство по астролябии — устройству, используемому для измерения расстояния до звезд).

Напишите свой? Вот бесплатный шаблон и контрольный список!

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

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

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

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

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

Но сначала краткий обзор этой статьи:

Когда, почему и как правильно использовать техническую документацию

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

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

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

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

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

Как спланировать, написать и доставить работающую техническую документацию

Итак, как же создать эти четкие, краткие и удивительно полезные документы?

Напишите свой? Вот бесплатный шаблон и контрольный список!

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

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

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

Шаг 1: Проведите исследование и создайте «План документации»

Как гласит старая пословица: «Напишите то, что вы знаете».

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

Если вы не являетесь экспертом в предметной области, это может означать проведение некоторых внутренних собеседований и налаживание отношений с технической командой, чтобы лучше понять материал (и избежать того, что старший технический писатель Уилл Келли называет техническим «Миссия невыполнима». написание проектов).Или это может быть так же просто, как просмотреть существующие ресурсы и руководства и провести краткий аудит того, что у вас есть, а что отсутствует.

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

  • Цели: Проще говоря, что вы хотите, чтобы люди могли делать? Это для использования вашего продукта? Находите справочные документы быстро и легко? Узнайте, как использовать определенные аспекты вашего инструмента? Разрешить товарищам по команде запрашивать ресурсы или заказывать оборудование? Наличие и знание четкой цели необходимо для написания хорошей технической документации и поможет информировать обо всем, что вы делаете.
  • Существующие ресурсы: Что сейчас доступно? Вы обновляете или объединяете текущие ресурсы или начинаете с нуля? Есть ли старые, устаревшие версии, которые нужно убить? Сделайте быстрый аудит и найдите все, что поможет вам писать или запутать аудиторию, если они это найдут.
  • Руководства по стилю: В некоторых отраслях требуется, чтобы вы писали техническую документацию определенным образом (например, рекомендации на простом языке для правительственных сайтов или упрощенный технический английский для аэрокосмических, авиационных или оборонных компаний).В других случаях у вашей компании может быть руководство по стилю, в котором объясняется, какой язык использовать, как разговаривать с пользователями и даже грамматические стили.
  • Описание тем: Какие темы и подтемы вы будете освещать в своей технической документации? Думайте об этом как о содержании и попытайтесь перечислить все основные разделы и подразделы, которые, по вашему мнению, вам понадобятся.
  • Инструменты и управление: Какое программное обеспечение, инструменты или веб-сайты будут использоваться для создания и управления документацией? Ссылка на соответствующие руководства по стилю.
  • Срок и окончательные результаты: Когда он должен быть и в каком формате он будет? Техническая документация касается не только содержания, но и структуры и доставки. А знание того, как будет представлен контент, перед тем, как вы начнете, расскажет вам, что вам нужно и куда приложить усилия.

Шаг 2: Структура и дизайн

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

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

Вот несколько быстрых советов для каждого:

Используйте шаблоны или «схемы» для согласованного дизайна на странице

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

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

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

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

  • Название: Что это?
  • Подзаголовок: Дополнительная информация
  • Обзор : Что вы узнаете
  • Содержание: Внутренняя навигация
  • Функции: Каждый раздел документа
  • Читать далее: Связанные документы, которые могут помогите пользователю

Вот пример использования Planio wikis:

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

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

Создайте простую логическую структуру навигации

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

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

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

Шаг 3. Создайте контент

Хорошо! Имея план документации и структуру , пора серьезно заняться созданием технической документации.

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

Начните с черновика

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

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

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

Несколько простых советов по хорошему письму:

Письмо не всем дается естественным путем.Особенно, если тема слишком сложная, техническая или сложная. Но поскольку ваша конечная цель — ясность, вы должны следовать нескольким простым правилам:

  1. Пишите как человек : используйте простой, ясный язык, когда это возможно. Мы все читали те документы, которые звучат так, будто Google Translate пошел не так, как надо. Если вы замечаете, что произносите неловкие предложения или сложный язык, отойдите на несколько минут. Иногда возвращение к письму после короткого перерыва — это все, что нужно, чтобы освежить сознание.
  2. Помните, ваши читатели — это не вы: Золотая заповедь технического письма — , не принимайте . Вам может показаться, что вы слишком очевидны, но вы должны четко осознавать уровень знаний вашей аудитории. Не думайте, что они знают даже наполовину меньше вас.
    Золотая заповедь технического письма — «не предполагай». Вам может казаться, что вы слишком очевидны, но вы должны осознавать уровень знаний вашей аудитории.
  3. Напишите столько, сколько нужно, чтобы быть полезным, и ни слова больше: Короткое письмо — хорошее письмо.Используйте форматирование, чтобы разбивать большие фрагменты текста и сохранять четкость в центре внимания. Как пишет технический писатель Amazon Том Джонсон: «Хороший технический писатель сокращает количество слов до нужной краткости, не делая ничего неясного».
  4. Помните о силе визуальных эффектов: Это еще одно клише, но изображения действительно говорят тысячу слов. По возможности визуализируйте то, что вы говорите, а не пытайтесь это объяснить.

Используйте правило 30/90, чтобы получить обратную связь

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

Если вы не являетесь экспертом в той теме, о которой пишете, неплохо было бы, чтобы эксперт по предмету (SME) пришел на рассмотрение после первого и окончательного черновиков. Обратная связь — это уже само по себе умение. Что касается технической документации, то один из лучших способов ее оформления — это то, что Джейсон Фридман называет «обратной связью 30/90».

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

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

Получите экспертные оценки и внесите исправления

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

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

Редактировать, редактировать и еще раз редактировать

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

Вики-сайты Planio особенно эффективны для редактирования с контролем версий, историей, ролями и разрешениями, чтобы вы и ваша команда всегда были в курсе того, кто что написал и что редактировал.

Вики-сайты Planio особенно эффективны для редактирования с контролем версий, историей, ролями и разрешениями, чтобы вы и ваша команда всегда были в курсе того, кто что написал и что редактировал.

Шаг 4: Доставка и тестирование

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

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

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

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

Наконец, проверяет удобство использования / проблемы с UX . Пользователи теряются или сбиваются с толку? Разве они не получают ответы, которые искали (или думали, что получали на основе заголовков или навигации?). Опыт пользователя сводится к большему, чем просто то, что вы написали. Найдите время поработать со сторонними тестировщиками, чтобы убедиться, что, когда реальные пользователи приходят к вашим документам, они уходят довольными.

Шаг 5. Составьте график обслуживания и обновления

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

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

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

4 дополнительных качества отличной технической документации

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

  1. Эффективность разработки и использования: Дублированный контент, неорганизованная структура и нечеткие процессы могут убить техническую документацию. Используйте такой инструмент, как wikis от Planio, чтобы сохранять организованный и эффективный контент.
  2. Актуальная информация: Нет смысла предоставлять пользователям неточную информацию или показывать им устаревшие скриншоты, которые не похожи на то, с чем они имеют дело.Поддерживайте актуальность вашей технической документации.
  3. Единый дизайн и структура: Каждый раз, когда вы вступаете в контакт с вашими пользователями, наступает время для создания вашего бренда. Придерживайтесь своего дизайна, стиля и тона во всей онлайн-документации.
  4. Доступен где угодно : Мобильная связь захватывает мир. Ваша техническая документация, как и остальная часть вашего веб-сайта или приложения, должна быть гибкой и обеспечивать удобство для пользователей на всех устройствах.

Технические документы могут воодушевить или расстроить — выбор за вами

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

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

Напишите свою собственную техническую документацию, используя наш шаблон!

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

.

Что такое функциональная спецификация?

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

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

Содержание продолжается ниже

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

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

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

  • Требования . Это формальное заявление о том, что, по мнению специалистов по планированию продукта, исходя из своих знаний о рынке и конкретного вклада существующих или потенциальных клиентов, необходимо для нового продукта или новой версии существующего продукта. Требования обычно выражаются в виде повествовательных утверждений и в относительно общем виде.
  • Цели . Цели пишутся дизайнерами продукта в соответствии с требованиями. Они более конкретно описывают, как будет выглядеть продукт. Цели могут описывать архитектуры, протоколы и стандарты, которым будет соответствовать продукт. Измеримые цели — это те, которые устанавливают некоторые критерии, по которым можно судить о конечном продукте. Измеримость может выражаться в показателях удовлетворенности клиентов или в терминах возможностей и времени выполнения задач. Цели должны учитывать ограничения по времени и ресурсам.График разработки часто является частью или следствием целей.
  • Функциональная спецификация . Функциональная спецификация (называемая функциональной спецификацией или просто спецификацией для краткости) является формальным ответом на цели. В нем описаны все внешние пользовательские и программные интерфейсы, которые должен поддерживать продукт.
  • Запросы на изменение конструкции . На протяжении всего процесса разработки, когда признается необходимость изменения функциональной спецификации, формальное изменение описывается в запросе на изменение конструкции.
  • Логическая спецификация . Структура программирования (например, основные группы модулей кода, которые поддерживают аналогичную функцию), отдельные модули кода и их отношения, а также параметры данных, которые они передают друг другу, могут быть описаны в формальном документе, называемом логической спецификацией. Спецификация логики описывает внутренние интерфейсы и предназначена для использования только разработчиками, тестировщиками и, позднее, в некоторой степени, программистами, которые обслуживают продукт и предоставляют исправления кода на местах.
  • Пользовательская документация . Как правило, все предыдущие документы (кроме спецификации логики) используются в качестве исходного материала для технических руководств и онлайн-информации, например, страниц справки, которые подготовлены для пользователей продукта.
  • План испытаний . Большинство групп разработчиков имеют формальный план тестирования, в котором описаны тестовые примеры, которые будут использовать написанное программирование. Тестирование выполняется на уровне модуля (или единицы), на уровне компонентов и на уровне системы в контексте других продуктов.Это можно рассматривать как альфа-тестирование. План также может допускать бета-тестирование. Некоторые компании предоставляют раннюю версию продукта избранной группе клиентов для тестирования в «реальной» ситуации.
  • Готовый продукт . В идеале конечный продукт представляет собой полную реализацию функциональной спецификации и запросов на изменение дизайна, некоторые из которых могут быть результатом формального тестирования и бета-тестирования.

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

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

Как написать документ функциональных спецификаций

В зависимости от проекта и команды функциональная спецификация может включать:

  • Объем проекта — цели, особенности, задачи, результаты, стоимость и сроки проекта.
  • Риски и допущения — факторы, которые могут повлиять на функциональный дизайн продукта.
  • Обзор продукта — объяснение того, как приложение решит конкретную проблему для целевой аудитории.
  • Варианты использования — функциональные требования помещаются в контекст действия пользователя. Это показывает, что происходит с точки зрения пользователя.
  • Требования — основные характеристики продукта, объясняющие его назначение.
  • Конфигурация — шаги, необходимые для настройки продукта, такие как настройка учетной записи пользователя.
  • Нефункциональные требования — второстепенные функции, которые не лежат в основе продукта.
  • Отчет об ошибках — объяснение того, как продукт будет обрабатывать ошибки или исключения.
How to write a functional specifications document Список возможных элементов, которые должны быть включены в документ функциональных спецификаций.

Форматы функциональной спецификации

Существует несколько форматов документа функциональной спецификации:

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

Преимущества функциональных характеристик

Создание документа функциональных спецификаций дает ряд преимуществ, в том числе:

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

Инструменты, используемые для функциональных спецификаций

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

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

Разница между функциональными характеристиками и техническими характеристиками

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

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

Пример функциональной спецификации

Ниже приводится пример функциональной спецификации:

Диаграмма вариантов использования — помогает изобразить взаимодействие

.