Clever Geek Handbook

プログラマーが期限を破る理由

導入する代わりに



私がどの会社に勤めていようと、部門やソフトウェア開発チームがほぼ常に期限を破ったのはまさに偶然です。 時には私たちは2日間、時には数週間は合わなかった。 通常、5〜10日を使い果たしました。 その結果、納品を遅らせるか、既知のエラー、不完全性、未検証の部品を引き渡して、次の開発段階に追いつくことを試みました。



私の経験が示しているように、過去のタスクの完了から始まる次の段階の開始は非常に悪い習慣です。 そして、このモードで作業すればするほど、何かを変えたいと思うようになります。 しかし、病気を治療する前に、原因を診断し、症状と区別する必要があります。 それで、開発期限の失敗の理由を特定し、「棚に置く」ための私の試みがここにあります。



マネージャー（天使の役割）



プロジェクトマネージャーは成功の重要な要素です。 インテリジェントなマネージャーを持つことは50％の成功とさえ言えます。 そして、そのような人の不在は90％の失敗です。 なぜマネージャーはそれほど重要なのですか？ 答えは簡単です。 マネージャーには、組織内のプログラマーとプロセスの両方を管理するのに十分な力と影響力があります。



私の意見では、マネージャーの仕事で最も重要なことは、彼がプログラマーと「世界の残りの部分」の間の仲介者として行動することです。 彼はプロセス変更の必要性を紹介し、他の部門に必要な資料を要求し、プログラマーの仕事の結果を提示し、会社の仕事にプラスの影響を及ぼす利益を保護することができます。



通常、平凡なマネージャーは次の間違いを犯す可能性があり、その結果、用語の遅延が発生します。



タスクの詳細レベルが不十分で、不可抗力があり、期限を見積もる経験が少ないことが、失敗のより微妙な理由です。 自己学習のレベルが高いマネージャーは、そのような間違いを避けるために時間をかけて学習します。



優れたマネージャーに内在する特徴：男らしさ、意志、誠実さ、開放性と社交性、建設的な批判と自己批判、正義、愛顧。



プログラマー（農民の役割）



また、プログラマのグループとして「純粋な」システムアーキテクトも含めています。 アーキテクトが人とプロセスも管理する場合、上記の管理要件は彼に進みます。



開発者の主なタスクは製品の実際の生産であるため、開発者にとって最も重要な要件は専門的な適合性です。 これには、キャラクターに加えて個人的な資質とスキルも含まれます。 私自身の経験から、会社が小さい場合、「チームワーク」というフレーズは空のフレーズではないことを知っています。 プログラマーのグループからどのように相乗効果を達成するか、私にはわかりません。 しかし、私はそれを破壊するために、コミュニケーションスキルの欠如などの些細なことで十分であることを知っています。 会社が「スタッフ開発」を実践している場合、コミュニケーションの問題は重要になります。 ここで、プログラマは必然的にメンターか見習い、あるいはその両方になります。



開発者は、自分や他の人が書いたコードに批判的でなければならず、同僚がアドバイスや行動でサポートできるようにし、たとえ他人のアドバイスが要求されていなくても差別できないようにしなければなりません。



仕事のタイミングに関する問題について前もって最初のプログラマーに警告することができれば、マネージャーはプログラマーに感謝するはずです。 個人的には、最初は、そのような「機能」が実装されず、バグが「修正」されることを上司に伝えることは非常に困難でした。 しかし、時間が経つにつれて、タスクを優先できるように、できるだけ早くこれを行う必要があることに気付きました。 あなたが知っているように、「警告-武装を意味する」ので、これはおそらくマネージャー自身のリーダーシップの問題からマネージャーの「お尻をカバーする」最良の方法です。



そして、プログラマーが期限に間に合わせるためにできることは次のとおりです。



優れた開発者に固有の機能である、競合のない、勤勉な、自己学習、責任、社交性に注目します。



コミュニケーション



コミュニケーションの役割については上記で述べました。 通信は非常に異なる面で行われますが、そうでない場合は、非効率的な通信を避けるようにしてください。 あなたは、必要なときにアドバイスを与えることなく、別の部門の従業員に止められている開発者です。これについてすぐに話し合い、重要性を説明してください。 助けなかった？ マネージャーに通知し、別のタスクに切り替えます。



別の例。 あなたはマネージャーです。 プログラマーのPetyaとKolyaはいつも同じことをする方法について議論しています（例えば、コーディングスタイルのトピックに関する聖戦）？ 必要なスタイルを入力し、自由がある場所を示します。 または、より一般的な方法で（スタイルについてではなく）、PetitとKolyaの紛争をかなり客観的に判断できる仲裁人を見つけます。 または、PetyaまたはKolyaに、重複しないさまざまなものの責任を負わせます。 または、「ピストンを挿入」して、批判が建設的でなければならないことを理解するようにします。

つまり、コミュニケーションの問題の解決策を探し、目を閉じないでください。 それぞれの決定は勝利ではないかもしれませんが、解決策の欠如は完全な損失です。

人と組織の間のコミュニケーションのもう1つの側面は、多くがライブコミュニケーションを無視することです。 仕事を遅くするための最良の方法は、電話、チャット、スカイプ、メール（！）を使用することです。 電子メールメッセージを使用する唯一の言い訳は、タスクが別の人に設定されていることを組織内の誰か（おそらく外部）に通知する必要がある場合と、その他の作業中の通信です。 しかし、ほとんどの場合、これはタスクアカウンティングシステムによって解決できます。 あなたが同僚から何かをする方法を知る必要があるだけで、彼がオフィスに座っている-怠けてはいけない、下に行く（同時に心を伸ばす）。 電話、チャット、スカイプは、 必要な場合にのみ使用する必要があるツールです 。 チャットからの時間損失は測定が難しく、目に見えませんが、非常に大きいです。



別の記事では、開発者の大規模なチームを1つの大きな部屋に配置するというトピックに値します。 この決定は参加者に大きく依存していると思います。 個人的には、私は騒音の中で仕事をすることはできませんが、10人以上のチームで、常に誰かが話します。 そのような決定を下す前に注意してください。



プロセス（法律）



プロセスによって、チームで作業するときに従わなければならない、正式および非公式に確立された注文を理解しています。 残念ながら、すべての企業が、一般的に人員が従う十分に明確なプロセスを構築することは決してできません。 もちろん、注文を官僚主義の庭に変えるべきではありませんが、完全に欠席すると遅かれ早かれ混乱に陥る可能性があります（従業員が組織に傾いていない場合、会社の仕事のエントロピーが大きくなる可能性が非常に高くなります）。



プロセスの公式な不在よりも悪いのは、プロセスの存在と非準拠のみです。 私たちのオフィスには閉じられたタスクの概念があり、それはタスクが完了し、そのタスクへの復帰が許可されていないことを意味すると仮定します。 次に、誰もがタスクを「閉じたタスク」の状態に送信し、それ以上記憶しないようにするために、できるだけ効率的にタスクを完了するよう努力します。 ここで、閉じられたタスク（つまり、誰もが閉じられていると認識したタスク）が再び発生することになったとします。 このようなプロセスの違反は、間違いなく痛みを感じます。 疑いもなく、実際にはどのビジネスにも戻らなくてもよいと保証することは不可能ですが、プロセススキームで考慮しない（または無視する）ことは間違いでした。



プロセスを説明するとき、考えられるすべての状況を想像し、それらを詳細に記述して紙に書くことは困難です。 しかし、最も重要な点は、一般的な習熟が義務付けられているドキュメントで修正する必要があります。 これらのルールは尊重されなければならず、誰もルールの例外について知らないことが望ましい。



プロセスの違反は以下を引き起こす可能性があります。



これらの現象は、タスクの実行時間に直接または間接的に悪影響を及ぼします。



一般的なツール



組織化されたソフトウェア開発のためには、多くのツールが必要であることは誰もが知っています。 これらには、タスクおよびエラーアカウンティングシステム、ドキュメントの共通リポジトリ、バージョン管理システムなど、さらに多くの興味深いものが含まれます。 これらのツールを使用してプログラマーチームの作業を調整するのにほとんど問題はありません。 そして、もしそうであれば、彼らはよく研究されており、通常は治療可能です。 しかし、非プログラマーもプロジェクトに関与している場合、基本的なレベルでこれらのツールを使用する習慣を彼らに浸透させるには時間がかかります。



いずれにしても、ソフトウェア開発は、開発が優先事項ではない場合でも、問題の解決に真剣に取り組む企業にこの制限を課します。 私が働いていた組織の1つでは、プログラマーが最初からこれらのシステムを使用していましたが、すべての参加者がそのようなシステムを使用する必要性を理解および認識する時間はプロジェクトの開始からほぼ1年後になりました。

必要なツールをすぐに使用できるようになるほど、時間を節約できます。



クラスライブラリとフレームワーク



プログラマーの役割から大きく離れることなく、他の人のコードの問題に触れます。 中庭には21世紀があり、もはや「自転車の書き方」（または車輪）を歓迎しません。 ほとんどのプログラムは、クールなサードパーティライブラリ、またはフレームワーク全体を使用して記述されています。 RoR、Drupal、.NET Fw、Qt（自分でリストを続けてください）だけで、製品の基礎ではなく、すぐに製品の作成を開始できます。 しかし、小さな「しかし」があります。人々はしばしば間違いを犯します。 最悪なのは、私たち（または他の誰か）がソフトウェア開発用のツールの選択でミスを犯した場合です。 この場合、適切なプラットフォームでまだ書き直さないと、設計段階と製品作成段階で時間を無駄にすることになります。



また、ライブラリが必要な機能の一部のみを提供する場合にも発生します。 不足していることを行うのに手がかかる時間をすぐに計算することをお勧めします。 時には、原則的にはできないことがあることが判明します。 サードパーティのライブラリで深刻なバグが発生すると、多くの時間が失われる可能性があります。 バイパスするか、自分で修正する（オープンソースの場合）か、バグについて作者に通知し、開発者がプロ​​ジェクトをサポートすることを期待して、無期限に待つ必要があります。 同様に、他の誰かのコードにドキュメントがない場合は非常に悪いです。 その場合、いくつかの問題を解決する時間を予測することはできません。 このようなタスクを「ブラックホール」と呼び、マネージャーに緊急に警告します。 「バグ」+「文書化されていない予期しない動作」という不快な組み合わせもあります。



残念なことに、プロジェクトの間違った/文書化されていない/バズニーの基礎が選択された場合、時間を評価する方法についての戦略を示すことさえできません。



制限事項



上記のすべては、大企業に適しています。 1人が複数の役割を果たしている小規模企業の場合、状況はエスカレートします。 製品の期待される品質レベルとその開発のペースが低下しない場合、プロジェクト参加者の要件は厳しくなります。 このような環境では、スタッフを非常に慎重に募集し、候補者の専門的および個人的な資質をできるだけ正確に評価することを強くお勧めします。



注：この記事の文脈における「プログラマー」と「開発者」という言葉は、互いに同義です。 言葉「マネージャー」、「マネージャー」、「リーダー」。


More articles:


All Articles