Это нормальная ситуация. Если заказчик готов отказаться от части функциональности, можно весь scope поделить на модули, подсистемы, эпики, фичи или приоретизировать и выбрать только самое необходимое, чтобы вписаться в бюджет. Либо попытаться договориться об итеративной или инкрементальной разработке.
Какой формат для описания задач используете при написания тз разработчикам? гост 34/19 трудоемкий. Просто текст читать муторно и не опишешь все тех.моменты. Поделитесь опытом описания задачи
По поводу шаблона, мне кажется, идеального стандарта нет. Можно использовать и ГОСТ34/19 в том объеме, как это подходит вам. Можно подойти к этому вопросу гибко и посмотреть другие стандарты, если кажется правильным дополнить шаблон разделами из них.
Без текста к сожалению не обойтись. Чтобы не превращать постановку в простыню на мой взгляд нужно учитывать такие моменты:
Если нет ресурсов приступить к параллельной разработке разными методами, как сократить риски пойти неверным путем и не получить результат как у вашей первой команды?
Тут надо понимать риски. Если не подстраховаться, потери при негативном сценарии могут значительно превысить затраты на ресурсы для параллельной разработки. Если же нет возможности это сделать, то какие есть варианты: