マネージャーガイド：開発者が本当に働いていることを理解する方法

この記事は、リンクにある資料の翻訳です。

開発のスピードに満足しているマネージャーに会ったことはありますか？ 個人的にはそうではありません。 しかし、時にはスピードよりもはるかに悪いこともあります。開発者の仕事について、クライアントと多くの教育的な会話を聞いたことがあります。その時点で問題の解決策を考えています。 ある日、トップマネージャーの1人が私の部屋に来て叫びました。 彼らはインターネットをサーフィンしています!!! 私たちはそれについて何ができますか？」

物語

そこで、2つのチームについての話をします。 どちらも同じ複雑さのモバイル製品に取り組みました。 チームの1人は、1日10〜12時間、多くの場合週末に働いていました。 各リリースは彼らにとっての戦いでした-彼らはほとんどいつも時間通りにそれを展開することができましたが、それは簡単ではなく、非常に困難でした。 誰もが一生懸命働くことを知っていました-絶え間ない動きがあり、チーム全体が忙しいことを見るだけで誰もが理解できました。 多くの場合、リリース前に「クリティカルブロック」があり、チーム全体がこの問題を解決するために集まりました。 あなたは彼らがコンピュータの近くに立って、何かを議論しているのを見ることができました。 運が彼らに微笑んだ場合-見つかった修正は新しいバグにつながりませんでしたが、時にはそれらのチェーン全体があった-次々と問題が発生しました。 したがって、彼らはリリースのためにビルドを準備するために一晩中働かなければなりませんでした。

2番目のチームは完全に異なっていました-彼らは午前11時に働き始め、午後6〜7時に帰宅しました。 彼らはまた定期的なリリースを行い、遅延はほとんどありませんでした。 彼らは、理解しやすく、保守しやすいように、アプリケーションのアーキテクチャに懸命に取り組みました。 アーキテクチャは完璧ではありませんでしたが、改善を試みました。 リリース前はパニックに陥っていなかったため、開発者は多かれ少なかれ新機能の複雑さを予測できました。 はい、彼らはユニットテストと統合テストにも多くの時間を費やしました。 スプリントのリファクタリングの半分を費やすことができます。 前のチームよりも簡単なタスクがありましたか？ いや


マネージャーはどのように見えましたか？ 「最初のチームは一生懸命働いており、2番目のチームはそうではありません。」などと申し上げます。マネージャーは、費やした時間を比較して「生産性」を測定しようとしました だから、誰にとっても、2番目のチームが非常に怠zyであることは明らかでした。

しかし、結果はどうですか？ それらは両方のチームでほぼ同じでした-稼働中のアプリケーション、多かれ少なかれ満足しているクライアント。 2番目のアプリケーションの方がうまく機能し、バグが少なかったとは言えません（これは事実です）

だから、あなたの開発者が懸命に働いていることを理解する方法

このストーリーは、開発者がどれだけ忙しいか見てチームのパフォーマンスを判断できないことを示しています。

個人的に、私は本当の開発者は怠け者であると信じています。 彼らが同じことを2回行う場合-彼らはこれを繰り返すのが面倒なので、彼らはこのプロセスを自動化する方法を見つけようとします。 彼らは怠け者なので、繰り返しを買う余裕はありません-彼らは可能な限りそれらを取り除きます。 彼らは常により便利で生産的なオプションを探しています。

ですから、マネージャーが「勤務時間中にYouTubeでビデオを見ている」と苦情を言うと、私は通常彼に尋ねます-「しかし、なぜこれが問題なのですか？ チームの結果に満足していませんか？」

プロジェクトマネージャー向けの簡単な手順を次に示します。 まず、問題が何であるかを判断します。

開発に問題やエラーはないが、「これは正しくない」と感じる場合：

1. コードを1日8時間書くことは不可能です。 あなたはタイプライターではないので、少なくとも考える時間を必要とします-最初に何を印刷するかを決めなければなりません。 思考に時間をかけると、さらに多くのタイピングが必要になる場合があります。
2. 思考については、休憩なしに1日8時間考えることはできません（そして、ここで私はこれからの休暇について考えるつもりはありません-個人的には終日考えることができます）。 私は「発明」を意味しました。 アイデアを思いつくには時間が必要です。 あなただけのアイデアマシンになることはできません。 したがって、就業日には常に小さな「ギャップ」があるはずです。
3. プロジェクトマネージャーが開発者の仕組みを理解することは非常に困難です。マネージャーにとって、この日は中断で構成されており、これが「マネージャーの流れ」です。 それどころか、開発者のフローは、タスクに関するすべての情報（変数とその値、オブジェクト、関係など）を脳にロードするときに継続的です。 ソリューションの「モデル」に加えて、コードを書くためにこれらすべてを頭の中に保持する必要があります。 あなたはそれにうんざりします。 あなたの脳は少し休息したい。 重い箱を何時間も運ぶようなもので、休むだけです。 そして、あなたはあなたの脳からすべてをアンロードし、Redditを開きます。 そしてその瞬間、上司がやってきて、「ねえ、どうして仕事をしないの？」
4. 進捗状況。 すべての時間がロードされている場合は、進行できません。 変更する時間がないだけです。 したがって、これには時間が必要です-実験のため、成長のため、学習のために
5. これは工場ではありません。 「リリースされたアイテムの数」などの単純なメトリックを使用してパフォーマンスを判断することはできません。 特定の時間におけるコードの行数や「機能の数」など、これらすべての単純なメトリック。 開発者は愚か者ではありません（残念ながら、彼らはあまりにも賢いです）-あなたがそれらを測定し始めるとき、彼らはあなたのメトリックをクラックします。 これから利益を得る唯一の方法は、「成功」のメトリックを設定することです。チームの目標、リリース、利益、顧客満足度を達成することです。 これで問題ない？ したがって、修正するものはありません。

開発エラーがあります
根本原因を見つけてください。 最も簡単な方法は、開発者が怠け者だと言うことです。 開発者が機能しなくても...一日中機能しません。 理由を見つけてください。 おそらく、プロジェクトマネージャーとしてのあなたの仕事が下手だからです。開発者はプロジェクトに興味がないのでしょうか。 すべてが非常に退屈だから？ 「何もする意味がないので、結局私は罪を犯します」？

はい、時々、単に働きたくない開発者に出くわします。 これは簡単に理解できます。 解決策は簡単です-あなたはそれらを解雇します。

だから、人を変えようとしないでください。 環境の変更、管理の変更、障害の除去。 庭師になりましょう-自分の手で本物の花を作ることはできませんが、成長させることはできます。