チャット系システムをつくっていて、「"空白文字だけの投稿"などの"有意な文字"を含まない投稿を許可しない」というタスクが出た。
機能仕様には含まれないので「バグ」という分類になっていたがそれについて少し考えた
なおそのタスクは即座に消化された。スピード優先。
この手のタスクをバグと分類すると何がまずいのか(なおこれを仕様バグをして扱うことには異論はない)
・開発者が責められているように感じる。
・外聞が悪い(今週のバグ5件?品質悪いんじゃないの?)
・本来バグとして扱うべき物(クラッシュバグや、TL同士が混線する問題)がこれらの「軽微な問題」に埋もれてしまう
・この手の「バグ」が現れることは常態化しがちなので、バグがあっても当然という意識になりがち
・バグ=問題=瑕疵担保で無償対応、という意識からバグかバグでないかの議論に無駄なエネルギーが割かれがち(受託でよくある問題)
対応として
私としてはこれがバグだろうがバグじゃなかろうがどうでもいい。内製開発だし。
ただこれが許されるとTLの見た目が悪くなるのでUXが悪化する。UXを悪化させたくないので対応したい。
なのでUX向上作り込みタスクと呼称した。
対象は「存在したとしてもUXをクラッシュするレベルではないが、あると使いづらい、ダサい」レベルのバグ
そうすると
・ポジティブに聞こえる
・外聞が良い(ユーザーの方をちゃんと向いているように見える。)
・やばさのあるバグと区別可能
・問題じゃないように聞こえるし「UX向上の作り込みやります!」と言うとやるやらないでもめたりはしない(優先度では少し揉めるが)
ということで名前重要