lead.prog,

Для ответа на данный вопрос - надо взять крайности и подсчитать минусы.
Вариант одын - Вы расжовываете полностью всю задачу.

Плюсы:
1) Выполнение задачи можно отложить на неопределённое время (вся инфа есть, носитель информации - кто разжевал - не требуется).
2) Для выполнения задачи требуется только её "закодить". Т.е. эту фазу многие технологии пытаются упразднить, для снижения проф. требований к кодеру.
3) Документация является пасивным консерватизным механизмом, для стабилизации продукта в разрезе модернизации. Как следствие - бОльшая продуманность требований "верхами", глубокая проработка требований-интерфейсов-рамок кодирования.
4) Имея чёткую, подробную документацию на каждый квант - можно чётче подсчитать время выполнения всей задачи, а так-же можно быстро масштабировать направление, ход и порядок выполнения работ.

Минусы:
1) Повышенная ответственность к создателю такого документа. Цена ошибки такого специалиста очень велика. Т.е. такой специалист есть "слабое звено" на предприятии ведущего разработку ПО.
2) Решение задачи будет ограниченно знаниями и потенциалом человека написавшего это задание.
3) Отсутствие полной заинтересованности в процессе разработки кодера (индусский вариант).
4) Отторжение либо долгое согласование найденного решения с другими участниками проекта (читай кодерами). Потеря времени для "загрузки" этого решения кодеру в "мозги". Возврат на разъяснения, дописывание. Потенциально вектор кодера направлен на нахождение ошибок и создание конфликтной ситуации.
5) Создатеь документа должен тратить время на снижение таких проблем как дублирование кода, функционала. Согласовывать или быть в курсе всех технических решений всего проекта в целом.

Возьмём другую крайность.
Данный человек документирует только обязательные условия тех. задания. Описание, способы решения, ноу-хау, поиск оптимального решения - делает(ют) программисты.
Плюсы:
1) При поиске решения используется весь потенциал команды. Очень значительное снижение рисков. Очень стабильный код в плане модификаций.
2) Вся команда в курсе решения. Нет необходимости разжовывать или объяснять почему так. В случае выбывания нескольких человек из коллектива - сам процесс не остановится и не заглохнет.
3) Нет отторжения "чужого решения" - участвуй, сделай лучше, либо подчинись мастерству. Команда работает - знания передаются по горизонтале очень и очень быстро.
4) В решение, поиск самого решения, вносятся знания всего коллектива. Т.к. двигатель прогресса лень - решение будет
сбалансированным. Т.е. снижается опасность накодить то, что не требуется.
5) Умеренность вносится и в процесс документирования решения. Сам описательный процесс, процесс макетирования и создания(можно сюда добавить и первичного юнит тестирования) можно расспаралелить. Что благоприятно сказывается на скорости и качества всего процесса в целом.
6) Найденные решения будут оптимальны, с учётом не только текущих но и будущих проблем (как с логической стороны, так и технической).
7) Рост в своих знаниях и умениях всей команды в целом.

Минусы:
1) Необходимо создавать группы разработки и работать с людьми. Справка: для создании команды(члены которой научатся только слышать друг-друга) уходит от 2 месяцев(как правило).
2) Просто дешёвые "кодеры" не подойдут. Т.е. за доширак не получится.
3) Руководитель группы должен уметь рукамиводить. Т.е. тупое разбиение и перекидывание задач на подчинённых тут не прокатит.


где то так... если ничего не забыл :)
(круглый)