ショットジレンマの呼び出し
これは、自社のUXプラクティスに関する懸念を表明する製品マネージャー（PM）へのインタビューからの引用です。
常に失敗したことの1つは、最終的な発言権を持つ人、実行する方法と方法を実際に決定できる人を定義しなかったことです。
製品所有者（PO）も同様に、UXプラクティスに関する懸念を次のように表明しました。
チームと協力するのは製品の所有者であり、実際には、システムがどのように機能するかをある程度設計します。 POは顧客、または顧客（つまり購入者）の代理人です。それらは、物事がどのように見えるべきかについて決定力を持っているものです... UXプラクティスがスコープに影響を与える場合、間違いなく決定するのはPOです。
ただし、ほとんどの場合、これらの製品所有者または製品マネージャーは必ずしもUXに関する十分な知識を持っているわけではなく、UXは彼らの主な関心事ではありません。多くの場合、これらの役割が優先するのは、予定どおりの予算内での配信と、「顧客」（つまり購入者）の満足度の保証です。これは、市場主導型でないソフトウェアの場合、エンドユーザーの見方を大幅に無視することになります。これは、1人のPOが次のように言って証明されています。
本当に悪い振る舞いをするテーブルコンポーネントがあり、私たちは皆それに同意しますが、それを変更する必要がある場合、それは莫大な量の作業になることを知っています...それはまだニースではありませんが、あなたはそれで働くことができます。それが今あるべき姿です。
私の質問は、アジャイル設定で作業するUXエキスパートの皆さんに向けられています。知りたい：
- 関与しているアジャイルプロジェクトで、製品の所有者や（該当する場合は）製品のマネージャーとどのように協力しますか？どのツールと方法を使用していますか？
ソフトウェアのUXに影響を与える決定に関して、誰がショットを呼び出すのですか？たとえば、ルックアンドフィール、フロー、実装する機能、各スプリントで優先順位を付ける機能など。 （UXに影響を与える決定のその他の例を自由に追加してください。また、優先順位付けに特定のツールを使用している場合は、それらについてお聞きしたいと思います）
「コラボレーション」が鍵だと知っています！しかし、ここでは、より「具体的」で「実践的」な答えを探しています。そのため、「共同作業」などの抽象的な概念ではなく、ツールと方法、対策、証拠などについて書いていただければ幸いです。 （上記の引用のような）あなたの経験についての「特定の物語」とあなたがそれらにどう対処したかを共有することも非常に役に立ちます。
これは素晴らしい質問です。大企業（Googleでの合意により固定化されたチームなど）や中小企業（スタートアップでの自発的な創設者の決定など）では、意思決定プロセスが失敗するのを見てきました。
残念ながら、ほとんどの企業向けトレーニングプログラムは、垂直スキルとリソースを備えたUXチームと開発チームを支援するように設計されていますが、効果的なチームワークを推進し、チームの効果的な意思決定を行う方法をカバーする企業プログラムはほとんどありません。
アジャイル/リーンフレームワークは、これにも直接対応していません。
以下は、適切な意思決定を促すのに役立つ補完的なアクションのスタックです。
1.意思決定のリーダーシップを確立する
コラボレーションはコンセンサスではありません！効果的なチームワークは、リーダーがいない、または拒否権を持つ人がいないことを意味しません。
- 優れたCEOは、経営陣のチームワークがビジネスリーダーシップにとって重要であることを理解しています（CEOが単独で実質的なビジネスを実行することはできません）。しかし、コンセンサスが難しい、遅い、またはコストがかかる状況では、最終的にショットを呼び出すことができることも理解しています。
- 同じことが製品チームにも当てはまります：チームワークを閉じてもリーダーがいないという意味ではありません。
- ショットコールの権限はあるが、製品に対する最終的な責任も負っている1人のチームリーダーがいるのが最善です（力には責任が伴います！）。
- 私は個人的には、プロダクトマネージャーが（最高の商業的連携を推進するために）製品チーム内の最終的な意思決定機関であり、チームの外でCEOまでさらにエスカレーションするファンです。しかし、多くの企業では、状況によっては他の役割が主導することが理にかなっている場合があります。
2.明確な専門家の役割を確立する
- 開発者は、グラフィックデザイナーよりもコード関連の問題を適切に判断する傾向があります。 UXプロフェッショナルは、製品マネージャーよりも、使いやすさを判断する傾向があります。したがって、優れたチームワークは、専門分野を認識し、意思決定に組み込む必要があります。
- SEALチームは小隊の構造をしており、全体として充電中のオフィス（OIC）を持っていますが、専門分野ではるかに多くの専門知識を持つスペシャリスト（スナイパー、ブリーチャー、コミュニケーターなど）もいます。意思決定は最終的にOICに依存しますが、適切な重みを持つ専門家からの専門知識を組み込む必要があります。
- たとえば、OICがブリーチミッションステージの計画中にブリーチャースペシャリストからのアドバイスを無視するのはばかげているでしょう。OICは、違反者の助言、または違反者に決定を完全に委任する場合があります。
3.データを使用する
データの早期、一貫性、および習慣的な使用は、チームが適切な情報に基づいた決定を行うのに役立ちます。また、決定は年功序列、好意、リーダーシップの気まぐれに基づいて行われるのではなく、利用可能なハードまたは統計的事実に基づいて行われるため、客観性と実力主義の文化をチームワークに組み込むのにも役立ちます。
データを使用することは、チームとしての意思決定の一環として、データを収集、分析、および提示する慣行を確立することも意味します。
データを使用することは、必要に応じて、チーム外の適切な関係者または情報リソース（顧客、CEO、コンサルタント、学者などの声）を利用することも意味します。
4.チームワークのための明確で一貫した文化と原則を確立する
データに基づく分析、明確な専門分野、意思決定の権限、協調的な合理的な議論/弁証法などの明確な原則により、役割と意思決定プロセスが明確になります。
一貫性のある原則主導の文化は、チームワークに安定した信頼できる環境を提供するのに役立ち、実行と意思決定の両方における摩擦を減らします。
チームワークの原則は、チーム以外の組織にも認識されることが重要です。たとえば、チームにリーダーがいる場合、そのリーダーは組織の他のメンバーからショットコールを実際に受ける権限を持っている必要があります。そうしないと、チームにリーダーが権限を与えられていないことがわかると、チームワークが崩壊する可能性があります。
これは非常に広範な質問であり、この長い答えは氷山の一角にすぎません。
分割統治
常に失敗したことの1つは、最終的な発言権を持つ人、実行する方法と方法を実際に決定できる人を定義しなかったことです。
これに対する機敏な答えは、誰もが一緒に決めることです。しかし、これは以下の理由で無惨に失敗することがよくあります。
みんなとすべてが多すぎます。言い換えれば、決定プロセスには、非常に多様な利害関係や願望を持つ非常に多くの人々が関与し、非常に多様な性質の多くのものが決定を下すことができません。
たとえば、チームリーダーミーティングに参加し、次の2つのいずれかを選択する必要があります。6か月間多くのユーザーから要求されたUXの改善と、CEOが追加できるために開発したい新機能収益。どちらが優先されますか？まあ、これはリンゴをバナナと比較するようなものです。前者はcustomer-centric、後者はgrowthです。
これは、クロス優先順位付けと呼ばれることがある問題です-明らかに関連性の低い2つのものの間の優先順位を決定しようとした場合。
さて、次の質問を考えてみてください：国が病院に余分な1500ベッドを持っているか、軍がさらに2台のドローン？首相に尋ねれば彼は言うだろう-私はそのような比較をする私の時間を無駄にしないで、私達は健康および防衛予算を定義し、それが適切であると思うように各部門が行います。
最後の例で解決策が明らかになると思います-divide-and-conquerアプローチを採用することで、決定が容易になり、上級管理者は主にケーキをスライスする。
これが実際の実例です：
- 悪い-特定の組織構造で、私はかつて製品管理会議に座っていて、対処するためにUXの問題と戦わなければなりませんでしたが、ほとんどやるべきことは他にもあると考えていた他の多くの力のために、何も行われました。
- 良い-次に、UXをそれ自体がアジャイルプロジェクトにするようにシステムを変更しました-私はデザイナーとして、そして他の2人の開発者として。この小さなチームは（POと一緒に、いつ作成できるか）、何が最も重要かについて一緒に決定を下していました。結果？ UXはより速く改善され、ユーザーは満足し、CEOでさえも肯定的なフィードバックが寄せられたことに満足しました。
また、POはUXの問題についてのみ私たちを案内する必要があったので、UX、新機能、バグ修正などの間で引き裂かれたわけではありませんでした。
ローンサメとしてのアジャイル
多くの場合、これらの役割が優先するのは、予定どおりの予算内での配信です。
アジャイルは優れた方法ですが、現実には、多くの（ほとんどではないにしても）組織が、自分が気に入っている部分だけをフォローし、そうでない部分をブラッシュオフしているだけです。個人的な経験と研究の両方がこれを実証しています。実際、私は個人的に、Wordによってアジャイルを追跡し、その可能性を最大化する1つのチームだけに遭遇しました GoogleのAngular team です。
残りは、あまりにも頻繁に「今すぐ購入」という方法でそれを利用します-市場投入までの時間のためだけに、研究、設計（UXおよびソフトウェア）、テスト、QA、コード品質の妥協。
幸いにも、私はこの体系的な失敗の認識が高まっていると思います。あまりに多くのスタートアップが、バグを追いかけて、競争力のない開発期間で4年後を迎えています。言葉はボトムアップで広がります。
製品の所有者はあなたに良いです
チームと協力するのは製品の所有者であり、実際には、システムがどのように機能するかをある程度設計します。 POは顧客、または顧客（つまり購入者）の代理人です。それらは、物事がどのように見えるべきかについて決定力を持っているものです... UXプラクティスがスコープに影響を与える場合、間違いなく決定するのはPOです。
次に何をすべきかに関しては、私は完全に同意します。私のPOでの経験は常に前向きなものでした-結局のところ、彼らは実際のユーザーにとって最高のことを知っており、望んでいます。実際、ドメインについての豊富な知識を持つこの実際のユーザーと、私たちが仮定するのではなく、価値がどこにあるかを案内してくれる他のユーザーがいたので、私の人生ははるかに楽になりました。
敗北主義者の態度と遅延のコスト
本当に悪い振る舞いをするテーブルコンポーネントがあり、私たちは皆それに同意しますが、それを変更する必要がある場合、それは莫大な量の作業になることを知っています...それはまだニースではありませんが、あなたはそれで働くことができます。それが今あるべき姿です。
まあ、これは正当な議論かもしれません。付加価値と比較して開発コストが高い場合は、POがより良い比率で別のタスクを選択しても問題ありません。
しかし、私はこの声明が技術的な負債が背後にあるかのように臭いがするのではないかと思います。その場合、これは医師に来て、さまざまな奇妙な症状について不平を言っているようなものです。 1日40本のタバコを吸います。コレステロールが高く、糖分が高く、食事とライフスタイルを変える必要があります。」そして、あなたは「いや...努力しすぎ」と行きます。
ここで頭に浮かぶかもしれないもう1つの概念は、遅延のコストReinertsen によって徹底的に議論されているように（本、あなたは望むかもしれません）聖書と解釈されるべきではないが）簡単に言えば、多くは、開発コストと合理的な顧客価値に基づいて決定を下します。しかし、最初に、顧客は合理的ではありません（特に、感情を定量化することが難しいUXの場合）。さらに重要なことは、開発コストと比較する必要があるのは、製品のライフタイム中に失うものについてです。では、今後5年間で修正しない場合でも、貧弱なテーブルコンポーネントを使用するコストは、それを改善するための開発コストよりも低くなりますか？
スカンクワークス
企業は、内部プロセスや古い習慣を変えるのが本当に難しいと感じています。
1つの解決策は、役割またはチームを導入することです。チームの唯一の責任は、品質を確保し、物事を改善することです。定義により、そのようなエンティティは自律的であり、時間/予算の制約を完全に認識しません。この方法は、一部の企業にとって非常に有益であることが証明されています。
ここでの重要な概念はautonomyです。このような概念は少し極端に見えるかもしれませんが（特に小規模ビジネスでは）、そのバリエーションは自律的なエンティティを持つのではなく、個人またはチームがある程度の自律性を獲得します。 Wordによると、Googleは従業員が自分の好きなことに10％の時間を費やすことを許可しているので、仕事はどういうわけか製品に関連しています。ある程度の自律性を獲得するworkcellsの概念もかなり一般的です。
したがって、あなたの質問に関連して-時々、自律的にショットを呼び出す権利を与えられた個人または小さなチームは非常に有益です。
@tohsterと@Izhakiから2つの非常に優れた回答があります。
私も同様の状況で、ソフトウェアを購入したユーザーがプライマリユーザーではないSaSS製品を使用してSCRUMに乗り込んでいます。だから私は私が見つけたものに私の経験を加えたいと思っています。
UXをドルに関連付ける
SaSS（Software as a Service）フィールドでは、顧客のチャーンが話題になっています。今年の講演の1つである パルス会議 は、顧客のチャーンの最大の原因が製品の使いやすさであることを示唆しています。また、製品が不足している場合に、サポートチームまたは保持チームが顧客を維持するためにできることはありません。これは、UXのより多くのリソースにアクセスするために活用できるものです。顧客の離脱により失われる収益の額。チャーンをわずか1％削減すると、どれだけのお金を回収できますか？顧客がサブスクリプションを毎年更新すると、将来どのくらいの収益が得られますか？
これは「悪い」ですが、「悪い」はどのくらい悪いのですか？
UXのトピックでは、管理とPOは、実際のユーザーと直接やり取りしていないため、何かがいかに悪いかまったくわかりません。彼らは言うことができます、ええそれは理想的ではありませんが、実際にはそうではないときでもそれはまだ使えます。ユーザーがアプリのその部分で1日の大半を費やすときではなく、フローを1回ではなく、1日に30回以上繰り返します。
ですから、この見方を彼らに持って来てください。彼らがユーザビリティセッションに参加できれば、それは素晴らしいことです。または、そうでない場合は、セッションからの録音を表示できます。突然、それはもはや抽象的な問題ではなくなりました。影響を受ける人々です。ユーザーのシャドーイングを行い、ユーザビリティセッションに参加した後、チームのPOがUXの懸念にはるかに敏感になったことがわかりました。
Product＆Tech Debtはゆっくりと製品を殺します
このPOは、Marty Caganの本 " Inspired：How to create products love your Customers "に紹介され、その後、このトピックに関するワークショップに参加しました。 Caganは、技術的および製品/ UXの借金に時間を割り当てるための巨大な支持者です。彼は当時Netscapeのプロダクトマネージャーであり、Netscapeブラウザーの死を直接Tech Debtに帰しました。新しい機能を次々と積み重ねていくと、コードとワークフローが不安定になり、文字通り新しい機能を追加できないか、システムが複雑すぎてユーザーが機能を見つけられなくなるほど、それに沿って使用します。
したがって、POはこれを理解し、当社のチームは5分の1のスプリントをTech＆UX Debtに捧げます。私は、POが短期的および長期的な利益のジャグリングに関連する退役軍人の話を聞くのに非常に役立つと思います。 UXやDevに重点を置いているように見えるUXやDevから来るものとは対照的に、彼らの分野の人々からそれを聞くと、概念はずっとよく伝わります。
部門間チーム内の交渉
スクラムでは、POは単一の絞り可能なネックとして機能します。そしてそう、そうです、技術的には、POは製品のバックログに入るものとアイテムの優先順位についての最終決定権を持つものです。
ただし、バックログに何を入れるかを決定するためには、多くの交渉が必要です。私たちのチームのグルーミングセッションでは、UXはPO、Dev Lead、QAと一緒に座り、今後の作業の可能性について話し合います。要件とUIを確認し、大まかな説明を行います。 UXアイテムを確認してレビューすることもありますが、開発リーダーは技術アイテムについても同じことを行います。
多くの場合、これらのセッションには時間を割いて、UXを改善するためのさまざまなオプションを考案するためにもう少し努力を費やします。このようにして、「すべてかなしか」ではなく、「時間とリソースの制約を考慮して、最良のオプションを選択するために一緒に取り組みましょう」になります。これは、人々が一見中途半端なものを選ぶ可能性が高い心理的なトリックですが、あなたは好意で物事を歪めるオプションを設定しました。
これは製品キラーですか？
これは、今年のLean UX NYCカンファレンスの講演者によって提起されました。最初に何を修正すべきかをどうやって知っていますか？このユーザビリティの問題が何人の人に影響を与えているか、これらのユーザーにどのような影響があるか、何もしないとどうなるかを尋ねます。改善をサポートするためにいくつかの統計を考え出す良い方法のようです。また、完全なコンテキストがあると、調査を行ったPOが表示され、バックログに記録される他のすべてのものに対して優先順位を付けるのに役立ちます。
関与しているアジャイルプロジェクトで、製品の所有者や（該当する場合は）製品のマネージャーとどのように協力しますか？どのツールと方法を使用していますか？
私が使用したツールと方法は、次のもので構成されています。
- 話している
- スケッチ
- 建物
- 示す
言い換えれば、彼らはアジャイルチームの一部です。そのため、アジャイルチームの全員と同様に、彼らはプロセス全体の一部にすぎず、乗ってくれます。
ソフトウェアのUXに影響を与える決定に関して、誰がショットを呼び出すのですか？
全員。それがアジャイルの精神です。それは単一のエンティティによって「所有」されていません。単一の「サインオフ」プロセスはありません。チームは一緒に働きます。そして、おそらく間違ったことがドアから出ます。それもプロセスの一部です。何が問題かを学び、次のスプリントで修正します。
アジャイルでは（そしてアジャイルの外でも、特にアジャイルでは）、UXチームはショットを呼び出すものではありません。それらは設計を容易にするものです。もちろん、彼らは設計に貢献しますが、彼らの仕事は主に誰もが設計プロセスに貢献できるようにすることです。
組織が「最後の発言権を持つ人」と格闘している場合、それはまだアジャイルと格闘している組織です。彼らは、ウォーターフォールの古い「カバーイヤーアス」モデルを保持しています。サインオフは一般的にアジャイルのボトルネックです。
組織でのサインオフの必要性が高い場合、それは通常、製品自体よりも企業の政治を優先する兆候です。これは確かに珍しいことではありません。しかし、確かにイライラします。