サポートの問題を考慮しながら、どのようにプロジェクトを現実的に計画できますか？

仕事で問題が発生しています。タイムスケールを評価し、期限を取得できるように、仕事をスケジュールしようとしています。

問題は、これから起こることをすべて知らずにプロジェクトを計画することが難しいことです。

たとえば、今は12月の初めまですべてのプロジェクトを計画していますが、その間にさまざまな社内および外部の会議、電話会議、余分な仕事があります。プロジェクトには3週間かかると言ってもいいですが、その間に1週間分の中断がある場合、完了日は1週間延期されます。

問題は3つあります。

1. プロジェクトをスケジュールするとき、時間スケールは文字通りに取られます。3週間と見積もった場合、期限は3週間に設定され、クライアントに通知され、延長の余地はありません。

2. 中間作業などは、プロジェクトに取り組む生産的な時間を失うことを意味します。

3. 仕事をするのに必要な時間がないクライアントもいるので、仕事に2か月かかると思っても、月末にプロジェクトを完了する必要があると言うことがあります。 -言うまでもなく、すでにやるべき仕事があります。

ガントチャートを使用して、所有しているすべてのプロジェクトとタイムシートに記入しようとしていますが、ガントチャートとはまったく比較されていません。このため、「まあ、このプロジェクトに3週間を予定していましたが、ここで1週間遅れているので、期限を1週間遅らせる必要があります。」

また、クライアントに伝えた期限を逃すことは専門的ではありません。

他の人はこのような状況にどのように対処しますか？プロジェクトの計画をどのように管理しますか？プロジェクト中に発生する非プロジェクト作業を考慮して、プロジェクトにどのくらいの「余分な」時間をスケジュールしますか？サポートの問題やバグなどにどのように対処しますか？計画中に説明できないことはありますか？

更新

たくさんの良い回答ありがとうございます。

問題は、起こることをすべて知らずにプロジェクトを計画することが難しいことです。

それがリスク管理のポイントです。すべてを知ることはできないので、知っていることに基づいて計画を立て、計画に最も影響を与える可能性があるものと、それらが発生する可能性を特定します。Xが発生した場合、推定（キーワード-推定）Y日または数週間だけスケジュールがずれるということで、スケジュールの潜在的な影響も評価します。

プロジェクトは3週間かかると言って、それは非常に良いことです。

そのような特定の推定値を与えないでください。範囲を指定するか、その推定値に達する確率を定量化します。たとえば、「このプロジェクトには2〜5週間かかります」または「このプロジェクトは3週間で85％の確率で、4週間で95％の確率で完了する」と言います。

締め切りに間に合わなかったと言い続けることは、クライアントにとっても専門的ではありません。

本当です。ただし、「見積もり」、「スケジュール」、および「期限」の概念が混在しています。推定値は、特定のタスクまたはプロジェクトを完了するのにかかる時間の概算と、それを満たす確率です。期限は、付加価値を得るためにプロジェクトを実施する必要がある顧客が課した日付です。スケジュールは、利用可能なリソースを使用して期限を満たす方法です。

割り当てられた作業を期限内に完了することが単に不可能な場合があり、世界のすべての推定とスケジューリングが違いを生むことはありません。

だから私の質問...他の人はどうやってこれをしますか？プロジェクトの計画をどのように管理しますか？その間に起こることを考慮して、プロジェクトにどれくらいの「余分な」時間をスケジュールしますか？

Steve McConnellによる2冊の本を読むことをお勧めします。両方とも、Steve McConnellによるものです。SoftwareEvaluation：Demystifying the Black ArtとRapid Development：Taming Wild Software Schedulesです。ソフトウェアの見積もりとは、見積もりを導き出し、クライアントに提示することと、交渉のいくつかの側面と非現実的な期待に対処することです。迅速な開発とは、一般的なプロジェクト管理であり、開発ライフサイクル、スケジューリング、リソース割り当て、およびプロジェクトのスケジュールと予算を最適に設定して見積りと期限を守る方法を扱います。

スクラム開発プロセスの詳細を掘り下げることをお勧めします。このようなサイドトラッキングアクティビティは、focus factorメトリックによってカバーされます。基本的に、2〜3回のスプリント/イテレーションを行い、チームのフォーカス係数を測定する必要があります（各メンバーにとっても役立ちます）。この後、あなたは毎日の活動をカバーするより正確な推定値を提供できるでしょう。

この記事をご覧ください- 「フォーカスファクター」

アジャイル開発に精通している人なら、おそらくフォーカスファクター（または生産性ファクター）について聞いたことがあるでしょう。これは、何かに取り組む必要がある「実時間」の数を決定するための計画に使用されます。「実際の時間」と「理想的な時間」の違いです。

中断に関することは、特定の個人またはチームでは、比較的小さな範囲の確率で発生する傾向があるということです。たとえば、毎週ほぼ同じ数のミーティング、毎月緊急のバグ修正に費やした時間とほぼ同じ時間、または特に平均以上の時間でデスクに立ち寄った人の質問に答えるのに同じ時間長期間。

多くの最新のスケジューリング技術はそれを考慮に入れています。スクラムはそれを速度に因数分解します。エビデンスに基づくスケジューリングでは、特定の推定値に対して信頼区間を持つ速度も使用します。Pomodoroは、特定の週に完了することができる「pomodoro」の数を決定するときに、中断を考慮します。これらはすべて、中断の履歴測定値を追跡し、それらを何らかの形で推定値に組み込むことに依存しています。それらすべてを見て、チームに役立つテクニックを考案することをお勧めします。

すべての周りの良いアドバイス。

サポートの問題に対処するのに役立つもう1つのことは、固定された「ラウンドロビン」ベースでサポートするために人々を捧げることです。

たとえば、5人の開発者が週の各曜日に1人を割り当てている場合。その日が来ると、割り当てられた開発者はサポートのみでその日のために働きます。翌日、別の開発者がサポートを引き継ぎます。このようにして、誰もが「フロー」にとどまるチャンスを持ち、誰もがドッグフードの味を味わうことができます。

通常のサポート作業を実際にどのように分割するかは重要ではありません（曜日のラウンドロビンは単なる例です）。重要なのは、サポート時間を一定の定期的な間隔に制限することです。これにより、サポートの問題に対処するために「誰もがすべてを落とす」ことができないというトレードオフにより、開発時間がより予測可能になります。

これは実際に経験を積んだスキルであり、多くの場合、人々はそのようなことを正確に判断する前に尋ねられます。私はいつも非公式のスタイルで結構結ばれたグループで働いてきましたが、うまくいくように見えるいくつかの経験則を開発しました。

まず、タスクは1週間もかかりません。タスクが完了するまでに数日かかると思われる場合でも、常に数週間で見積もります。週の終わりまでに行われない何らかの理由があります。

次に、中断、カスタマーサポートの問題、テストの実施など、タスクにかかる時間を見積もるのに最善を尽くします。次に、その数を2倍にします。それはあなたの見積もりです（週単位）。

第三に、あなたのマネージャーがあなたの見積りにパディングを追加していないことを確認してください。私たちのチームは私たちの見積もりについてマネージャーに不満を言っていました。彼はすでに2.1（彼の経験的に導き出されたパディング推定値）を掛けるつもりだったことが判明し、私たちは彼に伝える前にすでにそれを倍増していた。

それは派手なツールではなく、完璧な方法ではないかもしれませんが、驚くほどうまく機能します。

推定の必要性をしている人たちにはチームがされていないことを理解することが、これまでのプロジェクトに100％。病気休暇、休暇、ju審義務、死別休暇、必要な人事会議（ベネフィットタイムです！）、プロジェクトに関連しないチーム会議、やむを得ない遅延、トイレ休憩、既に生産中のアイテムのサポート、メールの処理、 、古いコンピューターが死んだ後に新しいコンピューターを構成し、将来の仕事に関する質問に答え、その仕事の見積もりを行い、考慮に入れる必要があるジュニアなどを指導します。推定者が8時間のうち6時間以上を引き受けることは無責任です1日あたり利用可能。これは、期限に間に合わないという保証です。期限に間に合わないことを保証している場合、不幸な顧客を保証しています。

あなたは絶対に正しいです-これから起こることをすべて知らずにプロジェクトを計画することは困難です。しかし、あなたが予見するタスクだけでなく、標準的なものを追跡することは非常に重要です。ここで、スケジュール管理が役割を果たします。私はMicrosoftプロジェクト管理（標準バージョン）を使用していますが、これにはプロジェクト管理スケジューリングソフトウェアの一部である機能も含まれています。

あなたは訪問することができhttp://www.microsoft.com/project/en/us/schedule-management.aspxの詳細については。

プロジェクトチームから多くの隠れた努力が引き出されているようです。実際に処理するタスクを分離することは有益かもしれません

..サポートの問題とバグとか？

他のチームメンバーが新しい開発タスクに集中できるように、特定のグループの人々に。これにより、全体の生産量は少し低下する可能性がありますが、注意散漫が少ないため品質は向上します。これは見返りにバグの数を減らすので、それがあなたのプロジェクトへの道になります。

計画の部分については、トーマス・オーウェンズの答えに完全に同意します。