＃＃＃導入＃＃＃
| 最近、ある PM が私に、彼女が直面したジレンマについて語った:「ソフトウェア エンジニアは、自分のプロジェクトにどれくらいの時間がかかるかをまったく見積もることができない。どうすればよいでしょうか?」最近、他の 2 人の CEO も同じことを私に言いました。大まかに言えば、問題は、時間の見積もりに関して、エンジニア、PM、マネージャー、広報、その他全員が異なる視点を持っていることです。ほとんどのエンジニアが本能的に考えるのは、すべてが計画通りに進んだ場合に、使用可能なプロトタイプを作成するのにかかる最小時間です。しかし、下流の人々が知りたいのは、プロジェクトがいつリリースできるようになるかということです。それはまったく別の話です。
|
ある PM は最近、彼女が直面したジレンマについて私に話しました。「ソフトウェア エンジニアは、自分のプロジェクトにどれくらいの時間がかかるかをまったく見積もることができません。どうすればよいでしょうか?」最近、他の 2 人の CEO も同じことを私に言いました。
「なぜプログラマーはプロジェクト時間を正確に見積もることができないのでしょうか?」 》（http://blog.jobbole.com/24924/）、皆さん深く理解しています。以前、2 日で完了すると予想されていたプロジェクトが、最終的には 4 か月かかったことがありました。この場合、「時間の 2 倍」という経験的推定値を使用したとしても、依然として 1 桁の差が存在します。これはビジネスに大きな影響を与えます。企業全体が発売イベントの開催に苦戦し、結局何か月も延期しなければならなくなったのを私は見てきました。
大まかに言えば、問題は、時間の見積もりに関して、エンジニア、PM、マネージャー、広報、その他全員が異なる視点を持っていることです。ほとんどのエンジニアが本能的に考えるのは、すべてが計画通りに進んだ場合に、使用可能なプロトタイプを作成するのにかかる最小時間です。しかし、下流の人々が知りたいのは、プロジェクトがいつリリースできるようになるかということです。それはまったく別の話です。
エンジニアにとって、プロジェクトにかかる時間を見積もることは生涯にわたる旅です。この問題を無視すると、あなたとあなたが直接または間接的に接触するすべての人に問題が発生する可能性があります。プロジェクトにかかる時間を正確に見積もることができれば、あなたは目立つようになり、同僚はそれをあなたのプロフェッショナリズム、安定性、仕事の質と結びつけるでしょう。
時間の見積もりが必要な理由
まず、エンジニアからよく寄せられる質問に答えましょう: 「なぜ時間を見積もる必要があるのですか?」 多くのエンジニアは、これが間接コストであると (何らかの理由で) 不満を抱いています。 「全力で働けば、プロジェクトはもっと早く終わるでしょう！」
主な理由は 2 つあります: 外部依存関係と優先順位です。
外部依存関係
効果的なキャンペーンは孤立した状態では機能しません。プロジェクトには、非エンジニアリング チーム (コミュニケーション、財務、広報、カスタマー サービス)、他のエンジニアリング チーム、さらにはエンド ユーザー自身とのコラボレーションなど、外部依存関係があることがよくあります。これらの外部依存関係の調整は通常、マネージャー、PM、または CEO の責任です。これは、時間の見積もりを行うのに最も適した人 (エンジニア) が、見積もりのための時間情報を最も必要としている人ではないことを意味します。この非対称性は根本的な矛盾を引き起こします。
＃＃＃＃＃＃優先度＃＃＃＃＃＃
時間の見積もりも、作業の優先順位付けの鍵となります。 「お金に見合うかどうか」はプロジェクトにおいて重要な指標であり、実際に見積もりを出さなければお金に見合うかどうかを判断することはできません。取り組んでいる機能が世界最高の機能であっても、時間をかけて綿密な見積もりを行ってみると、完成までに長い時間がかかることがわかるかもしれません。
Web サイトを 50% 高速化する 1 つのプロジェクトに取り組んでいるが、同じ時間内に、それぞれ Web サイトを 40% 高速化する 2 つのプロジェクトを完了できるとします。最初の見積もりを作成するのに時間を費やさなければ、より速くウェブサイトを作成できるかどうかは決してわかりません。
時間の見積もりの概要
時間の見積もりがほとんどの場合に必要であることは誰もが同意するところで、テクニックについて話しましょう。
「この基本バージョンを書くのにどれくらい時間がかかるだろう?」と考えて時間を過小評価してしまう
しかし、提供されるものは単なる基本バージョンではありません。また、書き込み、テスト、デバッグ、仕上げに必要な時間も考慮に入れてください。会議、面接、コードレビュー、メールの送信などにも時間がかかることを忘れないでください。
時間を過小評価するもう 1 つの理由は、コーディング中にほとんどの場合、完全に予測して検討することが不可能な「未知のもの」に遭遇することです。 IDE が更新され、プロジェクトが中断され、その修正に 1 日を費やすことになるかもしれません。これは時間の見積もりでは考慮できません。
しかし、私たちはまだ最初の直感よりもうまくできる可能性があります。私のやり方は次のとおりです:
ステップ 1: 技術計画の策定
作業を開始する前に、あらゆる主要プロジェクトに役立つ技術計画または設計文書を作成しておく必要があります。これを使用して、自分がやっていることを他の人に知らせ、フィードバックを得ることができます。技術計画の策定は、時間の見積もりを開始するための理想的な段階です。設計の技術的な詳細を完了すると、未知の問題が発見され、魔法のように推定時間を修正することになります。おそらく、使用しているライブラリを新しいバージョンにアップグレードする必要があることに気づくでしょう。これにより、作業に 1 日かかる可能性があります。使用する予定のライブラリが実際には存在せず、自分で作成する必要があることに気づく場合もあります。
ここでは粒度が重要です。いずれかのステップがあいまいまたは不明確に感じられる場合は、おそらくそれをスキップしたか（もっと学ぶ必要があります）、または小さなステップに分割する必要があります。同時に、ステップが細分化しすぎると、実際には脆弱になり、計画全体が無効になる可能性があります。 テクノロジー計画でどのような側面を考慮する必要があるかについては、Alicia Chen による記事「「もっと時間が必要」とはどういう意味ですか?」を参照してください。重要なポイントの 1 つは、何か間違ったことをしたために最初からやり直す必要がないように、PM やその他の関係者との潜在的な曖昧さを排除することです。
ステップ 2: 各ステップの時間予算を追加する
技術ソリューションの各ステップの実行にかかる時間を見積もります。これには通常、詳細を調べることが含まれます (「このライブラリの機能をすでに実装している人はいますか?」)。プロジェクトの性質によっては、単純なプロトタイプをレイアウトすることが、将来の潜在的な問題点の多くを明らかにするのに役立つ場合があります。
ステップ 3: 時間をたっぷり追加する
これで暫定的な見積もりが得られましたが、前に述べたすべての点をまだ考慮する必要があります。
- いつでもデバッグ: バグは常に存在します。デバッグは、特定のコードベースの経験とコードベースの成熟度に大きく依存します。
- 会議、面接、休暇など: 常にワークステーションでコーディングしているわけではないかもしれません。実際にコードを書くのに何時間かかりますか?見積もるときは、少なくともカレンダーを確認する必要があります。
- 最終テストとバグ除去: 通常、コーディング中にテストを作成する必要がありますが、多くのチームはリリース前に一連の仕上げ作業や統合テストを実施する必要があります。これらのタスクに十分な予算を見積もってください。ロールアウトが段階的に実行される場合、コンテンツの最初の 1% で修正が必要なバグが見つかる可能性があるため、これを考慮する必要があります。
- コード レビュー: プロジェクトには何回のコード レビューが必要ですか?通常どのくらい時間がかかりますか?十分な数のレビュー担当者を用意してください (レビュー担当者のスケジュールも確認してください)。レビュー担当者が 1 人だけのプロジェクトの場合は、レビュー担当者が休暇中であるか、重要な時点で多忙である場合に備えて、待機者を確保することに事前に同意するよう依頼する必要があります。
このすべての時間のオーバーヘッドをプロジェクトに追加し始めると、プロジェクトが実際に開始したときよりも時間の見積もりがはるかに正確に一致していることがわかり始めます。はい、実際には予想よりも時間がかかる可能性があり、期限を短縮する必要があるとプレッシャーを感じるかもしれません。しかし、あなたが信頼できるとわかれば、人々はあなたの見積もりを高く評価するでしょう。
ステップ 4: プロジェクトのリリース後、見積もり時間を確認して要約します
プロジェクトが完了した後に、これまでの作業を振り返るのは辛そうです。しかし、この種のレビューを行うことで、そこから多くのことを学び、次回はより良くできるようになります。
予想された時間と異なる処理結果はどれですか?統合テストに予想の 2 倍の時間がかかる場合は、それをメモし、次回のテストにはさらに時間をかけてください。あるいは統合テストシステムの改善を図る。
時間の経過とともに見積もりが改善されることは間違いありません。その過程で、チーム全体に役立つ素晴らしい洞察が得られるかもしれません。
結局のところ、すべてはコミュニケーションです
自分のスケジュールやその他の変更については、事前に他の人に知らせておく必要があります。リリースの 1 か月前に、使用しているライブラリに新しいセキュリティの脆弱性が存在し、最初から開始する必要があることをマネージャーに知らせると、マネージャーは広報、財務、またはユーザーにリリースの必要性を通知する時間があります。延期される。
他の共同作業者とのコミュニケーションから得られる重要なフィードバックは、推定時間の調整に役立ちます。デザイナーは「ああ、この派手なアニメーションに 1 週間かかるのであれば、完全にカットしてもいいでしょう」と言うかもしれませんが、PM は「これはユーザー調査のプロトタイプの実験にすぎません。あまり多くのものは必要ありません」と付け加えるかもしれません。 「このイテレーションのバグ クリーニングです。」マネージャーは、「会議に半分の時間を費やしましたか? それは私が修正します!」と言うかもしれません。
エンジニアの場合、上司を喜ばせるためだけに非現実的なスケジュールで妥協しないでください。予定時間と変更については率直に伝えるほうが、よりプロフェッショナルです。
他の人にとって、予定時間を遵守することは難しく、プロセスが必要です。推定時間を短縮するには、時間を短縮するようしつこく要求するのではなく、実際にリリースする必要のない機能やフェーズをじっくりと削減することによってのみ可能です。
プロジェクトにかかる時間を完全に見積もることはできません。そのための唯一の方法は、オープンで、コミュニケーションを取り、共感を持ち、断固として優先順位を付けることです。
