dev98Ситуация:
1. В компании нет четко описанного БП
2. В компании есть люди которые занимаются описанием БП
3. Офис где программисты и офис где методологи + заказчик находятся в разных городах
4. БП постоянно менятеся, т.к. еще неописан точно
5. Есть сложности в коммуникациях
6. Описание БП проиходит в Word'e
7. Сбор требований происходит там же...

Вопрос:
Как дейтсвовать программистам?

Как лучше собрать требования?

Где лучше внедрить продукт в филиале где программисты, или там где методологи и закачик?

Какими средстами лучше пользоватся программистам для описания требований?

Какими средстами лучше пользоватся методологам для описания БП?

Какими средстами лучше пользоватся для свзяи БП и требованиями ТЗ, когда БП меняется?

Есть ли прорывное решение? (проект уходит в глухой даун)


Попробую ответить на ваш вопрос ... пункты ответа не обязательно соответствуют номерам вопросов.
1. Учитывая, что аналитики и разработчики в разных городах то есть проблемы коммуникаций. Отсюда следует очень большое внимание уделять качеству разрабатываемой документации требований, т.к. это один из основных способов коммуникаций.
2. Изменение БП, а следовательно и изменение требований - вобщемто ожидаемая вещь, понятно, что все зависит от того насколько сильно все меняется. Нужно выстроить процесс управления требованиями (да и процесс управления изменениями вообще). Это позволит не на ощущениях, а на цифрах оценивать изменчивость требований, а при реализации процесса управления изменениями с учетом затраченных ресурсов -- еще и выйти на оценку "стоимости" этих изменений. Это будет ваша переговорная позиция с заказчиком на тему сроков/ресурсов/....
3. Полезно вести "реестр БП", где БП, по аналогии с требованиями, являлись бы дискретными. И трассировать требования на БП, чтобы быстро оценивать влияние изменений БП на требования.
4. Определить какие типы/уровни требований вы используете в соответствии с вашей спецификой и сформировать шаблоны документации требований. Деталей специфики вашей предметной области, компетенций аналитиков, устоявшихся правил работы с требованиями и т.п. я не знаю, посему не могу давать более конкретные рекомендации в этой области.
5. "Прорывное решение" -- в области организации процесса Разработки и управления требованиями и Управления конфигурациями и изменениями (как минимум в части управления изменениями) и договоренности всех участников следованию этому процессу. Для постановки таких процессов имеет смысл обратиться к консультантам (если интересно -- пишите на мой e-mail, обсудим)
6. Еще одно возможное решение -- соответствуящая организация команды разработки (в т.ч. со своими аналитиками) и работа по методологиям Agile (если интересно -- тоже пишите в личку).
7. Если у компании есть соответстующие возможности по приобретению инструментальных средств RDM и SCCM -- то следует их использовать при условии поставленного процесса. Как вариант -- тот же Telelogic DOORS для RDM.