MegamindがHabrと再会したという事実に照らして、今では両方のポータルの聴衆も団結していることが期待できます。 Habrが現代のテクノロジーの世界に馴染みのないマネージャーの注目を集めると考えるのは理にかなっています。 そのため、 SmartProgressチームは、開発とプロジェクト管理の岐路にある記事を準備することにしました。
この投稿が、マネージャーがプログラマーをよりよく理解し、ほとんどのマネージャーとエグゼクティブが力強くメインで歩くのと同じ熊手を踏まないようにすることを願っています-誰もがコードが時計仕掛けのように動作することを望みますが、同時に上司は開発者が優れたものを開発するために必要なものを忘れますコード。
「生産性の測定」
測定できないものを制御することはできません-これはマネージャーのギルドのお気に入りの公理の1つです。 しかし、どのように言っても、開発者の生産性を適切に評価できる人はいません。 IBM、Microsoft、Intel、およびIT界の他の多くの巨人の頭脳がこの問題に取り組んでおり、これまでのところ、プログラマの生産性を測定するための測定基準は見つかっていません。 これがあなたにとって馬鹿げているように思えるなら、あなたの考えを提供してください。 その後、あなたはITの世界で真のスターになり、あなたとあなたの天才についての本が書かれます。
したがって、問題は、開発者の生産性を測定するメトリックがないことです。 管理者が見つける方法は何ですか？ 彼らは少なくとも何かを熱心に測定しようとします-毎日書かれたコードの行数やデバッグされたばかりのバグ、時間通りに配信されたプロジェクトの数、その他の同様に重要なことを記録します。 この場合の最悪のシナリオは、開発者をやる気にさせ、「5年計画を満たさない」か、プロジェクトの完了を遅らせるという罰則を導入しようとする試みです。 結局のところ、プログラマーは不安定ではありません。 さらにコードが必要ですか？ できます。 バグ-特にこれにボーナスを与える場合、2シフトで修正します。 コード自体の品質のプリズムの下での生産性のみが、このようなアプローチが非常に悪い影響を及ぼします。
このトラブルを解決するにはどうすればいいですか？ 何十もの論文がこの主題に関して書かれており、コンセンサスは見つかっていません。 1つのことは明らかです。ワークフローを整理し、ソフトウェアの作成を調整するので、メトリックでプログラマに圧力をかける必要はありません。 しかし、マネージャーがパニックに陥らないようにしてください-彼らはまだ測定し、説明するべきものが山ほどあります。 たとえば、どの障害がプロジェクトの作業を遅くするか、これらのタスクまたは他のタスクにかかる時間を正確に追跡することができます（そして、そうすべきです）-後でこれは、そのようなプロジェクトの完了期限をより正確に推定するのに役立ちます。
「後で修正します」と考えている
プロジェクト計画では、計画されたすべてを作成するのに常に十分な日数がなく、日数-時間もありません。 そのため（および他の多くの理由で）、開発者はここで動作するバグや「松葉杖」ソリューションに目をつぶって、プロジェクトを完了させるだけです。 これは、技術的負債がどのように現れ、蓄積するかであり、いつかは返済しなければなりません。 負債が大きいほど、開発の後続の段階で増加し、プロジェクトの速度が低下します。 それは悪循環であることがわかりました-彼らはすぐに望んでいましたが、それはいつものように判明しました、つまり、まったく逆です。
各プロジェクトには技術的な負債があります-時には比較的迅速に対処できる場合もありますが、多くの場合、巨大な割合に成長します。 借金が多いほど、返済に時間がかかり、ご存じのようにお金もかかります。 したがって、古いコードと戦うよりも新しいコードを書く方が簡単です。
「すべて後で修正する」という考え方に対処する方法は？ まず第一に、マネージャーと顧客はプログラマーが彼らに伝えようとしていることを聞くべきです。 非常に多くの場合、最適なソリューションの実装には時間がかかり、製品のリリースのタイムラインを押し上げますが、管理者も顧客もそれを好みません。 ただし、後で正当化されます。 もちろん、さまざまなケースがありますが、1つ確かなことは確かです。1人の開発者がホイールを意図的にホイールに入れたくないのは、その結果を自分で処理する必要があるためです。
ドキュメントが少なすぎる
ドキュメンテーションには時間がかかり、開発者はコードを書き、書いた行数とデバッグしたバグ数で作業を評価します（そうでなければ評価方法がわからない場合）。 マネージャーは結果を求めています-開発者と結果のために働きます。 「ドキュメントはどうですか？」とあなたは尋ねます。 「そして、私たちはすでにすべてを覚えており、この時が来たらすべてを書きます。 チェスロボ！」-プログラマーが冷静に答えます。
ドキュメントが多すぎる
そして、誰もがドキュメントのないプロジェクトに慣れていますが、実際には、官僚的な泥沼に陥っているプロジェクトはあまりにも一般的です-言葉が多すぎてコードが足りません。 これは、会社がドキュメンテーションに対して「重量で」支払う場合に危険です。 実際、コメントの代わりに、コード内のあらゆる小さなことについて長く誠実なスピーチを期待できます。これには数か月かかることがあります。 彼らが望んだもの、彼らはそれを得た。
骨Love品の愛
なぜ機能するのに古代のコードを書き換えるのですか？ 古い実績のあるソリューションがあるのに、なぜ新しいテクノロジーを使用するのですか？ 一方で、これらは正しい発言ですが、古いコードを保存することは時間とお金であることを忘れないでください。 あるプログラミング言語から別のプログラミング言語にすべてを翻訳する必要があります。それは簡単ではなく、多くの落とし穴を隠します。 間違いなく、プログラマは、新しいシステムを生産的に作成して前進させるのではなく、古代のシステムを修正および修正し、古いロジックを洗練することにより、膨大な量の作業を行うことができます。
職場のサーカス
会社のオーナーがオフィスでビリヤードや卓球などのクールなことを覚えているのは素晴らしいことです。 しかし、多くの場合、開発者がコードに集中することが重要であることを誰もが忘れます。これには沈黙が必要です。 会話、キーのノッキング、着信音、その他のオープンスペースの「魅力」は、開発者を抽象的なアルゴリズムの世界から引き離します。 そして、彼らは仕事に戻る時間を必要とします。 これらは数秒、数分です-しかし、プロジェクト全体の規模では、こうしたことはコードの記述速度だけでなく、その品質にも悪影響を及ぼし、最も重要なことはプログラマ自身の脆弱な心の揺らぎを揺るがすことです。
悪名高い会議
マネージャーは話すのが好きで、ほとんどの場合、これらの会話はプログラマーには理解できません。 よく知られた話-マネージャーは「組織の詳細」について何時間も議論する準備ができているため、開発者はメインタスクに集中できません。 または別のシナリオ-会議のプログラマーは、デバッグする代わりに、既知のすべてのバグについて何時間も泣き叫ぶことができます。 したがって、多くの場合、会議は開発者の生産性を向上させることを目的としており、目的の結果が得られるだけでなく、まったく逆の動作もします。 さらに、営業日の真ん中にあるこのような集まりは、プログラムコードの作成者を抽象的なアルゴリズムの世界からそらし、再び作業気分に調整するためには時間を必要とします。
これに対処する方法は？ 会議にはまだ多くの肯定的な側面があるため、この場合は、回数と期間でやり過ぎないように監視する必要があります。 少ないほど良い。 最も重要で最も簡潔なもののみを説明します。
一部の進歩的な企業の足跡をたどり、会議を完全に放棄することにした場合は、優れたコミュニケーションメカニズムが必要になります。 ここでは、メジャーも重要です。開発者にとっては会議よりもさらに悪いので、手紙やレポートでやりすぎないでください。 また、計画を効果的に行い、目標を設定し、目標に向かって一緒に取り組むために、当社はあなたの会社を支援することができます。
だから、私たちはあなたが投稿を楽しんだことを願っています。 開発者の生産性を低下させる要因について何か言いたいことがありますか？ また、このパフォーマンスを改善するために、ライフハックのコメントをご覧ください。
SmartProgress-目標の達成