Статьи

Кто больше заинтересован в ТЗ

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

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

Рассмотрим варианты.

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

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

Отдельно стоит озвучить еще два случая, когда заказчик не готовит ТЗ заранее:

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

Б. Если с помощью делегирования разработки ТЗ исполнителю заказчик проверяет компетентность исполнителя перед тем, как поручить ему разработку. Либо не поручить, если ТЗ получится далеким от идеала, т.к. это может являться сигналом, что и с остальными навыками у исполнителя тоже не все в порядке.

Но в данных двух вариантах ТЗ все же в итоге появляется.

Итак, для чего ТЗ требуется заказчику в остальных случаях, если не брать в расчет эти два?

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

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

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

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

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

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

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

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

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

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

“Бюро ревью” поможет Вам написать ТЗ с максимальной пользой для проекта.

10.09.2024

Оставьте заявку

Мы свяжемся с вами для обсуждения задачи
Нажимая на кнопку, вы соглашаетесь с условиями обработки персональных данных и политикой конфиденциальности
Контакты
телефон: 8 931 111-32-15
telegram: @revuburo



Создавайте программные документы вместе с нашей командой