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

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

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

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

Есть 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. Я не уверен в правильности выбранного блога, но не нашел более подходящего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

В этом случае возможны два сценария. Либо Product Owner даже не подозревает о проблемах с доведением задач, либо этот сложный процесс является обычным способом ведения бизнеса.

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее: Советы по созданию плана коммуникации Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часто задаваемые вопросы

Как писать задачи для разработчиков?

1. Сделать презентацию проекта
2. Предоставить дорожную карту бизнеса
3. Найти общий язык
4. Организовать общение

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

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

Как правильно ставить задачи разработчикам?

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

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

Как сообщить об ошибке?

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

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

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