Документы как идея - метко!
Обсуждать "документы" вообще, и их влияние на разработку можно бесконечно.
Чтобы немного "приземлить" идею, предлагаю выделить:
"ТЗ","конструкторскую документацию", "пользовательскую документацию", "технологическую документацию", "управленческую документацию".
И тогда получается, что у этих подвидов "идеи документации" разное влияние как на процесс, так и на результат.
При актуальной и правильной управленческой (РМство) документации, из неполного ТЗ построена кривая архитектура (конструкторская документация), которая привела к внешне похожему на ожидаемый результату, ...
увы, не выдерживающий даже слабого дуновения ветерка. Сдать и сделать ноги не успели - развалилось на глазах.
В итоге, "в срок" не получилось, потому что пришлось переделывать архитектуру. И переписывать следом.
Отсюда вывожу: ТЗ и конструкторская документация - ни разу не вспомогательный процесс, а часть основного.
Я не увидел этого в "Цель" и "Цель2" - вероятно, потому, что для примеров все время выбирались "классические производства", где станки стоят на 1-2 порядка дороже з\п рабочего (если не брать глубокое заМКАДье, в ИТ все с точностью до наоборот), а от состояния ума рабочего перед станком характеристики результата зависят слабо (опять же, в отличие от ИТ, где джуниор, еще не отошедший от чтения "банды 4х" может простое действие копирования значения одного атрибута в другой сделать через все каноны - с фабриками, фасадами и прочей...гм). Соответственно, конструирование\проектирование в книгах как возможное ограничение не рассматривалось.
Технологическая документация, если под ней рассматривать требования к коду, применимости паттернов и проч., в рамках одного цикла одного проекта выглядит ненужными затратами. А играть роль начинает только на уровне компании в целом, когда кто-то задумается над причинами потерь. Но это уже другая тема.
Про РМскую документаци - не копенгаген.