製品チームの原則と属性—リファレンスガイド

May 09 2022
製品エンジニアリングチーム、または製品チームについては、今では頻繁に呼ばれているため、多くのことが書かれています。Spotifyがどのように彼らをハミングさせたのかについてさらに多くのことが書かれ、その後すぐに、彼らが成長し、適応し、そして進んだので、なぜ私たちがそれらをエミュレートしようとすべきではないのかを世界に伝えました。
注:分隊がこれほどシャープな服装をしていることはめったにありません。

製品エンジニアリングチーム、または製品チームについては、今では頻繁に呼ばれているため、多くのことが書かれています。Spotifyがどのように彼らをハミングさせたのかについてさらに多くのことが書かれ、その後すぐに、彼らが成長し、適応し、そして進んだので、なぜ私たちがそれらをエミュレートしようとすべきではないのかを世界に伝えました。なぜこれが非常に重要なのか、そしてなぜこれほど多くの人々が技術的な製品開発でどのように機能するのかを説明しようとしたのでしょうか。ええと、製品のユーザー、ひいては彼らが運営するビジネスの価値を実際に高めるには、特定のタイプのチームが必要だからです。

ただし、ここでリファレンスガイドとして概説したいのは、コアの原則と属性です。以下のリストは、BBC、ITV、Photoboxなどのさまざまな組織のさまざまな高性能デジタルチームと協力した私の経験をまとめたものです。

すべてのものと同様に、これは過度に規範的または福音主義的であることを意図していません。チームが運営するユーザー/顧客ベース、組織、および業界のコンテキストに、あらゆる運用モデル(または組織設計)を適合させることが非常に重要です。有用なものを取り、改善できるものを適応させ、それをあなたのものにします。最も重要なことは、それを試してみて、始めたばかりの場合は物事がでこぼこになることを期待してください。

コア原則

私の経験では、成功するには、製品チームは次のようになります。

  • 長期的—長期的とは、安定しているか、終了日が定義されていない状態で継続していることを意味します。分隊は通常、戦略に重要なビジネスレベルのピボットがある場合にのみ終了します。彼らはプロジェクトチームではありません(チーム対プロジェクトに関する私の記事を参照)。彼らは、提供する製品またはサービスの領域が継続的な投資を正当化することを認めています。分隊は、OKR、KPI、またはUSPの運転活動を中心に設立されます。その費用の関係もあり、分隊を設立することは気楽な決断ではありません。分隊は、成果物や機能のロードマップを設定するのではなく、長期的なミッションを統合し、真の価値を推進することに取り組んでいます
  • ビジネス目標に合わせて—チームは、目標と伝達されたビジネスの優先順位の間に直接線を引くことができなければなりません。これは、1つ以上の重要な結果を伴う目的の形をとることができます—私はOKRを支持する傾向がありますが、OKRは、焦点を作成したり目標を設定したりするための利用可能なフレームワークの1つにすぎません。
  • ビジョン、ミッション、戦略、および目標の設定—すべてのチームは、製品または製品領域のビジョンを持っている必要があります。これを、長期的な大きな賭けと最適化の概要を示す単純なミッションと明確な戦略と組み合わせます。四半期ごとの目標は集中力を維持するための優れた方法ですが、ここで、そして今では長期的な成功のために絶えず最適化するという罠に陥りがちです。2〜3年は、消費者向け戦略の場合は3〜5年、プラットフォームプレイの場合は3〜5年です。「ミッションはあなたを軌道に乗せ続けます。OKRは、焦点とマイルストーンを提供します。」(RadicalFocusのChristinaWodtke :目的と主要な結果で最も重要な目標を達成する)
  • 目標の結果を定期的に再評価する—分隊は、成果ではなく、定期的にレビューされる指標主導の結果(たとえば、22年度第1四半期にトライアルメンバーへのコンバージョンを2%増やすことで収益の減少を食い止めるため)に焦点を当てます(つまり、登録を再構築します)。形)。私は四半期ごとの分隊レベルのOKRを提唱する傾向があり、他の標準的なビジネスプロセスに合わせて調整しますが、私は長い間、うまくいくと思われる3年ごとのリズムで実験したいと思っていました(年次または半年ごとは確かに十分な頻度ではありませんが、しかし、多くの場合、四半期ごとに、利害関係者との最後のセットについて合意したばかりの新しいOKRを準備し始めているように感じることがあります)。
  • 仮説、実験、データ主導—分隊はデータを利用して、実用主義や経験豊富な直感を犠牲にすることなく、仮説、実験、意思決定を推進します。分隊は常に虚栄心の測定基準を避け、目的を達成することに対して実際に何かを意味することに焦点を当てる必要があります。全体として、分隊は、導入しようとしている機能の大部分について、データ中心の実験を設定することにバイアスをかける必要があります。「どの機能が機能するかどうかについて誰かが最もよく推測できる古いスタイルのロードマップをチームに提供するのではなく、製品チームに優先順位を付けたKPIのセットを提供することを強く望んでいます。その後、チームは何について電話をかけますか。これらの目標を達成するための最良の方法です。」(Marty Cagan、SVPG、The Role of Analytics)
  • 自律的で自分たちの決定を所有する—分隊は自律的であり、自分たち自身の決定を所有し、最終的に彼らが行う作業に責任を負います。これは無政府状態のライセンスではありません。遵守する必要のあるガイドライン/原則/法律はまだたくさんあります—プライバシー、ブランディング、インシデント管理、InfoSecなど。このモデルを通じて成功の可能性を高めるために、分隊は最初に「方法」について高い整合性を模索する必要があります。自律性は「何」にもっと焦点を合わせました。すべてのシナリオで、分隊は彼ら自身の成功と失敗に責任があります。
  • 自給自足—分隊は、作業を整理して提供する方法を自給自足します。依存関係を最小限に抑えるために、チームは部門を超えた分野を超えたチームとして構築され、目標を達成するために必要なスキルを実際に実行可能な限り多く含みます*。ベストプラクティスアプローチの観点からチームにガイダンスを提供できる重要な使用人リーダーの役割がいくつかありますが、これらの役割自体はチームの外にあります。さらに、最も重要な場所での調整とコンプライアンスを推進するのに役立つ特定の合意された標準(つまり、コーディング、プライバシー、ユーザーエクスペリエンス、ブランドなど)があります。もちろん、他にも重要な役割と利害関係者が常に存在しますが、これらはガイダンスとサポートを提供するためにあります。分隊は独自の決定を所有しています。
    *依存関係があることが理にかなっているタスクがいくつかあります。つまり、ラップトップの提供は、中央機能によって最適に提供される可能性が高い自然な依存関係になります。
  • 製品のライフサイクルとコンポーネントの所有者—各製品、機能、またはコンポーネントは、長期的な管理を確保し、必要に応じてコンポーネントを廃止して、クリーンなユーザーエクスペリエンスと効率的に保守可能なテクノロジー資産を確保するために、ライフサイクル全体を通じてSquadが所有します。ただし、分隊は、依存関係を回避し、配信のペースを維持するために、他の分隊のコンポーネントに変更と貢献を行うことも推奨されます。自分の目的を犠牲にして、ある分隊に別の分隊を支援するように依頼することは、モデル全体に​​とって有害で​​す。これらのタイプの相互依存性は、大規模な配信を窒息させます。理想的には、テクノロジー資産全体を分割して、いずれかの分隊が所有する必要があります。カバーされていないものは、公の場で崩壊し始めるか、疑いを持たない分隊に事件が強制されると「BAU」の負担になります。バランスの取れた製品チームのバックログの構築
  • プロセスの所有者—分隊は自分のプロセスを所有し、継続的に改善しますが、より広いビジネスが関与するための一貫したメカニズムを提供するために、一部のプロセスと慣行を分隊全体で義務付ける必要があります(つまり、特定のアジャイル手法は義務付けられていない可能性がありますが、隔週で開いているチェックインが必要です)。私の経験では、分隊を設立した最初の年に、「方法」、つまり採用するアジャイル手法は、分隊のジャンプスタートとベストプラクティスの確立を支援するための意図的に制限された一連のオプションからの選択になります。仕事への取り組み方に真の革新と創造性をもたらすために、これは時間の経過とともに緩和されることが期待されています。
  • エンゲージメントの明確なメカニズムを提供する—チームは、定期的な(隔週の)オープン招待チェックイン、四半期ごとのレビュー、毎月のチーム間のショーケース、定期的な技術/アーキテクチャのレビューなど、一連の明確なエンゲージメントのメカニズムを備えている必要があります。これらは、スタンドアップ、ストーリーライティングセッション、バックログ準備セッション、回顧展、デモなどの典型的な分隊式に追加されます。
  • クリティカルマスを持つ—チームは、開始して正常に形成するために必要なすべてのコアロールを持っている必要があります(属性を参照)。

実施されている場合、特に分隊の成功をサポートするいくつかの重要な組織原則があります。

  • 組織のビジョン、戦略、目的—すべての企業がその理由を中心とした組織レベルのビジョンを持っていることが不可欠です(サイモン・シネックによるTEDトーク「偉大なリーダーが行動を起こす方法(Start withWhy)」を参照)。これはブランドの物語などと呼ばれることもありますが、他のすべての活動を導くのはノーススターです。これと密接に関連しているのは、戦略、またはビジョンに到達するために何が行われるかについてのアイデア、そしてそれに向かって進むための測定可能な方法です。前述のように、私は一般に次のように知られている目標と主要な結果を提唱します。 OKR。これらはすべて、定義が明確であり、組織内のすべての人に透過的に伝達される必要があります。
  • 個人の目標—分隊の個人の目標は、分隊の目標を反映している必要があります。これは、対立する方向性や、分隊の仕事に集中することから個人の時間を奪うことを避けるためです。部門または機能主導の目標は、ビジネス目標ではなく、個人の開発目標の焦点であり続ける必要があります(もちろん、継続的な学習と開発を奨励およびサポートすることが重要です)。補足:意識的または無意識的なサンドバッグを避けるために、報酬ボーナスを分隊OKRに結び付けてはなりません。
  • ライン管理—規律、または機能に沿ったライン管理は、日常の分隊管理とは別のものであり、分隊メンバーの大多数が分隊外の誰かによってライン管理されるのが普通です。これにより、競合する優先順位が導入されることはなく(個々の目標の上記のセクションを参照)、代わりに、すべての従業員をサポートする、構造化されたスケーラブルで人主導の回線管理ネットワークが提供されます。ラインマネージャーは通常、組織が水平方向に拡張できるように3〜6の直属の部下を配置し、人員管理の要件が高い大規模なチームを削減する必要があります。この規則の例外ソフトウェア工学であること。チームの技術リーダーによってライン管理されているソフトウェアエンジニアには賛否両論がありますが、これは主に状況と組織設計に固有のものになります。組織設計の詳細については、Matthew Skelton&ManuelPaisによる「TeamTopologies:Organizing Business and Technology TeamsforFastFlow 」を読むことをお勧めします。

私の経験では、分隊には明確な属性のセットがあり、通常は成功するように設定するのに役立ちます。私の意見では、分隊は次のようになります。

  • 8±2の最適なサイズ—典型的な分隊は8人プラスマイナス2であり、12人を超えてはなりません。これは、効率的な建設的な議論とタイムリーな意思決定のための環境を作ることです。アマゾンの創設者ジェフ・ベゾスが説明したように、これは古典的な2つのニューヨークのピザサイズのチームです。
  • 献身的—分隊のメンバーは献身的であり、彼らの分隊に長期的にコミットし、他の分隊やチームと共有されません。これはとても重要です。個人は、依存関係、ボトルネック、および回避可能な遅延を最小限に抑えるために、チームに完全に参加するか、完全に参加しないかのいずれかです。これは、個人が分隊を動かすことができないということではありません。自然な進歩、好奇心、消耗により、分隊のメンバーは時間の経過とともに進化し、移動しますが、彼らは自分のリズムと働き方を見つけるために、長期的な専任チームと見なす必要があります。定期的な切り刻みや変更は可能な限り避ける必要があります。 。製品と技術以外の役割では、分隊に参加する前に期待と責任を確実に理解するために慎重な会話が必要になります(特に、このように機能する場合もありますが、出向やパートタイムの役割とは考えるべきではありません。それらが組織内で確立された初期の頃)。
  • 分野横断的—分隊は単なる技術提供チームではなく、実際には製品と技術の従業員だけで構成されています(ただし、大部分はこれら2つの機能で構成されています)。分隊は、スキルの最も効果的な組み合わせをもたらし、外部への依存を最小限に抑えるために、真に部門の枠を超え、分野を超えたものでなければなりません。彼らは、より幅広いビジネスドメインの専門家を構成に含めることができます/含める必要があります。これは多くの組織で見られる慣習ではありませんが、大きな違いを生み、部門の連携をさらに加速するのに役立ちます。
  • 従業員トリオ主導—ほとんどの場合、分隊は、情熱的で権限を与えられた規律リーダーのグループによって内部的に主導されるべきです。これらは、チーム内の準公式*リーダーであり、プロダクトマネージャー、エンジニアリングリード、およびプロダクトデザイナーです。しかし、日常的に、分隊のすべてのメンバーは一般的に平等であると見なされています。
    *多くの場合、プロダクトマネージャーは一般的にチームリーダーと見なされます。いくつかの点でこれは理にかなっていますが、より熱心な実装では、これにより、目的の操作モードに不健全な単一の意思決定ポイントが作成される可能性があります。一般的に、少なくともエンジニアリングリード、そして多くの場合は製品デザインリードも、リーダーシップの役割を担うようにステップアップすることが推奨されます。ただし、これを強調しすぎるのは必ずしも良いことではありません。リーダーシップがない場合でも(つまり、病気、年次休暇、ライン管理の責任などのために)、分隊は日常業務を行い、意思決定を行うことができるはずです。そのため、「半公式のリーダー」と呼ぶことで、意図的にあいまいさを残しています。
  • 従業員の人員配置—ほとんどの場合、分隊は内部全体に人員を配置する必要があります。恒久的な資源が船上で購入されている間、これは通常一時的なものですが、外部の手段を通じて分隊に部分的に資源を与えることが理にかなっている場合があります。真の所有権を持ち、組織の長期的な使命に完全に参加することは、分隊の成功にとって非常に重要です。主に契約または外部の個人で分隊を調達することは、常勤スタッフに有害なメッセージを送る可能性があり、短期的なニーズを解決することはできますが、長期的に持続可能または成功する方法を確立することはめったにありません。
  • チームメンバーを明確にする—これは明白に聞こえるかもしれません。分隊に座っている個人がいて、次に分隊の外に座っているがそれに隣接している個人がいます。この例としては、ユーザーエクスペリエンス、エンゲージメント、メンバーの定着率の向上に焦点を当てた「コンテンツエクスペリエンス」チームがあります。このチームは、エクスペリエンスを構成する記事、ビデオ、ポッドキャストの作成に焦点を当てた「コンテンツカテゴリチーム」と並んでいます。チームとチームは、相互に依存していると感じないようにしながら、コミュニケーションのための継続的なメカニズム*と緊密に連携する必要があります。
    *これは、各チームの個人が管理する必要があります。ほとんどの場合、1:1の共有スラックチャネルを使用し、お互いのチェックインに参加します。
  • コロケーション— Covid-19のひどい影響に銀色の裏打ちがあるとすれば、それはリモートワークとオンラインコラボレーションの加速です。これは継続的かつ急速に進化する一連のプラクティスであり、あらゆる種類のチームが機能し続けることを可能にし、やがて、より効果的な分散型チームとまったく新しい運用方法への道を開く可能性があります(つまり、リモートですが、週に1日オン- 「ワークショップ水曜日」のサイト)。しかし、パンデミックがもたらした変化にもかかわらず、可能な限り、分隊は大部分の時間、物理的に同じ場所に配置されるべきであると私は信じています。誤解しないでください。分散型リモート分隊は、十分に確立されたリモート作業テクノロジーとポリシーを備えた高度に成熟した組織で作業できます。パンデミックとリモートワークの出現にもかかわらず、
  • 目的に合ったコラボレーションスペースでの運用—上記に基づいて、分隊は運用できる固定された信頼性の高い目的に適合した環境を必要とします(つまり、タスクボード用の壁スペースを備えた固定デスク、設計ディスカッション用のホワイトボード、分析用のモニターパイプライン、リモートコラボレーション用のオンラインツールを構築します)。これは、パンデミック後の環境では贅沢な気分になり、組織内の他のチームやチームとロータベースで共有できるように、これらのコラボレーションゾーンを作成する方法があります。

© Copyright 2021 - 2022 | hachiwiki.com | All Rights Reserved