В техническом задании или в задание как правильно писать: «В задании» или «в задание» как пишется? Есть 1 правило!

Как написать правильное ТЗ? | Rusbase

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

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

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

А на выходе получаете неприятный осадок от зря потраченных денег.

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

1. В вашем техническом задании должны содержаться максимально конкретные цели

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

2. Не скупитесь на слова

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

Приведу пример из заказа по копирайтингу:

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

3. Дайте примеры

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

4. Не игнорируйте исполнителя — отвечайте

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

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

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

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

Поэтому вам важно помнить следующее: постарайтесь встать на один уровень с исполнителем. Не надо знать деталей, важно понимать типовые задачи, а именно:

• Сформировать семантическое ядро по высокочастотным и низкочастотным запросам, то есть использовать не самые распространенные слова, по которым могут гуглить ваш магазин, а чуть уже. Например, если у вас онлайн-магазин по продаже одежды, то по слову «одежда» или «платье» ваш запрос будет тяжелее продвинуть. Вернее, ваш магазин, конечно, найдется на десятой странице, но тратить время — себя не уважать. А вот по запросу «красное платье в горох» ваш запрос окажется выше. Подобные фразы или слова фрилансеры формируют самостоятельно.
• Подготовить карту сайта для поискового робота.
• Прописать robots.txt для индексации в Google и «Яндекс».
• Сделать перелинк сайта, то есть связать страницы сайта или из других источников гиперссылками.
• Прописать метатеги для каждой страницы.
• Подготовить список рекомендаций по улучшению сайта.

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

Ниже — не лучший пример ТЗ:

В задании должны обязательно отражаться следующие требования:

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

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

Как правильно писать техническое задание на разработку веб-сайта — Маркетинг на vc.ru

Всем привет, мы веб-студия Mad Design — специализируемся на разработке веб-проектов. Около 75% наших клиентов, при обращении к нам, не предоставляют вообще никакого ТЗ на разработку веб-сайта, около 20% пишут как могут, и оставшиеся 5% приходят к нам с подробным ТЗ (спасибо вам большое!).

Эта статья для тех, кто хочет самостоятельно написать ТЗ для разработки своего проекта! Лично мы в 99% случаев ТЗ разрабатываем бесплатно.

13 409 просмотров

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

Есть 2 варианта:

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

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

Суть техзадания:

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

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

Пример: «Будущий интернет-магазин кондиционеров будет служить основным инструментом для привлечения клиентов и увеличения продаж. От большинства конкурентов нас отличает наличие собственного сервисного центра и технический персонал прошедший обучение в Японии. Наш посетитель и потенциальный клиент должен с первого взгляда понять, что попал на сайт серьезной организации, однако серьезность не должна „давить“ — мы хотим произвести впечатление открытой компании с которой легко работать.».

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

Название, логотип, стиль и дизайн и их значение в техническом задании

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

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

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

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

• www.site1 — нравится цветовая гамма и подача товаров, размер шрифтов мелковат.
• www.site2 — отлично реализован «быстрый заказ», все остальное ужасно.
• www.site3 — основной конкурент, все хорошо, но на него похожим быть нельзя.

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

Структура и основная функциональность сайта или интернет-магазина

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

1. О компании

1.1. Руководство 1.2. Вакансии

2. Каталог товаров

2.1. Микроволновые печи

2.1.1. Panasonic 2.1.2. Samsung 2.1.3. Daewoo

2.2. Водонагреватели

2.2.1. Проточные

2.2.1.1. Bosh

2.2.1.1.1. Проточный водонагреватель Bosh BX5L 2.2.1.1.2. Проточный водонагреватель Bosh BX10L 2.2.1.1.3. …

2.2.2. Накопительные

2.2.3. Газовые проточные

3. Контакты

3.1. Схема проезда

Схематическая структура:

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

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

Уточнения

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

Сроки и стоимость

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

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

Ваши контакты

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

Заключение

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

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

Команда веб-студии Mad Design благодарит вас за внимание и желает всем успехов и хорошего настроения!)

Согласно техническому заданию / Хабр

Добрый вечер, созидающая часть Хабра!

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

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

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

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

Жаль только, что, полное неоспоримых преимуществ, Тех. Задание, содержит пару больших и жирных «но».

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

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

Одна будет грязно-серой, другая – белоснежной; одна — стоить доллар, другая в три раза дороже! Выбрав одну – вы заработаете геморрой, выбрав другую – достигнете небывалых высот мысли.

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

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

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

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

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

Разумное применение

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

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

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

Изображения взяты с сайтов: pt.wikinoticia.com cultofmac.cultofmaccom.netdna-cdn. com, www.popwuping.com, www.thinkgeek.com

P.S. Я не уверен в правильности выбранного блога, но не нашел более подходящего.

Техническое задание. Принципы написания. — Грамант

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

 

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

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

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

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

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

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

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

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Зачем нужно ТЗ

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

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

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

Каким должно быть ТЗ

На самом деле, соблюдение четких правил при составлении ТЗ не требуется. Разные компании и предприниматели оформляют задания по-разному. Вопрос в преследуемых целях. 

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

Нужно написать небольшой текст на тему «Душевые кабины». Текст должен быть для людей. Без переспама.

А кто-то описывает все в деталях и структурирует каждый аспект:

Нужно написать текст на тему «Душевые кабины» объемом 3500 знаков. Уровень спама – до 55%, уровень воды не более 18%, уникальность – от 90%. Слово «душевые» использовать не более 15 раз. Избегать стоп-слов (и, или, но, а).

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

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

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

В случае с текстами сюда можно отнести:

• количество знаков на абзац,

• тип и размер шрифта,

• количество используемых ключевых слов,

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

• необходимые форматы данных (таблицы, списки, цитаты и т. п.).

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

• выбор системы управления данными (WordPress, Joomla и т.п.),

• выбор фреймворков (React, Angular и т.п.),

• количество всплывающих окон,

• ширину контентной части страницы,

• расположение форм обратной связи в приложении,

• дополнительные функции. 

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

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

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

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

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

Этапы работы

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

1. Этап разработки идей и дополнение существующего плана действий. 

2. Демонстрация первого прототипа. 

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

4. Тестирование функциональности.

5. Разработки дизайна. 

6. А/Б-тестирование визуальных компонентов и CTA-элементов.  

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

Другие аспекты

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

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

Срок выполнения работы тоже приписывается заранее, как и общий бюджет проекта. 

Примеры ТЗ

Рассмотрим два абстрактных примера технического задания в том виде, в котором они часто встречаются.

Для разработчиков

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

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

Текст ТЗ может содержать более конкретную информацию об имеющихся функциях:

• На сайте должна быть форма для загрузки файлов (только в форматах JPG, PNG).

• При скролле должно появляться сообщение с предложением зарегистрироваться. 

• Если пользователь долго бездействует (более 20 секунд), должен появляться робот-помощник (его функциональность описана ниже).

• Под каждым материалом на сайте должна быть секциями с комментариями. 

Также в ТЗ можно внести требования к дизайну и оформлению кода:

• Цвет подзаголовков берем из макета (#CD6326).

• Списки должны быть оформлены в формате ul > li > a.

• Блочные структуры должны быть реализованы с помощью свойства селекторов flex.

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

• Работа должна быть доступна в репозитории my-new-project.

• Каждое изменение должно сопровождаться отдельным коммитом. 

• В качестве базы данных используется технология MongoDB.

Для копирайтеров

Текст на тему «Стоит ли использовать WordPress в 2020 году?».

Общие требования к тексту:

1. Статья должна быть поделена на части. Каждый подзаголовок отделяет один логический блок. 

2. В тексте необходимо использовать одну таблицу и минимум один список.

3. Между списками, таблицами, цитатами и подзаголовками должно быть расстояние минимум в 400 знаков. 

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

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

6. Ключевые фразы должны быть равномерно распределены по тексту. Расстояние между ключевыми фразами не менее 1000 знаков. Первое ключевое слово должно использоваться в первом абзаце.

Объем текста: от 10 000 знаков.

Примерная структура текста:

1. Что такое WordPress.
2. Основные преимущества WordPress.
3. Сравнение WordPress с другими CMS.

Ключевые фразы:

• WordPress (8)
• Темы для ВордПресс (1)
• CMS WordPress (2)
• Для разработчиков (1)
• Для новичков (2)
• Как установить на сайт WordPress (1)
• Joomla (2)
• Drupal (1)

Вместо заключения 

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

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

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

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

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

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

Закон № 44-ФЗ не устанавливает обязательного шаблона для технического задания, оно составляется в произвольной форме с соблюдением правил описания объекта закупки, предусмотренных ст. 33 Закона № 44-ФЗ.

В ТЗ очень важно раскрыть ключевые особенности и потребности заказчика:

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

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

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

• Требования энергетической эффективности: если объект закупки включает товар, работу или услугу, в отношении которых установлены требования энергетической эффективности (п. 7 Правил установления энергетической эффективности, утвержденных Постановлением Правительства РФ от 31.12.2009 № 1221).
• Подтверждение соответствия. К примеру, если это предусмотрено техрегламентом на объект закупки либо объект закупки относится к перечню товаров, подлежащих обязательной сертификации.
• Соответствие товара макету (образцу) или изображению с обязательным фиксированием эталона в техническом задании.
• Необходимость обучения лиц, которые будут использовать и обслуживать товар.
• Другие требования в зависимости от объекта закупки.

Заказчик формирует описание объекта закупки (техническое задание) в виде отдельного электронного документа и включает его в состав извещения о закупке или документации о закупке — при закрытых конкурентных способах (п. 1 ч. 2 ст. 42, пп. «а» п. 1 ч. 1 ст. 72 Закона № 44-ФЗ). При закупке работ по строительству, реконструкции, капремонту, сносу объекта капстроительства для надлежащего формирования технического задания заказчику необходимо включить утвержденную проектную документацию, или типовую проектную документацию, или смету на капремонт объекта капитального строительства (п. 8 ч. 1 ст. 33 Закона № 44-ФЗ).

В конце статьи вы найдете шаблон описания объекта закупки.

В конце статьи есть шпаргалка

Применение каталога товаров, работ, услуг (КТРУ)

Важно помнить, что при составлении технического задания (описания объекта закупки) заказчик обязан руководствоваться каталогом товаров, работ, услуг (п. 2 и 4 Правил использования КТРУ, утвержденных Постановлением Правительства РФ от 08.02.2017 № 145), в том числе при описании:

• Наименования объекта закупки. Указывается в извещении, в документации о закупке — при закрытых процедурах, в контракте и реестре контрактов.
• Характеристик объекта закупки. Позиция КТРУ может не содержать описания товара, работы, услуги, в указанном случае заказчик вправе самостоятельно установить характеристики объекта закупки (Письма Минфина России от 24.01.2022 № 24-03-08/4090, от 25.08.2020 № 24-06-05/74463).
• Наименования единицы измерения количества товара, объема работы, услуги. Если в КТРУ нет такой информации, заказчик вправе самостоятельно выбрать единицу измерения в соответствии с национальной системой стандартизации. Единицы измерения определяются в ОКЕИ (Письмо Минфина России от 07.02.2020 № 24-01-08/7999).

В случае описания предмета закупки без применения КТРУ должностное лицо заказчика может быть привлечено к административной ответственности по ч. 4.2 ст. 7.30 КоАП РФ при наличии жалобы от участников закупки или плановой проверки закупочной деятельности заказчика.

Закупка с неопределенным объемом

Обучение для заказчика

Управление закупками по 44-ФЗ. Повышение квалификации, 120 ак.часов

Подробнее о курсе

Для экономии трудозатрат, оптимизации расходов и обеспечения непрерывных поставок заказчики вправе проводить закупки с неопределенным объемом. В документации заказчик устанавливает начальную цену единицы товара (работы, услуги), начальную сумму цен таких единиц и максимальное значение цены контракта (ч. 24 ст. 22, п. 9 ч. 1 ст. 42 Закона № 44-ФЗ). Закупки с неопределенным объемом чаще всего реализуются при закупке сырья, материалов, запасных частей, топлива, транспортных услуг. При этом Законом № 44-ФЗ не предусмотрен исчерпывающий перечень, который указывает, что допустимо покупать без фиксированного объема.

Чтобы понять, что это закупка с неопределенным объемом, надо внимательно изучить извещение. Также рекомендуется ознакомиться с проектом контракта: в нем заказчик указывает, что количество товара, объем работ или услуг будет определяться на основании заявок (ч. 1 ст. 34 Закона № 44-ФЗ).

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

Нарушение № 1. Неясные формулировки, значения

Из описания объекта закупки должно быть однозначно понятно, что заказчик собирается закупить. Требования к показателям характеристик (min, max или точные значения) следует указывать недвусмысленно, предельно понятно и доступно. Согласно ст. 33 Закона № 44-ФЗ, извещение должно содержать требования, которые позволяют установить, подходят ли предлагаемые товары, работы или услуги заказчику. Не следует использовать термины «не хуже», «не слабее» и тому подобные — это необъективное описание. Что для заказчика лучше, а что хуже, поставщик не обязан знать или угадывать.

Характеристики объекта закупки, например, могут выглядеть так:

Товар (далее — мебель) должен соответствовать ГОСТ 16371-2014 «Мебель. Общие технические условия» (введен в действие Приказом Росстандарта от 15.06.2015 № 683-ст), ГОСТ 26800.1-86 «Мебель для административных помещений. Функциональные размеры столов». Наименование товара: стол эргономичный. Цвет: коричневый.

Размер, Ш x Г x В (ширина, глубина, высота): минимальные значения — 100 x 100 x 71,5 см, максимальные значения — 165 x 110 x 71,5 см. При этом высота не подлежит изменению.

Требования к столешнице: материал — высококачественная МДФ, толщина: минимальное значение — 12 мм, максимальное значение — 35 мм. Облицовка — ПВХ-пленка. Столешница должна быть эргономичной и иметь плавные края. В столешнице должно быть предусмотрено отверстие для проводов с заглушкой.

Бывает, что заказчики ошибаются при указании диапазона значений, например «ширина более 360 мм и менее 214 мм». Иногда при описании объекта закупки не учитываются собственные инструкции по подготовке заявок: «в случае, если присутствует слово «диапазон», «в пределах», то поставщику необходимо предоставить диапазон значений ниже установленного заказчиком». Каким образом это понимать в случае температурного диапазона, непонятно.

Достаточно часто заказчики переписывают с государственных стандартов все подряд характеристики, при этом товар не может обладать всеми требуемыми характеристиками одновременно. Например, что касается подвижности и жесткости бетона (ГОСТ 7473-2010), то бетон может быть либо жестким (Ж), либо подвижным (П) — это взаимоисключающие характеристики. Однако заказчики умудряются вписать в техзадание и то и другое: «жесткость Ж1–Ж4; подвижность П1–П4». Материала с такими характеристиками не может быть. И это является нарушением ч. 2 ст. 33 Закона № 44-ФЗ.

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

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

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

Нарушение № 2. Ссылка на ГОСТ без какого-либо описания

Еще одно распространенное нарушение — это перечисление в техническом задании ГОСТ без привязки к конкретным товарам. Позиция ФАС в этой ситуации такова: подобное описание объекта закупки не позволяет идентифицировать каждый товар и не позволяет потенциальному поставщику подготовить заявку должным образом.

Нарушение № 3. Отсутствие фразы «или эквивалент»

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

Узнайте подробнее об этом требовании закона на вебинаре Контур. Школы «Техническое задание: требования к содержанию и особенности составления».

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

Основные правила подготовки технического задания

Применяйте национальные стандарты

Помимо положений Закона № 44-ФЗ, необходимо руководствоваться иными правовыми актами, техническими регламентами, документами, разрабатываемыми и применяемыми в национальной системе стандартизации, связанными с определением соответствия поставляемого товара, выполняемой работы, оказываемой услуги потребностям заказчика (ГОСТ Р, ГОСТ, СНиП и пр.), что прямо указано в п. 2 ч. 1 ст. 33 Закона № 44-ФЗ. Если планируете использовать иные показатели, то вам придется обосновывать необходимость их применения в извещении о закупке, в противном случае высок риск жалобы.

Обучение для заказчика

Управление закупками по 44-ФЗ. Повышение квалификации, 120 ак.часов

Подробнее о курсе

Не ограничивайте конкуренцию

В целях обеспечения конкуренции в описании объекта закупки не допускается включать:

• Требования, которые создают преимущественные условия для отдельных участников закупки.
• Требование поставить товары, выполнить работы или оказать услуги, которые технологически и функционально не связаны между собой, при этом наличие или отсутствие взаимосвязи устанавливается для каждого случая индивидуально. К примеру, объединение в один лот лицензируемых и нелицензируемых видов работ может свидетельствовать о потенциальном нарушении, поскольку может ограничивать число участников закупки (Письмо ФАС России от 09.02.2015 № АЦ/5147/15).
• Любые иные требования, которые влекут необоснованное ограничение конкуренции.

Учитывайте особенности национального режима закупок

Один из примеров — случаи применения Постановления Правительства РФ от 10. 07.2019 № 878 при закупке радиоэлектронной продукции или Постановления Правительства РФ от 30.04.2020 № 616 при закупке промышленных товаров. В этих ситуациях запрещено закупать совместно товары из перечня с товарами, которые в него не включены.

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

Поставка б/у товара возможна

По умолчанию товар должен быть новым, неиспользованным, не в ремонте, у которого не менялись составные части, не восстанавливались потребительские свойства (п. 7 ч. 1 ст. 33 Закона № 44-ФЗ). Если вы допускаете возможность поставки товара, бывшего в употреблении, предусмотрите в техническом задание соответствующее положение (Письмо Минфина России от 25.05.2021 № 24-06-08/40268).

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

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

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

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

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

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

При формировании технического задания заказчики должны руководствоваться требованиями ст. 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведенный в документации макет. Коллекция плитки без эквивалента — это нарушение п. 1 ст. 33 Закона № 44-ФЗ. Если такое требование указано и оно влечет ограничение количества участников закупки, для минимизации риска жалобы следует сопроводить указание конкретной плитки словами «или эквивалент».

Шпаргалка

В шпаргалке собрана полезная информация из статьи:

• Пример описания объекта закупки (ТЗ) 712.2 КБ

Скачать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Эта глава была адаптирована из книги Дэвида МакМуррея «Технические статьи в Интернете», которая находится под международной лицензией Creative Commons Attribution 4. 0.

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

Это гостевой пост от Хамзы Хана

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

«Подождите, — говорите вы себе, — за что я здесь отвечаю? Кто что делает? Где сроки для отдельных лиц?» Примерно сейчас вы, вероятно, готовы к третьей чашке кофе…

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

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

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

Шаг

Детали

Сроки

Контекст

Вот как их использовать:

1. Шаг

Задача должна начинаться с глагола, поэтому запишите ее как действие. Представьте, что вы подаете заявку на участие в конференции. Крайний срок подачи заявки – 3 октября. Вы должны инстинктивно понимать, что первый шаг к созданию презентации — это 9 шагов.0418 писать . Поэтому ваша задача должна начинаться со слова «Написать».

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

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

2. Детали

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

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

«Написать первый черновик итогового отчета маркетинговой команды за 2015 год»

Подойдите к деталям письма так же, как журналист подходит к написанию истории. Рассмотрим 5 W. Я лично по умолчанию:

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

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

«Леди-босс хочет подробный отчет (30-40 страниц) о победах и поражениях нашей команды за 2015 год. См. документы: «Стратегические цели на 2015 год», а также «Вехи на 2015 год». ” на Google Диске при составлении этого отчета. Босс-леди будет использовать этот отчет для информирования о распределении бюджета на 2016 год, поэтому, пожалуйста, не забудьте выделить наши основные победы, особенно ту действительно успешную кампанию, которую мы провели в марте. В то же время, давайте также коснемся некоторых областей для роста. Описывая эти неудачи, обязательно используйте позитивный тон и сосредоточьтесь на том, чему мы научились на них. Дайте мне знать, если у вас возникнут дополнительные вопросы!»

3. Дедлайны

Американская писательница и гуру тайм-менеджмента Дайана Шарф Хант сказала: «Цели — это мечты со сроками». Но заявленные цели — это только начало. Чтобы идеи действительно реализовались, у каждой задачи должен быть установлен крайний срок. Когда дело доходит до установления сроков, обязательно придерживайтесь подхода «обещай меньше, делай больше». Установите вехи между настоящим моментом и крайним сроком, чтобы не сбиться с пути.

«Написать первый проект итогового отчета отдела маркетинга за 2015 год» (срок исполнения: 23 сентября)

4. Контекст

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

«Написать первый проект итогового отчета отдела маркетинга за 2015 год» (срок выполнения: 23 сентября) [Проект: Маркетинговая стратегия] [Отмечен: Написание] [Отмечен: 1 час] [Отмечен: Высокий приоритет]

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

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

1. Энергетический контекст

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

2. Контекст, основанный на времени

Это особенно полезно в те неприятные 15-30 минут между встречами. Знание того, сколько времени займет выполнение задачи, может помочь вам максимально эффективно использовать время простоя. Например, я фильтрую свой список задач, чтобы найти несколько 5-минутных и 10-минутных задач, которые нужно выполнить до начала следующей встречи.

3. Контекст, основанный на приоритетах

Лучше всего об этом сказал Дуайт Эйзенхауэр: «То, что важно, редко бывает срочным, а то, что срочно, редко бывает важным». Указание уровня приоритета ваших задач даст вам больше ясности в отношении порядка, в котором задачи должны решаться.

4. Контекст работы/жизни

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

Таким образом, ваша задача может звучать так:

«Написать первый проект окончательного отчета маркетинговой команды за 2015 год» (срок выполнения: 23 сентября, 10:00) [Проект: Маркетинговая стратегия] [Отмечено: Написание] [Отмечено: 1 час ] [Tagged: Срочно] [Tagged: High Priority]

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

Об авторе

Хамза — отмеченный наградами маркетолог и предприниматель. Он является соучредителем Splash Effect, маркетингового агентства в Торонто на стыке высшего образования и цифровых технологий. Он является главным редактором журнала Year One, целью которого является мотивация людей в периоды личного и профессионального перехода. Хамза также является профессором факультета бизнеса Seneca College. Он регулярно говорит и пишет на темы продуктивности, стартапов, хип-хопа, маркетинга, лидерства, максимальной производительности и реализации идей. Его идеи были представлены 99U и многочисленные национальные СМИ и отраслевые издания.

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

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

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

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

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

Вот как правильно создавать задачи.

 

Что такое задача?

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

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

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

 

Написание задачи

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

 

Описательность

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

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

По моему опыту, большинство задач должны быть более описательными, чем они есть на самом деле. Одно неполное предложение описания должно состоять из двух или трех предложений. Должны быть вспомогательные данные (например, идентификационные номера объектов) и скриншоты. Описание должно включать некоторые «почему» задачи, а не только «что». Например, приведенную выше задачу с кнопкой лучше было бы сформулировать так: «Поменять местами кнопку А и кнопку Б на экране X. Пользователи сообщают, что кнопка Б является основным действием».

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

 

Предписанность

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

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

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

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

 

Совместная работа над задачей

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

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

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

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

Подробнее от Дэвида Вандегрифта Когда качество должно заменить скорость?

techcomm11e_full_ch30

Печатная страница 551-569

Инструкции по написанию

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

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

Большинство организаций не считают такое участие угрозой. Опрос более 500 организаций, проведенный в 2012 г. (Abel, 2013), показывает, что организации пытаются этим воспользоваться. Среди основных результатов опроса можно выделить следующие четыре:

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

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

ПОНИМАНИЕ РОЛИ ОБУЧАЮЩИХ ВИДЕО

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

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

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

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

Обучающие видеоролики, как правило, короткие. В то время как читатель документа может легко перемещаться между различными частями или шагами, зрители видео могут только нажимать кнопку воспроизведения, паузы и остановки. По этой причине следует разбивать длинные задачи на серию коротких видеороликов: в идеале 2–3 минуты, но не более 12–15 минут. Дайте каждому четкий, конкретный заголовок, чтобы зрители могли легко понять, хотят ли они его просмотреть.

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

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

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

РАЗРАБОТКА НАБОРА ПИСЬМЕННЫХ ИНСТРУКЦИЙ

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

Подробнее о планировании читайте в гл. 3.

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

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

• Каковы ожидания ваших читателей? Для простого и недорогого продукта, такого как выключатель света, читатели ожидают найти инструкции, написанные на обратной стороне упаковки или напечатанные черно-белым шрифтом на маленьком листе бумаги, сложенном внутри упаковки. Для дорогого потребительского товара, такого как телевизор высокой четкости, читатели ожидают найти инструкции в более сложном полноцветном документе, напечатанном на высококачественной бумаге.
• Вам нужно создать более одного набора инструкций для разных аудиторий? Если вы пишете о сложном устройстве, таком как электронный термостат, вы можете создать один комплект инструкций для электриков (которые будут устанавливать и обслуживать устройство) и один комплект для домовладельцев (которые будут эксплуатировать устройство). Помимо создания бумажных копий документов, вы можете разместить их в Интернете вместе с кратким видео о задачах, которые вы описываете.
• Какие языки следует использовать? В большинстве стран говорят на нескольких языках. Вы можете решить включить инструкции на двух или более языках. Это поможет вам лучше общаться с большим количеством людей и избежать юридических проблем. В делах об ответственности суды США иногда приходят к выводу, что, если компания знает, что многие из ее клиентов говорят, например, только по-испански, инструкции должны быть как на испанском, так и на английском. У вас есть два варианта представления информации на нескольких языках: одновременное представление или последовательное представление. В одновременное проектирование , вы можете использовать страницу с несколькими столбцами, на которой в одном столбце представлена ​​графика, в другом — текст на английском языке, а в третьем — текст на испанском языке. Очевидно, что это не сработает, если вам нужно представить информацию более чем на двух-трех языках. Но это эффективно, потому что вы представляете каждый рисунок только один раз. В последовательном дизайне вы представляете всю информацию на английском языке (скажем, на страницах 1–8), затем всю информацию на испанском языке (на страницах 9).–16). Последовательный дизайн удобнее для читателей, потому что они не отвлекаются на текст на других языках, но вам придется представлять графику более одного раза, что сделает инструкции длиннее.
• Будут ли читатели обеспокоены информацией? Если читатели сочтут информацию пугающей, сделайте дизайн непугающим. Например, если вы пишете для обычных читателей о том, как настроить беспроводную сеть для домашних компьютеров, создайте открытые страницы с большим количеством пустого пространства и графики. Используйте крупный шрифт и узкие текстовые столбцы, чтобы каждая страница содержала относительно небольшой объем информации. На рис. 20.7 показаны преимущества открытой конструкции.
• Повлияет ли среда, в которой читаются инструкции, на дизайн документа? Если люди будут пользоваться инструкциями на открытом воздухе, вам потребуется бумага с покрытием, устойчивая к влаге и грязи. Если люди будут читать инструкции, сидя в небольшом закрытом помещении, вы можете выбрать небольшой размер бумаги и переплет, который позволит читателю складывать страницы для экономии места. Если у людей много места, вы можете создать инструкции размером с плакат, которые можно прикрепить к стене и которые легко читать с другого конца комнаты.

а. Беспорядочный дизайн

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

Перепечатано с разрешения Slide-Lok.

б. Привлекательный дизайн

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

Перепечатано с разрешения Anthro Corporation.

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

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

Подробнее о фрагментации см. в гл. 11.

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

ПЛАНИРОВАНИЕ БЕЗОПАСНОСТИ

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

ПРИМЕЧАНИЕ ПО ЭТИКЕ

ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ВАШИХ ЧИТАТЕЛЕЙ

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

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

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

СЛОЖНЫЙ	В этой лаборатории необходимо носить защитные очки.
ПРОСТОЙ	В этой лаборатории вы должны носить защитные очки.
ПРОСТОЙ	Носите защитные очки в этой лаборатории.

Иногда фраза работает лучше, чем предложение: «Необходимы защитные очки».

Поскольку типичное руководство или набор инструкций может содержать десятки комментариев, некоторые из которых относятся к безопасности, а некоторые нет, эксперты разработали сигнальные слова для обозначения серьезности совета. К сожалению, сигнальные слова не используются последовательно. Например, Американский национальный институт стандартов (ANSI) и MILSPEC вооруженных сил США публикуют определения, которые значительно различаются, а многие частные компании имеют свои собственные определения. На рис. 20.8 представлены четыре наиболее часто используемых сигнальных слова. Первые три сигнальных слова сопровождаются символами, показывающими комбинации цветов, одобренные ANSI в его стандарте Z535.4.

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

Организации, создающие продукты, которые используются только в США, разрабатывают информацию о безопасности в соответствии со стандартами, опубликованными ANSI и федеральным управлением по охране труда (OSHA). Организации, создающие продукты, которые также используются за пределами США, разрабатывают информацию о безопасности в соответствии со стандартами, опубликованными Международной организацией по стандартизации (ISO). Рисунок 20.9показывает знак безопасности, который включает стандарты ANSI и ISO.

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

Опасность	Опасность используется для предупреждения читателей о непосредственной и серьезной опасности, которая может привести к летальному исходу. Писатели часто используют все заглавные буквы для обозначения опасности.	ОПАСНО: ЧРЕЗВЫЧАЙНО ВЫСОКОЕ НАПРЯЖЕНИЕ. ОТОЙДИ.
Предупреждение	Предупреждение используется для предупреждения читателей о возможности серьезной травмы или смерти или серьезного повреждения оборудования. Писатели часто используют все прописные буквы для предупреждений.	ПРЕДУПРЕЖДЕНИЕ: ВО ИЗБЕЖАНИЕ СЕРЬЕЗНЫХ ТРАВМ РУКИ ПЕРЕД НАЧАЛОМ ЭКСПЛУАТАЦИИ ЭТОЙ МАШИНЫ ВЫ ДОЛЖНЫ УБЕДИТЬСЯ В НАЛИЧИИ ОГРАНИЧИТЕЛЕЙ РУКОЯТОК.
Осторожно	Внимание! Не используйте неперезаряжаемые батареи в этом зарядном устройстве; они могут повредить зарядное устройство.
Примечание	Примечание используется в качестве подсказки или предложения, чтобы помочь читателям успешно выполнить процедуру.	Примечание. Поставляются два вида шайб — обычные шайбы и стопорные шайбы. Обязательно используйте здесь стопорные шайбы.

Рис. 20.8 Сигнальные слова

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

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

Сигнальное слово «Опасно» и текст соответствуют подходу ANSI. Информация представлена ​​на английском языке.

Рисунок 20.9 A Типовая табличка безопасности

Источник: Clarion Safety Systems, 2013 г.: www.clarionsafety.com/Electrical-Hazard-Safety-Labels.

На рис. 20.10 показаны рекомендации одной отраслевой ассоциации по размещению информации о безопасности на конвейерных лентах.

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

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

Рисунок 20.10 Размещение информации о безопасности на оборудовании

Источник: Ассоциация производителей конвейерного оборудования, 2004 г. Перепечатано с разрешения Ассоциации производителей конвейерного оборудования.

СОСТАВЛЕНИЕ ЭФФЕКТИВНЫХ ИНСТРУКЦИЙ

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

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

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

• How-to. Это самое простое: «Как установить амортизатор J112».
• Герунд. Глагол в форме -ing : «Установка амортизатора J112».

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

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

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

Составление введения к инструкциям

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

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

  ПРИМЕЧАНИЕ. Для облегчения сборки не затягивайте все гайки. Сделайте только три или четыре полных оборота резьбы болта.

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

• Подробнее о графике см. в гл. 12.

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

Составление пошаговых инструкций Основой набора инструкций является пошаговая информация.

Составление шагов в инструкциях

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

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

  1
  	1,1
  	1,2
  2
  	2. 1
  	2,2
  и т. д.

  Если вам нужно представить длинный список шагов, логически сгруппируйте шаги в наборы и начните каждый набор с четкого заголовка. Например, список из 50 шагов можно разделить на 6 наборов по 8 или 9 шагов в каждом.

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

  СЛИШКОМ МНОГО ИНФОРМАЦИИ	1. Смешайте одну часть цемента с одной частью воды, используя шпатель. Когда смесь станет густой по консистенции без комочков размером больше шарика, поместите полоску смеси примерно на 1? высокий и 1? шириной по лицевой стороне кирпича.
  СЛИШКОМ МАЛО ИНФОРМАЦИИ	1. Возьмите шпатель.
  ДОСТАТОЧНЫЙ КОЛИЧЕСТВО ИНФОРМАЦИИ	1. Смешайте одну часть цемента с одной частью воды, используя мастерок, пока смесь не станет густой по консистенции без каких-либо комков больше, чем мрамор.
  	2. Поместите полоску смеси высотой около 1 дюйма и шириной 1 дюйм вдоль лицевой стороны кирпича.

• Подробнее о повелительном наклонении и страдательном залоге читайте в гл. 10.

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

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

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

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

ИНСТРУКЦИИ ПО РАССМАТРИВАНИЮ, РЕДАКТИРОВАНИЮ И КОРРЕКТИРОВКЕ

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

Подробнее о юзабилити-тестировании читайте в гл. 13.

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

ПОСМОТРЕТЬ НЕСКОЛЬКО ПРИМЕРНЫХ НАБОРОВ ИНСТРУКЦИЙ

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

Обратите внимание, что автор использует герундий (-ing фразу) в основном заголовке для описания действия («Использование сканера штрих-кода»).

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

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

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

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

Рисунок 20.12 Список инструментов и материалов

Предоставлено General Electric Corporation.

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

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

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

Этот набор информации о безопасности определяет ключевые слова предупреждение, предостережение и важно. Рис. 20.13. Выдержка из информации по безопасности

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

В исходном сообщении клиент описывает проблему, с которой он столкнулся при печати файла TIFF на принтере Xerox.

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

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

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

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

Рисунок 20.15 Выдержки из обсуждения на форуме поддержки клиентов

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

Источник: Корпорация Xerox, 2013 г.: http://forum.support.xerox.com/t5/Printing/TIFF-files/td-p/21986. Используется с разрешения корпорации Xerox.

Как успешно ставить задачи команде разработчиков

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

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

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

К сожалению, есть деловые люди , Владельцы Продуктов или Бизнес-аналитики , которые пишут задачи для команд разработчиков и даже не подозревают, что у них проблемы с коммуникацией. Даже опытные деловые люди иногда становятся жертвами бюрократии и расширенной иерархии. Иногда Владельцы Продукта просто не выполняют свою роль в полной мере. Владельцы продукта должны быть связующим звеном между бизнес-стороной и командой разработчиков. Их основная задача — хранить все функции, запрашиваемые бизнес-стороной, в одном месте и сообщать разработчикам требования к продукту. Однако это не всегда происходит так, как должно.
В этом случае возможны два сценария. Либо Product Owner даже не подозревает о проблемах с доведением задач, либо этот сложный процесс является обычным способом ведения бизнеса.
Тем не менее, нам всем приходится сталкиваться с тем фактом, что неправильно поставленных целей могут привести к стрессу и напряжению в команде разработчиков, в то время как неправильно или иррационально поставленные задачи часто требуют больше усилий (и денег) для выполнения. Что приводит к превышению бюджета и нарушению сроков (что также может привести к штрафным санкциям). И, конечно же, мы тратим много времени, снова и снова объясняя требования.
Давайте внимательно посмотрим, что происходит. Каковы основные проблемы, которые могут вызвать недопонимание между командой разработчиков и клиентом? Большинство из них можно условно разделить на три подвопроса:

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

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

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

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

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

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

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

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

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

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

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

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

• Заголовок – по существу, краткое описание задания, отвечающее на вопросы Что? Где? Когда?
• Описание — основная часть задачи и фактический набор целей, которые необходимо достичь.
• Бонус! – дополнения, помогающие понять описание:
  • Скриншот с пометками, касающимися задачи
  • Зависимости и эффекты на другие части приложения
  • Файл с сохраненными формулами (если это расчет)
  • Интерактивный прототип, показывающий, как перемещаться между страницами
  • Ссылка на конкурента

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

• Заголовок — эта часть такая же, как и в (а) — в краткой форме вы говорите, что произошло, где и когда.
• Описание. Помимо шагов для воспроизведения, идеальное описание содержит
  • Пользовательские данные о том, кто столкнулся с ошибкой, и среду, в которой возникла ошибка;
  • Время происшествия;
  • Дополнительные условия, типичные для данного применения;
  • Ожидаемый и фактический результат;
  • Ссылки на исходные требования, скриншоты и т. д.

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

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

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

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

Этап 1. Разработка бизнес-требований.

Этап 2. Процесс разработки.

Этап 3. Принято клиентом и развернуто.

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

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

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