Комментарии 1
Для меня это вполне очевидные вещи, однако удивительно, почему они не очевидны для других людей.
Первая задача которую я преследую когда завожу документ о дефекте — его быстрое разрешение. Если у других людей документ вызывает хоть какие-то дополнительные вопросы, нужно улучшать документ.
Я заметил, что часто разработчики «терпят» плохо оформленные репорты. Наверное им нравится решать головоломки, чем сложнее тем лучше.
Я считаю этого делать нельзя, разработчик должен вернуть такой документ автору. Я постоянно твержу это своим разработчикам, чтобы они пытались расшифровать плохо оформленный или неполный документ, не тратили на это свое время, а вернули документ, иначе документы никогда не станут лучше и будет как в теории разбитых окон.
Но для этого должна существовать четкая директива признанная во всем проекте. У нас такой нет.
Первая задача которую я преследую когда завожу документ о дефекте — его быстрое разрешение. Если у других людей документ вызывает хоть какие-то дополнительные вопросы, нужно улучшать документ.
Я заметил, что часто разработчики «терпят» плохо оформленные репорты. Наверное им нравится решать головоломки, чем сложнее тем лучше.
Я считаю этого делать нельзя, разработчик должен вернуть такой документ автору. Я постоянно твержу это своим разработчикам, чтобы они пытались расшифровать плохо оформленный или неполный документ, не тратили на это свое время, а вернули документ, иначе документы никогда не станут лучше и будет как в теории разбитых окон.
Но для этого должна существовать четкая директива признанная во всем проекте. У нас такой нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стиль ведения дефектов