Code breakers

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

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


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


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



Цель составления ТЗ — не просто формальность. Она в том, чтобы удостовериться, что две стороны правильно друг друга поняли. Что заказчик не ждёт второго Facebook, а разработчик не берёт обязательство создать новый Twitter. 

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

А ещё это документ, где в одном месте хранится информация и данные о планируемом проекте. К нему надо будет обращаться по ходу работы, чтобы не сбиваться с пути. 

ТЗ - это зафиксированные договорённости, обещания и ожидания с обеих сторон.

Каким должно быть ТЗ — своё или заказчика


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

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

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

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

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

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

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

Как составить бриф для ТЗ 


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

Бриф, анкета с вопросами, поможет составить скелет техзадания и расширять его.

Блоки, из которых состоит техническое задание


Блок 1. Описание проекта


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

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

Блок 2. Требования к проекту


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

Системные требования


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

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


  • Они более специфические. Здесь заказчик описывает «хотелки» относительно того, что должно уметь приложение.  
  • Перечисление интеграций с внешними сервисами. 
  • Поддержка геолокации, наличие Push-уведомлений.

Типовые сценарии использования


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

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

типовой сценарий как последовательность шагов пользователя и откликов сайта, ведущих к результату: пользователь кликает на кнопку регистрации ➡️ отклик сайта  ➡️ открывается окно с формой  ➡️ пользователь заполняет и кликает ОК ➡️ отклик сайта ....  ➡️ результат 

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

Блок 3. Структура и функциональность


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

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

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

Блок 4. Сопутствующая информация  


В этом блоке надо досогласовать сопутствующие моменты. 

  • Ожидания и требования к скорости работы сайта, условия работы сайта в разных версиях браузеров, расширений и прочее, адаптивность продукта под различные устройства. 
  • Дизайн сайта. Фирменный стиль к проекту должен был появиться ещё на этапе Блока 1, но здесь нужно оговорить внешний вид новых элементов, надписей, шрифтов, иконок, которые должны появиться в разрабатываемом продукте.
  • Обязанности. В ТЗ должно быть прописано, кто и за что отвечает. Иначе получится так, что заказчик ожидал авторских текстов разработчика, а разработчик этого делать и не собирался и везде поставил «Lorem ipsum». 



Чего нужно избегать в ТЗ


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

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

Как и когда происходит утверждение техзадания


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

Полезные материалы для разговора с заказчиком-клиентом


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

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




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



Как делать