Fulfillment と Monetization の業務の進め方
Monetizationと Fulfillmentの両セクションは、共通の業務の進め方に従います。Monetization ページの CustomersDot のエンジニアリングやインシデント対応プロセスなど、セクション固有の内容は各セクションのページに記載しています。
共通の Slack チャンネル
| チャンネル | 目的 |
|---|---|
| #fulfillment_monetization_fyi | 両セクションへの質問窓口 |
| #fulfillment_monetization_engineering | 共通のエンジニアリング用チャンネル |
| #fulfillment_monetization_daily | 毎日のスタンドアップの報告 |
| #fulfillment_monetization_pm | プロダクトマネジメント |
| #fulfillment_monetization_design, #fulfillment_monetization_research | Product Design と UX Research |
| #fulfillment_monetization_speak_spark | 交流 |
窓口チャンネルで質問した場合は、回答を得たら ✅ のリアクションを付けてください。お客様の緊急の問題には STAR エスカレーションを利用します。お客様に関わるライセンスやサブスクリプションのリクエストには、L&R Internal Requests フォームを利用してください。
Stable Counterpart
Sales と Go-To-Market
| Name | Role |
|---|---|
 Jesse Rabbits | Sr. Manager, Deal Desk |
 Gurmee Sodhi | Senior Analyst, Online Sales & Self Service Product GTM |
Finance と IT
| Name | Role |
|---|---|
 Anna Piaseczna | Analytics Engineer |
Support Engineering
| Name | Role |
|---|---|
 John Lyttle | Manager, Support Engineering |
 Ket Slaats | Manager, Support Engineering (APAC) |
Product Technical Program Management
プロジェクト管理プロセス
私たちは透明性をもって業務を進め、ほぼすべてを公開し、プロダクト開発フローに従います。
SAFE
私たちの業務では、財務情報や機密性の高い情報を扱います。SAFEに該当するエピック、Issue、動画、MR は機密扱いとし、公開できない内容には社内ハンドブックを使用してください。将来のバージョンでの機能提供の約束を参照してください。
計画
プロダクト開発タイムラインに従い、月次のマイルストーンで計画します。各グループには、優先順位を付けた Issue とキャパシティを記載する計画 Issueがあります。26 日頃に PM と EM が候補の Issue をレビューし、ウェイトを付けます。1 日までにスコープを確定します。
エンジニアは、最初に Deliverable の Issue に取り組み、その後、マイルストーンに残っている Issue の上位から選びます。定期的な運用業務（監視ローテーション、トリアージ）は、キャパシティに算入するため、ウェイトを付けた Issue として計画します。
作業依頼の受付
ロードマップに関わる作業を依頼するには、受付 Issueを作成し、PM にタグ付けします。PM は依頼を評価し、ロードマップ上にエピックを作成し、受付 Issue からリンクしたうえで受付 Issue をクローズします。このプロセス外のリクエストには対応しません。
優先順位付け
優先順位付けのフレームワークと部門横断の優先順位付けに従います。判断材料には SLA、OKR、Support の優先 Issue リスト、技術的負債を含めます。会社の新規作業と保守の 60/40 という配分は、規則ではなく指針として使用します。各グループは OKR でそのバランスを設定し、必要に応じてセクションにエスカレーションします。すべてのチームが、部門横断のダッシュボードレビューのために月次の優先順位付けテンプレートを使用します。
見積もり
事前調査の後、通常は計画時に見積もりを行います。
| ウェイト | 説明 |
|---|---|
| 1 | 可能な限り最も単純な変更で、副作用がありません。 |
| 2 | 単純な変更で、要件を完全に理解しています。 |
| 3 | 単純ですが影響範囲がより広い変更です。要件は明確です。 |
| 5 | 複数の領域にまたがる複雑な変更で、リファクタリングを伴う可能性があります。いくらか不明な点が残っていると考えられます。 |
| 8 | コードベースの多くに関わる、または多くの意見を必要とする複雑な変更です。 |
| 13 | 依存関係と不明確な要件を伴う大きな変更です。実施を確約する前に分割してください。 |
私たちは予測可能性よりも開発速度を重視しますが、業務が部門横断にわたるため、80% の予測可能性を目指します。確信が持てない場合は、多めに見積もるか、スパイクと実装の Issue に分割します。見積もりが変わった場合はすぐに修正し、PM に伝えてください。
毎週の非同期 Issue 更新
エンジニアは、割り当てられた Issue を毎週更新します：
### Async issue update
1. Current status (one sentence):
1. Confidence this lands in the milestone: not / slightly / very
1. Can this be broken down further? yes / no
1. Were expectations from the last update met? If not, why:
/health_status on_track | needs_attention | at_risk
大規模なプロジェクトでは、親エピックに毎週ステータスを投稿し、完了率、主要な期日に対する進捗、リスクとブロッカーおよびその軽減策、成果を報告します。
デモ
Fulfillment Demos プレイリストのデモを通じて、デモのプロセスに従い、複数のマイルストーンにまたがる作業の進捗を共有します。説明欄にエピックまたは MR をリンクしてください。
ユーザー体験
Product Designers は Product Design のワークフローに従い、グループではなくプロジェクトに割り当てられます。その割り当ては、UX の優先順位 Issueで四半期ごとにレビューします。中規模・大規模のプロジェクトでは、[UX] Issue をデザインの SSOT として使用します。UX の支援や MR レビューは、#fulfillment_monetization_designで依頼してください。
振り返り
月次の非同期の振り返りを、8 日以降に gl-retrospectives/fulfillmentで行い、その後、26 日頃にタイムゾーンを持ち回りにして、録画する同期ディスカッションを行います。グループは、特定の Issue やエピックについて、四半期ごとのイテレーションの振り返りを行うこともできます。
オンボーディングと交流
新しいエンジニアはオンボーディングテンプレートを使用し、オンボーディングバディが付きます。任意参加の毎週の交流会と四半期ごとのチームデーは、共有カレンダーに掲載しています。
リンク
- Fulfillment の方向性
- Fulfillment ガイド（CustomersDot の管理とプロセスのドキュメント）
- Issue トラッカー
- パフォーマンス指標とエンジニアリングダッシュボード
- ペアプログラミング
5d840611)