Сообщений в теме: 6

[PolinaR]

Очень интересует вопрос на сколько нынче распространена практика предоставления доступа к БД ошибок Заказчику.
С одной стороны можно наглядно демонстрировать как мы доблесно и быстро справляемся с трудностям =) а с другой стороны..... Фиг его знает чем всё это закончится. Если будут проблемы, то Заказчик и так нервничать начнёт, а тут ещё эта база глаза мозолит: и оформлена неудобно, и ошибки не фига не правятся....

Вопрос, собссно, в следующем. Знаете ли Вы компании, которые предоставляют своим заказчикам доступ к БД ошибок.

[wmi]

Вопрос, собссно, в следующем. Знаете ли Вы компании, которые предоставляют своим заказчикам доступ к БД ошибок.

Наша компания предоставляет. Но БД построена так что есть возможность фильтровать что показывать кастомерам, а что только для внутреннего пользования.

[PolinaR]

Спасибо за ответ.
Но меня интересуют именно названия компаний, которые "исповедают" данную политику взаимоотношения с клиентами. Я не прошу Вас назвать Вашу компанию, но может Вы приведёте примеры подобных компаний...
Microsoft не в счёт =))

[Dimon]

Спасибо за ответ.
Но меня интересуют именно названия компаний, которые "исповедают" данную политику взаимоотношения с клиентами. Я не прошу Вас назвать Вашу компанию, но может Вы приведёте примеры подобных компаний...
Microsoft  не в счёт =))

Мне немного не ясна цель данного вопроса.
Любая оутсорсинговая компания (мне кажется вы работаете в этой сфере), стремится создать для заказчика максимально прозрачные процессы. А прозрачность и есть открытость.

Я к сожалению работаю в Украинской компании, и о CMM и CMMI знаю только по наслышке. Но уверен участники форума, подтвердять, что внедренние данных процессов абсолютно прозрачно и для самого заказчика.
Также раз уж вы Tester/QA, посмотрите статьи о TQM (на чем базируется большинство процессов), открытость и контроль на каждом шаге производства (в нашем случае ПО), ключ к успеху и если заказчик будет принимать участие, а он, как никто другой заинтересован в успехе, то успех хотябы станет ближе.
Пожалуста участники форума, с поставленными и сертифицированными процессами, поправьте меня, если я ошибаюсь или неправильно использую терминологию.

Я видел(иногда участвовал) в проектах где заказчик поступает по принципу, выставив требования, а дальше тихо ждет результата. Это пример плохой коммуникации. BTS один из способов коммуникации между Вами и Вашим заказчиком, на равне с IMs, email, etc. Зачем им принебрегать?
По большей части заказчик который мало что понимает и представляет вряд ли полезет в в BTS, т.к. полученная информация для него будет сложна и непонятна. Крупные же заказчик, настаивают на использовании таких систем или дают доступ к своей, как часть своих же процессов.

и оформлена неудобно

А вы не пробовали другую систему?
Сейчас Issue Tracking System (ITS думаю, более широкое поняти, чем BTS) большое множество. И не раз были обсуждения их на этом форуме, и есть статьи на этом сайте.

Кратенько повторьсь.
Из бесплатных наиболее известна BugZilla, имеет кучу дополнений. Но...
Нам она показалась излишне запутанной и мы используем Mantis. В тем более скоро должен выйты его версия 1.0, которая будет достаточно функциональной и конфигурируемой.
Из платных (для sourcefourge проектов бесплатна) пробовали и работали (клиента система) с Jira очень конфигурируемая система и проста, можно приспособить под любой LifeCycle. Также наслышан о FogBugs увы пробовать не приходилось.

Вы немогли бы уточнить Вашу должность, почему Вас так волнует доступ к БД?
Ведь Ваше дело в систему отрепортить, и иногда следить, чтобы следовали процессу репорта (если таковой имеется).
Это менеджеры должны волноваться и волнуются, что в системе много багов и они медленно фиксятся.

[Mex]

Демон рулит, даже добавить нечего :)

[Лена]

Мы, например, предоставляем доступ заказчику к багам. Пользуемся bugzilla.
Только заказчик, когда получил две сотни писем о комментариях к багам и исправлениях статусов, перестал базу смотреть. Теперь если какой вопрос к заказчику, на багзиллу не надеемся - приходится дополнительно письмо писать, а раньше прямо в багзилле обращались - удобно было.

[Dimon]

Мы, например, предоставляем доступ заказчику к багам. Пользуемся bugzilla.
Только заказчик, когда получил две сотни писем о комментариях к багам и исправлениях статусов, перестал базу смотреть. Теперь если какой вопрос к заказчику, на багзиллу не надеемся - приходится дополнительно письмо писать, а раньше прямо в багзилле обращались - удобно было.

Точно. Очень частая ситуация.

Но subject заключался в вопросе, а стоит ли открывать БД вообще.
Ответ наверно будет "Yes!"

Для заказчика не имеющего прямое отношение к IT.
Вы точно ничего не потеряете, т.к. сказано выше он просто испугается полученному объему информации. И затем в его глазах вы будете выглядеть действительно специалистами.
Note: Если Вам чего-то объясняют, а вы не особо понимаете, то Вам подсознательно кажется что вы столкнулись с специалистами.

Для заказчика с большим опытом в IT.
У Вас вряд ли будет выбор "не открывать", т.к. такие заказчики, бывает даже, на пол шага впереди Вас, и знают чего ожидать от системы и как ее использовать. (Как я писал выше, у них может быть и своя BTS)