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

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

Если речь идёт о процессе разработки и внедрения, то регламент должны предложить консультанты или менеджеры. Если же речь идёт о нечётких постановках, то здесь решение простое:
1) формализация заданий, например, через почту
2) должна быть ясна иерархия их ставящих, например, если пришло два разных задания, то необходимо точно знать, чьё будет выполняться или кто из руководства примет об этом решение
3) что касается требований, то пусть сами разработчики будут вначале уточнять (опять-таки через почту), а потом уже браться за разработку.

В любом случае, необходимо (а) выделить определённые узловые точки в процессе разработки, (б) выделить человека, который будет принимать решение при спорных ситуациях с регламентом, (в) людей, которые смогут давать экспертные оценки при спорных вопросах. Ну а ограничивать все это будет бюджет и менеджер

А так процесс можно кратко разделить, например, на следующие этапы:
задумка/хотелка - постановка - техническое задание и/или техническое решение - реализация - документация - акт тестирования - акт принятия.

Э-эх. Хорошо бы! У нас обычно. задумка/хотелка - реализация. Тестирование в процессе эксплуатации

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

Это нормально до тех пор, пока есть человек, который отвечает за корректность разработки и сроки. Обычно много документов пишется когда нечего делать, надо "оправдать" затраченные средства/время или недостаточный профессионализм.

Наиболее устойчивым является конфигурация, когда за разработки по определённому модулю (их сроки и качество) отвечает руководитель группы разработчиков, который дальше сам распределяет задачи по подчинённым программистам, обеспечивает контроль и т.п.

Какой регламент, какая документация. Это же явная угроза, что программиста выпрут с работы на следующий день, после ее написания.
И вообще желательно в коде программы заменить все переменные наборами 32 байтовых случайных символов, слить все в одну строку длиной 64К с разделителем в один пробел.
Из комментариев допускается только фразы типа "This fu$king piece of sh!t contains not detected bug and must be rewrited in the next release."
И тогда можно спать спокойно, в том числе и на работе.

читая посты ниже.,что - всему своё время.

А вот и господа консультанты подошли.