Bugtracker - агрегирование и автоматизированный рабочий процесс

Введение:

Я работаю в компании-подрядчике. Мы делаем SW для разных корпоративных клиентов, каждый из которых имеет свои собственные правила, стандарты SW и т.д.

Проблема:

В результате мы используем несколько систем отслеживания ошибок. Количество потоков билетов относительно велико, и SLA иногда бывает смертельным. Главная проблема заключается в том, что мы отслеживаем эти билеты в нашем собственном BT (в настоящее время Mantis), но мы также общаемся с клиентами в их BT. Но, поскольку это так, два канала связи создают слишком большой информационный шум.

Решение, прогресс:

Фактическое решение - это сотрудник, отвечающий за синхронизацию потоков и отслеживание SLA и многое другое. Он потребляет довольно большую часть своего времени (около 70%), что можно потратить на что-то более ценное. Другое дело, что он недостаточно быстрый, и иногда синхронизация не синхронизируется. Некоторые части комментариев оставляются только на одной системе, некоторые теряются полностью. (И не начинайте меня с праздников или болезней, что там начинается веселье)

Вопрос:

Как автоматизировать этот процесс: объединение задач, просмотр SLA, уведомление правильных людей и т.д. частично или все вместе?

Спасибо, за ваши ответы.

+12
01 сент. '15 в 22:24
источник поделиться
3 ответа

Вам нужно что-то вроде Zapier. Он может отображать различные приложения и синхронизировать данные между ними. Он работает просто:

  • Вы создаете zap (например, между redmine и командной работой).
  • Вы настраиваете сопоставление (как элементы/атрибуты в redmine сопоставляются с элементами/атрибутами в командной работе)
  • Вы генерируете токены доступа в обеих системах и записываете их в zap.
  • Zapier выполняет регулярную синхронизацию между redmine и командной работой.

Но мантис еще не поддерживается Запиром. Если все/большинство ваших клиентов BT находятся в списке приложений Zapier, вы можете перенести свой собственный BT на другую платформу или сделать запрос к Zapier для поддержки мантитов.

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

+2
10 сент. '15 в 5:05
источник

Вы можете посмотреть Slack: https://slack.com/

Это отличный инструмент для групповых разговоров

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

у вас может быть множество инструментов интеграции, и вы можете использовать Zapier https://zapier.com/ с ним в программные триггеры.

С разными каналами вы можете уведомлять правильных людей частично или все вместе в групповом разговоре:)

+2
11 сент. '15 в 9:05
источник

Очевидным ответом является создание интеграции между всеми различными BT. Не зная, что это такое, трудно сказать, насколько это возможно. Большинство современных БТ имеют API и поддерживают интеграцию. Некоторые, особенно более настольные, нет. Для тех, кому вы, вероятно, нужно напрямую контролировать базу данных.

Zapier, как уже было сказано, является отличным инструментом для создания интеграции и может уже иметь некоторые из них, которые вам нужны. Мне нравится Slack, и у него есть API, но сообщения в основном представляют собой текст, и если вы не хотите делать какие-то разграничения при отправке сообщений в свой API, это, вероятно, не сработает.

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

Другая альтернатива - просто остановиться. Если ваши требования диктуют, что вы используете программное обеспечение отслеживания ошибок своих клиентов для проектов, которые вы делаете для них, просто используйте их программное обеспечение и прекратите дублирование усилий. Если вам нужен какой-то центральный репозиторий или что-то для управления работой, может быть, просто простая таблица где-то или электронная таблица с клиентом, проектом, номером проблемы, статусом и, если возможно, ссылкой на проблему в клиентской BT. Я понимаю необходимость и желание централизовать это, но если это удушает производительность, тогда альтернативные издержки слишком высоки. ИМО.

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

0
11 сент. '15 в 12:25
источник

Посмотрите другие вопросы по меткам или Задайте вопрос