Здравствуйте Forrest, Вы писали:

F>Коллеги, прошу у вас совета по одному вопросу.

F>Вкратце история возникновения этого самого вопроса. Работаю не в софтверной компании, а скажем так, в IT отделе большой компании
F>занимающейся продажами. Как это и положено начинали с малого до развивались до того, что отделе сейчас порядка 15 человек, которые
F>в среднем группами по 3-5 чел разбросаны по уголкам России. Основная наша задача автоматизация производства и продаж, с нею мы с
F>горем пополам справляемся, но вот свою деятельность автоматизировать пока не можем. Сейчас перехожу к самому вопросу. Что я хочу F>видеть. Это некоторую централизацию управления нашей работы. Т.е. должно быть общее хранилище исподников кода,

Т.е. вы не используете контроллеры версий?
Почему?
Гляньте в сторону CVS-сервер + WinCVS + AraxisMerge
платное только последнее, но без него можно обойтись или найти фришны-диф.

F>этот код должен быть хоть как-то спроектирован, а не написан сразу после требования Марьи Ивановны о получении не существующего
F> пока квартального отчета.
F>Должен быть центральный репозиторий требований к проектам, что мы ведем. Хотелось бы проекты оформить в какие-то итеративно
F>подобные жизненные циклы, а не в стихийные штурмы по требованию начальства. Вообщем приблизиться хотя бы ко второму уровню СММ.
F>Кроме этого, работа наша во многом стала дублироваться, т.е. один нарисовал библиотеку для одного отчета, другой, не зная о том что
F>все это уже создано, благополучно рисует такую же, за что оба получают не плохие деньги от руководства, и благодарности F>пользователей.

Нужен человек, который следт за коммитами в общий репозиторий, и координировал действия программистов.
И вовремя стучит им по голове )
Да и программистам нужно следить за внешними изменениями общего кода.
(как правило они этого не хотят делать.)
Работает правило: легче самому написать, чем разбираться во внешнем коде.
на выходе: каждый клепает свое(и как правило кривое.)

F> И все бы можно было сделать, если бы не два но, первое это катострафически быстрое изменение требований.

Побольше обобщайте. все что встретилось более ожного раза — суйте в либу.
Последующие задачи будут решаться быстрее...

F>Мысли руководства примерно такие: программеры мол свои, они за работу деньги получают, сегодня решили одно, пусть автоматизируют,
F>завтра совершенно противоположное, пусть опять автоматизируют. Понятно, что ни о каком документировании кода, его проектировании,
F>описании серьезном тестировании здесь речь не ведется.

А на чем ведется разработка?
Если С++, то поставьте DoxyGen — она генерит *.chm файлик, с индексом по исходному коду.
Это и есть дока для разработчика.
Ничего и писать не нужно...

F>И второе, “но” вытекает из первого, ребята и сами не прочь разложить то, что они делают по полкам,

Еслиб хотели, давно разложили. )

F>но если требования меняются так быстро, что задачу то понять не всегда успеваешь,

Конкретный пример можешь привести.
Чтот не верится что начальство так скачет, или Вы сегодня автоматизируете продажу конфеток,
а через недельку разрабатываете CAD?

F>а не то что ее задокументировать и закодировать.
F>Если их заставить, перед тем как взяться за кодирование, 50% времени посетить проектированию и всяческим там вещам по составлению
F>артефактов, то я думаю, что все это увязнет в болоте. Здесь можно принять волевое решение, типа того, что делаем так и ни как по-
F>другому, если бы была уверенность в том, что это пойдет на пользу,

Это имхо необходимо...,но сложно.
Ты командуешь всем этим?

F>а не затормозит процесс и вызовет недовольство в команде.

Если платят хорошо... то никуда они не денутся )

F>Если у кого есть соображения и опыт по управлению ситуациями схожими с моей, то пожалуйста поделитесь, буду весьма благодарен.