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

[Teffy]

Всем доброго врямени суток!
Посоветуйте, пожалуйста. Мы столкнулись с тем, что нам нужна система, где будет храниться информация о клиентских запросах. У нас есть bugtracking - Mantis. Вот теперь думаем толи его поднастроить, толи что-то похожее найти. Требования к системе: простота, возможность добавить свои статусы заявки, т.е. туда будет доступ у клиентов, чтобы посмотреть в каком состоянии их запрос. Желательно, чтобы система была недорогая (ничего глобального пока не надо), а то и вовсе бесплатная. Посоветуйте, пожалуйста!

[afon]

Mantis довольно просто настроить под такие задачи - у нас на фирме он успешно используется для описанных вами целей. Так что мне кажется вам не стоит пытаться изобрести что-то новое, а все таки пользоваться имеющейся у вас системой, соответственно ее настроив. Тем более что Mantis удовлетворяет вашим требованиям - простота, возможность добавить свои статусы заявки.

[van]

Действительно, для описанных требований подойдет любая система отслеживания ошибок.
Но я почему - то уверен, что список требований не ограничивается простотой и возможностью добавления статусов...

Думаю, что рано или поздно "всплывут" такие требования к системе, как:
- разграничение доступа
- контроль изменений
- отслеживаемость
- трассируемость
- отчетность
и т.п.

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

А дальше уже, исходя из этих требований, выбирать систему, которая максимально будет им удовлетворять. Будет ли это система отслеживания ошибок, система управления требованиями или CRM система.

[Clauster]

Действительно, для описанных требований подойдет любая система отслеживания ошибок.
Но я почему - то уверен, что список требований не ограничивается простотой и возможностью добавления статусов...

Думаю, что рано или поздно "всплывут" такие требования к системе, как:
- разграничение доступа
- контроль изменений
- отслеживаемость
- трассируемость
- отчетность
и т.п.

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

А дальше уже, исходя из этих требований, выбирать систему, которая максимально будет им удовлетворять. Будет ли это система отслеживания ошибок,  система управления требованиями или CRM система.

Имхо, все популярные на данный момент BTS обладают необходимыми требованиями.
PS осталось дождаться ответа Баранцева про TrackStudio ;)

[van]

Имхо, все популярные на данный момент BTS обладают необходимыми требованиями.

Не соглашусь!
Назавите пожалуйста, какие BTS в настоящее время предоставляют возможность:
- версионности
- строить таблицы/диаграммы трассируемости
- контроля изменений
- историчности
- ведения дискуссий
- формальной проверки требований
- экспорта/импорта в офисные приложения

Я же не зря написал и т.п. :)

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

PS. Если поднапрячься, то можно еще вспомнить несколько полезных требований для системы управления требованиями :)

[winzard]

PS. Если поднапрячься, то можно еще вспомнить несколько полезных требований для системы управления требованиями :)

Если не сложно, вспомните, пожалуйста.

[Clauster]

PS. Если поднапрячься, то можно еще вспомнить несколько полезных требований для системы управления требованиями :)

Прошу заметить, что изначально речи о системе управления требованиями не идет.
Зачем забивать человеку мозги? Речь о change request-ах, запросах на изменение ПО.

[Teffy]

Всем спасибо!
но речь действительно идет просто о системе регистрации запросов на изменение. Дело в том, что мы решили, что пускать клиентов в Mantis не очень хочется, а вот дать им возможность следить за статусом заявки и по необходимости внести в нее комментарий надо. Пришли к этому, потому что количество вопросов о том как дела продвигаются и в какой стадии их запрос (несмотря на обговоренные сроки) напрягают. Да и хочется, чтобы можно было просмотреть каталог именно клиентских запросов. Так что система нужна простая (чтобы и клиентам, не всегда хорошо владеющих компьютером было удобно и не пугало). Надо наверно будет еще в мантисе покопаться. Но может все-таки есть какой-то похожий продукт. Что-то мы ищем ищем и никак найти не можем...

[afon]

to van:
- разграничение доступа
- контроль изменений
- отслеживаемость
- трассируемость
- отчетность
- ведения дискуссий
- экспорта/импорта в офисные приложения
Все это Мантис умеет делать.

А по поводу
- строить таблицы/диаграммы трассируемости
- формальной проверки требований
Речь идет о системе Change Request'ов, а не о системе проверки требований. Для этого есть специализированные инструменты и вопрос был не о них

to Teffy:
" Дело в том, что мы решили, что пускать клиентов в Mantis не очень хочется, а вот дать им возможность следить за статусом заявки и по необходимости внести в нее комментарий надо"
Так в чем проблема? Заведите отдельный проект в Мантисе и добавьте туда ваших клиентов - они соответственно ничего другого (того что вы не хотите показывать) не смогут увидеть.
В крайнем случае можно поднять второй Мантис сделав в нем один единственный проект - для ваших клиентов.
По поводу простоты - я работал с несколькими системами баг-трекинга, н ни одна из них не была настолько интуитивно понятной и удобной как Мантис.

[sunlex]

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

Можете перечислить эти баг-трэкинг системы (которые по вашему более удобны чем Мантис)?
Мне интересно мнение людей реально работавших с продуктами:)

[Clauster]

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

Можете перечислить эти баг-трэкинг системы (которые по вашему более удобны чем Мантис)?
Мне интересно мнение людей реально работавших с продуктами:)

Вы хотели сказать менее?

[Imbecile]

У себя на работе используем RT.
Преимущество перед Мантисом - наличие понятия очередь.
В двух словах.
Создаём четыре очереди:
<ProjectName>-Incoming
<ProjectName>-Design
<ProjectName>-Development
<ProjectName>-QA
и ещё одну для поддержки
<SysAdmin>

В очереди помещаются тикеты (Tickets)
Задача ответственных за очередь побыстрее спихнуть тикет ещё куда-нибудь
Закрыть тикет может только создатель или кто-то с соответствующими правами, например Top Level Manager
Процесс использования выглядит приблизительно следующим образом (проще показать на примере):

1. Клиент хочет чтобы у него кнопка была красной и круглой. Он помещает тикет в Incoming
2. Ответственный за заявки клиента рассматривает тикет и помещает его либо в Design, либо в Development (в зависимости от того, требует ли request пересмотра архитектуры, уточнения требований и т.п.)
3. Ответственный (либо исполнитель) очереди Design, как только уточнит требования, передаёт заявку дальше, в Development.
4. Разработчики рассматривают заявку и реализуют её в коде. Параллельно руководитель проекта со стороны QA готовит тест-кейсы, тест-план и т.п. После окончания разработки тикет передаётся в очередь QA.
5. После получения тикета в очередь QA, производится тестирование соответствующего функционала. Все критические баги (например, кнопка не круглая, а треугольная) комментятся в тикете и после окончания тестов, тикет возращается разработчикам.
6. Разработчики фиксят баги и отдают тикет обратно в QA (в принципе, если проблема в дизайне, можно и в дизайн). И так до тех пор, пока не можно будет заявить о том, что кнопка реализована согласно пожеланиям клиента. После этого, тикет передаётся обратно заказчику (или Top Level менеджеру) и он проводит приёмочное тестирование в результате которого выносит решение, закрыть тикет или отправить опять по соответствующему циклу.

RT - бесплатное ПО
RT - web-приложение
RT - позволяет посылать email нотфикации всем заинтересованным стронам, как в автоматическом режиме (при помещении тикета в очередь, нотификацию получают её наблюдатели, в случае с очередью Development это может быть Team Leade и QA Leader), так и в ручном режиме (просто указываются адреса, на которые слать оповещения об изменении состояния тикета).
RT - позволяет настроить уровни прав доступа на конкретные очереди (тикеты в очереди) для каждого учасника процесса производства ПО (и не только, например у нас RT используется для организации работы всего офиса, покупка сахара, кофе, подготовка новых компов и т.п.)
Ну и ещё куча всяких возможностей.

Из недочётов:
дурацкая система поиска тикетов
непривычный интерфейс
И к тому, и к другому надо привыкнуть.

В любом случае, в каждый момент времени все заинтересованные стороны могут видеть, на какой стадии находится работа на Request-ом. Главное, каждый раз, когда кто-то, что-то сделает, надо прокомментировать это в тикете.

P.S. Зачем я добавил очередь Sysadmin в своём примере? Просто, чтобы показать и их участие в процессе разработки софта, например настроить монитор на тестовом серваке так, чтобы он показывал не в чёрно-белом режиме, а в цветном :) и соответственно тикет попадёт в Sysadmin.

P.P.S. А вообще, как показывает опыт, инструмент - это не главное, главное это организация процесса. Сначала в любом случае надо организовать процесс на словах (Request Workflow), а уже исходя и его видения - выбирать инструмент.

[zemljak]

Imbecile, очень познавательно.
Только вот скажите, сколько времени у вас может занять фикс такого реквеста?

[Clauster]

У себя на работе используем RT.
Преимущество перед Мантисом - наличие понятия очередь.

Думаю, что описанный вами процесс легко организовывается как в Мантисе, так и в другом более менее приличном багтрекере :)

5. После получения тикета в очередь QA, производится тестирование соответствующего функционала. Все критические баги (например, кнопка не круглая, а треугольная) комментятся в тикете и после окончания тестов, тикет возращается разработчикам.

извращенцы :)

[Imbecile]

Imbecile, очень познавательно.
Только вот скажите, сколько времени у вас может занять фикс такого реквеста?

От одного часа до нескольких дней (или даже недель).
Обычно через RT идут requests, которые подразумевают действительно много работы либо содержат в себе совокупность более маленьких.

Но не вижу никаких причин, почему бы не использовать RT и для маленьких requests.

P.S. Мой пример - это только один из способов использования RT. Я не считаю, что его должны использовать все подряд. Нашей компании удобно использовать описанную схему, кто-то разработает другую. Всё зависит от нужд и организации процесса.

[Imbecile]

Можете перечислить эти баг-трэкинг системы (которые по вашему более удобны чем Мантис)?
Мне интересно мнение людей реально работавших с продуктами:)

К сожалению сам реально не работал, но по отзывам знакомого разработчика, FogBugz (от JoelOnSoftware) на порядок лучше, чем Mantis или BugZilla. Правда FogBugz - платная программа.