mcureenab ConceptОписание спсоба, средств реализции, архитекуры приложения и пр. только после ТЗ - в проектной документации в терминах и представлениях программиста .

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

Можно рассматривать два случая:
1. Необходимость автоматизированной системы возникла из логики Заказчика, никак не связана с появлением новых программных продуктов, встречей с командой автмоматизаторов, владеющих разнообразными средствами решеня проблем специалистов дургих предметных областей. В этом случае Заказчик заинтересован прежде всего именно в решении собственных проблем и любые "функциональные возможности", которые ему предлагаются автоматизаторами, рассматривает только постольку, поскольку эти возможности обеспечивают решение его проблем и/или достижения целей в бизнесе (связанных с повышением эффективности). . Заказчику не "отделка" нужна и не "внешний вид" сами по себе, а нужно знать, как все то поможет ему решить его проблемы. А Разные задачи преметой области требуют использования разных функциональных возможностей . Реализуемость требований может быть установлена только после того, как установлены эти требования. Поэтому до того, как задачи предметной области Заказчика твердо определены, обсуждение любых предложений по функцональным возможностям может быть основано только на догадках и есть большой риск, что работа по подготовке таких предложений будет потрачена впустую. А чтобы эта работа была проделана могут потребоваться достаточно большие трудозатраты автоматизаторов. И если Заказчк хорошо понимает, что он хочет (а автоматизатор еще нет), то есть большой риск что эти преждевременные трудозатраты в значительной мере будут напрасными.

2. Другое дело если Заказчик не очень уверен в том, что именно ему необходимо. А специалист по автоматизации уже реализовал аналогичные проекты у других Заказчиков и обладает знаниями о том, какие именно программные решения могут быть востребованы в типовых задачах данного Заказчика. И конечно же без демонстрации возможностей программных решений нельзя обойтись, если речь идет о замене устаревшего софта на новый и нужно продемонстрировать преимущество именно предлагаемых программных технологий. В этом случае действительно, движение идет от возможностей программных решений . Но важно иметь виду, по какой причине переход к новой системе стал необходимым, так как обычно неудовлетворенность старой системы связана как с количественным, так и качественным изменением бизнеса Заказчика и он заинтересован в адекватной поддержке этих изменений на уровне софта, а в этом случае мы так или иначе возвращаемся к ситуации 1.

Самое досадное это то, что часто работа начинается исходя из ситуации 2, а когда проект уже должен был быть сделан, выясняется, что на самом деле нужно было исходить из ситуации 1. Конечно, терпенье и труд все перетрут и можно натянуть в конце концов функционал макета на требования заказчика, но время!, но деньги!.

Tyo ацинтяпВот в пятницу захотелось узнать - а как обстоят дела с постановкой задачи в больших и маленьких компаниях, в Москве и вне Москвы, где лучше. И вообще, насколько это здорово, когда есть ТЗ? )

Совсем большая компания, банк.
С постановкой задачи дела обстоят отвратительно.
Написанием ТЗ занимаются специальные люди, к-рые делают это на основании изучения потребностей финансовых подразделений. Затем ТЗ отправляют разработчикам.
Испорченный телефон.
В результате разработчики стояит перед дилеммой -- или писать по ТЗ (тогда получится нечто, не удовлетворяющее потребителя, зато разработчик чист перед начальством), или войти в контакт с потребителем и писать то, что ДЕЙСТВИТЕЛЬНО нужно потребителю (но тогда разработчик нарушает установленный порядок работы)
Такие дела, блин... :(

Что Вы имели в виду под ситуацией "испорченный телефон":
1. "Специальные люди" написали неправильные (даже с точки зрения финансовых подразделений) требования? Если да, то каков профессиональный опыт (именно опыт!) этих специалистов (в области профессионального программирования или профессональноф работы в финансах)?
2. "Специальные люди" написали правильные требования, но разработчики сдлели бы это лучше? При общение с непосредственным заказчиком можно уточнить важные детали, которые помогают при проектировании/реализации системы?