Введение

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

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

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

Нужно ли техническое задание?

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

Подходы к составлению ТЗ для разных методологий

Как я упомянул ранее, сегодня существует две наиболее используемых методологии разработки. Подходы к составлению ТЗ в этих методологиях значительно отличаются. Рассмотрим их подробнее.

Водопадная модель (старый подход)

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

Рекомендации при использовании водопадной модели

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

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

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

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

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

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

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

Водопадный подход к разработке ПО был описан ещё в 70-х годах прошлого века. За этом время были выявлены существенные недостатки его применения. Например, после подписания договора внести изменения в ТЗ заказчику непросто.

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

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

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

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

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

Пример применения водопадной модели

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

Agile-методология (новый подход)

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

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

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

Работающий продукт важнее исчерпывающей документации. (Одна из 4 ценностей, прописанных в манифесте Agile)

Рекомендации по Agile-подходу

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

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

В Agile так же, как и в Waterfall (водопадная модель), активно применяют различные инструменты проектирования, но уже не в процессе составления ТЗ, а на этапе разработки продукта.

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

Важно отметить, что составление ТЗ при Agile вовсе не является обязательным, но по-моему мнению, упрощает процесс разработки.

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

Особенности Agile-подхода

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

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

Пример применения Agile-подхода

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

Заключение

1. Существуют два основных подхода к составлению ТЗ в IT-сфере: водопадная модель и agile-методология.

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

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