Есть ли жизнь просле спецификации?

Функциональность бизнес-приложения - совместное дело заказчика и разработчика

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

Спецификация здесь является только точкой отсчета - слепком того, как разработчики (я имею в виду всю команду - начиная от бизнес-аналитика и кончая последним PMом :-) поняли свою задачу. Если затем кто-то из игроков по какой-то причине встает в позу и начинает "пенять на спеку" то дело швах.

Даже при самом мегакомпетентном заказчике, он какие-то вещи не поймет, пока не начнет системой пользоваться хотя бы в тестовом режиме

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

Что же можно пожелать командам, работающим над бизнес приложениями?

Заказчику

• Назначать менеджером со своей стороны гибкого человека, который абсолютно "в теме" бизнес контекста, желательно с минимальными техническими скиллами (как вариант -- хорошо работает связка "бизнес-спец"+"спец от ИТ").
• Быть готовым к длительной фазе приемки. Быть готовым за нее платить :-). 
• Запланировать пилотную эксплуатацию систему на живых пользователях. 
• По возможности, не привязывать к первой версии системы критичных дедлайнов.

Исполнителю

• Заложить в бюджет проекта достаточное количество времени и денег на доработку системы после старта приемочного тестирования.
• Не надеяться, что после того как спецификация будет написана, она не изменится.
• Не пытаться сделать абсолютно всеобъемлющую спецификацию чисто аналитически -- все равно только после того, как заказчик посмотрит на готовую систему, он поймет, чего на самом деле хотел.
• Проектировать систему так, чтобы было легко вносить очевидные бизнес - изменения (добавить поле, добавить/удалить/изменить валидатор, поправить алгоритм постройки отчета, поправить права на функциональность и т п).