#Book [[📒エンジニアリングマネージャーのしごと]] ### 11.1 サウロンの目 - サウロンの目 = 強烈なプレッシャー - デリバリーのプレッシャー - 継続的に障害が発生した時 - 視線を浴びている時は、次の原則を適用するようにしよう - チームの足並みを揃える - 成功する方法を全員が確実に理解するようにする。[[🗃️チーム]]がゴールに向かうための[[🗃️ファシリテーション]]をする - 過剰なまでのコミュニケーション - 取り組んでいること、進捗状況、下した重要な決定について明確にしておく - 反応や[[🗃️フィードバック]]を求める - 頻繁にリリースする - 視線が逸れた時 - お祝いする - 技術的負債をキレイに片付ける - 自分用のプロジェクトの時間をとる - 振り返る - 計画を立てて、気持ちを切り替える - サウロンの目にみられていることが続くと、燃え尽きや離職を引き起こす - プロダクトのリリース時期をずらすのは良い選択 - チームが回復するための期間を設ける ### 11.3 スコープ、リソース、時間 #### スコープ - 機能を、Must, Should , Could, Won'tに分解する - Shouldは重要だけど、最初の[[🗃️マイルストーン]]や締切の時にはなくても良いかもしれない - Coludは、あるとよいが必須ではない - Won'tは、意図的にやらない意思決定をしたもの - [[🗃️MoSCoW法]] - ストレッチゴールを推奨する - Mustと、最初のリリースで必要なShouldを整理する #### リソース - [[🗃️プロジェクト]]の考慮事項 - タスクの並列性 - コードの接近性 - 複数のエンジニアが同じコードを触ってコンフリクトを起こしてしまう - 技術的難易度 - 遅い[[🗃️プロジェクト]]に人を追加するとさらに遅くなることがわかっている #### 時間 - 締め切りを調べる - 締め切りをずらすことが本当に意味することは何なのかを確認する - 例 - メールキャンペーンの配信が少し遅れるくらいしか影響がないのか、 - CEOが数千人の前で披露するのか - 多くの場合は、締め切りはずらせる - これに失敗した場合は、別のレバーを引きましょう - 締め切りが動かせないなら、スコープや、リソースを見直す必要がある