После полутора лет упорной работы и «наколов» с реализацией проектов в виде постоянных исправлений четко формулировать свои мысли и грамотно излагать их в ТЗ у меня научилось 12 человек — это 2/3 моих внутренних клиентов.

Встречались ТЗ от 1 до 300 листов. Лучше прочитать 100 подробных листов и не пожалеть время в них разобраться, чем потом «допиливать» и менять все заново. Но в таком объеме, как правило, уже много лишней информации и описаний, особенно в экономической аналитики, например. А для технического проекта 300 листов не предел.

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

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

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

Хорошо, когда уточнения идут по ходу реализации. Хуже, когда сделаешь все, запустишь, пользователь радуется. А в момент непосредственной работы завляет, что это и то он «видел по-другому» и «исправить всего ничего». А по сути — менять все в проекте :)

Кстати, о шаблонах. Для каждой организации они опять-таки свои. Более того, удалось поработать с разными шаблонами. Некоторые включают в себя лишь пункты: цель, пользователь, входные данные, выход отчета, особенности. Не каждый пользователь способен так кратко емко описать задачу.
А на дополнительные консультации зачастую у пользователей не хватает времени. Приходилось даже сталкиваться со страхом обсуждения.

Совершенно верно. Однако следует учитывать масштаб реализуемого проекта. Как правило, в большинстве рабочих вопросов и некрупных проект-отчетов такой схемы достаточно. Более того, в любом случае пользователь (при крупном проекте — каждый член рабочей группы) должен сначала понять, что ему надо, а затем транслировать это аналитику или исполнителю непосредственно.

О наболевшем. Удалось побывать и в роли «исполнителя» и в роли «заказчика», барьер в понимании редко преодолим. Иногда приходится работать чисто по проектной документации и разбираться в чужой для себя сфере — это отнимает и силы, и время.