Bugtracker - агрегирования и автоматизированный технологический процесс

Question

Введение:

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

Проблема:

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

Решения прогресса:

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

Вопрос:

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

Благодарим вас за ответы.

Answer 1

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

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

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

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

Answer 2

Вы можете посмотреть слабину: https://slack.com/

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

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

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

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

Answer 3

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

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

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

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

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