ТЗ на разработку. Как его написать, если вы не айтишник?

Что такое техническое задание (ТЗ) и причем тут зеленый забор

ТЗ – это важный документ, который описывает жизненный цикл создания продукта. Он содержит требования, в соответствии с которыми осуществляется создание и разработка продукта. Основа ТЗ – бизнес-требования.

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

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

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

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

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

Бизнес-требования, например, могут звучать так:

Сокращение ручного труда персонала ресторана при обработке данных; Автоматизация формирования отчета по поступившим заказам в форматы *.xlsx, *.pdf на основе собранных данных; автоматизация отправки отчета по поступившим заказам на e-mail менеджера.

Что должно быть в ТЗ 

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

Например:

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

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

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

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

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

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

Как написать ТЗ для MVP

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

Techopedia описывает три ключевых особенности MVP:

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

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

Что может быть такими критериями успешности продукта?

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

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

• доля обрабатываемых через продукт документов (например, 70% от всех документов, участвующих в процессе).
• сокращение общей длительности процесса обработки документов (например, до автоматизации 2 дня, после – 30 минут).

Чек-лист. Как составить ТЗ для MVP:

1. Сформулировать бизнес-требования к проекту. Описать максимально подробно, какие задачи бизнеса будет решать проект.
2. Описать пользовательские сценарии – то, как с проектом будет взаимодействовать пользователь.
3. Подробно изложить видение по структуре проекта. Описание разделов лучше составлять развернуто: не просто «раздел о нас», а структура страницы, контент, нужна ли форма обратной связи, какие поля должны в ней быть.
4. Собрать референсы – примеры похожих продуктов, которые нравятся, и примеры продуктов, которые категорически не нравятся.
5. Зафиксировать используемые в проекте технологии. С этим помогут технические специалисты.
6. Собрать все данные в один документ, структурировать информацию.
7. Отформатировать текст, чтобы его было удобно читать и редактировать (например, использовать буллеты вместо сплошного текста, проставлять внутренние ссылки).

Фото на обложке: pixabay.com

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

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (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 систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.

ТЗ Определение бизнеса | Law Insider

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

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

• имеет значение, данное этому термину в Соглашении о раздельном проживании.

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

• означает любой бизнес, в котором Компания или любая Дочерняя компания или другое Аффилированное лицо: (x) участвует в течение срока Деловых отношений Получателя гранта; или (y) любой бизнес, в котором Компания или любая Дочерняя компания или другое Аффилированное лицо предприняли существенные существенные шаги для участия в течение двенадцати (12) месяцев до такого Прекращения, при условии, что в отношении обоих компонентов (x) и (y ) настоящего предложения, Грантополучатель имел обязанности в отношении Конфиденциальной или служебной информации о таком бизнесе (или предполагаемом бизнесе) до Прекращения. Без ограничения вышеизложенного, считается, что деятельность Компании включает в себя деятельность по заканчиванию и обслуживанию скважин (включая, помимо прочего, гидроразрыв пласта, гибкие НКТ, нагнетание давления, проводку, цементирование, опрессовку, откачку, перфорацию, извлечение труб и другие дополнительные услуги), услуги по нефтяному инжинирингу (включая, помимо прочего, услуги, связанные с стимуляцией гидроразрыва пласта и разработкой месторождений), услуги по наклонно-направленному бурению и добыче.

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

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

• означает полис или полисы, являющиеся предметом Плана передачи страхового бизнеса.

• означает компанию, которая отвечает одному из следующих критериев: потребляет менее 293 000 кВтч газа в год, или потребляет менее 100 000 кВтч электроэнергии в год, или имеет менее десяти сотрудников (или их эквивалент на полную ставку) и годовой оборот или годовой баланс не более 2 млн.

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

• означает бизнес, услугу или профессию, осуществляемую в жилище или на земле вокруг жилища лицом, занимающим жилище, которое –

• имеет значение, указанное в преамбуле.

• означает бизнес:

• означает исключенный бизнес, в отношении которого AUL воспользовалась своим опционом в соответствии с разделами 2.02(b), 2.06(b), 7.05(a) и/или 7.05(b) на исключение из расчета своей комиссии по прибыли.

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

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

• означает виды деятельности, которые исключены из заявки на межобщинную бизнес-лицензию, и включает те виды деятельности, которые указаны в Приложении «А».

• означает лицензированный бизнес (если таковой имеется) Лицензиата и любое дочернее или связанное предприятие Лицензиата по производству электроэнергии или предоставлению Вспомогательных услуг;

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

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

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

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

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

• означает функции и действия, которые Лицензиат обязан выполнять в соответствии с Лицензией, выданной Комиссией, или в качестве предполагаемого Лицензиата в соответствии с Законом;

• означает деятельность в качестве доверенного лица, исполнителя или администратора;

• имеет значение, указанное в преамбуле.

Письмо по средам: магия ТК

На этой неделе на сайте Шона storygrid.com была такая замечательная статья, что я срываю ее здесь, чтобы поделиться со своими глазами. Речь идет о написании первого черновика.

Мэтт Квирк, автор книг «500» и «Нулевой холодный ствол»

Мэтт Квирк — писатель ( The 500, The Directive, Cold Barrel Zero ), друг и клиент Шона. Вот его секретное оружие для прохождения первого черновика:

Используйте TK . Это основная смазка чернового первого наброска. Это привычка, которую я выучил, работая репортером, но не осознавал ее магии написания романов, пока не прочитал этот совет от Кори Доктороу. ТЗ — это пометка редактирования, означающая «приходить» и эквивалентная оставлению в тексте пробела или квадратных скобок (именно ТЗ, а не ТК, потому что редакционные пометки часто опечатываются намеренно, чтобы не путать их с окончательным текстом: редакторы пишут graf и hed для абзаца и заголовка).

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

 

Я на 100 % согласен с этим трюком Мэтта. То, что он называет «экзистенциальным ужасом «Сработает вся эта книга или нет?»», я бы назвал Сопротивлением.

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

Сопротивление попытается сломить нашу волю, ввергнув нас в благоговейный трепет (его голос, который мы слышим в наших головах) длительностью проекта, масштабом его амбиций, адским бесконечным трудом, чтобы добраться от ГЛАВЫ ПЕРВОЙ до КОНЦА .

Наш союзник в этой борьбе — Импульс.

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

Это гений ТК.

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

Вместо этого быстро нажмите «ТК» и продолжайте движение.

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

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

This entry was posted in Популярное