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

Предлагаю внедрить в ваш типовой рабочий процесс инструмент понижения неопределённости — любая задача, фича, проект начинаются с явного этапа исследования и оценки. Принцип: «исполнитель понимает задачу».

Например, приходит к вам внутренний клиент и просит вкрутить новую фичу. Вы не обещаете ему сроки сразу, а говорите, что вам нужно икс дней на исследование и планирование. Пропустить этот этап нельзя. Если он согласен потратить ваше время таким образом, вы садитесь и собираете себе техническое задание — что и в каких модулях нужно поменять, какие краевые условия, какие подводные камни и так далее. Результат этой работы — задание и план с промежуточными контрольными точками — «гвоздями в гусенице». Если клиенту план окей, вы начинаете работу.

Этап подготовки лучше стандартизировать. Например, для простых на вид задач — три дня, для сложных — неделя. Так клиентам будет проще планировать свои запросы.

Стесняться явно тратить время на подготовку задания не стоит. Это не наглость, а необходимость в текущей ситуации. Некоторые компании на подготовительную работу спокойно просят не только время, но и деньги.

Что касается управления, когда задача уже в работе — «стоп, мы это не потянем» и подобное — дедлайн ваш главный советчик. Если вы собрали план с промежуточными контрольными точками, отправились его реализовывать и видите, что «гвозди» срываются так, что уже и общий дедлайн под угрозой, надо остановиться и решить, что делать.

В общем случае лучше упрощать решение — флексить, но не отказываться от задачи вовсе и не сдвигать срок. В конечном счёте вам платят за результат в срок, если результата нет, причины, честно говоря, клиентам не так уж и важны.

Когда настроите нормальную прогнозируемую работу с текущей системой, подумайте о постепенной переработке легаси. Один из рабочих подходов — «построить сбоку». С таким подходом вы какое‑то время не трогаете «олд‑щит», а нужные вам штуки строите параллельно с ним. Пример — новый сайт бюро.