[感想]The Staff Engineer’s Pathの5章を読んだ

[感想]The Staff Engineer’s Pathの4章を読んだ
の続編

マスタカと言えばStaff Engineer
実はSeniorより上なんだぜ・・・！
そんなわけで本書を読んだわけだ

今回は以下章の感想
5. Leading Big Projects

プロジェクトマネジメント
・プロジェクトマネジメントとは
ドライブに例えられる

ただし、ペダルを足に置くことではなく自身で動くこと

道を選んで
決定をして
障害に対応すること
全員を安全に目的地に連れて行くこと

これがプロジェクトマネジメント！

初期
・プロジェクトが始まると
カオスになっていて
何をするのか、誰がするかという状態になっている
テックリードならこれらを解消するのがあなたがこの役割です

・難しいプロジェクトは
他の人も難しいと感じるw

・戦略を練るとき
自身の一番の強みを使おう
コードが得意ならコード
話すのが得意なら誰かと話す
読書家ならドキュメントを読む

・リスクを下げる
リスクを下げるために不明点を明確にする
何を知らないか
どんなアプローチを取るか
プロトタイプを作れるか
以前やっていた人はいないか
等

メンバー
・メンバーの責任範囲を決める
各々に役割を与えて責任を与える
各々の役割は以下を記載することで明確になる
略してRACI
Responsible：実際にやる人
Accountable：説明する人。だいたいResponsibleと同じ人
Consulted：意見を聞かれる人
Informed：進捗を更新を求められる人

すべての役割が埋まっていることを確認する
埋まっていなければ、その仕事が終わっていることを確認する
もし、埋まっておらず、仕事も終わってなければそれはstaff engineerの仕事。
マネージャーがいなければマネジメント
要求確認の担当がいなければ担当する

したくない仕事や時間がなければ社内外から採用する必要がある
自分のしたくない仕事が好きな人がいたらそれが最適な人材

作業について
・見積もり
仕事を最小の単位にして見積もる
さらに見積もりは誤るので3倍で見積もる

・運用チーム
運用チームを組むなら3人以上で組もう
可能なら6人以上が望ましい

・コードを書くかどうか
どのぐらいコードを書くかはチームの大きさによる
小さいチームならたくさんコードを書いても良い
複数チームのプロジェクトなら小さい変更程度になる。
大抵はコードレビューをたくさんしてコードはほとんど書かない
なぜなら、コードを書くことに時間を割くことでレバレッジがかかることは滅多にないから
大半のコードはジュニアによって書かれることが多い

・staff engineerの振る舞い
自分自身しかできないことはやるがペアでやる
さもなければ、後で説明する
あるいは、途中まで実装して誰かに渡す
このようにして他人に知識を共有する

遅延
・watermelon project
外から見たら全部オンスケ
ただし内側は全部遅れ
進捗遅れは隠さずに助けを求める

・プロジェクトが遅延したら
あなた一人がプロジェクトを成功したいと思っているわけではない
上司もその上の上司も成功して欲しいと思っている
助けを求めないのであれば、上司が助けるのは難しい
責任者の最大の失敗は、助けを求めなかったこと

学習
・何かを学ぶとき
コンフォートゾーンにいないと感じるなら
何かを学んでいることになっている

また何かを間違えたならそれも何かを学ぶことになる

5章はプロジェクトがメインでした。
Staff Engineerって普通のエンジニアじゃないですね
技術中心の何でも屋に見えるw
サブCTOに近いイメージですね
まだまだ続くよ

Pocket

関連記事: