Как составить техническое задание на разработку ПО по ГОСТ

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

Зачем вообще нужно ТЗ

У технического задания три роли. Оно переводит расплывчатые пожелания в конкретные требования, по которым можно работать и которые можно проверить. Оно защищает обе стороны: заказчик получает то, что заказал, а исполнитель ограждён от бесконечных «а давайте ещё вот это». И оно служит опорой для приёмки, потому что готовый результат сверяют именно с ТЗ, а не с тем, что кто-то смутно помнит из первого разговора.

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

Что говорит ГОСТ

В России структуру технического задания задают государственные стандарты. Для автоматизированных систем это ГОСТ серии 34, для программных изделий ГОСТ серии 19. Они описывают, из каких разделов должен состоять документ и что в каждом отразить. Пугаться их не стоит, по сути это проверенный временем чек-лист, который не даёт забыть важное.

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

Частые ошибки

Первая и главная ошибка это размытые формулировки. Фразы вроде «система должна работать быстро» или «интерфейс должен быть удобным» невозможно проверить, а значит они не требования, а пожелания. Хорошее ТЗ говорит конкретно: какое время отклика считается приемлемым, какие действия пользователь должен выполнять без обучения.

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

Кто должен писать ТЗ

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

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

Нужно ли строго следовать ГОСТ

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