優れたチーム、ダメなチーム

優れたチームには、使命感と言えるほどの情熱を持って追求したくなる圧倒的な魅力あるビジョンがある。
ダメなチームは報酬しか考えない。

出典:ユーザーストーリーマッピング – Jeff Patton序文より

チームというよりも、部門とか会社とかレベルの問題なんだろうけど、グサっと来ました。
大小問わずチームを率いる時は、やはりメンバーが魅力を感じらえる苦しくても頑張れるビジョンが必要だと思う。
その他にも16の優れたチームの定義が。この序文に触れられるだけでも、手にとって良かった。

  • 優れたチームは、リアルな問題を解決するためにスコアカードKPI(重要業績評価指標)、顧客の苦闘の状況、顧客が製品を使ったときに生成されるデータをよく見て、絶えず新技術を応用するチャンスを探しながら、ヒントやアイデアをつかんでいる。
    ダメなチームは、営業や顧客から要件を集めてくる。
  • 優れたチームは、もっとも大切なステークホルダーが誰か、そのステークホルダーがどのような制約を抱えているかを理解し、ユーザーと顧客のために役立つだけでなく、ビジネスの制約の枠内で作れるソリューションを作り出すことに力を注いでいる。
    ダメなチームは、ステークホルダーから要件を集めてくる。
  • 優れたチームは、そのアイデアが本当に構築に値するのかを見極めるために、アイデアをすぐに試せるテクニックに習熟している。
    ダメなチームは、優先順位を指定したロードマップを作るために会議を開く。
  • 優れたチームは、社内各部署の優秀なリーダーを集めたブレーンストーミングを積極的に行う。
    ダメなチームは、チームの外の誰かが提案をしてくれても、反発する。
  • 優れたチームは、製品担当、デザイン担当、技術担当が隣同士に座り、機能、ユーザエクスペリエンス、実現するためのテクノロジーにおける助け合いを推進している。
    ダメなチームは、それぞれの部門の席に座り、部門の外からのサービスの依頼には、文書による依頼や会議の日程調整を要求する。
  • 優れたチームは、イノベーションのためにいつでも新しいアイデアを試そうとするが、収益とブランドはきっちり守る。
    ダメなチームはテストの実行許可を待ち続ける。
  • 優れたチームは、力のあるインタラクションデザインなど、勝てる商品を作るために必要なスキルセットの確保にこだわる。
    ダメなチームは、インタラクションデザインがどのような仕事かさえ知らない。
  • 優れたチームは、エンジニアが参りにディスカバリープロトタイプを試す時間を持っている、製品をよくするための意見も言える。
    ダメなチームは、急ぎの案件のときだけ、見積書を作るためにエンジニアにプロトタイプを見せる。
  • 優れたチームは、顧客をよりよく理解し、最新のアイデアに対する顧客の反応を見るために毎週、顧客と直接議論をする。
    ダメなチームは、自分がお客さんだと思っている。
  • 優れたチームは、自分たちが気に入ったアイデアの多くが顧客の役には立たないことを知っており、役に立つかもしれないものでも、望ましい成果を挙げるまでには、数回のイテレーションが必要であることを知っている。
    ダメなチームは、ロードマップに載ったものを作り、納期と要件を満たしていれば満足してしまう。
  • 優れたチームは、スピードの重要性を知っていて、イノベーションで鍵を握るのがイテレーションの早さであることを理解している。ここで言うスピードは、適切なテクニックによって得られるもので、時間労働のようなものではないこともわかっている。
    ダメなチームは、同僚が働いてくれないからペースが上がらないと不満を言う。
  • 優れたチームは、顧客からの要求をよく吟味し、顧客と自社の業績に貢献できそうなソリューションだと確信したら、その実現のために力を注ぐ。
    ダメなチームは、営業に振り回される会社だと文句を言う。
  • 優れたチー宇は、コンスタントに小規模なリリースを重ねた方が顧客に安定したソリューションを提供できることを知っている。そのため継続的にインテグレーション、リリースを行う。
    ダメなチームは、苦痛に満ちたインテグレーションフェーズの最後にマニュアルでテストを行い、それからすべてをまとめてリリースする。
  • 優れたチームは、重要な顧客のことで悩む。
    ダメなチームは、競合他社のことで悩む。
  • 優れたチームは、ビジネスKPIに大きなインパクトを与えられたときに祝杯をあげる。
    ダメなチームは、何かをリリースできたときに祝杯をあげる。

出典:ユーザーストーリーマッピング – Jeff Patton序文より