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

Содержание

что это такое и как правильно составить

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

Какие преимущества получат стороны от правильно подготовленного ТЗ для сайта?

Для заказчика:

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

Для исполнителя:

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

Что такое техзадание и зачем оно нужно?

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

Главная цель ТЗ: удостовериться, что клиент и исполнитель правильно поняли друг друга.

Кто составляет ТЗ для сайта?

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

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

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

Какая информация должна быть отражена в ТЗ?

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

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

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

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

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

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

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

Требования к интеграциям. Отдельно требуется указать, что необходимо интегрировать на сайт. Это могут быть различные сервисы: CRM-системы, 1С, iiko, сервисы email рассылок, коллтрекинг, программы лояльности, средства аналитики и другие. Все необходимое для ведения бизнеса лучше указать сразу, чтобы не растягивать процесс разработки или вообще остановить его.

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

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

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

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

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

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

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

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

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

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

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

Общая информация о будущем проекте
Цели разработки проекта
Маркетинговые исследования
Бизнес-процессы
Структура проекта по разделам и типовым страницам
Содержимое типовых страниц
Функционал
Требования к интеграциям
Требования к административной части
Группы пользователей и доступы
Требования к серверу, безопасности и браузерам
Требования к дизайну
План по интернет-продвижению
Требования к обучению и документации
Дополнительные требования и материалы

Нужна всего лишь доработка существующего веб-сайта? Можно сократить количество пунктов:

Цели доработки проекта
Бизнес-процессы
Структура проекта по разделам и типовым страницам
Содержимое типовых страниц
Функционал
Требования к интеграциям
Дополнительные требования и материалы

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

Нужна наша помощь — свяжись с нами!

Поделитесь с друзьями:

ТЗ на разработку сайта || Artmebius

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

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

Информация будет полезна:

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

Что такое ТЗ

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

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

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

Клиенту техническое задание помогает:

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

Исполнителю ТЗ полезно, чтобы:

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

ТОП-8 советов: как составить хорошее техническое задание

Избегайте двойственности

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

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

Яркий пример такой ошибки — дизайн этого сайта. Для кого-то это вполне соответствовало фразе «сделайте красиво».

Самые частые штампы:

Должен нравиться. Кому? Какие критерии этого самого «нравится»?
Удобный. Для чего? Какому пользователю — школьнику с телефоном или бабушке с допотопным компьютером?
Выдерживать большие нагрузки. 10 тысяч пользователей? 100? Или несколько миллионов?
Наполнен экспертным качественным контентом. Какие статьи считать экспертными? Под какую ЦА делается ресурс?

Вместо расплывчатых формулировок даём чёткие указания:

Не «быстрый», а «90 баллов в Google PageSpeed Insights».
Не «выдерживает большой поток пользователей», а «100 тысяч человек ежедневно».
Не «помещаем в этот блок статьи», а «делаем рейтинг из 5 самых популярных публикаций».
Не «минималистичный стильный дизайн», а готовый схематический эксиз.

Помните о цели и задачах

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

Не забываем и про функционал. Конкретно прописываем — новостной портал, блог, интернет-магазин, форум.

Прописывайте технические требования

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

Обязательно прописываем:

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

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

Создавайте структуру

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

Чтобы получить хорошо структурированный сайт, нужно:

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

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

Делайте прототипы страниц

Прототипы страниц — это описание того, какие элементы должны на них располагаться.

Создавать их можно двумя способами:

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

Пишите сценарии использования

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

Например:

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

Типичная структура «действие — ответ сайта — результат».

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

Определитесь с контентом

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

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

Опишите дизайн

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

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

Структура ТЗ

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

В документе нужны такие разделы:

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

С таким ТЗ у вас не возникнет недопониманий и бесконечных доработок.

Техническое задание — обзор дизайна

ЧЛЕН КОМИССИИ ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

РОЛЬ КОМИССИИ

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

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

Группа рассмотрит следующие темы.

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

В зависимости от этапов рассмотрения проекта, ниже приводится руководство по ожидаемым чертежам и описаниям.

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

РУКОВОДСТВО ПО ПРОВЕРКЕ КОНСТРУКЦИИ

Пожалуйста, перейдите по ссылке в прикрепленном файле, чтобы прочитать Руководство по оперативной доставке панели проверки DW. Также см. публикацию Design Review Principles & Practice 2013 года.

ЧЛЕНСТВО В КОМИССИИ

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

Около 70 членов Комиссии были набраны в результате открытого конкурса кандидатов. Большинство из них представлены на нашем сайте. Большинство членов Группы живут и/или работают на западе Англии. Если нужен специалист, мы можем обратиться к более широкому национальному пулу членов Комиссии, предоставленному через The Design Network, но это бывает редко.

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

КОНФЛИКТЫ ИНТЕРЕСОВ

Члены комиссии должны обсудить любые возможные конфликты интересов в диалоге с руководителем комиссии, который проверит это с заявителем и МПУ. Любые согласованные непредвзятые заявления будут доведены до сведения на заседании Группы проверки DW, и они будут зарегистрированы и включены в окончательный отчет. Если оно носит предвзятый характер, то член Комиссии не будет принимать участие в рассмотрении.

Для справки, Конфликт интересов может иметь место, когда член Группы заинтересован в предложении из-за:

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

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

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

КОНФИДЕНЦИАЛЬНОСТЬ

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

Участники DW Review получат справочные материалы от заявителя/разработчика по схеме, которая будет рассмотрена заранее. Это будет отправлено через диспетчера панели и должно оставаться конфиденциальным, даже если обзор находится в «живом» приложении планирования.

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

Копия отчета будет предоставлена всем участникам. В письме будет четко указано его конфиденциальный статус. Письмо будет исправлено только в случае фактической ошибки (например, в написании географического названия), и оно будет повторно разослано всем участникам с разъяснением причины ошибки. Если обзор DW предоставляется на этапе, предшествующем заявке, то отчет не публикуется (за исключением случаев, когда это согласовано разработчиком и LPA в ходе консультаций). Если обзор ХД предоставляется при подаче заявки на планирование, то отчет становится общедоступным документом и может быть опубликован на портале планирования. Разработчику рекомендуется ссылаться на рекомендации группы проверки DW и любые предыдущие письма в Заявлении о дизайне и доступе, представленном вместе с заявкой на планирование. Это рассказывает историю эволюции дизайна схемы и поможет обосновать принятый подход. Предыдущие справочные «рабочие чертежи» не будут опубликованы, только письмо с обзором DW.

План развития

Группа проверки DW будет придерживаться NPPF и системы, основанной на плане, но также не стесняется оспаривать и проводить проверки по своему усмотрению. Еще одним важным справочным материалом являются Национальное руководство по проектированию и Национальный кодекс по проектированию моделей. Группа также может ссылаться на другие методологии и рекомендации по проектированию, такие как «Строительство для здорового образа жизни», «Руководство для улиц», «Смена передач» и LTN 1/20.

Местные органы власти предоставят обзор политики на обзоре DW из принятого или разрабатываемого местного плана, других политик, SPD и т. д. Местным органам власти не обязательно представлять свои окончательные формальные взгляды на схему (поскольку на нее может повлиять ДРП). Координатор LPA обрисует политический контекст и расскажет об аспектах, которые могут вызывать у него озабоченность, в которых они поддерживают схему, и если есть вопросы, которые они особенно хотели бы, чтобы комиссия рассмотрела.

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

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

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

ПОСЕЩЕНИЕ ОБЪЕКТА

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ ПО РАЗМЕЩЕНИЮ И РЕДИЗАЙНУ ВЕБ-САЙТА УГАНДЫ ДЛЯ ЧЕЛОВЕЧЕСТВА.

Habitat for Humanity Уганда ищет консультанта или фирму с соответствующим опытом для разработки и создания всеобъемлющего веб-сайта, который обеспечивает заметное присутствие в Интернете для программ HFHU и предлагает функциональные возможности для его членов. Техническое задание (ТЗ) служит запросом предложений от фирм/компаний, заинтересованных в предоставлении этих услуг.

ВВЕДЕНИЕ

Habitat for Humanity Uganda (HFHU) является филиалом Habitat for Humanity International (HFHI), чьи усилия направлены на содействие ликвидации бедности в мире.

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

С момента основания в 19 г.82, HFHU Построил, восстановил, отремонтировал или улучшил более 40 000 единиц жилья в Уганде , чтобы предоставить простое, достойное и доступное жилье более чем 240 000 человек.

ОБЗОР ЗАДАЧ

(a) Утвержденный дизайн веб-сайта, включая внутренние страницы, в течение 4 недель после подписания договора;

(b) Каркас всего веб-сайта в течение как минимум 1 недели после утверждения дизайна;

(d) перенос контента со старого веб-сайта в соответствии с форматом, используемым HFHU, который должен быть завершен в течение 2 недель после завершения этапа программирования;

(e) этап бета-выпуска/тестирования на сервере поставщика в течение четырех рабочих дней;

(f) Веб-сайт для переноса и настройки на рабочем сервере

(g) Обслуживание после этого до декабря 2023 года.

(h) Доменное имя доступно с HFHU.

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

Обучение

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

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

Поставщик услуг предоставит Habitat for Humanity соответствующие электронные и бумажные копии руководств пользователя для веб-сайта. Руководства должны включать административные функции и статистические модули, описывать все функции CMS и подробно объяснять процессы добавления контента, редактирования контента и удаления контента с пошаговыми инструкциями и соответствующими изображениями для каждого процесса.

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

ОСНОВНЫЕ РЕЗУЛЬТАТЫ РЕЗУЛЬТАТОВ

Нанятая компания/поставщик/агентство должна будет создать (спроектировать, разработать, протестировать и внедрить) веб-платформу в установленные сроки, соответствующую следующим критериям:

ДИЗАЙН N
Создание эстетически и визуально привлекательного, удобного в использовании и адаптивного дизайна веб-сайта, который прост в обслуживании и обновлении и совместим с ПК, MAC, мобильными телефонами и планшетами
Управление контентом: решение должно позволять уполномоченному персоналу проекта (или назначенному персоналу) редактировать и обновлять веб-сайт, включая возможность создавать, удалять, редактировать и публиковать контент. людям с нарушениями зрения и слуха для доступа к веб-сайту
Создайте 6 шаблонов для обмена информацией, связанной с событиями, публикациями, изображениями, блогами и потоковым видео.
Блоки новостей сайта/актуального контента: веб-решение предоставляет области контента/экрана, содержащие: Календарь, Предстоящие события, Последние новости/Новости сайта Актуальные темы

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

Агентство веб-разработки должно настроить веб-сайт на сервере, одобренном и арендованном HFHU.
Предоставить документацию по настройке и настройке CMS с учебным пособием (со снимками) для обновления каждого раздела/страницы веб-сайта

B. ХОСТИНГ ВЕБ-САЙТА поставщик, предоставляющий услуги хостинга со следующим:

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

0004

Нанятое агентство веб-разработки

предоставит авторизованным пользователям отчеты о статистике/управлении сайтом с несколькими соответствующими отчетами, например, о регистрации пользователей, использовании сайта, ключевых интересах/темах
, чтобы гарантировать, что веб-сайт может обеспечить интеграцию с социальной сетью:
Обсуждается в рамках совместных пространств и других соответствующих статистических данных.
Чтобы гарантировать SEO с помощью 10-15 ключевых слов, предоставленных HFHU, включая анализ сайта, конкурентный анализ, оптимизацию контента сайта, оптимизацию HTML-кода, отправку в заслуживающие доверия поисковые системы, обмен ссылками и отчет о рейтинге в Интернете.
Проверка неработающих гиперссылок на сайте. Поставщик услуг должен регулярно проверять работоспособность сайта и возвращаться к резервному копированию при необходимости, сообщая об этом сотрудникам HFHU по номеру
. Требуется пройти проверку безопасности уполномоченным органом. Сертификат должен быть доступен команде HFHU. Продавцу предлагается нанять сертификат SSL и соответствующий контроль доступа для веб-сайта HFHU.
гарантирует, что инфраструктура сайта будет исправлена с последними исправлениями и обновлениями безопасности в случае с открытым исходным кодом,
Принять все разумные и необходимые меры для обеспечения целостности контента от вредоносных программ и/или хакерских действий.
Поддерживать резервную копию файла с базой данных веб-сайта в течение всего срока действия контракта. Бэкап нужно делать каждую неделю.
Резервная копия веб-сайта, код и исходные файлы будут доставляться клиенту в полном объеме в конце каждого квартала.
Любой выполненный веб-дизайн, анимация и т. д. будут переданы в высоком разрешении / формате PSD / в редактируемых файлах сотрудникам HFHU.
Обеспечить поддержку на месте и обучение назначенного персонала HFHU как интерфейсу администратора, так и базовому обслуживанию архитектуры и дизайна сайта, а также загрузке/размещению и т. д. контента на веб-сайте.
На этапе обслуживания нанятое агентство веб-разработки будет ежемесячно предоставлять подробные отчеты о производительности веб-сайта в отношении SEO и посещаемости веб-сайта.
Предоставление специального узлового сотрудника для HFHU для решения вопросов, связанных с веб-сайтом, а также для обновления контента, особенно по срочным вопросам
Календарь, события, напоминания, интеграция календаря: определенные авторизованные пользователи должны иметь возможность создавать и администрировать события и сведения о событиях. Другие пользователи должны иметь возможность искать и находить события на основе определенных критериев. Участники должны иметь возможность получать уведомления о запланированном мероприятии и напоминания о предстоящих мероприятиях.
Система управления документами (DMS): Загрузка документа/видео/аудио (файл любого формата) с описанием – Кто загрузил – Дата загрузки – Формат файла и т. д., создание новой соответствующей страницы (при необходимости), Наведение курсора на описание файла Загружаемое изображение с именем (совместимым с основными ОС и браузерами) должно быть загружено с соответствующими метаданными, включая обязательные ключевые слова/теги/поля (будет решено позже) – для внутренней поисковой индексации.

Документы, которые должны быть представлены во время подачи предложения
Ссылка на последние 5 завершенных или текущих проектов веб-сайта с контактной информацией: идентификатор электронной почты, номер мобильного телефона, организация/учреждение/компания и наименование;
Справочная информация о компании/частном лице, других реализованных проектах развития и резюме ключевого персонала, который будет заниматься этим заданием;
Портфолио, содержащее ранее разработанные вспомогательные материалы для веб-сайта/другую соответствующую информацию, связанную с дизайном, которая поможет нам понять эстетику агентства и чувствительность дизайна
Раздел, объясняющий компетентность и опыт организации в выполнении аналогичных заданий;
Предлагаемая стратегия/методология, рабочий план, сроки и бюджет задания;
Подробный бюджет на дизайн, разработку и обновление контента веб-сайта HFHU

Подробный бюджет на ежегодное обслуживание веб-сайта HFHU и
Подробный бюджет на хостинг (с разбивкой) веб-сайта HFHU на один год

900 03 РАСПИСАНИЕ ВРЕМЕНИ /ПРОДОЛЖИТЕЛЬНОСТЬ

Вся работа должна быть завершена в течение 30 дней после заключения контракта. Уточнены сроки выполнения работ.

СОБСТВЕННОСТЬ

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

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

9. РЕЗУЛЬТАТЫ

1. Полнофункциональный веб-сайт

2. Руководство пользователя/Руководство по эксплуатации

3. Подробное системное руководство

4. Другое связанное программное обеспечение.

5. Актуальное портфолио и образцы работ

6. Коды пользователей и все необходимые коды

УСЛОВИЯ ОПЛАТЫ

Оплата производится в следующем порядке:

30% Депозит оплачивается проверка по договоренности, после этого еще 50% будут ОПЛАЧЕНЫ, когда веб-сайт будет полностью функциональным, и 20% после гарантийного периода.

Оплата производится чеком в соответствии с финансовыми правилами и положениями HFHU.

Консультант обязан уплатить 5% налога у источника, как это предусмотрено в налоговом законодательстве Уганды,

КРИТЕРИИ ОЦЕНКИ ПРЕДЛОЖЕНИЙ

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

Техническая и финансовая оценка будут иметь вес 70% и 30% соответственно.

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

1. Экспертиза фирмы [30 баллов]

2. Методология, ее соответствие условию и своевременность плана реализации [20 баллов]

3. Квалификация ключевого персонала, предложенного для назначения [20 баллов]

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

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