最高のエンジニアを追い出す方法
(padraigobrien.com)「開発者たちの在籍期間をより短くする方法」と「直す方法」
- ソフトウェアを作れないマネージャーを採用しましょう
→ FIX: 技術マネージャー、ディレクター、VPが四半期ごとに1週間ほど機能を開発してデプロイするようにしましょう。3日ほどかかる機能を、実際の作業/協業方式で。
- とてつもなく多くのマネージャーを採用し、階層を設けましょう
→ FIX: 組織をフラットにし、可能な限り管理階層を取り除きましょう
- できるだけ多くの会議をしましょう
→ FIX: チーム間の協業を最小化し、チーム内部では多くの協業が起こるように組織を設計しましょう
- ソフトウェア定義プロセスを苦痛なものにしましょう
→ FIX: 開発者の負担を減らす方法。チケットを作るとき、少なくとも3人（エンジニア、テスター、プロダクト担当者）が10分間議論して作成するようにしましょう
- ソフトウェアのデプロイを苦痛なものにしましょう
→ FIX: 表面化した問題点に20%の時間を割り当て、分析して修正する時間を持てるようにしましょう
- エンジニアに自分の作業時間を見積もらせましょう
→ FIX: 見積もりはしないでください。経験上99%以上当たらず、うまく機能しません。日付が必要なら forecasting のような最新の方法をおすすめします
- チームをとても小さくしましょう
→ FIX: 少なくともチーム規模は6人がよいです
- エンジニアをほかのチームから借りてきましょう
→ FIX: チームがミッションを持って長く存続するようにし、人を移動させないでください
5件のコメント
VPにtaskをassignするなんて、考えただけでも心臓が縮み上がりますね。四半期ごとに1週間とはいえ、おそらくその1週間の間に数え切れないほどの横やりとAIが生み出されそうです。もちろん、前向きな変化ではあるのでしょうけど :)
私がいた会社と似ていますね（笑）
開発リーダーがいたのですが、社長がコントロールできないということで、社長の知人が紹介した開発担当取締役を据えて、1年以内に開発チームが崩壊してしまいました。
forecastingとは何を指しているのでしょうか？
基本的に Estimation は、作業時間がどれくらいかかるかを推定して予測することですが。
Forecasting は天気予報と同じように、「既存のデータに基づいて」予想するものだと定義されています。
チームがエピックをストーリーに分割し、ストーリーごとにどれくらいかかったか（ストーリーポイント）などがきちんと記録されている場合、
週あたりに完了するフィーチャーの量に応じて、それを基に予想日を出す、といったことになると思います。
（私も本や文章で学んだだけで、実際に適用したことはないので……大まかにだけ説明します。）
良い回答をありがとうございました。（そして、ニュースをいつも楽しく読んでいます！）