Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Насколько я помню свой опыт общения с OTRS 2.x, то служба поддержки вникала в неё серьезно дольше чем в использование той же JIRA, хотя не скажу, что у JIRA очень уж простой интерфейс. Плюс не было никакой интеграции с багтрекером.
Искренне надеюсь, что в 3-й версии с интерфейсом и интеграцией стало получше.
Искренне надеюсь, что в 3-й версии с интерфейсом и интеграцией стало получше.
Ну видимо у нас своя специфика была. Простых сотрудников поддержки, «исполнителей», которые только смотрели в свой список задач, не было. Одни и те же люди работали сразу над несколькими проектами, занимались уточнением приоритетов и, если нужно, «раскидыванием по очередям», а так же администрированием OTRS.
Т.е. как я и предупредил в начале — универсальных решений не бывает :)
Т.е. как я и предупредил в начале — универсальных решений не бывает :)
OTRS нацелен на крупные команды (суппорт хостинга), администраторы, first/second line support и даже вовсе на других сотрудников. Тут не необходимость использования, а поиск подходящего «не универсального решения», по-скольку все решения в каком-то роде не универсальны.
OTRS лучше и удобнее использовать когда:
1. Вы вообще не хотите знать ни о каких интерфейсах, а просто выслать письмо с проблемой.
2. Для всех реквестов вы хотите использовать единую точку входа, например, support@mycompany.com
3. У вас большой штат обслуживающего персонала (не только админы) по разным направлениям и вы хотите, чтоб нужные запросы автоматом попадали к нужным людям (очереди, которые кстати автоматизируются, чтоб их не раскидывать вручную)
4. Чтобы это всё трекалось по времени, SLA, исполнители вовремя уведомлялись о сроках, менеджеры знали о состоянии дел.
Примеры:
«у меня не работает мышка/принтер/клавиатура/монитор» и прочая мелочь попадает в очередь к эникейщикам
«Выход нового сотрудника» попадает в очереди к hr и админам
«Сгорел датацентр/упали сервера» попадают в очереди к совершенно другим админам
И всё это автоматически.
На больших предприятиях это даёт серьёзных выигрыш. Но в настройку системы придётся окунуться с головой. На малых предприятиях — это может быть накладно и вовсе невыгодно.
Кстати, jira из коробки тоже относительно мало чего умеет в этом плане. Она больше заточена сразу под разработку ПО.
OTRS лучше и удобнее использовать когда:
1. Вы вообще не хотите знать ни о каких интерфейсах, а просто выслать письмо с проблемой.
2. Для всех реквестов вы хотите использовать единую точку входа, например, support@mycompany.com
3. У вас большой штат обслуживающего персонала (не только админы) по разным направлениям и вы хотите, чтоб нужные запросы автоматом попадали к нужным людям (очереди, которые кстати автоматизируются, чтоб их не раскидывать вручную)
4. Чтобы это всё трекалось по времени, SLA, исполнители вовремя уведомлялись о сроках, менеджеры знали о состоянии дел.
Примеры:
«у меня не работает мышка/принтер/клавиатура/монитор» и прочая мелочь попадает в очередь к эникейщикам
«Выход нового сотрудника» попадает в очереди к hr и админам
«Сгорел датацентр/упали сервера» попадают в очереди к совершенно другим админам
И всё это автоматически.
На больших предприятиях это даёт серьёзных выигрыш. Но в настройку системы придётся окунуться с головой. На малых предприятиях — это может быть накладно и вовсе невыгодно.
Кстати, jira из коробки тоже относительно мало чего умеет в этом плане. Она больше заточена сразу под разработку ПО.
Согласен, спорить не буду. Мы использовали OTRS для небольшой кросс-функциональной команды.
Насчет автоматического раскидывания по очередям тоже согласен, есть такое. Но иногда приходят письма вида «а-а-а-а, ничего не работает» от клиентов, с которыми ведется несколько проектов. И в какую очередь положить, приходится выяснять глазами и телефоном :)
Ну и в качестве ремарки, читал как-то про команду, которая использовала OTRS именно для баг-трекинга (и внутреннего тоже). Так что все относительно.
Насчет автоматического раскидывания по очередям тоже согласен, есть такое. Но иногда приходят письма вида «а-а-а-а, ничего не работает» от клиентов, с которыми ведется несколько проектов. И в какую очередь положить, приходится выяснять глазами и телефоном :)
Ну и в качестве ремарки, читал как-то про команду, которая использовала OTRS именно для баг-трекинга (и внутреннего тоже). Так что все относительно.
В стеке Atlassian это к JIRA Service Desk (https://www.atlassian.com/software/jira/service-desk).
Интересно было бы посмотреть еще на то, что с помощью багтрекеров сделать нельзя?
Хотел сначала ответить «нельзя варить кофе», но потом вспомнил про видео с управлением тостером из JIRA. Так что не буду слишком категоричен :)
У нас баг-трекер используется для учета оборудования. Удобно.
Картинка к HelpDesk великолепна.
в JIRA мешает отсутствие вложенных проектов и вложенных задач (подзадачи есть, но они не могут в свою очередь быть вложенными). Существует ли от этого недуга какой-нибудь плагин?..
Есть хороший плагин, который эту проблему «лечит» — Structure. Но, как и многое хорошее в этом мире, он стоит денег.
В TrackStudio неограниченное количество уровней вложенности есть, причем задачи могут быть разных типов, иметь разные права и workflow.
Если сравнивать по тому функционалу, который описан в статье, то:
— прием почты от зарегистрированных/незарегистрированных пользователей тоже есть
— приема заявок через web из коробки нет, решается написанием своего интерфейса (это что-то вроде плагина, можно разные web-морды делать для разных пользователей)
— бюрократия есть. Графического редактора workflow нет, но в остальном гибче JIRA, подробности на сайте TrackStudio
— почтовые рассылки есть, аналогично JIRA
— Дележ ресурсов есть
— голосования из коробки нет, нужно скрипты писать
— тест-менеджмент есть
— API: SOAP и read-only REST, но готовых плагинов/скриптов мало (несколько десятков).
Если сравнивать по тому функционалу, который описан в статье, то:
— прием почты от зарегистрированных/незарегистрированных пользователей тоже есть
— приема заявок через web из коробки нет, решается написанием своего интерфейса (это что-то вроде плагина, можно разные web-морды делать для разных пользователей)
— бюрократия есть. Графического редактора workflow нет, но в остальном гибче JIRA, подробности на сайте TrackStudio
— почтовые рассылки есть, аналогично JIRA
— Дележ ресурсов есть
— голосования из коробки нет, нужно скрипты писать
— тест-менеджмент есть
— API: SOAP и read-only REST, но готовых плагинов/скриптов мало (несколько десятков).
Максим, с TrackStudio, к сожалению, практически не сталкивался и ничего про неё в статье не написал. Поэтому, спасибо за дополнение.
Из интересных вопросов, хотя немного и не в тему. Планируется в TrackStudio делать какое-то взаимодействие с Continuous Integration системами? Или может уже есть какие-то решения?
Из интересных вопросов, хотя немного и не в тему. Планируется в TrackStudio делать какое-то взаимодействие с Continuous Integration системами? Или может уже есть какие-то решения?
Прямо из коробки нет, но можно реализовать скриптами (аналог плагинов в JIRA), по цене это будет не очень дорого, стоить несколько тысяч рублей.
Вообще из-за небольших размеров команды и community в TrackStudio интеграция «из коробки» с разными системами заметно хуже (есть разве что SVN/CVS/Perforce/Bazaar/Git, Google Calendar, вход через LDAP/NTLM/JOSSO/Crowd, экспорт в CSV/XML/MS Prokect, импорт из CSV, ну и REST + SOAP), для JIRA список куда длиннее.
Еще одно отличие JIRA от Redmine/TrackStudio: JIRA — это только трекер (для документов предполагается использовать Confluence), а в TrackStudio/Redmine есть возможность хранения документации. В TrackStudio еще есть макросы типа как Confluence, автосоставление оглавлений, оповещения при изменении документов, история изменений и прочие стандартные для таких систем вещи.
Вообще из-за небольших размеров команды и community в TrackStudio интеграция «из коробки» с разными системами заметно хуже (есть разве что SVN/CVS/Perforce/Bazaar/Git, Google Calendar, вход через LDAP/NTLM/JOSSO/Crowd, экспорт в CSV/XML/MS Prokect, импорт из CSV, ну и REST + SOAP), для JIRA список куда длиннее.
Еще одно отличие JIRA от Redmine/TrackStudio: JIRA — это только трекер (для документов предполагается использовать Confluence), а в TrackStudio/Redmine есть возможность хранения документации. В TrackStudio еще есть макросы типа как Confluence, автосоставление оглавлений, оповещения при изменении документов, история изменений и прочие стандартные для таких систем вещи.
А где в TrackStudio возможность хранения документации? Полазил по сайту и не нашел такого.
В Redmine да, есть своя wiki-система, но, imho, Confluence на голову бьет любую другую wiki-систему в варианте для корпоративного использования, как по удобству, так и по функционалу. Другое дело, что не всем этот функционал нужен.
В Redmine да, есть своя wiki-система, но, imho, Confluence на голову бьет любую другую wiki-систему в варианте для корпоративного использования, как по удобству, так и по функционалу. Другое дело, что не всем этот функционал нужен.
Посмотрите вот тут, вверху скриншоты
www.trackstudio.ru/whatsnew.html
По поводу функционала: в TrackStudio документы — это просто особый вариант представления задачи, они лежат в той же БД, они в дереве выводятся, задачи могут ссылаться на них (а из документов можно ссылаться на задачи, документы так же можно организовывать в дерево.
В TrackStudio есть макросы, на самом первом скриншоте на этих макросах дашборд нарисован (тоже документ), можно свои макросы писать и, например, графики выводить (описание есть в документации). Другое дело, что Confluence можно использовать как такую локальную социальную сеть, а в TrackStudio документы — это просто документы.
www.trackstudio.ru/whatsnew.html
По поводу функционала: в TrackStudio документы — это просто особый вариант представления задачи, они лежат в той же БД, они в дереве выводятся, задачи могут ссылаться на них (а из документов можно ссылаться на задачи, документы так же можно организовывать в дерево.
В TrackStudio есть макросы, на самом первом скриншоте на этих макросах дашборд нарисован (тоже документ), можно свои макросы писать и, например, графики выводить (описание есть в документации). Другое дело, что Confluence можно использовать как такую локальную социальную сеть, а в TrackStudio документы — это просто документы.
Ясно, вижу. Но это не полноценная wiki-система, а просто возможность хранить и редактировать документы. Кого-то определенно устроит и такое, но если работа над документами идет в команде, то лучше все-таки Confluence (и опционально SharePoint или Alfresco).
А чего именно не хватает? Картинки вставлять можно, история изменений есть…
Хотя в целом да, цели создать полноценную систему для работы с документами не было, более типичное применение — knowledge base.
Хотя в целом да, цели создать полноценную систему для работы с документами не было, более типичное применение — knowledge base.
Я, например, от wiki-системы ожидаю, как минимум, такие вещи (не знаю, есть ли они у вас):
— Возможность просмотра diff-ов между ревизиями страницы.
— Возможность комментировать/обсуждать страницы
— Экспорт страниц в разные форматы
— Мержинг одновременно отредактированных страниц или редактирование страниц по секциям. Чтобы люди могли работать над одной страницей одновременно.
Ну а Confluence, в частности, добавляет всякие плюшки вроде вставки картинок прямо из буфера обмена, присоединение файлов через drag-n-drop, ну и пачка социальных (и удобных) штук, про которые вы упоминали.
— Возможность просмотра diff-ов между ревизиями страницы.
— Возможность комментировать/обсуждать страницы
— Экспорт страниц в разные форматы
— Мержинг одновременно отредактированных страниц или редактирование страниц по секциям. Чтобы люди могли работать над одной страницей одновременно.
Ну а Confluence, в частности, добавляет всякие плюшки вроде вставки картинок прямо из буфера обмена, присоединение файлов через drag-n-drop, ну и пачка социальных (и удобных) штук, про которые вы упоминали.
Да, понял. Есть частично:
1) Diff между ревизиями есть
2) Комментирование было, отрезали чтоб упростить интерфейс, если будет потребность — вернем. У нас для страницы можно создавать подзадачи и можно обсуждать исправления уже там.
3) Экспорт в PDF ожидается в следующей минорной версии, сейчас есть экспорт в CSV, XML
4) Мержинга нет.
Из прочего — вставка картинок из буфера у нас тоже есть, файлы через drag-n-drop можно присоединять к задачам, для документов пока не делали. А вот социальных штук в самом деле нет.
1) Diff между ревизиями есть
2) Комментирование было, отрезали чтоб упростить интерфейс, если будет потребность — вернем. У нас для страницы можно создавать подзадачи и можно обсуждать исправления уже там.
3) Экспорт в PDF ожидается в следующей минорной версии, сейчас есть экспорт в CSV, XML
4) Мержинга нет.
Из прочего — вставка картинок из буфера у нас тоже есть, файлы через drag-n-drop можно присоединять к задачам, для документов пока не делали. А вот социальных штук в самом деле нет.
Баг-трекер это не только ценный инструмент, но обычно и система почтовых нотификаций
Бобёр это не только ценных мех…
Бобёр это не только ценных мех…
А существует ли в Redmine поддержка SLA?
У меня на Redmine уже 4 года база данных агенства недвижимости
Колонку телефон замазал, а телефоны в тексте номер замазать — смекалки не хватило?!
Страшно таким людям оставлять свои персональные данные.
Уведомлю владельцев номеров, чтобы больше с такими людьми и компаниями не связывались.
Страшно таким людям оставлять свои персональные данные.
Уведомлю владельцев номеров, чтобы больше с такими людьми и компаниями не связывались.
Да ужас просто, персональные данные, вот только эти телефоны взяты с авито и из газет, люди деньги платили, чтобы мир узнал их телефоны. Вы что в СМС им сказали? Ваш телефон zionkv опубликовал, злодей такой, не подавайте больше номер в газеты? Не говоря о том, что при продаже имущества люди часто покупают одноразовую симку, чтобы потом не мучали звонками.
В общем, мой вам совет: слезайте с лошади, снимайте латы и не грубите людям. А я все лишь человек, который не замазал пару номеров там, где их вообще не надо было замазывать, хотя, на остальных скриншотах с редмайном замазаны в обоих местах, видимо, год назад подумать не мог, что они пишут номера в комментарии. Спасибо за бдительность!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не баг-трекер, а…