Программирование как "Антибиотик" проекта: "Одно лечим - другое калечим"

Коллеги, добрый день.

Я за советом к опытным программерам, тим-лидам или просто успешно управляющим командами с веб-разработкой.

-

Систематически возникает следующая проблема:

1) Программисты внедряют что-то на сайт - например новую категорию на сайте (или правки по старой категории).

2) Проверка внедряемого (собственно по поставленному ТЗ) не выявляет каких - либо проблем.

3) В местах, которые согласно ТЗ не были затрагиваемы проверяющим начинаются проблемы. Отвалилось что-то здесь, что-то там. Что-то еще появилось там где не должно было и так далее.

В результате получается, что задача проходит проверку, но полученный результат, если что-то слетело просто катастрофичен.

-

Есть несколько напрашивающихся "простых" вариантов решения:

1) После любой правки проверять все.

- Катастрофически нерентабельно с точки зрения ресурсов. Можно сократить время проверки знанием условно "глобальных переменных", которые участвуют не только в проверяемом разделе, но и в других. И таким образом проверять только те места, где еще участвует эта глобальная переменная. Но проблема в том, что зачастую нет данных о том, переменная глобальная или нет (если касается веб-сайта). То есть нет понимания, что конкретно это меню выводится не только в этом разделе, но еще и в другом месте. В общем и целом путь нерентабельный как я его вижу. И непонятно кто должен отвечать за эту проверку (чьи ресурсы уйдут на проверку) - программиста или специалиста, который проверяет задачу. Т.к. проверяющий свою задачу должен только ее и проверить, а не все вокруг.

-

2) Дать на "ковровую проверку" всем заинтересованным участникам.

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

-

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

-

В общем проблема меня задолбала. Программисты, к которым я обращаюсь - разводят руками - "так все делают" - и либо одна правка вызывает 3 дополнительных косяка - либо тратят тонну ресурсов на перепроверку.

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

-

Вопрос:

Как правильно этот вопрос менеджерить?

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

Что предусмотреть, чтобы это было не слишком ресурсозатратно?

.

Спасибо