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

Содержание

Техническое задание на разработку сайта – что это и зачем нужно?

— Вы строите дома?

— Да, мы уже давно этим занимаемся и построили много домов

— Отлично, постройте мне дом!

— С радостью, а какой дом вы хотите?

— Ну, обычный. Такой с комнатами и красивый.

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

— Не, ну вы же профессионалы, давайте вы сами это все сделаете без меня. Мое задание очень простое – мне нужен удобный и красивый дом. Вы же делали такие дома, верно?

— Да, конечно. Но у нас в портфолио есть многоквартирные пятиэтажные проекты, а есть маленькие летние домики.

— Ну причем тут летние домики, мне нужен дом. Обычный в котором можно жить круглый год. Что не понятного я говорю?

— По этажности у вас есть предпочтения?

— Я еще не решил

— По системе отопления что-то планировали?

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

— Ок, а где расположен участок, на котором хотите строить?

— За городом

— Газ там подведен? Электричество?

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

Занавес

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

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

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

Составление технического задания сайта

Оформление и внешний вид

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

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

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

Объем технического задания или сколько вешать в граммах?

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

Кто должен создавать техническое задание?

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

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


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

Какие разделы должны быть в техническом задании?

Самым основным выделяют два момента – это внешний вид и функционал.

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


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


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

Что делать если читаешь техзадание, но ни слова в нем не понимаешь?

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

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

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

Все по ГОСТу или дайте мне больше и больше стандартов!

Как ни странно, но существуют ГОСТы как писать техническое задание на создание автоматизированной системы (ГОСТ 34 и ГОСТ 19). Эти стандарты, кроме всего прочего, определяют состав документа по разделам, которые необходимо написать.

Ориентируясь на ГОСТ 34 должна быть, следующая структура документа:

  1. Общие сведения

  2. Назначение и цели создания (развития) системы

  3. Характеристика объектов автоматизации

  4. Требования к системе

  5. Состав и содержание работ по созданию системы

  6. Порядок контроля и приемки системы

  7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

  8. Требования к документированию

  9. Источники разработки


Этот стандарт утвержден в 1990 году. Его более ранний собрат ГОСТ 19 от 1980 года описывает следующие разделы техзадания:

  1. Введение;

  2. Основания для разработки;

  3. Назначение разработки;

  4. Требования к программе или программному изделию;

  5. Требования к программной документации;

  6. Технико-экономические показатели;

  7. Стадии и этапы разработки;

  8. Порядок контроля и приемки;

  9. Приложения.

Стоит ли следовать данным ГОСТам? Если у вас не госзаказ, тогда потребности в этом нет. Однако, если ваш проект имеет более-менее крупный масштаб (например, планируете создавать онлайн сервис), то общие идеи и некоторые элементы по структуре можно с пользой оттуда позаимствовать.

Резюме

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

Разработка технического задания (ТЗ) по ГОСТ

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

Мы осуществляем разработку следующих видов технического задания:

ТЗ на АСУ и её составные части
ТЗ на программу
ТЗ на сайт (портал)

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

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

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

Подходы к составлению ТЗ

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

Нами выделены следующие принципы:

Совместная работа всей проектной команды
Максимально подробное описание конечного продукта
Сдача-приёмка конечного продукта.

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

ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Заказать ТЗ

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

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

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

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

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

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

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

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

Документ этот может занимать, как одну страницу А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+

Загрузка…

Пример тз на разработку программного обеспечения, как написать техническое задание

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

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

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

Структура технического задания

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

1. Оглавление
2. История изменений документа
3. Участники проекта
4. Назначение документа
5. Терминология
6. Общий контекст

class=»fs-13″>

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

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

class=»fs-13″>

7. Система размещения баннеров
8.

Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine

class=»fs-13″>

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.

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

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

class=»fs-13″>

Бизнес vs Функциональные требования

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

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

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

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

Пример бизнес-требования:

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

Пример функционального требования:

«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».

Обычно мы включаем

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

Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

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

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

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

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

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

Опыт в предметной области

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

Примеры технических задач: Concierge

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

Примеры включают …

  • Создание формы сбора потенциальных клиентов — Вам необходимо захватить потенциальных клиентов на целевой странице или на вашем веб-сайте и отправить их на вашу платформу электронного маркетинга или просто получить уведомление по электронной почте. Мы можем легко построить вам форму.
  • Автоматизация электронной почты — Написал серию электронных писем вроде (немедленно отправьте это, через 2 дня отправьте это, через 7 дней сделайте это) и хотите, чтобы это было отправлено людям, которых вы захватили в этой форме захвата лида? Мы можем это сделать.Следуйте этим инструкциям о том, как предоставить информацию об этом.
  • Обновите изображение на своем веб-сайте — Хотите изменить изображение на своем веб-сайте? Поменяли текст или цвета? Отправьте его, и мы внесем изменения.
  • Настройка формы оплаты — используя Stripe, eWay или Paypal для приема платежей, мы можем настроить форму заказа где-нибудь в вашей воронке продаж или на вашем веб-сайте. (Вам может потребоваться сертификат SSL)
  • Настройка веб-семинара в GotoWebinar — Проводите веб-семинар, но не настраивали его раньше? Отправьте детали, и мы создадим их для вас.
  • Добавьте отзывы на свой веб-сайт — Получил несколько отзывов на LinkedIn или отправил их по электронной почте, и вы хотите продемонстрировать их на своем веб-сайте, отправьте их и сообщите нам, где их разместить.
  • Создайте страницу LeadPages на своем веб-сайте — Хотите разместить свою страницу LeadPages на своем сайте так, чтобы это был www.yourdomain.com/leadpage вместо домена leadpages? Сообщите нам, какая ведущая страница и какой URL должен быть у вас, и мы его настроим.
  • Facebook, Twitter, Google, Youtube Пиксели ретаргетинга — начинаете ли ретаргетинг с помощью рекламных кампаний PPC? Обязательно отправьте коды пикселей пользовательской аудитории, и мы разместим их на всех страницах вашего веб-сайта.
  • Коды отслеживания пикселей конверсии — Если вы размещаете рекламу PPC, скорее всего, у вас есть пиксель отслеживания конверсий, который мы может разместить на странице, которую люди видят, если они успешно «конвертируются» для этой кампании.Отправьте код и укажите, на какой странице его разместить, и мы его запустим и запустим.
  • Создайте простую целевую страницу с подпиской, используя Visual Page Builder — Используя LeadPages, ClickFunnels, Thrive Architect, Divi или OptimizePress, мы можем создать для вас простую подписку или целевую страницу, используя одну из наших предопределенных структур шаблонов.
  • Дублировать существующую страницу — У вас уже есть целевая страница или структура страницы и вы хотите клонировать ее, а затем внести некоторые простые настройки и изменения? Сообщите нам, какую страницу дублировать и какие настройки нужно внести.
  • Импортируйте CSV-файл в CRM — У вас есть CSV-файл и вам нужна помощь в его импорте в свой инструмент электронного маркетинга? Отправьте его, дайте нам знать, как его сохранить, списки, теги, последовательности и т. Д …
  • Настройка пользовательского домена для Clickfunnels — Хотите, чтобы пользовательский домен указывал на ваши clickfunnels вместо yourcompany.clickfunnels.com вы хотите platform.yourdomain.com, отправьте через свои учетные данные DNS и Clickfunnels, и мы настроим его.

И многое другое…

Если вы не уверены, что мы это делаем, спросите, и произойдет одно из двух.

1. Если мы сможем это сделать, мы сделаем это правильно.

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

12-шаговое руководство по полному техническому аудиту сайта

Контрольный список для технического SEO:

12 шагов к технически идеальному месту

Мы много обсуждаем стороннее SEO.Создание, управление и аудит обратных ссылок — важный аспект SEO, и он становится все сложнее. Внутреннее SEO — тоже горячая тема; особенно сейчас, в эпоху семантического поиска Google, когда старые методы SEO не работают так хорошо, как раньше.

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

Offpage, onpage и техническое SEO

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

Предлагаю пройти пошагово по нашему контрольному списку технического SEO-аудита:

1. Проверьте индексацию.

Во-первых, давайте посмотрим, как ваш сайт индексируется поисковыми системами. Самый быстрый способ — зайти на «сайт: https: // www.доменное имя »в поле поиска.

Поиск по сайту с операторами.

Однако результаты будут хороши для второстепенных сайтов с примерно 500 URL. Чтобы проверить индексацию крупных сайтов, вы можете использовать инструмент SEO-аудита от WebSite Auditor. Запустите инструмент, введите URL-адрес вашего сайта, чтобы создать проект, и перейдите к Domain Strength , чтобы проверить индексирование.

Проверка индексации сайта с помощью Website Auditor.

В идеале это число должно быть близко к общему количеству страниц вашего сайта (которое вы можете увидеть в разделе Структура сайта> Страницы в своем проекте WebSite Auditor) за вычетом тех, которые вы намеренно запретили индексировать.Если пробел больше, чем вы ожидали, вам необходимо просмотреть запрещенные страницы. Это подводит нас к более глубокому SEO-аудиту.

2. Найдите ресурсы, индексирование которых запрещено.

У вас может возникнуть соблазн просто просмотреть файл robots.txt , чтобы убедиться, что ваши важные страницы доступны для сканирования. Но на самом деле ваш файл robots.txt — это только один из нескольких способов ограничить индексирование ресурсов. Как насчет метатега noindex, X-Robots-Tag, или страниц-сирот , на которые нет внутренних ссылок? А как насчет ваших файлов JavaScript и CSS, которые могут иметь решающее значение для рендеринга вашего контента? Для комплексной проверки возможности сканирования вам обязательно понадобится инструмент технического SEO-аудита.

Чтобы получить полный список всех заблокированных ресурсов с помощью поискового робота WebSite Auditor, перейдите к Структура сайта> Аудит сайта и щелкните Ресурсы, индексирование которых запрещено .

Зарегистрируйте ресурсы аудита сайта, заблокированные от индексации.

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

Настройте параметры обходчика в настройках проекта или при перестроении.

3. Проверьте свои URL-адреса в Google Search Console.

Общее правило заключается в том, что URL-адреса должны быть оптимизированы для SEO: то есть URL-адреса должны быть описательными (содержать ключевые слова), достаточно короткими (не превышающими 75 символов) и статическими (без «?», «_» И параметров).

В консоли поиска Google есть инструмент проверки URL-адресов, позволяющий проверить, не страдает ли конкретная страница какими-либо проблемами SEO. Инструмент предоставляет информацию о проблемах индексации, страницах AMP, связанных с URL-адресом, ошибках структурированных данных, проверяет наличие канонических и повторяющихся URL-адресов.

Website Auditor обнаруживает проблемы с URL.

Чтобы найти ошибки сканирования на сайте, перейдите к отчету об охвате в консоли поиска Google: он показывает, какие URL-адреса были правильно проиндексированы, подтверждены предупреждениями или заблокированы инструкциями robot.txt, метатегами, каноническими тегами и т. Д. Нажмите на ошибку, чтобы найти затронутые URL-адреса, исправить их и подтвердить.

Отчет о покрытии

в Google Search Console предоставляет статистику сканирования.

параметров URL в старой версии Google Search Console.

4. Проведите аудит структуры своего сайта.

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

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

Проверьте глубину перехода по внутренним ссылкам.

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

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

• Найдите бесхозные страницы.

Страницы-сироты не имеют внутренних ссылок, поэтому их сложно найти для посетителей и поисковых систем.Это означает, что если поисковые системы вообще обнаружат их, они, скорее всего, будут сканировать их довольно редко. Чтобы обнаружить их, перестройте свой проект WebSite Auditor, перейдя в Структура сайта> Страницы и нажав кнопку Rebuild Project . На шаге 2 восстановления установите флажок Искать потерянные страницы и продолжите восстановление.

Измените настройки сканера, чтобы указать поисковые инструкции.

После завершения перестройки отфильтруйте записи по тегу страницы-сироты.

Полное руководство по поисковой оптимизации по использованию внутренних ссылок см. В этом посте.

5. Проверьте свой HTTPS-контент.

Google начал использовать HTTPS в качестве сигнала ранжирования в 2014 году; с тех пор миграции HTTPS становятся все более распространенными. Сегодня, согласно отчету о прозрачности Google, 95% веб-сайтов в Google используют HTTPS.

Если ваш сайт еще не перешел на HTTPS, вы можете рассмотреть возможность миграции HTTPS. Если вы все же решите защитить себя, не стесняйтесь использовать фреймворк из примера нашего собственного перехода на HTTPS в link-assistant.com.

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

• Смешанное содержание.

Проблемы со смешанным содержимым возникают, когда в остальном защищенная страница загружает часть своего содержимого (изображения, видео, скрипты, файлы CSS) через незащищенное HTTP-соединение. Это снижает безопасность страницы и может помешать браузерам загружать незащищенное содержимое или даже всю страницу.Чтобы проверить свой сайт на наличие проблем со смешанным содержимым, в своем проекте WebSite Auditor перейдите в Site Audit> Encoding and Technical Factors .

Перенаправить содержимое HTTP на страницах HTTPS на защищенные протоколы.

• Канонические ссылки и перенаправления.

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

Убедитесь, что правильно настроено перенаправление с HTTP на HTTPS, обратите внимание на проблемы с версиями сайта с www и без www.

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

Чтобы получить исчерпывающий список всех ресурсов вашего сайта, не использующих HTTPS, перейдите на панель мониторинга Все ресурсы WebSite Auditor. Щелкните HTML в разделе Внутренние ресурсы и отсортируйте список по URL-адресу (щелкнув столбец заголовка). Таким образом, вы должны сначала увидеть перенаправленные URL-адреса ваших HTTP-страниц (код статуса 301).Для каждой найденной HTTP-страницы в нижней части экрана проверьте список Найдено на страницах , чтобы получить полный список страниц, которые ссылаются на HTTP-страницу, которую вы изучаете. Исправьте ненужное перенаправление, указав ссылку на HTTPS-версию страницы.

Исправьте существующие перенаправления HTTP.

6. Увеличьте краулинговый бюджет.

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

Старый раздел статистики сканирования Search Console.

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

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

• Позаботьтесь о неработающих ссылках.

Когда поисковый бот попадает на страницу 4XX / 5XX, единица вашего краулингового бюджета тратится зря.Вот почему так важно найти и исправить все неработающие ссылки на вашем сайте. Вы можете получить полный список из них в разделе Аудит сайта WebSite Auditor> Ссылки , щелкнув Неработающие ссылки .

Исправить неработающие ссылки.

Неработающие ссылки не только тратят ваш краулинговый бюджет, но также сбивают с толку посетителей и съедают ссылочный вес. Важно помнить, что, помимо тегов , неработающие ссылки могут скрываться в тегах , заголовках HTTP и картах сайта.Чтобы получить исчерпывающий список всех ресурсов с кодом ответа 4xx / 5xx, лучше всего проверить ресурсы вашего сайта на панели управления всеми ресурсами WebSite Auditor. Щелкните Внутренние ресурсы и отсортируйте список по Код состояния HTTP (щелкнув столбец заголовка). Теперь щелкните любой из неработающих ресурсов, чтобы увидеть, где скрываются ссылки на него.

Найдите недостающие ресурсы в разделе «Код состояния HTTP», теги ссылок.

• Исправить цепочки переадресации.

Каждое перенаправление, за которым следуют роботы поисковых систем, является пустой тратой единицы вашего краулингового бюджета.Более того, если на вашем сайте имеется неоправданное количество переадресаций 301 и 302 подряд, в какой-то момент поисковые пауки перестанут следовать по перенаправленным URL-адресам, и целевая страница может не сканироваться.

Вы можете получить полный список перенаправлений в WebSite Auditor, а также список цепочек перенаправлений, найденных на вашем сайте. Просто перейдите на панель мониторинга Site Audit и найдите 302 редиректа, 301 редирект и длинные цепочки перенаправления.

Исправьте ненужные перенаправления.

• Ограничить индексацию страниц без SEO.

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

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

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

7. Удалите дублирующийся контент с помощью проверки SEO на странице.

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

Дублированный контент может сильно навредить вашему SEO-рейтингу. Чтобы получить подсказку о дублировании контента на вашем сайте, обратитесь к разделу «На странице» на панели инструментов Site Audit WebSite Auditor. Страницы с повторяющимся заголовком и мета-тегами, вероятно, будут иметь дублированный контент и внутри сообщения блога.

Перезаписать повторяющийся контент.

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

8. Протестируйте и увеличьте скорость страницы.

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

Скорость страницы — это не только один из главных приоритетов Google, но и показатель его ранжирования как для настольных, так и для мобильных устройств. Чтобы проверить, проходят ли ваши страницы тест скорости Google, откройте свой проект WebSite Auditor и перейдите к Content Analysis . Нажмите Добавить страницу , укажите URL-адрес, который вы хотите протестировать, и введите целевые ключевые слова.Через мгновение ваша страница будет проанализирована с точки зрения оптимизации на странице и технического SEO. Переключитесь на Технические факторы и прокрутите до раздела Mobile Friendliness and Page Speed ​​, чтобы узнать, не были ли обнаружены какие-либо технические проблемы. Инструмент аудита рассчитывает оценку SEO для скорости страницы на основе показателей Google Web Core Vitals.

Тест скорости страницы для мобильных и настольных ПК; помните об индексировании с ориентацией на мобильные устройства.

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

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

Анализируйте статистику скорости сайта в Google Analytics.

9. Оптимизируйте свои страницы для мобильных устройств.

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

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

• Проверьте свои страницы на удобство использования для мобильных устройств.

Тест Google для мобильных устройств включает в себя набор критериев удобства использования, таких как конфигурация области просмотра, использование плагинов, а также размер текста и интерактивных элементов. Также важно помнить, что удобство для мобильных устройств оценивается для каждой страницы, поэтому вам нужно будет проверять каждую целевую страницу на удобство для мобильных устройств отдельно, по одной. Вы можете быстро запустить проверку в WebSite Auditor — тест Google для мобильных устройств встроен прямо в инструмент. В своем проекте перейдите к модулю Content Analysis , выберите страницу, которую вы хотите проанализировать, и введите целевые ключевые слова.Когда анализ будет завершен, просмотрите раздел Page Usability (Mobile) , чтобы увидеть, были ли обнаружены какие-либо ошибки или предупреждения.

• Проведите комплексный SEO-аудит вашего мобильного сайта.

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

Чтобы провести углубленный аудит мобильного веб-сайта, вам необходимо запустить сканирование сайта с помощью специального пользовательского агента и robots.txt настройки. В своем проекте WebSite Auditor перейдите на панель мониторинга Pages и нажмите кнопку Rebuild Project . На шаге 2 включите экспертные параметры и убедитесь, что установлен флажок Следуйте инструкциям robots.txt ; в раскрывающемся меню рядом с ним выберите Googlebot-Mobile. Справа ниже установите флажок «Обход как конкретный пользовательский агент ». В раскрывающемся меню справа выберите второй пользовательский агент в списке:

Сканирование как определенный бот и пользовательский агент.

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

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

10.Просмотрите свою карту сайта.

Вы наверняка знаете, насколько важна ваша карта сайта. Этот файл сообщает поисковым системам о структуре вашего сайта и позволяет им находить свежий контент. (Если у вас нет карты сайта, вам действительно стоит пойти и создать ее прямо сейчас. Вы можете сделать это в WebSite Auditor, просто запустив проект для своего сайта, перейдя на панель инструментов Pages и нажав Карта сайта кнопка.)

Проверяя карту сайта, убедитесь, что это:

• Чистый. Не допускайте ошибок, переадресации и URL-адресов, заблокированных для индексации, в вашей карте сайта; в противном случае вы рискуете, что поисковые системы будут игнорировать карту сайта, как будто ее там нет.
• Актуально. Убедитесь, что ваша карта сайта обновляется каждый раз, когда контент добавляется на ваш сайт (или удаляется с него) — это поможет поисковым системам быстро обнаруживать новый контент.
• Лаконично. Google не будет сканировать карты сайта, содержащие более 50 000 URL. В идеале вы должны сделать его намного короче, чтобы гарантировать, что ваши самые важные страницы сканируются чаще: технические эксперименты по SEO показывают, что более короткие карты сайта приводят к более эффективному сканированию.
• Зарегистрировано в Search Console. Сообщите Google о вашей карте сайта. Вы можете отправить его вручную в Google Search Console или указать его местоположение в любом месте файла robots.txt следующим образом: Карта сайта: http://yourdomain.com/sitemaplocation.xml

Помимо технического аудита сайта, инструменты Website Auditor для веб-мастеров позволяют быстро создавать карту сайта, а также файл robot.txt. Дополнительные сведения о файлах Sitemap см. В руководстве Google.

11. Добавьте разметку структурированных данных.

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

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

Вы можете проверить свои структурированные данные в Google Search Console: инструмент проверки URL будет сообщать о ваших расширенных сниппетах и ​​о том, какие структурированные данные не поддаются анализу.Вы также можете найти такую ​​информацию в инструменте Аудитора веб-сайтов на вкладке Страницы> Открыть график и разметку структурированных данных .

Существует несколько различных словарей для описания структурированных данных, таких как Schema.org, JSON-LD или Microdata. Для получения дополнительных сведений о разметке раздела схемы перейдите к нашему краткому руководству по SEO по структурированным данным.

12. Попросите поисковые системы повторно сканировать ваш сайт.

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

Вы можете отправить обновленные URL-адреса на повторное сканирование из Google Search Console с помощью инструмента проверки URL-адресов. Введите URL-адрес страницы, которую нужно повторно сканировать, и нажмите Запросить индексирование . Вы также можете Test Live URL (ранее известная Fetch как функция Google ), чтобы увидеть свою страницу в ее текущей форме, а затем запросить индексацию.

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

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

Аналогичная опция есть и в Bing Webmaster Tools. Просто найдите раздел «Настроить личный сайт» на панели управления и щелкните «Отправить URL-адреса» . Введите URL-адрес, который необходимо повторно проиндексировать, и Bing обычно его просканирует в течение нескольких минут.Инструмент позволяет веб-мастерам отправлять до 10 000 URL-адресов в день для большинства сайтов.

Регулярно проводить аудит сайта

И последнее, но не менее важное. Регулярный аудит сайта должен быть приоритетом в вашей стратегии SEO. Какие бы изменения ни появлялись в сети, они могут самым непредсказуемым образом влиять на рейтинг. Вот почему действительно разумно настроить инструменты SEO-анализатора для регулярных технических проверок, чтобы обнаруживать проблемы SEO и устранять их, как только они появляются. Например, вы можете запустить автоматизацию аудита сайта с помощью профессиональной версии Website Auditor: добавьте задачу, чтобы получать ежемесячный отчет о SEO-аудите с критериями, которые вам нужно контролировать, такими как трафик, обратные ссылки и т. Д.

В Website Auditor вы можете настроить отчет аудита сайта, чтобы получать данные, которые вам нужно регулярно отслеживать (индексирование, неработающие ссылки, на странице и т. Д.).

Это самые важные технические советы по SEO в 2020 году. Что вы думаете о техническом SEO как таковом? Какую тактику вы считали наиболее эффективной в последнее время? Присоединяйтесь к обсуждению и поделитесь своими мыслями в комментариях ниже.

Управление проектами — Написание пользовательских историй для внутренних технических задач

Переполнение стека
  1. Около
  2. Продукты
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
  5. Реклама Обратитесь к разработчикам и технологам со всего мира
  6. О компании

Stack Overflow — Где разработчики учатся, делятся и строят карьеру

Переполнение стека
  1. Около
  2. Продукты
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
  5. Реклама Обратитесь к разработчикам и технологам со всего мира

Техническая документация по разработке программного обеспечения: типы и инструменты

Время чтения: 22 минуты

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

Проектная документация по этапам и назначению

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

Гибкий подход и водопад

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

Водопад — это линейный метод с отдельными целями для каждой фазы разработки. Команды, использующие водопад, тратят разумное количество времени на планирование продукта на ранних этапах проекта.Они создают обширный обзор основных целей и задач и планируют, как будет выглядеть рабочий процесс. Команды Waterfall стремятся создать подробную документацию до начала любого из этапов проектирования. Тщательное планирование хорошо работает для проектов с небольшими изменениями или без них, поскольку оно позволяет точно составлять бюджет и оценивать время. Однако планирование водопада оказалось неэффективным для долгосрочного развития, поскольку оно не учитывает возможные изменения и непредвиденные обстоятельства на ходу.По данным глобального опроса KPMG Agile, 81% компаний инициировали трансформацию Agile за последние три года.

Схема цикла Agile-разработки

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

Сегодня Agile является наиболее распространенной практикой в ​​разработке программного обеспечения, поэтому мы сосредоточимся на практике документации, связанной с этим методом.

Виды документации

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

В соответствии со следующими классификациями.

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

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

  • Документация по продукту
  • Технологическая документация

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

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

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

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

Продукт: Системная документация

Документация по системе

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

Документ о требованиях к продукции

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

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

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

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

  1. Роли и обязанности .Начните свой документ с информации об участниках проекта, включая владельца продукта, членов команды и заинтересованных лиц. Эти детали прояснят обязанности и сообщат о целевых целях выпуска для каждого из членов команды.
  2. Цели команды и бизнес-задача . Кратко опишите наиболее важные цели.
  3. Предпосылки и стратегическое соответствие . Кратко объясните стратегическую цель ваших действий. Почему вы создаете продукт? Как ваши действия влияют на разработку продукта и соответствуют целям компании?
  4. Предположения. Создайте список технических или бизнес-предположений, которые могла бы иметь группа.
  5. Пользовательские истории. Перечислите или свяжите пользовательские истории, необходимые для проекта. Пользовательская история — это документ, написанный с точки зрения человека, использующего ваш программный продукт. История пользователя — это краткое описание действий клиентов и результатов, которых они хотят достичь.
  6. Критерии приемки. Это условия, которые указывают на завершение пользовательской истории. Основная цель критериев приемлемости — определить удовлетворительный результат для сценария использования с точки зрения конечного пользователя.Прочтите нашу специальную статью о критериях приема, чтобы узнать больше.
  7. Взаимодействие с пользователем и дизайн . Свяжите со страницей исследования дизайна и каркасы.
  8. Вопросы. По мере того, как команда решает проблемы по ходу проекта, у них неизбежно возникает много вопросов. Хорошая практика — записывать все эти вопросы и отслеживать их.
  9. Не работает. Составьте список того, что вы не делаете сейчас, но планируете сделать в ближайшее время. Такой список поможет вам организовать командную работу и расставить приоритеты.

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

  • Используйте ссылки и якоря . Они помогут вам упростить чтение и поиск документа, поскольку читатели смогут постепенно понимать информацию. Например, вы можете предоставить ссылки на интервью с клиентами и ссылки на предыдущие обсуждения или другую внешнюю информацию, связанную с проектом.
  • Используйте графику и инструменты построения диаграмм , чтобы лучше сообщать о проблемах вашей команде.Люди более склонны воспринимать информацию, глядя на изображения, чем читая обширный документ. Различные визуальные модели помогут вам выполнить эту задачу и более эффективно обозначить требования. Вы можете включить диаграммы в процесс создания требований, используя следующие программные инструменты построения диаграмм: Visio, Gliffy, Balsamiq, Axure или SmartArt в Microsoft Office.

Пользовательский интерфейс Проектная документация

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

Документацию UX можно разделить на этапы. Этап исследования включает:

  • Персоны пользователей
  • Пользовательский сценарий
  • Карта сценария
  • Карта истории пользователя
  • Руководство по стилю UX

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

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

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

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

Пример карты пользовательской истории с разбивкой на выпуски

Источник: feedotter.com

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

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

  • Карты сайта
  • Каркасы
  • Мокапы
  • Прототипы
  • Схемы потоков пользователя или путь пользователя
  • Отчеты юзабилити-тестирования

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

Пример структуры карты сайта

Источник: uxforthemasses.com

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

Схема работы пользователя приложения поиска работы

Источник: medium.com

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

Пример каркаса для мобильного приложения Peekaboo

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

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

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

Проектный документ архитектуры программного обеспечения

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

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

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

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

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

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

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

Схема архитектуры веб-приложения Azure

Источник: docs.microsoft.com

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

Исходный код документа

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

Документы с исходным кодом могут включать, но не ограничиваются, следующие сведения:

  • Фреймворк для генерации HTML и другие применяемые фреймворки
  • Тип привязки данных
  • Выкройка с примерами (напр.г. модель-представление-контроллер)
  • Меры безопасности
  • Прочие модели и принципы

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

Документация по обеспечению качества

В Agile есть разные типы тестовых документов. Мы выделили самые распространенные:

  • План управления качеством
  • Стратегия тестирования
  • План испытаний
  • Технические характеристики тестового набора
  • Контрольные листы испытаний

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

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

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

  • Список функций для тестирования
  • Методы испытаний
  • Таймфреймы
  • Роли и обязанности (например, модульные тесты могут выполняться командой QA или инженерами)

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

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

Техническое обслуживание и справочное руководство

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

Документация по API

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

Документация по API

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

Продукт: Пользовательская документация

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

  • конечных пользователей
  • системные администраторы

Документация для конечного пользователя

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

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

Краткое руководство по началу работы с OneNote, источник: slideshare

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

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

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

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

  • Часто задаваемые вопросы
  • Видеоуроки
  • Встроенная поддержка
  • Порталы поддержки

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

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

Документация системного администратора

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

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

Технологическая документация

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

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

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

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

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

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

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

Дорожные карты Agile-продуктов

Дорожные карты продукта

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

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

  • Стратегическая дорожная карта
  • Дорожная карта технологий или ИТ
  • План выпуска

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

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

Пример стратегической дорожной карты программного продукта

Источник: productplan.com

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

Пример технологической дорожной карты

Источник: hutwork.com

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

Пример плана выпуска

Источник: productplan.com

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

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

Инструмент общего назначения

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

  • Atlassian Confluence — самый популярный инструмент для совместных проектов, в котором есть вся экосистема для управления требованиями к продукту и написания документации.Confluence известен стабильной вики-системой и эффективным интерфейсом управления пользовательскими историями.
  • Document 360 — это база знаний самообслуживания / платформа документации по программному обеспечению, разработанная для продуктов «Программное обеспечение как услуга».
  • bit.ai — это инструмент для совместного создания, хранения документации, обмена данными и использования вики-системы. Документация интерактивна, что означает, что разработчики могут встраивать блоки или фрагменты кода прямо в документ и делиться им одним щелчком мыши. Закончив редактирование документации, вы можете сохранить ее в формате PDF или в формате markdown и опубликовать на любой другой платформе.
  • Github не нуждается в представлении, за исключением тех, кто хочет использовать его для документации по программному обеспечению. Он предоставляет вам собственную вики-систему и позволяет конвертировать вашу документацию в привлекательные витрины веб-сайтов.

Редакторы Markdown

Поскольку документацию по программному обеспечению легче использовать в сети, ее необходимо создавать в надлежащем формате. Вот почему используются текстовые языки разметки. Самый популярный из них — Markup, который легко конвертируется в HTML, не требует специальных знаний для его использования.Разметка используется на GitHub и Reddit и практически везде для веб-документации. Итак, вот несколько редакторов Markdown, которые могут быть полезны для создания документов для вашего проекта:

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

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

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

Инструменты для документации UX

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

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

Интерфейс эскиза

  • InVision — один из самых популярных инструментов для создания прототипов. InVision славится своими функциями совместной работы и кроссплатформенными возможностями, что делает его отличным инструментом для разработки будущих интерфейсов.
  • UXPin — это инструмент для проектирования Mac и Windows, который позволяет создавать любые типы чертежей. Вы также можете загрузить свои эскизы или каркасы из других продуктов и сделать из них интерактивный прототип.
  • Adobe XD — где XD означает опыт дизайна.Продукт ориентирован на UX-специалистов. Это позволяет дизайнерам создавать прототипы с высокой точностью и делиться ими через приложение.

Инструменты для документации API

Чаще всего процесс создания документации API автоматизирован. Программисты или технические писатели могут писать документацию вручную или использовать генераторы документации API:

  • Swagger — это бесплатный программный сервис с самодокументированием, предназначенный для создания и обновления веб-сервисов и API RESTful.
  • RAML 2 HTML — это простой генератор документации, использующий спецификации RAML.

Инструменты для технических писателей

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

  • MadCapFlare — мощное облачное программное обеспечение с функцией многоканальной публикации, многоязычной поддержкой, обширными учебными ресурсами и многим другим.
  • Adobe RoboHelp — полнофункциональная CMS, которая позволяет создавать мультимедийный контент, удобное управление микроконтентом, совместную работу для контроля версий и т. Д.
  • ClickHelp — отмеченная наградами платформа, предлагающая простой переход с других программ, гибкие варианты разрешений и ряд возможностей отчетности.

Образцы и шаблоны программной документации

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

Шаблоны общей проектной документации

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

  • Atlassian Confluence Templates предлагает готовые шаблоны проектной документации общего назначения вместе со своим продуктом.
  • ReadySET Pro — это большая библиотека шаблонов документации по программному обеспечению в формате HTML, которая включает документы по планированию, архитектуру, дизайн, требования, тестирование и многое другое.
  • ReadTheDocs — это универсальный шаблон, созданный на платформе ReadTheDocs, содержащий инструкции по написанию каждого типа документа, который может вам понадобиться, от архитектуры и диаграмм UML до руководств пользователя.

Шаблоны дорожных карт продуктов

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

Шаблоны документации по обеспечению качества

Если вы все еще ищете шаблоны, связанные с контролем качества, вы можете проверить здесь:

  • StrongQA.com есть различные шаблоны документации для QA-специалистов. К ним относятся контрольные списки тестирования, шаблоны дымового тестирования, планы тестирования и многое другое.
  • Template.net имеет раздел с шаблонами планов обеспечения качества.
  • EasyQA предлагает SDK для тестирования программного обеспечения и шаблоны с подробным руководством по созданию качественного плана тестирования.
  • Тестирование программного обеспечения — это большая платформа, включающая блог, форум и всевозможные информационные материалы для специалистов по тестированию.

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

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

Примеры специализированной архитектуры: AWS, Microsoft Azure и Google Cloud

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

  • Amazon — Центр архитектуры AWS предоставляет рекомендации по архитектуре AWS, платформы, инструменты и передовые методы выполнения архитектурных рабочих нагрузок в облаке.
  • Microsoft — этот ресурс предлагает множество полезных материалов по архитектуре Azure, включая примеры сценариев, диаграммы архитектуры и многое другое.
  • Google — посетите официальную библиотеку иконок с образцами для построения архитектурных схем Google Cloud.

Как писать документацию по программному обеспечению: общие советы

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

Напишите достаточно документации

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

Учитывайте свою аудиторию

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

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

Использовать перекрестные ссылки

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

Не игнорируйте глоссарии

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

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

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

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

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

Документация — совместная работа всех членов команды

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

Нанять технического писателя

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

Дополнительные советы по созданию и поддержке документации

Вот еще несколько предложений, которые помогут вам оптимизировать и ускорить процесс написания документов и дальнейшего управления:

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

Заключительное слово

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

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

Векторные изображения Техническое задание

, Стоковые векторные изображения Техническое задание

и Роялти-Фри Изображения Техническое задание | Бизнес-мультфильм женщина, трудолюбивая в офисе. Многие задачи концепции, векторные иллюстрации картинки, сервисные инструменты значок, бесшовный фон с математическими формулами.EPS 8Современный рабочий знакФизический бесшовный образец с уравнениями, графиками и другими вычислениями. Научный вектор бесшовный образец с физическими и математическими рисунками, решениями задач, графиками, проектами, формулами, «рукописным на старой бумаге» Индекс мастераМатематический бесшовный образецБесшовный образец математической операции и уравнение, бесконечный арифметический узорКруглый значок гаечного ключаМатематическое дерево для вашего дизайнаВектор бесконечной текстуры с прекрасной девушкой, сидящей за столом вокруг математических формул, думающих и решающих задачи, «написано от руки на бумаге сетки для тетрадей» ПРОФЕССИЯ.Слово коллаж на белом фоне. Бизнес мультфильм женщина, трудолюбивая в офисе. Многие задачи концепции, векторные иллюстрации клипартыБесшовный фон с математическими формулами на доскеФорма сердца с математическими формулами для вашего дизайнаМатематическая бесшовная текстураПрототипирование и моделирование 2×2 Концепция дизайнаМеханический бесшовные векторные фоновый узор. Математический научный вектор бесшовных текстур с рукописными графиками и формулами, физическими расчетами. Векторный фон естественных наук.Бесшовный узор из формул по астрономии на белом фоне. Обратно в школу черные баннеры с каракулями, желтый школьный автобус. Ремесленник с ящиком для инструментов. Синий и электрический цветаОбразовательная игра в тени с роботамиТени с роботами раскраскаAppleАбстрактный бесшовный векторный узор. Механический. Изолированный. Розовый, фиолетовый и whitemechanical бесшовные векторные фоновый узор. Желтый, зеленый, бежевый цветаМеханический. Изолированный. Розовый, фиолетовый и синий цвета. Ремесленник персонаж с инструментом. Бесшовный узор из формул на геометрии, изолированные на белом. Слово коллаж на белом фонеХудожники и мастераЖонглирование инструментамиКрасивый физический вектор бесшовные модели, «написано от руки на бумаге для тетради», разные цветаСтроительный шлемКрасивый вектор бесшовные модели «Я люблю физику», «написано от руки на бумаге для тетрадей» Бесшовный фон с математическими формулами на доскеРабочие иконки ромбИнструмент IconSeamless узор из формул и каракулей школьных предметов isoService Инструменты IconWrenches IconBinder Свойства IconФорма сердца с математическими формулами для вашего дизайнаЧерная доска в деревянной рамке — vectorPROFESSION.Слово коллаж на белом фонеПользовательская разработка и тестированиеПрототипирование и моделирование горизонтальных баннеровСервисный план значокБесшовный фон с математическими формулами на доскеОфисной работник значокМатематическая коллекция: рамка, дерево, бесшовный фонПроблемаРабочий день значокДжентльмен работает за часами значокБизнес мультфильм женщина, усердно работает в офисе Концепция многих задач, векторные иллюстрации клипаЧерная доска в деревянной рамке — векторПрототипирование и моделирование ИконкиЗначок водоснабженияЗначок сервисных инструментовЗначок водоснабженияРаботник с домомНабор векторных иконок гаечный ключ 24PROFESSION.
Оставить комментарий

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

Ваш адрес email не будет опубликован.

© 2019 Штирлиц Сеть печатных салонов в Перми

Цифровая печать, цветное и черно-белое копирование документов, сканирование документов, ризография в Перми.