質問: 設計バグの重大度をどのように伝えますか?標準化する方法はありますか? ユーザビリティ関連のバグに対処してトリアージするとき、私は頻繁にショーを作成するか、問題に関するユーザーの苦痛を精巧かつ劇的に説明することに頼らなければならないことに気づきます。私は常にこれのいくつかを行う必要があると確信していますが、問題がどの程度深刻であるか/感じているかを伝えるためのより標準化された方法があったら幸いです。私はmozillaでバグをタグ付けするヒューリスティックスを発見するバグをタグ付けしている人々について読んだことがあります。これは素晴らしいアイデアだと思いますが、それは深刻さにはあまり役立ちません。誰かがそこに良いアイデアやプロセスを持っていますか?例としては、1つのバグがデザイナーに感じられるかもしれませんが、この状態ではこれをリリースしてはいけませんが、それをプログラムした開発者にとっては、動作は明白に見えるので、それほど深刻ではないようです。
回答: この問題に2、3年悩み、使い勝手が比較的悪い製品を作成した後、この問題を別の方法で解決しました。問題の原因は2つあります(少なくとも私が作業する場所)。1)「ビジネス」は、ユーザビリティの問題をスケジュール設定/優先順位付けすることは決してないため、a)新しい機能/バグ修正が必要であり、b)発想する方法がありません。使い勝手が悪い場合のコストの定量化(つまり、ソフトウェアの専門家ではなく、ドメインの専門家です)。2)(従来の)開発者は、a)問題の範囲/コストを確認できない場合が多く、b)フロントエンド開発に自信がない場合が多いため、c)常にフォーカスが盗まれているため、ユーザビリティの問題をスケジュールしたり優先したりすることはありません。開発者の仕事の中核となる問題によって。その結果、使い勝手が悪くなります。そのため、imoでは、ユーザビリティに対処するために、本質的に別の開発チャネルが必要です。これは、技術的負債とほとんど同じです(私が主張することも、この方法で「解決」されます)。理想的な世界では、独自の優先順位でフロントエンドエンジニアを採用するために、反復ごとに2、3のアジャイルポイント(または2週間のリリースごとに2日間)を費やすだけの小さな開発チャネルを作成します。 -リスト。この新しい開発チャネルは、ユーザビリティの問題を絶えず一貫して発生させ、ユーザビリティの問題は、非ユーザビリティの問題ではなく、お互いに優先されます。さて、私の最初の段落の両方の聴衆にとって、いくつかの研究の要約、ケーススタディの結果、認められた教祖からの引用などを集めて数日を費やすなら、人々を説得する議論を構築することができるはずです。しかし、1時間の仕事を十分に優先させるために、4時間の研究と議論の構築に費やす時間のある人は誰でしょうか。しかし、単一の問題の優先順位付けを正当化するのではなく、開発の別のチャネルを正当化することを支持するものではなく(アプリの使いやすさの悪い例をいくつか挙げて)一緒に議論を得る場合、見返りは突如努力に値するものです。私は普通のc#.net開発者であり、ユーザビリティへの関心が高まっています。私がしたことは、ユーザビリティの問題を検討することの重要性についての議論をまとめ、ctoに提案書を提出し、今ではユーザビリティの問題に自分の時間の一部を割り当てています。私のチームはいくつかの中核的な開発リソースを失いました(私たちは採用していたのでとにかくそれはより簡単な議論でした)が、今やいくつかのユーザビリティが最終的に見られるでしょう。私の新しい仕事の一部は、使い勝手が悪い機能をリリースしないように他の開発者を教育することだと私は長期的に考えています。それがあったように、効果を増幅します。幸運を!