Почему опасно экономить на разработке технического задания для IT-проекта

Любой IT-проект реализуется на основании технического задания (ТЗ). В нем содержатся описания целей, требований, подходов к решению и т.д. Можно ли «доработать» ТЗ потом, уже после начала работ? По мелочам — да, конечно. Более того, это даже необходимо, потому что заранее невозможно предусмотреть все нюансы.

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

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

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

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

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

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

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

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

• Общее описание проекта. Цели и задачи разработки
• Описание функционала мобильного приложения
• Описание функционала серверной части приложения
• Описаний интеграций, если они требуются
• Описание автоматизированного рабочего места администратора (как правило, для CRM и/или CMS)
• Общие требования к режимам работы, тестированию, условиям безопасности и эксплуатации системы
• Требований к структуре интерфейсов мобильного приложения
• Требования к видам обеспечения (лингвистическое, программное, аппаратное, информационное)
• Порядок сдачи и приема работ
• Требования к документированию разработки

Кроме того, есть пара частых недопониманий в общении заказчика и разработчика.

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

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

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

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

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

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

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

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

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

В конечном счете, ТЗ описывает все ключевые ракурсы разработки:

• Бизнесовый
• Технический
• Коммуникационный
• Визуальный
• Юридический

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

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

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

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

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

Так сколько же стоит страховка от проблем в виде грамотно составленного технического задания? В среднем вилка такая:

• От 1 до 2 месяцев
• От 150 до 500 тыс. рублей

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

Экономить на ТЗ точно не стоит. Ведь это современное прочтение доброго старого «семь раз отмерь, один раз отрежь».