要求開発Openthologyを保守業務に適用できないか

パッケージソフトの保守業務は、Ｑ＆Ａ、新機能の追加、不具合の修正などなど多々あります。特に海外のパッケージを扱う場合は海外企業への問い合わせことが多くなりますがその回答が思うようなレスポンスで得られず作業が滞ってしまうこともしばしばです。
ここでも問題なのが作業の優先順位です。しかし優先順位を決めるのは難しいことです。当たり前ですが、顧客からしてみれば自分の作業が一番ということになります。そこで要求開発Openthologyの準備、立案、デザイン、シフトの考え方が適用できると思います。特に準備フェーズにおける「目的・ゴール」を定め全員で「共有」するプロセスは、顧客からの問い合わせだけを取り上げて作業するのではなく、なぜその問い合わせが必要なのか、本当に必要なのかなどを顧客と話し合い、問い合わせで解決しなければいけないゴールを明確にし全員で共有することが必要だと感じています。
今まで保守作業が混沌とした状態が続いていなのはOpenthologyの「準備フェーズ」が明確になされていなかったためと考えています。保守業務を行う上でのプロセスをOpenthologyで明確にしたいと思っています。
ただ、保守業務特有の作業優先順位を具体的にどうやって決めれば良いかはこれから考える必要があります。例えば、業務への影響度によって優先順位を決める場合は、影響を受ける利用者数を影響度とするなどが考えられます。