А нужно ли список багов в проекте делать публичным?

Сейчас стало модным давать пользователям возможность смотреть список известных багов в проекте, вносить новые баги и даже голосовать за баги.

Плюсы более-менее очевидны:

• Разработчики получают хороший способ для сбора информации о проблемах пользователей.
• Пользователи могут использовать список известных багов, чтобы решить проблемы самостоятельно. Часто это оказывается более быстрым способом и снижает нагрузку на службу техподдержки.

Но если плюсы дают знать о себе сразу, то минусы такого подхода проявляются через некоторое время:

• Багтрекер — это часто еще одно место для поиска информации о проблеме. Т.е. если у пользователя возникла ошибка, и он хочет решить проблему сам, то он должен посмотреть в форуме и поискать в багтрекере. Если оставить пользователям только форум или только багтрекер — будет даже лучше, т.к. искать похожие проблемы нужно будет только в одном месте.
• Предположим, пользователь нашел ошибку в продукте и внес ее в багтрекер. Если бы он написал по e-mail и не получил бы ответа в течение суток, то либо разработчики уже умерли, либо сервис оставляет желать лучшего :-) Но если бага попала в базу, то этот факт совершенно не обязывает разработчиков хоть как-то реагировать. Наличие баги в багтрекере совершенно не означает, что разработчики ее признают или собираются исправлять — ее вполне могут закрыть через 5 лет с комментарием won't fix. Спросить прямо в багтрекере многие пользователи стесняются, все-таки это «общественное» место.
  Т.е. видя багрепорт в багтрекере, пользователь может подумать, что:
  • если разработчики багрепорт не закрыли, значит, они признают проблему. Ошибка будет скоро исправлена
  • разработчики просто накапливают информацию по проблеме. Будут ли разработчики исправлять эту ошибку и когда — неизвестно.
  • Про эту ошибку разработчики знают X лет, а она все еще не исправлена. Наверное, они ее вообще исправлять не собираются, не стоит тратить на ее обсуждение время.
  Причем, если разработчики сначала долго накапливали информацию по какой-то проблеме, а потом сказали won't fix — реакция пользователей может быть крайне негативной.
  
• Есть такое плохое явление — дать задание разработчику исправить bug, непосредственно внесенный пользователем. Конечно, это упрощает жизнь руководству (не нужно думать, чем занять разработчика, «повесил» на него какой-нибудь баг и сиди спокойно), но плохо сказывается на качестве продукта. Уж слишком велик созблазн исправить именно эту маленькую проблему, а не попробовать понять и устранить причину этой и десятка других подобных проблем.

Решение проблем, в принципе, известно:

• Делаем 2 типа задач: bug report и change request.
• Если пользователь нашел ошибку, то он просто создает bug report. Причем регистрировать надо все ошибки, заставлять пользователя искать похожие проблемы чтоб избежать дубликатов — это очень плохая идея т.к.:
  • это неуважение к пользователю. Он нашел глюк, а вместо того чтоб получить от него информацию любым удобным способом как можно быстрее (хоть по e-mail), его заставляют регистрироваться, искать чего-то похожее, заполнять какие-то формы и т.п.
  • пользователь не может знать, что это тот же самый глюк, а не похожее проявление какого-то другого глюка.
  • разработчики (частично) теряют информацию о важности проблемы, так как не все проблемы регистрируются.
    Т.е.bug report — это не сообщение об абстрактной ошибке, а о проявлении ошибки у данного конкретного пользователя.
  Представьте, что Вы приходите в милицию с заявлением о краже, например, а у Вас не берут заявление, пока Вы не сходите в архив, и не поищите похожие преступления :-) А в области software development такое поведение считается открытостью компании и хорошим сервисом :-)
• После того как пользователь внес bug report, представитель компании должен сообщить ему (лично) когда проблема будет исправлена и что планируется делать. Bug report без ответа сильно подрывает доверие к самой идее.
• Когда в компании все-таки решили исправить ошибку, нужно создать отдельные задачи типа change request, которые должны быть связаны с bug report-ами. Несколько change request-ов нужны, если исправление ошибки включает в себя не только исправление кода, но и обновление документации, сайта и т.п. Важность создания отдельных change request-ов еще в и том, что исключается возможность «повесить» исправление проблемы на разработчика без лишний раздумий.

Главная проблема с этим подходом — далеко не все issue tracking системы позволяют удобно связывать bug report-ы и change request-ы, назначать на них разные workflow, устанавливать для них разные правила видимости.
Если Ваша система не позволяет так делать, я бы посоветовал использовать багтрекер или только для общения с пользователями (вносим только bug reports), или только для внутренней разработки (вносим только change requests), но не мешать все в одну кучу.