Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить. Здесь разговор пойдёт о "надо бы сделать".
А "надо бы сделать" — это "авгиевы конюшни" IT.
X уже полгода не работает — срочно починить!
В моей практике был отличный пример, когда сломалась группа контролов (управляющих элементов в интерфейсе пользователя). Контролы эти предназначались для модераторов, но узнали о проблеме тестировщики... через несколько месяцев!
Само собой была поставлена задача "починить". Однако, не надо исправлять ошибки там, где не просят "пользователи".
Спросив у модераторов, узнал, что эти контролы никогда и не были нужны.
Итог — час работы и удаление довольно запутанной логики из проекта, которая и не была нужна.
Меняем название / стиль / страницу!
У каждого изменения должна быть какая-то причина. Казалось бы... К сожалению, это не всегда так. Иной раз это просто работа по-инерции, иной — хотелка дизайнера / менеджера / другого заказчика.
Если делать изменения под каждую хотелку, то проект вскоре превратится в неподдерживаемую химеру. При этом продукт будет глючным и эклектичным как винегрет.
Банальным вопросом "а зачем?" можно убрать огромное количество задач на исправление в проекте.
Пользователь не понимает — надо переделать!
Ещё один пример из личной практики. Один из интерфейсов был сложным и перегруженным. К сожалению, в штате не было ни одного специалиста по UX, да и просто человека, способного предложить адекватный интерфейс. Но было много людей, утверждающих, что их идея лучше.
В итоге лучшим решением оказалось не переделывать интерфейс, а написать вменяемую документацию. Модулем пользовались редко, к тому же отнюдь не новички — они без проблем читали пару абзацев с руководством, после чего вопросов не оставалось.
Срочно переверстать X под новые требования!
Часто бывает, что задачи доформулируются в последний момент, что требования меняются.
Не надо заниматься фигнёй. Если прилетели "срочные" правки, то, скорее всего, опять ничего толком не продумали.
Не надо делать двойную работу "в стол". Лучше разобраться: а зачем и почему мы меняем X? А не придётся ли завтра снова всё переделывать?
Если дело действительно срочное, то можно обойтись минимальными правками, либо вообще без них. Если не такое уж и срочное — возьмите тайм-аут на принятие окончательного (для данного этапа) решения.
В макете был другой шрифт!
Если вам попался дизайнер, который от страницы к странице сохраняет стиль схожих по смыслу элементов — вы счастливый человек!
Зачастую это не так. У дизайнера есть несколько проектов, под которые он рисует "типа красивые картинки". В этом плане дизайнер — процесс без памяти: он не помнит, какого размера был заголовок на предыдущей странице; не знает, что кнопки у нас на сайте делаются закруглёнными. Он просто делает "типа красиво".
Поэтому несоответствие макета уже свёрстанным элементам — всего лишь маркер того, что дизайнер не следует общему стилю.
Если же прилетают правки "сделать как в макете" — это уже детектор ленивого менеджмента. Он не задумался о макете в разрезе всего проекта. Он просто "лайкнул" картинку.
Вместо итога
Бывают правки, от которых зависит судьба проекта. Это всё то, без чего он не является ценным для пользователя.
Бывают правки, от которых зависит благосостояние компании. Обычно это про деньги, контракты и всяких юристов.
Все остальные правки — не факт, что нужны.