昨年、Emilie Schario と Taylor Murphy は、 「データ チームを製品チームのように運営する」という素晴らしいアイデアを提案しました。この記事の主な前提は次のとおりです。製品チームには、データ チームが採用することで恩恵を受ける優れたプラクティスがたくさんあります。しかし、途中のどこかでこの点を見失い、喜んでストローマンに置き換えました。データ資産の運用グレードのシステムを維持し、より多くのデータ製品を構築し、 データ コントラクトを強化するサービスにおける運用の意味を入念に定義しました。これらはすべて検討に値するものですが、実際に影響を与えるデータ チームよりも、データとデータ資産の適切な処理に関心があります。

ここでの中心的な考え方は、「データ プロダクト」の定義と境界について口論したり、データ プロデューサーに SLA を設定したりすることではなく、プロダクト チームをモデルとして使用して、データ チームがどのように機能するかを再考するよう強制することでした。

データ チームを製品チームのように運営する方法について、時間をかけて詳しく説明したいと思います。

核となる 2 つのアイデア: ユーザー中心と積極性

製品チームが具現化する 2 つのコア原則があります。それは、ユーザー中心性と積極性です。それぞれについて順番に説明しましょう。

ユーザー中心

最高の製品チームはユーザー中心です。彼らは定期的に顧客と話し、ユーザーからの直接的なフィードバックをロードマップに直接反映させます。このフライホイールは、優れた製品の生命線です。機能を出荷するだけでなく、問題を解決することを保証します。

データ チームも同じように運用する必要があります。私たちは、私たちの仕事が技術的にいかに興味深いものであるかに夢中になりすぎており、私たちが科学的/工学的追求のための独立した避難所ではないことを忘れていました.私たちはビジネス価値を提供するために雇われたビジネスユニットです.そして、製品チームと同様に、データを使用してビジネス上の問題を解決しない場合、比喩的な「データ製品」(私たちが行うすべてのデータ作業) は機能しません。

これは、その場しのぎの要求に事後対応するという意味ではありません。これは、科学的な試みを完全に避けるという意味でもありません。それは単に、ビジネスが必要とするものに注意を払い、その目的のために機会を追求することを意味します。 Taylor と Emilie は、同僚は顧客であると示唆していますが、これだけでは不十分だと思います。ビジネスは顧客です。あなたはそれを知り、理解し、それを中心に行うすべてのことを方向付ける必要があります。

積極性

第二に、最高の製品チームは、製品構築プロセスをサポートするための積極的なプロセスを設定しています。彼らは、ビジョンを設定し、ブレインストーミングを行い、顧客の要求に直接対応する範囲外にある情熱的なプロジェクトを追求するための意図的なスペースを自分自身に提供します。

一方、分析チームがこのように活動することはめったにありません。少なくとも、インバウンド リクエスト以外のデータの調査に時間を費やす必要があります。チーム レベルでは、意図的にロードマップを作成し、レバレッジの高い作業を行うことができるように、パターンに注意を払う必要があります。

とはいえ、リアクティブな作業は確かにその場所を占めています。アナリストはビジネスがデータを探索するための主要な手段であるため、多くの場合、私たちは必然的に支援的な役割を担っていることに気付くでしょう。しかし、鍵となるのは、この作業の背後にあるコンテキストを理解することを常に推し進め、このコンテキストが戦略的でレバレッジの高いプロジェクトの動機となるようにすることです。

しかし、どのように始めますか？

元の LO 記事には、これをすべて可能にするための組織レベルの優れた提案がいくつか含まれています。学際的なチームを集めてインスピレーションを引き出します。これに加えて、すぐに実行できる具体的なプロセスレベルの変更をいくつか示します。

1. 知識統合のプロセスを確立します。

チームの作業を 1 か所にまとめることは、ユーザー中心になるための前提条件です。ユーザー中心の作業を行うには、求められているすべての作業を把握する必要があります。共有スペースで作業を整理すると、チームの作業全体でパターン マッチングが可能になります。これは、製品チームがブレインストーミングの前に UX の調査結果を調査するのと同じことです。

コンプライアンス違反は大きな問題であるため、これが最大のハードルになります。人々は現状維持に努めており、文書化や知識共有のイニシアチブが失敗するのを私はよく見てきました。 Notion、Confluence、または Dropbox paper (および分析固有のソリューションであるハイパークエリ) などの wiki ワークスペースで作業を公開すると、この障壁を打ち破ることができます。

広く採用されるようにするための重要なコンポーネントは次のとおりです。

• 使用に対する摩擦を減らします。 git を使用してピア レビュー プロセスをセットアップするのは魅力的かもしれませんが、プロセスの層は厳密さを保証しません — それらは採用を減らします。簡単で軽いことを行い、チームが自分の仕事をツールに投入できるようにすることに集中してください。
• 組織の足場を設定します。ここでも、ハイパークエリ、概念、またはコンフルエンスなどのツールを wiki 構造で使用して、チームが集中化だけでなく組織に関するプラクティスを確立できるようにします。合理的で機能的なカテゴリに同意し、新しいアナリストを業務に参加させる中心的な「ここから開始」ドキュメントを作成します。

2. ビジネス ニーズを深く理解する。

私たちは単なる技術職ではありません。私たちは、データとその他のビジネスとの間の架け橋です。そして、データに没頭するだけでは (これはこの会話の 1 つの側面にすぎません)、本来あるべきほど効果的ではありません。

私たちは技術力に誇りを持っていますが、私たちが仕事をしている理由を知っている場合にのみ効果的です.鋭いビジネス感覚がなければ、データのプルに追いやられているストレージ Bに移動するまで、分析の後に無意味な分析を書き上げます。

実際に言えば、これはどのように見えるか：

• 常に理由を尋ねます。 SQL に飛び込む前に、ビジネス目標について利害関係者と足並みをそろえていることを確認してください。これを書き留め、アプローチに同意してから、作業を行ってください。これは、意思決定プロセスへの関与が技術的な作業に限定されないという前例を作ります。少なくとも、翻訳者として、良くても思考パートナーとして見られます。
• ビジネスを気にする。当たり前のことのように聞こえますが、アナリストやデータ サイエンティストがビジネスに目隠しをして、仕事の技術的側面に没頭しているのをよく見てきました。この振る舞いは、真に機能不全で影響力の低い分析組織の前兆です。一般に、より高い影響はより良い分析からもたらされるのではなく、より高いレベルの戦略的実行におけるデータ駆動型の影響からもたらされます。

結論

データ分析の性質は、過去 10 年間で劇的に進化しました。これまで以上に多くのデータ、計算能力、ツールにアクセスできるようになりました。しかし、私たちは、新たに発見された力を備えた組織内で活動する必要があることをまだ理解していません.ここでは、成功したプラクティスを他のドメインから引き継ぐことが役立ちます。特に製品チームは、ユーザー中心主義と積極性に重点を置くことが、ヘルプ デスク分析チームと真に戦略を推進するチームとの違いを意味する可能性があります。また、ユーザー中心性と積極性は、ビジネス ニーズに対する鋭い認識と、より優れた知識共有の実践から生まれます。

hyperquery で公開された元のブログ投稿。