しかし、多くのプロジェクト-記事やブログで書かれているサードパーティ、および会社の近隣部門のプロジェクトを見ると、プロジェクトマネージャーが異なると、タスクのタイミングを評価するアプローチが異なることがわかります。 そして、彼らはこの問題に対する私の態度と必ずしも一致しません。
原則
締め切りの推定に関するトピックに蓄積された情報を要約すると、作業のタイミングを評価するための次の原則を受け取りました。
- タスクの最終評価は、即時実行者のみが行うことができます。
- 時間の見積もりは常に楽観的です。
- サブタスクへの分割を必要とするタスクの全時間を見積もることは不可能です。
これらの原則を守って、トンネルの終わりの光はコードの最初の行からさえ見えるようになります。 直接のエグゼキューター（またはグループ開発の場合はエグゼキューター）自身が、より正確な評価のために一般タスクをサブタスクに分割し、サブタスクごとにリスクを示します。 したがって、各サブタスクに時間を追加することで、作業全体の非常に楽観的な締め切りを得ることができます。 これらの用語にリスクが掛けられ、作業全体に必要な概算時間が取得されます。 主なことは、パフォーマーだけでなく顧客もこれらの原則を理解していることです。そうでなければ、パフォーマーと「推測ゲーム」をプレイしたいと思うでしょう。
推測ゲーム
タスクを完了する過程で、解決するために追加の時間を必要とする状況が発生する場合があります。 たとえば、システムアーキテクチャでは問題を「迅速かつ美しく」解決することができないため、開発チームは、システム全体の状態を悪化させるハッキングやその他の多くの不要な作業を行うか、プロジェクトリーダーに必要なモジュールのリファクタリングを依頼する必要があります。
両方のソリューションは明らかであり、2番目のソリューションは長期的にはより受け入れやすいという事実も明らかです。 状況の複雑さは、一部の意思決定者が、社内の全員が「推測ゲーム」をしていると考えていることです。プログラマーが期限に名前を付けたら、その期限を守る必要があります。 そして、彼は変化した状況を気にしません。彼は、一般的な問題に対する最適な解決策を見つけることを試みるよりも、請負業者の条件に対する責任を「取り除く」ことがより重要です。
個別のアプローチ
ほとんどすべてのプロジェクトは、独自のアーキテクチャと独自の遺産（通常は「重い」）を持っているため、タスクを評価するときは、プロジェクトの特異性を調整するのが妥当です。 プロジェクトが若く、考え抜かれ、コードが設計とコーディングのすべての規範と規則をきちんと遵守して書かれている場合、それはもう1つのことです。うまくいけば。」
アーキテクチャが混乱し、既存のコードが乱雑になるほど、期限に間に合わないリスクが大きくなります。 そのような場合、問題による時間の予備推定に乗算する特別な係数を入力することで解決策を見つけます。
マインドゲーム
タスクを設定する人が開発者にとってどれだけの経験があっても、彼はその実装のタイミングを「推定」することしかできません。特定のケースごとにあまりにも多くのニュアンスを考慮する必要があります。特定のプロジェクト内の問題を解決します。
また、タスクマネージャーに技術的なバックグラウンドがない場合は、タスクのタイミングを推測することしかできません。 そして、彼は好奇心からのみこれを行うことができます-そのような評価には実用的な価値がないため、彼は推測するかしないでしょう。
問題は、一部のプロジェクトマネージャーがプログラマーが特定のタスクを実行する期限を個人的に設定しようとしていることです。これは基本的に馬鹿げています。 この無知の根源は、IT分野での作業の詳細に関する理解不足にあります。システム管理者のみがサーバーを構成する時間を見積もることができ、プログラマーのみがタスクに費やす時間を知ることができます。 マネージャーの仕事はタスクを管理することですが、タスク内のプロセスはもはや彼の能力ではありません。
汎用性
他のプロジェクトに機能を転送する機能を含むべきタスクがいくつかあります。 会社に複数のプロジェクトがあり、それぞれのプロジェクトで見積もられたタスクを完了する必要がある場合は、このタスクのタイミングと複雑さの評価を確認します。
まず、タスクが実装段階に入った後ではなく、「普遍性」の要件をすぐに述べる必要があります。 顧客が開発の後期段階のいずれかで機能をユニバーサルにしたい場合、これはコードのかなりの部分を書き換えることにつながり、したがって用語の改訂につながります。
私の練習では、プロジェクトの1つの複雑なメカニズムの終わりに、顧客が別のプロジェクトでそれを使用したい場合、タスクの特異性についての回答を受け取ったときに、機能が普遍的でないと不満を言うケースがありました。 しかし、これは難しいケースです...
ハードケース
また、タスクマネージャー（顧客）が自分を専門家と見なす場合についても言及したいと思いますが、実際には彼はふりをしていません。 このような顧客は、この記事で説明されていることを何も信じておらず、十分な技術的知識がなくても、タスクを最も近い時間で完了するための期限を推定できると考えています。
そのような専制政治のケースを放棄する方が良いです。 これはすべての人にとって最善の方法です。請負業者は非現実的な期限を取り除きますが、顧客は無数の試みの後、依然として「プロフェッショナリズム」で死にます。
物語
私の記憶では、機能が多少改良された後、経営陣が、低迷して絶対に不採算なプロジェクトを「凍結」したいというケースがありました。 プログラマーはタスクを評価するように求められ、リスクなしに評価しました。非常に楽観的で最小限の時間枠を与えました。 彼らが掘り始めたとき、彼らは深刻なリファクタリングにいることに気づきました。 オフィスでの眠れない夜と土曜日と日曜日の仕事の後、締め切りは最終的に満たされましたが、わずかな欠陥がありました。 これらの欠陥について、当局からの評決が続きました。プログラマーは、彼らが命名した用語を破りました。 「推測」のゲームがあり、リスクについて聞きたがりません。
プログラマー自身が自分自身を設定したため、プロジェクトとずさんさを失ったとしてさらに非難されましたが、経営陣自身は投資家との会合で見栄えがよく、損失をもたらすプロジェクトを開発チームの混乱に非難しました。