Разработка технического задания на программное обеспечение

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

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

Зачем это заказчику

• Сравнимые предложения. Без ТЗ подрядчики считают разное, и цены отличаются в разы не потому, что кто-то дороже, а потому, что каждый понял задачу по-своему.
• Фиксированная цена. Смета, посчитанная по описанию в два абзаца, обязательно поедет. По внятному ТЗ можно зафиксировать стоимость и держать ее.
• Понятная приемка. Есть чек-лист, по которому проверяют результат. Спор «так не договаривались» сводится к чтению документа.
• Меньше переделок. Половина правок, которые всплыли бы на третьем месяце, обнаруживается при написании ТЗ и стоит часы вместо недель.
• Независимость от исполнителя. Если подрядчик не подошел, вы не начинаете с нуля: ТЗ ваше, и с ним можно идти дальше.

Что должно быть в ТЗ, а чего быть не должно

Как мы это делаем

1. Разбираем задачу. Что за процесс, кто участвует, где сейчас теряется время, чего должно стать. Основной материал — разговоры с теми, кто будет работать в системе, и ваши текущие таблицы и документы.
2. Определяем границы. Что входит в первую очередь, что во вторую, чего не делаем вовсе. Это самая ценная часть: большинство проектов срывается не из-за сложности, а из-за расползания объема.
3. Проектируем данные. Сущности, связи, источники правды. Скучный раздел, который определяет все остальное: ошибка здесь дороже любой ошибки в интерфейсе.
4. Описываем сценарии и правила. Как проходит работа от начала до конца, включая отклонения: отмена, возврат, ошибка, отсутствие прав. Правила расчета — с примерами и числами.
5. Собираем прототип ключевых экранов. Кликабельный, с подписями. Он заменяет десятки страниц описания интерфейса и позволяет спорить о конкретном, а не о формулировках.
6. Пишем критерии приемки. Что именно будет проверяться и как. Без этого приемка превращается в обмен мнениями.

Где здесь искусственный интеллект

• Разбор исходных материалов. Ваши таблицы, регламенты, переписка и записи разговоров превращаются в структурированный список сущностей, шагов и требований. Ручной разбор занимает дни.
• Поиск пропусков. По описанию сценария модель перечисляет случаи, о которых обычно забывают: отмена на середине, дубль, нет прав, нет связи, предельные значения. Это заметно сокращает число «а мы не подумали» на приемке.
• Проверка на противоречия. В большом документе легко написать в двух местах разное. Автоматическая вычитка находит такие расхождения лучше человека.
• Варианты прототипа. Два-три решения одного экрана за часы, чтобы обсуждать увиденное, а не описанное.
• Черновики формулировок. Типовые разделы — требования к ролям, к данным, к приемке — набрасываются быстро, а содержание вносит человек, который разговаривал с вашими людьми.

Сроки и стоимость

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

Нужно ли ТЗ вообще

Честный ответ: не всегда, и это зависит от размера задачи и от того, как вы собираетесь работать.

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

Кто пишет ТЗ и почему это важно

Есть три варианта, и у каждого своя особенность.

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

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

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

Разбор существующего ТЗ

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

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

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

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

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

Что вы получаете

• Документ на 20–40 страниц — без воды, с разделами, которые реально читают.
• Схему данных — сущности, связи, источники правды.
• Кликабельный прототип ключевых экранов с подписями к элементам.
• Разбивку на очереди с оценкой трудоемкости по каждой.
• Критерии приемки — чек-лист, по которому проверяется результат.
• Оценку сроков и бюджета — от людей, которые сами разрабатывают, а не считают по аналогии.

Дальше по теме