У нас есть стандартная система отслеживания проблем для отслеживания дефектов/улучшений с точки зрения конечного пользователя и управления проектами. Тем не менее, нам также необходимо отслеживать внутренние ошибки команды, которые могут включать рефакторинг определенных частей кода или изменение чего-либо в приложении, с которым у конечного пользователя нет никакого взаимодействия.Отслеживание проблем с внутренней разработкой
Лучше ли отслеживать эти дефекты и улучшения в одной системе слежения? Моя оговорка заключается в том, что руководители проектов, которые смотрят на дефекты пользователя, будут смущены этими внутренними запросами, и это вызовет ненужную озабоченность. У нас есть еще одна система отслеживания дефектов только для внутреннего использования команды?
Спасибо, мне нравится этот подход. PM здесь больше сосредоточены на бизнес-функции, поэтому он не предназначен для скрытия информации от кого-либо, а просто для того, чтобы не сводить их с недостатками, которыми они не справляются. – BoxerBucks
Я бы не различал внутренние и внешние ошибки. Возможно, внутренние ошибки/задачи могут быть помечены, если менеджеры хотят отделить их в отчетах. Разделение систем или типов дефектов может привести к неумелой работе - «Позвольте мне просто зафиксировать то, что у меня есть сейчас, если кто-то обнаружит ошибку, это будет все равно». – publicRavi
@publicRavi - Возможно, но я бы предположил, что внутренние и внешние недостатки будут сталкиваться с одним и тем же вниманием, это будет просто из разных команд. Фактически, «внутренняя» ошибка может столкнуться с большим вниманием, потому что они будут больше внимания разработчиков, и мы все знаем, насколько придирчивые разработчики могут быть о коде и элегантности (или, по крайней мере, должны быть) – BoxerBucks