We are All Product Owners! An Impact Guide for Engineers

市場での製品の売れ行きや会社への貢献には関係がなく、期日通りにデリバリーしていればうまくいったとしていた

QA の役割は、明らかに壊れたものをエンジニアリング部門が出荷するのを阻止すること

発売日は神聖なもの

ビジネスにインパクトがあれば、何をいつ出荷したかはあまり重要ではなく、評価期間の6か月間に実際に測定可能なインパクトを与える必要があった

QA の役割はエンジニアリングと連携して適切な機能が適切に動作することを確認すること

製品がユーザーに良い影響を与えるほど優れていると判断した時点でshipしていた

会社の最優先目標に焦点を当てた、ビジネスへの影響

会社の収益を増やし、コストを節約し、顧客数や取引数を増やし、サポートコストを削減するなど

エンジニア目線でいうと

事故の削減

製品領域の主要なバグを修正し、ユーザーにとってより良いものにする

ユーザーが注目する領域でのパフォーマンスの向上

インフラをより安く、より速く、より安定させる

他の人がより速く物事を構築できるように（そして採用されるように）システムとフレームワークを構築する

開発者の診断/構築/出荷にかかる時間を短縮

採用する質の高い人材の数を増やす

メンタリング（メンティーにあなたが助けたことを認めてもらうこと）

すべてが測定できるわけではない

「機能を予定通りに出荷しました。」

「社内のフロントエンドプロジェクトのアーキテクチャレビューに参加しています。」

「モバイルとフロントエンドのエンジニアリング、分析、QA の調整を支援しました。」

「文化設定の会議に参加しています。」

インパクトベースで書き直す

「商品ページから直接チェックアウトフローを有効にして、購入を 10% 増加しました」

「以前は製品ラインごとに 20 分かかっていましたが、そのうち 20% の時間はプロセスが失敗し、再度実行する必要がありました。私が変更を加えた後は、新しい製品ラインを 10 秒で同期できるようになりました。二度とそのプロセスに手を加える必要はありませんでした。」

「今半期は20回の面接に参加し、2人の新入社員を採用することができました。」

「クライアントのエンジニア全員の同期会議をスケジュールしました。リファクタリングが必要な領域が 3 つ特定されました。そのうち 2 つはすでに完了しており、クラッシュは 20% 減少しました。」