R&D のためのドッグフーディング

あらゆるものをドッグフーディングする

GitLab の仕組みを理解する最良の方法は、業務のできるだけ多くの部分で GitLab を使うこと です。 ドッグフーディングのアンチパターン を避け、可能な限り外部ツールではなく GitLab を活用する方法を見つけてください。例えば: ドキュメントやスプレッドシートの代わりに Issue を使い、Slack スレッドの代わりにコメントで会話を残すように心がけてください。

PM としてだけでなく、GitLab のすべてのチームメンバーとして、すべての機能を積極的に使うべきです。少なくとも あなたが責任を持つすべての機能は使ってください。これには GitLab の UI に直接表示されず、サーバー設定が必要な機能も含まれます。

もしドキュメントが理解できなかったり、何かをインストールするのに苦労したりするなら、他の誰かがわざわざそれをしてくれるでしょうか？このハンズオンの経験は、痛点を理解するのに有益なだけでなく、何が改善できるか、GitLab に何の機能が欠けているかを理解するのにも役立ちます。

いつドッグフーディングするか？

ドッグフーディングのプロセスは、Product Development フローの バリデーションフェーズ から始めるべきです。PM は 社内顧客 と会話の場を設け、問題と可能な解決策に関するフィードバックを収集する必要があります。これにより、GitLab を深く理解しているチームからのフィードバックがグループに提供され、社内顧客の要件を最初から考慮できるようになります。社内でドッグフーディングされた機能は、このプロセスを経ていないものよりも成功する傾向があることがわかっています。

機能が minimal で viable に向かっているとき、指名された GitLab チームメンバー（および興味のある人全員！）はその機能を広範に使用し、PM と開発チームに積極的にフィードバックを提供する必要があります。

機能が viable で complete に向かっているとき、指名された GitLab チームメンバーはその機能を 排他的に 使用し、排他的な使用が不可能な状況では PM に直接フィードバックを積極的に提供する必要があります。

ドッグフーディングの例外:

機能が planned および/または minimal に向かっているときは、ドッグフーディングは必須ではありません。ただし、社内顧客からフィードバックを得るための最初の会話は 実施されるべき です。

GitLab という会社 は特定の方法で動きますが、GitLab という製品 は多くの異なる会社やペルソナで動作するように設計されています。私たちの組織の働き方とは合わない機能を広いコミュニティが欲していると リサーチを通じて検証された 場合、ドッグフーディングは必須ではありません。

R&D チームメンバー向け

R&D 組織として、会社全体で当社の製品をドッグフーディングできるようにする責任もあります。これは 顧客を理解する、私たち自身が愛する製品を提供する、自社製品を使って改善点を浮き彫りにする と整合しています。

1. その機能を追跡している Issue に Dogfooding および Dogfooding::Promote Feature ラベルを追加します。Issue 上でフィードバックスレッドが開始されていることを確認してください。

   Note: 将来的には、どの機能が ドッグフーディングを要求している か、関連するエンゲージメントを把握できるよう、トラッキングと可視化を追加する予定です。