process - Bugtracker - 集計と自動化されたワークフロー

Question

はじめに:

請負会社で働いています。私たちは、さまざまな企業クライアント向けに、それぞれ独自のルール、SW 規格などを持つ SW を作成しています。

問題：

その結果、いくつかのバグ追跡システムを使用しています。チケット フローの量は比較的多く、SLA は致命的な場合があります。主な問題は、これらのチケットを独自の BT (現在は Mantis) で追跡しているが、顧客の BT でも通信していることです。しかし現状では、2 つの多くの通信チャネルがあまりにも多くの情報ノイズを生み出しています。

解決策、進行状況:

実際の解決策は、ストリームを同期し、SLA やその他多くのことを追跡する責任を持つ従業員です。彼の時間のかなりの部分 (約 70%) を費やしており、それをより価値のあるものに費やすことができます。もう 1 つは、彼の速度が十分ではなく、同期が実際には同期されていない場合があることです。コメントの一部は 1 つのシステムにのみ残され、一部は完全に失われます。（そして、休日や病気で私を始めないでください、それが楽しみの始まりです）

質問：

このプロセスを自動化する方法: タスクの集約、SLA の監視、適切な担当者への通知など、部分的またはすべて一緒に?

回答ありがとうございます。

Answer 1

Slack を見ることができます: https://slack.com/

グループでの会話に最適なツールです

チーム全体のオープン チャネルで話し合い、共有し、決定を下すか、機密事項についてはプライベート グループで話し合うか、1 対 1 のダイレクト メッセージを使用します。

多くの統合ツールを使用でき、Zapier https://zapier.com/を使用 してトリガーをプログラムできます。

さまざまなチャネルを使用すると、グループ会話で適切な人に部分的またはすべて一緒に通知できます:)

Answer 2

明らかな答えは、さまざまな BT のすべてを統合することです。それらが何であるかを知らなければ、それが完全に可能かどうかを言うのは難しい. 最新の BT のほとんどには API があり、統合がサポートされています。一部、特にデスクトップベースのものはそうではありません。それらについては、おそらくデータベースを直接監視する必要があります。

誰かがすでに示唆したように、Zapier は統合を作成するための優れたツールであり、必要なもののいくつかが既に利用可能になっている可能性があります。私は Slack が大好きで、API がありますが、メッセージは基本的に単なるテキストであり、API にメッセージを投稿するときに何らかの区切りを付けたい場合を除き、おそらく機能しません。

予算はわかりませんが、統合を作成するにはリソースが必要です。これらを管理するだけの人を雇うことをお勧めします。内部と外部のバグ追跡システムをクロス ポピュレートし、それぞれの進行状況を追跡するのは、唯一の責任者です。本当に必要なのは、細部にまで注意を払っている人だけです。開発者である必要はありません。これは、開発者リソースを使用するよりも費用対効果が高いはずです。

もう 1 つの選択肢は、単純に停止することです。要件により、クライアントのために行うプロジェクトにクライアントのバグ追跡ソフトウェアを使用するように指示されている場合は、クライアントのソフトウェアを使用するだけで、労力の重複はやめてください。何らかの中央リポジトリまたは作業を管理するための何かが必要な場合は、クライアント、プロジェクト、課題番号、ステータス、および可能であればクライアントの BT の問題へのリンクを含む簡単なテーブルまたはスプレッドシートが必要です。これを一元化する必要性と要望は理解していますが、それが生産性を阻害している場合は、機会費用が高すぎます.

これに対応する統合ツールを作成すると、非常に実用的な製品が得られます。これは実際にはかなり一般的な問題です。