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

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

Какую роль играет ТЗ в разработке приложения

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

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

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

Этапы разработки технического задания для приложения

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

Идеологический этап

Первое, что должно стать ясно специалистам — какая цель у продукта, над которым они работают. И формулировки “Чтобы приносило бизнесу прибыль” недостаточно. 

Маркетинговые исследования

Все начинается с исследований (полевые или кабинетные):

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

Определение механизмов работы приложения

Цели есть. Следующий этап — понять, как продукт будет этих целей достигать. Оговариваются механизмы и технологии, использованные в приложении, решаются вопросы из сектора “Как?”:

1. Как организована структура приложения?
2. Как отображается информация в интерфейсе?
3. Как реализуются функции приложения (какие технологии используются для их реализации)? 
4. Как осуществляется монетизация мобильного приложения?
5. Как (в каком направлении) развивается продукт в дальнейшем?

Последний пункт обрисует программу апдейтов приложения, что защитит в будущем от проблем реализации этих апдейтов. Попросту говоря — защитит от ситуаций “Работает — не трогай”. 

Поиск примеров похожей реализации

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

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

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

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

Мухи — отдельно, котлеты — отдельно

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

1. Конкретика. Если есть требование к фону — это условие не должно быть в виде “Белый фон”. Это должны быть конкретные параметры RGB или HEX-код цвета. Если есть требование к шрифту — это не “Шрифт классический с засечками среднего размера”, а точное название “Times New Roman размер 18pt” и т.д. 
2. Разделение полномочий. В работе участвуют дизайнер и программист. Это значит, что первый отвечает строго за то, как выглядит интерфейс приложения, а второй — как это реализовать в коде. И у них не должна болеть голова за обязанности друг друга.
3. Факты вместо оценок. Никаких “красиво”, “полезно”, “читабельно”.
   Уважающий себя разработчик понимает, что у каждого — свои понятия и оценки, и соглашаться работать с таким ТЗ — соглашаться работать бесплатно и удовлетворять капризы заказчика, пока тому это не надоест.
4. Пункт “на усмотрение разработчика”. Все нюансы готового продукта учесть не получится, а задерживаться из-за решения каждой мелочи, о которой просто не подумал заказчик — контрпродуктивно. На этот случай существует пункт “Все не оговоренные детали решаются на усмотрение разработчика”. Так проект будет в безопасности от просрочек.

Чем отличается профессиональное ТЗ от обычного

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

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

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

В каких случаях заказчик может создать ТЗ сам:

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

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

Разработка технического задания командой специалистов

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

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

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

Как выбрать себе подрядчика по техническому заданию

1. Выше мы упомянули только дизайнера, разработчика и маркетолога, которые по стандарту привлекаются к составлению ТЗ. Но для каждого случая может потребоваться своя команда специалистов, отвечающих за разные сферы разработки. Поэтому у подрядчика, предоставляющего услуги по составлению ТЗ, должны быть сотрудники, не просто собранные в команды на проектную работу, а проверенная, постоянная команда профессионалов всех возможных специализаций в сфере разработки приложений, которые примут активное участие в проекте ТЗ для будущего мобильного приложения.
    
2. Оптимально, если подрядчик, составляющий ТЗ сам является разработчиком, представляет собой компанию полного цикла — от проведения исследований рынка и разработки концепции будущего товара или услуги до, непосредственно, воплощения готового продукта в жизнь. Такой подход гарантирует, что участники команды-подрядчика способны оценить все возможности и риски выведения новой торговой марки, и на любом из этапов этого процесса предпримут действия, которые принесут успех будущему бренду.
3. Следующим требованием является понимание подобранной команды специалистов целей приложения клиента, в каких условиях ему придется существовать — на рынке вообще, и в конкретной нише. Это значит, что для команды важен опыт в разных проектах, наличие кейсов работы над известными брендами. Если в портфолио у агентства торговые марки, о которых лично вы, как рядовой потребитель, не слышали — каков шанс, что такая команда сделает ваш продукт известным?
4. Об известности. Специалист, приступая к работе в какой-то сфере, первым делом, создает собственную торговую марку. Будет ли это персональный брендинг (т.е., брендинг, как личности), или презентация своего продукта или сервиса — подрядчик должен сначала создать узнаваемое имя себе, а потом уже предлагать свои услуги клиентам. Успешный личный пример — единственный пример, не вызывающий сомнений и вопросов. 

Разработка ТЗ для мобильного приложения от агентства KOLORO

Агентство KOLORO — это команда специалистов, имеющих за плечами опыт вывода торговых марок на рынок и превращения их в звезд своей ниши, в бренды-лидеры. За время своей работы мы выпустили более 1000 товаров, ежедневный доход от их продажи переваливает за 1 млрд долларов. Это больше, чем бюджет некоторых стран мира.

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

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

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

Хотите быть владельцем бренда, который вдохновляет? Обращайтесь за консультацией к нашим менеджерам по телефону +38 (044) 223 51 20 или по e-mail: [email protected]. 

Примеры кейсов можно посмотреть здесь.

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

Главная \ Компания \ Техническая информация \ Примеры технических заданий на проектирование \ Прочие примеры технических заданий \ Пример технического задания проект многофункционального бизнес-центра

 

№	Перечень основных данных и требований.	Сведения об основных данных и требованиях.
1.	Заказчик.
2.	Основание для проектирования.	Согласованный акт выбора земельного участка под строительство, общей площадью 1600 кв.м., технические условия.
3.	Вид строительства.	Новое строительство.
4.	Стадия проектирования.	Рабочий проект.
5.	Основные технические показатели.	Здание в 2 этажа.
6.	Указания по объемно-планировочному решению. Основные характеристики здания.	Здание  общей площадью 2500 кв.м. переменной этажности, состоящее из 4-х корпусов, расположенных квадратом, с образованием внутреннего двора, с прозрачной крышей для естественного освещения. Фронтальный корпус  является зданием бизнес-центра, 3 двухэтажных корпуса, расположенных  П-образно,  образуют с корпусом бизнес-центра замкнутый квадрат, являются зданием бизнес-инкубатора. По периметру внутреннего двора, на втором этаже предусмотреть открытый балкон-галерею. В корпусе бизнес-центра:    А. Парадный вход с пандусом для инвалидных колясок, вестибюль с гардеробом, стойкой портье и площадью для службы информации и копи-центра и парадной лестницей на 2-й этаж, а также санузлы. Б.На 1-м этаже расположить выставочный зал, площадью 250кв.м, предусмотреть возможность мобильных перегородок с целью, при необходимости увеличить выставочные площади за счет атриума, а также предусмотреть отдельный вход для размещения габаритных экспонатов. В.На 1-м этаже расположить кафе- ресторан на 40 посадочных мест с кухней и отдельным хозяйственным входом. Кафе-ресторан открытого типа, пространственно сообщается с внутренним двором. Г.На 1-м этаже расположить интернет-кафе на 10 посадочных компьютерных мест, совмещенное с деловой библиотекой. Д.На 1-м этаже расположить 2 офиса для встреч, переговоров, презентаций, семинаров, один -площадью 25 кв.м и второй -площадью 40 кв.м. Е.На 1-м этаже расположить небольшую торговую галерею на 3 торговые точки, для торговли бизнес-литературой, канцтоварами и расходными материалами, сувенирами. Ж.На 2-м этаже расположить конференц-зал площадью 250 кв.м, на 130 посадочных мест, предусмотреть мобильные перегородки, позволяющие при необходимости разделять зал на 2 или 4 части для автономного одновременного использования площадей. З.На 2-м этаже расположить 2 учебные комнаты по 25 кв.м. И.На 2-м этаже расположить офисы торгово-промышленной палаты по типу open space с мобильными перегородками для возможности свободного планирования офисного пространства, площадью 160 кв. м., включая санузлы. К.На 2-м этаже расположить кабинет директора с секретарем, бухгалтерию,2  кабинета для консультантов, комнаты для персонала, санузлы. М.В цокольном этаже расположить помещения технических и вспомогательных служб. В корпусах бизнес- инкубатора: А. Предусмотреть отдельный вход в бизнес- инкубатор с пандусом для инвалидных колясок, отдельную лестницу на 2-й этаж. Б. 30 однотипных офисных помещения, площадью 25 кв.м каждое, выходящих во внутренний двор на 1-м этаже и на балкон- галерею на 2-м этаже, расположенные блоками по 2 офиса с единым тамбуром   площадью 5,5 кв.м.  Перегородки между офисами в одном блоке должны  легко убираться, при необходимости соединить пространство в одно офисное помещение. В. На 1-м этаже -15 офисов, 3 помещения общего пользования по 18 кв.м каждое, 2 комнаты техперсонала и санузлы. Г. На 2-м этаже -15 офисов, 3 помещения общего пользования по 18 кв.м каждое, 2 комнаты техперсонала и санузлы. Д .Здание корпусов бизнес-инкубатора должно быть спроектировано таким образом, чтобы при необходимости строительства 2-й очереди была возможность примыкания следующих корпусов бизнес-инкубатора. Е. Пространственное сообщение внутреннего двора с помещениями всего первого этажа бизнес-центра и бизнес-инкубатора сделать максимально открытым. Ж.При планировке офисных помещений, кабинетов, комнат для переговоров и обучения предусмотреть встроенную мебель.
7.	Основные требования к архитектурно- планировочному решению, отделки здания.	Архитектурно- планировочное решение бизнес-центра согласовать с заказчиком.
8.	Основные требования к конструктивным решениям и материалам несущих и ограждающих конструкций: -тип фундаментов- -перегородки- -перекрытия- -тип окон- -двери- -кровля- -санузлы- -тип лестниц-	Стены наружные и внутренние- монолитный железобетон. Монолитные. Монолитные. Монолитные. Пластиковые с двойным стеклопакетом, открывающиеся в двух положениях для проветривания помещений. Межкомнатные деревянные. Шатровая- плоская, стеклянный купол над внутренним двором. Согласно СНиП. Сборный,  ж/ б марши и площадки.
9.	Отопление.	Центральная система отопления с нижней разводкой из пластиковых труб от собственной газовой котельной. Нагревательные приборы – радиаторы алюминиевые.
10.	Вентиляция	Вентиляция естественная, в пищеблоке принудительная. Кондиционирование центральное.
11.	Водопровод, канализация и горячее водоснабжение.	От городской сети, согласно ТУ. Материал труб для внутренних сетей- трубы полиэтиленовые. Установить счетчики холодной и горячей воды.
12.	Электроснабжение.	От городской сети, согласно ТУ и ПУЭ. Предусмотреть систему резервного электроснабжения.
13.	Пожарная сигнализация и система оповещения при пожаре.	Выполнить согласно нормам и требованиям пожарной безопасности.
14.	Газоснабжение.	Согласно ТУ.
15.	Телефонизация, интернет.	Согласно ТУ.
16.	Требования к благоустройству.	Территория участка должна быть разделена на зоны: -парковка на 40 легковых автомобилей, -садово-парковая зона с озеленением, расстановкой малых архитектурных форм (светильников, скамеек, памятников, фонтана, урн), -подъездные пути к дополнительным и хозяйственным  входам в бизнес- центр, -водоотвод по ливневой канализации.
16.	Дополнительные условия.	Выполнить: Инженерно- геологические изыскания, топографическую съемку, требования пожарной безопасности и мероприятия ГО и ЧС. Перечень встраиваемой мебели с расстановкой по комнатам . Проект должен быть разработан специальной проектной организацией, имеющей лицензию на данный вид деятельности. Проект предоставить в 4-х экземплярах и в электронном виде.
16.	Сроки проектирования.
17.	Мероприятия по ГО и ЧС, раздел « Охрана окружающей среды».	Согласовать при проектировании с ГО и ЧС.
18.	Определение сметной стоимости  строительства.	Стоимость строительства рассчитать, основываясь на данных справочника базовых цен на проектно- изыскательские работы.
19.	Определение стоимости проектных  работ.	Рассчитать, основываясь на данных справочника базовых цен на проектно- изыскательские работы.

 

Оставить заявку на разработку Технического задания

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

---

Работаем по всей России

Контакты. Тел/ф + 7(812) 627-93-38;  [email protected]

Автор G+

---

Связаться с нами вы можете с 9.00 – 18.00 (пнд — пят). Наш специалист всегда ответит на Ваши вопросы и проконсультирует по возможным решениям тех или иных задач по телефону или по запросу на почту [email protected].

+7 (931) 350 04 34  +7 (963) 306 04 27

по номеру +7 (911) 130 08 19  Наш Skype: dc-region  Наш Telegram по номеру: +7 (911) 130 08 19

---

Мы в социальных сетях
        

---

• Пользовательское соглашение
• Политика обработки персональных данных

Пример ТЗ на разработку ПО (CRM): требования, задачи, интерфейс

II. Функциональные требования

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

• администратор системы,
• администратор,
• оператор,
• менеджер,
• руководитель отдела продаж,
• маркетолог,
• руководитель сервиса,
• сервис-менеджер.

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

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

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

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

Интерфейс администратора системы

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

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

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

Интерфейс администратора

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

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

Интерфейс оператора

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

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

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

В карточке обзвона должна отображаться информация о клиенте, его автомобиле, менеджере, дате выдачи. И вопросы: «C какой долей вероятности Вы будете рекомендовать наш салон друзьям и коллегам?» с возможностью указания оценки от 0 до 10 (либо отсутствием оценки), «Прокомментируйте свою оценку» с возможностью выбора нескольких категорий жалоб и указанием комментариев по каждой из них. Должна быть возможность указать общий комментарий для карточки обзвона.

Интерфейс руководителя сервиса

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

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

Интерфейс менеджера

Основная страница данного интерфейса должна содержать следующие элементы:

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

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

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

Интерфейс руководителя отдела продаж

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

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

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

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

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

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

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

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

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

Интерфейс маркетолога

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

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

Возможность редактирования / удаления / создания категорий жалоб.

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

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

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

Техническое задание на проектирование

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

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

Служба по работе с заказчиками ООО «ПриволжскНИПИнефть»:
443125,  город Самара, улица Силовая 11.
Тел.: (846) 221-01-38, (846) 221-65-67.

E-mai: [email protected]

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

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

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

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

Техническое задание на проектирование битумного хранилища (терминала)

Техническое задание на проектирование мазутного хранилища (терминала)

Техническое задание на проектирование нефтебазы

Техническое задание на разработку проекта реконструкции АГНКС

Техническое задание на разработку проекта склада авиаГСМ

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

Техническое задание на проектирование НПЗ и мини-НПЗ

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

Техническое задание на разработку проекта строительства битумохранилища для АБЗ

Техническое задание на проектирование АЗС

Техническое задание на разработку проекта технического перевооружения нефтебазы

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

Техническое задание на разработка проекта реконструкции УКПГ

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

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

Полные исходные данные заказчик передает предприятию-разработчику проекта.

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

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

1. Состав исходных данных

1.1. Исходные данные должны включать следующие разделы:

— введение;

— общие сведения о технологии;

— перспективы производства и потребления;

— патентный формуляр;

— характеристика производимой продукции;

— характеристика сырья, материалов, полупродуктов и энергоресурсов;

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

— химизм, физико-химические основы технологических процессов, в том числе по переработке отходов производства;

— описание технологического процесса и схемы;

— материальный баланс;

— расходные коэффициенты сырья и вспомогательных материалов;

— математическое описание аппаратов и процесса;

— данные для расчета и выбора основного технологического оборудования, технические проекты или технические задания на нестандартное оборудование;

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

— аналитический контроль производства;

— рекомендации по охране окружающей среды и утилизации отходов производства;

— рекомендации по безопасной эксплуатации производства и охране труда.

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

2. Содержание разделов исходных данных.

2.1. Введение

2.1.1. В этом разделе указывается предприятие-заказчик или организация-заказчик, номер договора и дата его заключения.

2.2. Общие сведения о технологии

В разделе должны быть отражены:

2.2.1. Наименование технологического процесса, метод производства, мощность производства, количество технологических линий (потоков), стадий.

2.2.2. Сведения об отечественных и зарубежных аналогах.

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

2.3. Перспективы производства и потребления

В разделе приводятся:

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

2.3.2. Обеспеченность производства сырьем и материалами требуемого качества.

2.4. Патентный формуляр.

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

2.5. Характеристика производимой продукции

В разделе приводятся:

2.5.1. Техническое наименование продукта в соответствии с нормативно-технической документацией.

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

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

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

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

2.6. Характеристика сырья, материалов, полупродуктов и энергосредств.

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

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

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

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

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

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

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

2.7.4. Данные о возможности образования статического электричества.

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

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

2.8.1. Химизм процесса по стадиям.

2.8.2. Тепловые эффекты химических реакций и физических процессов.

2.8.3. Кинетические уравнения основных и побочных реакций.

2.8.4. Конверсия и выход по стадиям процесса.

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

2.9. Описание технологического процесса и схемы

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

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

В описании указываются:

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

— используемое основное оборудование;

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

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

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

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

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

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

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

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

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

Как написать техническое задание?

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

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

Зачем нужно техническое задание и из чего состоит ?

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

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

• технические характеристики;
• маркетинговые требования;
• особенности конструкции.

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

Технические характеристики

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

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

К техническим характеристикам, указанным в техническом задании на создание сайта интернет-магазина, также относятся:

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

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

Маркетинговая характеристика

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

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

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

Внешний вид сайта

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

• шрифты;
• цветовая матрица;
• звуковые эффекты;
• расположение окон.

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

 

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

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

1. Постановка задачи и определение основных требований (одностраничное приложение, интернет-магазин, лендинг).
2. Подготовка и составление технического задания на создание сайта, доработка требований и поиск в них несоответствий. Так как наличие в техническом задании внутренних несоответствий не даст возможности создать качественный продукт. Поэтому несоответствия должны быть устранены до реализации.
3. Согласование технического задания с компанией-разработчиком программного обеспечения. Дело в том, что одни требования трудновыполнимы, а другие могут быть излишними. Могут быть разные варианты выполнения задачи. Для выяснения недоразумений и устранения несоответствий необходимо обсудить нюансы разработки с компанией-разработчиком до составления окончательного варианта технического задания.
4. Далее уточняются все малейшие детали и обсуждаются сроки выполнения и, что немаловажно, стоимость работ с учетом их сложности. В противном случае из-за недостаточно четкого определения технического задания объем работ может дополнительно увеличиться и потребовать непомерного бюджета.

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

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

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

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

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

Где можно найти хороший пример технического задания?

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

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

Подведение итогов

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи и делайте работу с первой же идеально спланированной попытки! Это правильно!

Категории: Все статьи, Другое

Вы уже сообщали об этом

Примеры формулировок задач

Анализ и определение базовых планов архитектуры для Program Office	базовые модели архитектуры	Программный офис	анализировать, определять
Анализ и поддержка усовершенствований процессов для системы XYZ	улучшения процессов	Система XYZ	анализ, поддержка
Анализ, сканирование, тестирование и аудит сети для компьютерной лаборатории	сеть	Компьютерная лаборатория	анализировать, проверять, сканировать, тестировать
Оценка новых технологий и возможностей компьютерной лаборатории	новые технологии, возможности	Компьютерная лаборатория	оценить
Помощь в разработке политик и процедур обеспечения информации (IA) для Программного офиса	Политика обеспечения информации (IA), процедурные документы	Программный офис	помогать, разрабатывать
Автоматизация и создание онлайн-отчетов для Program Office	онлайн-отчеты	Программный офис	автоматизировать, сгенерировать
Захват, сопоставление и отчет о проблемах безопасности при установке для системы XYZ	вопросы безопасности при установке	Система XYZ	захват, сопоставление, отчет
Проведение периодического анализа требований к помещениям для Программного офиса	периодический анализ требований к оборудованию	Программный офис	поведение
Проведение системных оценок и анализов для Программного офиса	анализы, системные оценки	Программный офис	поведение
Проведение системного тестирования, тестирования подсистем и тестирования компонентов для компьютерной лаборатории	системное тестирование, тестирование подсистем, тестирование компонентов	Компьютерная лаборатория	поведение
Проведение, предоставление, поддержка и разработка специальных исследований, брифингов, документов и отчетов о состоянии системы XYZ	специальные исследования, брифинги, документы, отчеты о состоянии	Система XYZ	проводить, разрабатывать, обеспечивать, поддерживать
Копирование, сортировка, печать и переплет технических публикаций и презентационных материалов для Программного офиса	технические публикации, презентационные материалы	Программный офис	переплет, подбор, копирование, печать
Создание и ведение документации системного администрирования, журналов и процедурной документации для компьютерной лаборатории	документация по системному администрированию, журналы, документация по процедурам	Компьютерная лаборатория	создать, поддерживать
Создание контрольных списков объектов для программного офиса и управление ими	контрольные списки объекта	Программный офис	создавать, управлять
Создание, обновление и предоставление раскадровок и отчетов для программного офиса	раскадровки, отчеты	Программный офис	создать, предоставить, обновить
Разработка, разработка и распространение учебных программ для программного офиса	учебные программы	Программный офис	проектирование, разработка, распространение
Разработка и анализ программных показателей для Программного офиса	показатели программы	Программный офис	анализировать, разрабатывать
Разработка и интеграция планов управления рисками и стратегий управления рисками для системы XYZ	планы управления рисками, стратегии управления рисками	Система XYZ	разработать, интегрировать
Разработка и поддержка документации по управлению интерфейсом (ICD) для системы XYZ	Система XYZ	разработать	поддерживать
Разработка и рекомендация по усовершенствованию процесса обеспечения миссии для Программного офиса	улучшения процесса обеспечения миссии	Программный офис	разработать, рекомендовать
Разработка руководств, учебных курсов и компьютерного обучения для компьютерной лаборатории	справочники, учебные курсы, компьютерное обучение	Компьютерная лаборатория	разработать
Распространение компакт-дисков, персональных компьютеров (ПК) и периферийных устройств для компьютерной лаборатории	Персональные компьютеры (ПК), периферийные устройства, компакт-диски	Компьютерная лаборатория	распространять
Создание и поддержка учетных записей пользователей для компьютерного класса	учетных записи пользователей	Компьютерная лаборатория	установить, поддерживать
Оценка планов тестирования системы для системы XYZ	планы тестирования системы	Система XYZ	оценить
Оценка, участие и подготовка обзора управления программой (PMR), интегрированного базового обзора (IBR), технических обзоров и аудитов для программного офиса	Анализ управления программой (PMR), интегрированный базовый анализ (IBR), технические обзоры, аудит	Программный офис	оценивать, участвовать, готовить
Создание сертификационной документации для системы XYZ	сертификационная документация	Система XYZ	генерировать
Создание, ведение и установка требований к обучению, файлов, форм и планов файлов для программного офиса	требования к обучению, файлы, формы, планы файлов	Программный офис	установить, создать, поддерживать
Нанять квалифицированных инструкторов и фасилитаторов для Программного офиса	квалифицированных инструктора, фасилитаторов	Программный офис	аренда
Выявление и оценка перекрестного риска для Программного офиса	перекрестный риск	Программный офис	оценить, идентифицировать
Выявление, ведение и управление документацией по отчетности о недостатках для Программного офиса	отчетная документация по дефектам	Программный офис	идентифицировать, поддерживать, управлять
Взаимодействие и координация видеотелеконференций (VTC) для программного офиса	Видеотелеконференция (ВТК)	Программный офис	координата, интерфейс
Обслуживание мультимедийного оборудования для компьютерного класса	мультимедийное оборудование	Компьютерная лаборатория	поддерживать
Поддержка системы отслеживания для системы XYZ	система слежения	Система XYZ	поддерживать
Управление и эксплуатация факсимильного оборудования для компьютерной лаборатории	факсимильное оборудование	Компьютерная лаборатория	управлять, управлять
Управление программными активами для программного офиса	программные активы	Программный офис	управлять
Мониторинг и анализ коммуникационного трафика, легитимности вызовов и затрат для программного офиса	трафик связи, легитимность вызова, стоимость	Программный офис	анализировать, контролировать
Надзор за работой генерального подрядчика и субподрядчика для Программного офиса	деятельность генерального подрядчика, деятельность субподрядчика	Программный офис	наблюдать за
Выполнение анализа базы данных для системы XYZ	анализ базы данных	Система XYZ	выполнить
Проведение проверок обеспечения качества для Программного офиса	обзоры обеспечения качества	Программный офис	выполнить
Выполнение аккредитации безопасности и сертификации для системы XYZ	аккредитация безопасности, сертификация	Система XYZ	выполнить
Планирование и реализация стратегии до приобретения и стратегии приобретения для Программного офиса	стратегия до приобретения, стратегия приобретения	Программный офис	орудие, план
Планирование, разработка и поддержка системных программных возможностей и операционных концепций для программного офиса	возможности системных программ, операционные концепции	Программный офис	разрабатывать, поддерживать, планировать
Планирование, отслеживание и составление графика основных этапов для программного офиса	вехи	Программный офис	план, расписание, трек
Подготовка и обновление инструкций по эксплуатации для системы XYZ	инструкция по эксплуатации	Система XYZ	поддерживать, готовить
Подготовка брифингов, координация персонала и документация по решениям для программного офиса	брифинги, координация персонала, документация решений	Программный офис	подготовить
Подготовка и представление Предварительных обзоров проекта (PDR) и Критических обзоров проекта (CDR) для Программного офиса	Предварительные обзоры проекта (PDR), Критические обзоры проекта (CDR)	Программный офис	подготовиться, представить
Подготовка, обработка и обработка Меморандума о взаимопонимании (MOU), Меморандума о соглашении (MOA) и Соглашения с торговым партнером (TPA) для Программного офиса	Меморандум о взаимопонимании (MOU), Меморандум о соглашении (MOA), Соглашения с торговым партнером (TPA)	Программный офис	обрабатывать, готовить, обрабатывать
Предоставление и поддержка мостового планирования и подключения для компьютерной лаборатории	планирование моста, подключение	Компьютерная лаборатория	обеспечение, поддержка
Обеспечить анализ контроля изменений, отчеты о состоянии, отслеживание и контрольные действия для программного офиса	анализ управления изменениями, отчеты о состоянии, отслеживание, контрольные действия	Программный офис	предоставить
Обеспечивает визуализацию, архивирование и извлечение контента для компьютерной лаборатории	отображение содержимого, архивирование, поиск	Компьютерная лаборатория	предоставить
Предоставление отчетов об активах данных и анализ влияния изменений данных для Программного офиса	отчеты об активах данных, анализ влияния изменений данных	Программный офис	предоставить
Обеспечьте ИТ-поддержку Программному офису	ИТ-поддержка	Программный офис	предоставить
Обеспечение поддержки управления системой XYZ	поддержка управления	Система XYZ	предоставить
Обеспечение поддержки клиентов уровня 2 для системы XYZ	Поддержка клиентов уровня 2	Система XYZ	предоставить
Проверка спецификаций системы, спецификаций системных сегментов, спецификаций оборудования и документации по управлению интерфейсом (ICD) для программного офиса	спецификации системы, спецификации системного сегмента, спецификации оборудования, документы управления интерфейсом (ICD)	Обзор базовых планов проектирования системы, требований к архитектуре и функциональной совместимости для системы XYZ.	базовый план проектирования системы, архитектура, архитектура, требования к функциональной совместимости
Поддержка аварийного восстановления данных для системы XYZ	аварийное восстановление данных	Система XYZ	поддержка
Поддержка моделирования и симуляции (M∓S) Требования для программного офиса	Требования к моделированию и имитации (M&S)	Программный офис	поддержка
Поддержка мультимедийных мероприятий для Офиса программ	мультимедийные события	Программный офис	поддержка
Поддержка системной интеграции, планирования и выполнения тестов для системы XYZ	системная интеграция, планирование испытаний, выполнение испытаний	Система XYZ	поддержка
Поддержка архитектуры, планирования и управления на системном уровне для Программного офиса	управление, планирование, архитектура системного уровня	Программный офис	поддержка
Вспомогательные системы тестируют технику безопасности для системы XYZ	системные испытания техники безопасности	Система XYZ	поддержка
Устранение неполадок и решение проблем с программным обеспечением сетевой операционной системы для Program Office	проблемы с программным обеспечением сетевой операционной системы	Программный офис	решить, устранить неполадки
Обновление конфигураций плана помещения для компьютерной лаборатории	конфигурации плана этажа объекта	Компьютерная лаборатория	обновление
Обновление учебной базы данных для компьютерного класса	обучающая база данных	Компьютерная лаборатория	обновление

Задачи — Руководство по стилю Rackspace для документации по техническому содержанию

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

В этом разделе приведены рекомендации по разработке задач.

• Названия задач

• Знакомство с задачами

• Предпосылки

• Процедуры

• Шаги

• Результаты, проверка, примеры и поиск и устранение неисправностей

• Направление к следующему действию

• Похожие темы

Названия задач

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

Примеры

• Создание пользователей в SQL Server

• Настройка SQL Server Management Studio для подключения к SQL Server в Windows

• Добавление новых маршрутов ServiceNet на сервер

Инструкции по использованию заглавных букв см. в разделе Заголовки и заголовки.

Знакомство с задачами

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

Примечания:

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

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

Предпосылки

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

• Гиперссылка на предыдущую задачу, если эта задача должна быть выполнена перед этой задачей

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

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

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

Примечание

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

Процедуры

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

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

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

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

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

Шаги

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

• Используйте повелительные предложения

• Показать одно действие на шаг

• Предоставлять контекст перед действие

• Обеспечить условия до действия

• Следуйте шагу с пояснениями информация

• Показать только действия как шаги

• Используйте снимки экрана экономно

• Этикетка дополнительных шагов

• Опускать лишние слова

• Показать несколько возможностей в список

• Документировать только один метод

Используйте повелительные предложения

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

Примеры

1. Войдите в облачную панель управления.

2. Используйте следующую команду для запуска vsftpd :

    запуск службы sudo vsftpd
    

Показывать одно действие на каждом шаге

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

Примеры

1. В разделе Export выберите свою базу данных (например, 388488_drupal).

2. Прокрутите вниз до нижней части окна и выберите Сохранить как file , который сохранит вывод вашей базы данных в файл.

3. Щелкните Перейти .

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

Укажите контекст перед действием

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

Примеры

1. В области навигации щелкните Правила для входящих подключений .

2. На странице «Параметры привязки и SSL» выполните следующие действия:

Укажите условия перед действиями

Если шаг определяет ситуацию или условие, укажите ситуацию или условие перед описанием действия.

Примеры

1. Если доступна новая версия, нажмите Установить .

2. Чтобы узнать тип шифрования вашего компьютера с Windows (32-битный или 64-разрядная версия), перейдите в панель управления сервера и щелкните System .

Показывать только действия как шаги

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

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

Примеры

Использование:

1. В Linux введите следующую команду:

    sudoackspace-monitoring-agent --setup
    

   Отображается список параметров настройки.

Использование:

1. В разделе Other Options в поле Rackspace Email выберите Mobile Синхронизация .

2. На странице «Активировать мобильную синхронизацию» выберите отдельных пользователей для активировать или выбрать Добавить Mobile Sync ко всем почтовым ящикам на этом вариант домена .

Осторожно используйте снимки экрана

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

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

Дополнительные сведения о том, когда использовать снимки экрана, см. Рекомендации и процесс создания скриншотов.

Обозначьте необязательные шаги

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

Пример

1. (Необязательно) Нажмите Дополнительные параметры .

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

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

Пример

1. Выберите тип тома:

   • Standard : Стандартный диск SATA для пользователей, которым необходимы дополнительные хранилище на их сервере

   • Высокая производительность : SSD-накопитель с более высокой производительностью вариант для баз данных и высокопроизводительных приложений

Документировать только один метод

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

Пример

Использование:

1. Выберите Файл > Создать .

Не использовать:

1. Выберите Файл > Создать или нажмите Ctrl+N .

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

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

• Результат выполнения задачи.

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

• Пример, который иллюстрирует или поддерживает задачу.

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

Направление к следующему действию

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

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

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

Предыдущий Столы

Далее Телефонные номера

Agile Contracts- Шаблон рабочего задания — Технический отдел GSA

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

GSA Tech Guides также предоставляет дополнительный контент и рекомендации, которые углубляются и предоставляют конкретные инструменты/методы по разбивке требований и соответствующие подходы к определению размера для стимулирования реализации Agile-проекта. Вот некоторые примеры содержания:

• Проведение Agile-проекта
• Управление требованиями в гибкой среде
• Определение завершения требования
• Оценка и относительный размер

Кроме того, раздел «Вопросы для интервью для Agile-вендоров» и «Конкретные роли Agile» содержат дополнительные рекомендации для сотрудников GSA о том, что следует запрашивать и ожидать от подрядчиков в процессе проверки.

СКАЧАТЬ Шаблон наряда на задание

Справочная информация

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

Цели

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

Образец заявления о целях

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

«Пользователи и потребности пользователей будут расставлены по приоритетам на основе бизнес-целей / ценности и технических зависимостей в [название приложения, используемого для управления невыполненной работой продукта]».

Объем работ

[Указать объем работ для заказа]

Образец описания объема работ

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

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

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

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

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

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

• Задачи, которые подрядчик должен успешно выполнить,
• Эксплуатационные требования, которые должны быть выполнены во время работы подрядчика,
• Общие административные требования и любые другие условия,
• Инструкции по выставлению счетов подрядчику для получения оплаты»

Роли и обязанности

[Добавить сюда конкретные роли]

ЗАГРУЗИТЕ шаблон Заявления о производительности труда (PWS) для образца языка в Agile Роли и обязанности

Задачи

[Добавить сюда конкретные задачи]

3

3 Заявление

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

«В рамках соглашения о закупке Agile Blanket Purchase Agreement (aBPA) работа будет проводиться двухнедельными спринтами и проверяться в конце каждого спринта на предмет приемлемости и обратной связи»

Эксплуатационные требования

[Добавить конкретные навыки и знания персонала]

Образец образца формулировки навыков и знаний

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

[укажите здесь соответствующий домен] e.g. создание и тестирование веб-приложений или мобильных приложений: ориентированные на пользователя методы проектирования, тестирование удобства использования, дизайн взаимодействия с пользователем, визуальный дизайн, определенные языки кода, развертывание в облаке, службы входа/аутентификации с открытым исходным кодом, методологии Agile и scrum и т. д. ».

«Оба COR + технический руководитель должны согласовать с поставщиком настройку среды разработки и тестирования и доступ к учетным записям до начала работы».

Результаты работы

[Добавить конкретные сведения здесь]

Также ЗАГРУЗИТЕ шаблон Заявления об эффективности работы (PWS) для примера языка результатов Подрядчика, примеров методов доставки и сроков

Переходы

План перехода

2 [Добавить 90 конкретных сведений применимо к переходам здесь]

Действия в переходный период

[Добавить сюда конкретные сведения, применимые к переходам]

Командировочные и другие прямые расходы (ODC)

[Добавьте конкретные детали, применимые здесь]

Положения и условия

Тип контракта

Также ЗАГРУЗИТЕ шаблон Заявления о выполнении работ (PWS) для образца языка для типов контрактного языка

Период исполнения (POP)

[Добавьте конкретные сведения, применимые здесь]

Образец языка для POP

«Период эффективности (POP) включает базовый период в 3 месяца с 5 дополнительными вариантами периодов, каждый из которых длится 3 месяца. Кроме того, может быть установлен резерв на срок до 6 месяцев. Ожидается, что POP начнется в течение 10 календарных дней после присуждения контракта».

Место исполнения

[Добавить конкретные сведения, применимые здесь]

Администрирование контрактов

[Добавить конкретные сведения, применимые здесь]

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

Содержание счета-фактуры

] [Добавить 90 конкретные сведения0, применимые здесь Окончательный счет-фактура

[Добавить конкретные детали, применимые здесь]

Процедуры закрытия

[Добавить конкретные детали, применимые здесь]

СКАЧАТЬ шаблон наряда на выполнение работ для получения дополнительных ресурсов, включая шаблоны цен

Ссылки

• Справочник TechFAR по закупке цифровых услуг с использованием гибких процессов
• Разработка программного обеспечения: эффективные практики и федеральные проблемы в применении гибких методов, учебник по гибким контрактам Том Арброгаст, Крейг Ларман и Бас Водди,
• Поиск партнера, которому можно доверять Agile RFP, Питер Стивенс цитирует
• Agile Services для предприятия, шаблон технического задания — GSA Alliant Shared Interest Group (SIG)
• Отчет об эффективности работы (PWS) Электронные анкеты для обработки расследований (e-QIP) Разработка прототипа

7.

7 Инструкции по написанию – основы технического письма

7. ОБЩИЕ ТИПЫ ДОКУМЕНТОВ

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

Эффективный набор инструкций требует следующего:

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

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

1. Проведите тщательный анализ аудитории и задачи

В начале процесса определите аудиторию и ситуацию ваших инструкций. Помните, что определение аудитории означает определение уровня знакомства ваших читателей с темой.

2. Определить количество задач

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

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

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

3. Определите наилучший подход к пошаговому обсуждению

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

• Запись приветствия
• Воспроизведение ваших сообщений
• Сохранение ваших сообщений
• Пересылка ваших сообщений
• Удаление ваших сообщений и т. д.

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

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

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

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

4. Проектирование групп задач

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

1. Задачи распаковки и настройки
2. Установка и настройка задач
3. Основные рабочие задачи
4. Текущие задачи обслуживания
5. Задачи устранения неполадок.

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

Альтернативные форматы см. в примерах инструкций.

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

• Укажите конкретные задачи или процедуры, которые необходимо объяснить, а также объем (что будет и что не будет охвачено)
• Укажите, какие знания и опыт необходимы аудитории для понимания инструкций
• Дайте общее представление о процедуре и ее результатах
• Укажите условия, при которых эти инструкции следует (или не следует) использовать
• Дайте обзор содержания инструкции.

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

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

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

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

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

• Шаги фиксированного порядка — это шаги, которые должны выполняться в указанном порядке. Например, если вы меняете масло в автомобиле, слив масла — это этап, который должен пройти перед заливкой нового масла. Это нумерованные списки (обычно вертикальные нумерованные списки).
• Шаги переменного порядка — это шаги, которые можно выполнять практически в любом порядке. Хорошими примерами являются те руководства по устранению неполадок, которые говорят вам проверить это, проверить то, где вы пытаетесь что-то исправить. Вы можете делать такие шаги практически в любом порядке. Для этого типа маркированный список является подходящим форматом.
• Альтернативные шаги представляют собой два или более способов выполнения одной и той же задачи. Альтернативные шаги также используются, когда могут существовать различные условия. Используйте маркированные списки с этим типом, со вставкой ИЛИ между альтернативами или вступлением, указывающим, что альтернативы вот-вот будут представлены.
• Вложенные шаги могут использоваться в случаях, когда отдельные шаги в рамках процедуры сами по себе достаточно сложны и должны быть разбиты на подэтапы. В этом случае вы делаете отступ дальше и упорядочиваете подшаги как a, b, c и так далее.
• Бесступенчатые инструкции . можно использовать, когда вы действительно не можете использовать нумерованный вертикальный список или обеспечить прямое руководство в стиле инструкций для читателя. Некоторые ситуации должны быть настолько обобщены или настолько разнообразны, что невозможно указать шаги.

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

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

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

Использование пассивного залога в инструкциях может быть проблематичным. По какой-то странной причине некоторые инструкции звучат так: «Кнопка Pause должна быть нажата, чтобы временно остановить отображение». Мы не только беспокоимся о психическом здоровье кнопки паузы, но и задаемся вопросом, кто должен ее нажимать ( ниндзя ?). Было бы полезнее указать, когда читатель должен «нажать кнопку паузы». Рассмотрим такой пример: «Кнопка таймера установлена ​​на 3:00». Опять же, можно спросить: «установлено кем? Ниндзя ? Человек, следующий этим инструкциям, может подумать, что это просто отсылка к какому-то существующему состоянию, или может задаться вопросом: «Они разговаривают со мной?» Использование третьего лица также может привести к неловкости: «Затем пользователь должен нажать кнопку «Пауза». Инструкции, как правило, должны быть написаны с использованием форм командных глаголов и с использованием «ты», чтобы читателю было совершенно ясно, что он должен делать.

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

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

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

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