複数の1人のプロジェクトでマルチタスクを行う必要がある場合、どのように管理/整理しますか？
私たちは、複数の小さなプロジェクトに取り組んでいる開発者のチームです。開発者は、3人以上の1人のプロジェクトで作業を続け、動き続けることができます。あなたの時間はかなり断片化されていて、プロジェクト間の移動が中断されているように感じることがあります。時々イライラし、ストレスがたまり、圧倒的。理想的な世界では、これはそうではありませんが、非常に一般的であるように見えます。それが避けられないセットアップにいるとき、どうやってそれを最大限に活用しますか？
特にマルチタスク環境での生産性の向上とストレスの軽減に役立つアイデア/ヒント/方法を探しています。 DOおよびDO N'Tなど。どのような境界、制限を設定する必要がありますか？どの開発方法論が機能し、機能しませんか？何が効果的か知っていますか？
この種の環境を最大限に生産的にするための適切な方法はありますか？
プロジェクトの期限、経営陣への可視性、ビジネスへの影響など、考慮すべき要素は多数あります。
一般的には、私はいくつかのルールを使用して効果的に作業しました：
- 機能/バグで分類すると、タスクと呼ばれます。これは、プロジェクトからプロジェクトへのホッピングのため、何らかのタスク追跡メカニズムを使用していることを意味しますmust。コンテキストスイッチのオーバーヘッドをできるだけ最小限に抑えるために、プロジェクトに着手したらすぐに、どこにいてどこに行くのかを知る必要があります。
- もちろん、プロジェクトごとに優先順位に従ってタスクを実行してください。
- タスクを完了まで実行します。プロジェクトAの優先度1のタスクでは、通常、プロジェクトごとに割り当てるよりも時間がかかる場合でも、とにかく実行してください。プロジェクトに早く戻った場合は、プロジェクトに戻ったときに何をしようとしていたのかを考え直す必要があります。
- 管理者から割り当てられたタスクがある場合は、優先度キューを作成して使用可能にします。それが単なるホワイトボードの場合は、与えられたすべてのタスクが山の底に行くことを経営陣に伝えます。彼らがそれを一番上にしたいのであれば、彼らは先制/中断しているタスクを見る必要があります。
- プロジェクトごとに一般的な時間を割り当てます。それが1日、半日、1週間の場合は、環境にとって意味のあるものは何でも、それに固執するようにしてください（上記のようにタスクを完了することを除いて）。プロジェクトAの午前中に2つのタスクを実行できる場合は、それを実行します。プロジェクトを分割しすぎないでください。以前と同様に、プロジェクトBのタスクが与えられ、現在プロジェクトAにいる場合、次のように言うことができます。「すばらしい。私は明日の朝にプロジェクトBにいます。最初に見ていきます朝のこと」
- 同じプロジェクトを続けて行う場合でも、1つのプロジェクトに割り当てる2つのワークセッション（プロジェクトで作業する期間）があることを頭に入れておいてください。
- 効果的な区切り記号を使用してセッションを分割します：1日の終わり、昼食、休憩。あなたの心が100％機能しなくなるところ。コンテキストの切り替えは自然なものであり、プロジェクトを切り替えなかった場合でも、とにかく行う必要があります。
目標は、奇抜な量の作業/プロジェクトを管理するための明確に定義されたスケジュールを作成することです。次のようなスケジュールを守る場合：
Mon Tues Wed Thurs Fri
Morn A B A B A
Aft A C C C C
...その後、メトリックはより正確で予測可能になります。開発/配信日にバーンダウンチャートを使用している場合、より正確で予測可能になります。特定のマネージャー、QA、他の開発者、ソフトウェア/ハードウェアリソースなどの利用可能性を考慮したスケジュールの作成には時間がかかる場合がありますが、一度停止すると、通常どおりのビジネスになり、取得できません。とても動揺。
私の最初の反応は、チームがある場合、なぜあなたがそうでないように働いているのですか？
確かに理由があるかもしれませんが、それが述べられているかどうかはわかりません。
制限要因
私の提案は、できるだけ多くの製品をできるだけ早く、可能な限り最大の利益率で売り込むように作業を編成することです。これをどのように行うかは、ビジネスモデルや、実行できることを制限する要因など、さまざまな要因によって異なります。
- 応答性：完了するまで1つのプロジェクトを実行できますか？それとも、各プロジェクトの利害関係者と時間を費やして、彼らのニーズに応えていることを示す必要があるのでしょうか。
- フォーカス：作業に集中する時間のブロックがある場合にのみ、タスクを最大速度まで加速できます。
- コミュニケーション/コンサルテーション：早い段階で頻繁にコミュニケーションをとる必要がありますか？おそらく意思決定について相談し、それによって作業に遅延を導入する必要がありますか？このカテゴリのニーズを満たすために、プロトタイプとプロジェクト間のラウンドロビン切り替えを使用するために最低限必要なことは何ですか？
- 分業：一人で何種類もの仕事をしていますか？プロジェクトを分割して、同じ種類の反復作業を、専門知識をより速く構築する人がそれをより多く行うことで、より速く行うことができるようにできるでしょうか？
- 資本/キャッシュフロー：マイルストーンに到達したとき、または時間と資材のために、最後に支払われますか？複数のプロジェクトを並行して処理すると、複数の支払いが発生したり、シリーズで完了する可能性のあるプロジェクトが遅れたりしますか？
- 競争：当社の製品の市場は、競合他社の数が少ないため、早期参入により売り上げが増加するようなものですか？
- 採用：早く着手した場合、市場で製品を採用し始めるまで、市場が未熟すぎて強力な売上を上げることができないでしょうか？他の誰かが開拓者になるのを待つ利点はありますか？
- 収益の流れ：完了時に一度支払われますか、それともプロジェクトを完了すると、製品の一定量または増加量での販売が許可されますか？製品が配備された後、お客様が当社に支払うメンテナンスまたはサブスクリプション料金はありますか？
いくつかの仮説的なシナリオ
時間と材料を請求するが、最後にしか支払われない場合、制限要因はプロジェクト期間です。 4つのプロジェクトがある場合、全員に1つずつ割り当て、各ジョブを最短から最長まで順番に実行します。あなたは、最初の仕事から利益を得て、2番目の仕事のために借りたリソースを減らすか、より多くの助けを借りて2番目の仕事をより早く終わらせることができます。
一度完成した製品が毎月一定または増加する売り上げを持つ市場を生み出す場合、プロジェクトが完了するたびに複合収益が増加します。厳密なラウンドロビンアプローチを採用する場合、これはすぐにではなく後で発生します。
最長のジョブを優先すると、他のすべてのジョブが待機し、小さなジョブが最長のデュレーションを持ち始めます。これは、これらの顧客の目には特に問題です。
あなたが最初に市場に出すことで利益を重視して何かを販売している場合、あなたは何かを早く犠牲にする余裕があります。
最優先で作業する場合は、1人の顧客が満足し、残りの顧客が不満または他の場所に行く可能性があります。
素朴な例
何年も前に、私は4人のソフトウェア開発者のそれぞれが通常9か月から12か月かかる独自のプロジェクトのリーダーとして働くことが効率的で力があると考えられていた会社で働いていました。これは数年続いたので、同じように組織する人を数人増やしました。次に、より大きなプロジェクトがあり、代わりに4人のチームを作りました。チームと一緒に、はるかに大きなプロジェクトに取り組み、約12か月後にリリースされたとき、会社の歴史の中で最高の年を迎えました。
その後すぐに、同僚と私は、1人1年に1つのプロジェクトをやめた場合、将来のプロジェクトで収益が増える可能性があるという考えについて話しました。ここにスケッチがあります：
Method 1: Project per developer
Four developers, four projects of 12 months duration, that sell 500K/quarter.
Project 1 Project 2 Project 3 Project 4 Total
Q1:
Labor (man months): 3 3 3 3 12
Net Income: 0 0 0 0 0
Q2:
Labor (man months): 3 3 3 3 12
Net Income: 0 0 0 0 0
Q3:
Labor (man months): 3 3 3 3 12
Net Income: 0 0 0 0 0
Q4:
Labor (man months): 3 3 3 3 12
Net Income: 0 0 0 0 0
Q5:
Labor (man months): 0 0 0 0 0
Net Income: 500K 500K 500K 500K 2000K
Y1 Income: $0
Total Income for 15 months: $2000K
Method 2: Four developers working as a team.
Four developers, four projects of 12 months duration, that sell 500K/quarter.
Project 1 Project 2 Project 3 Project 4 Total
Q1:
Labor (man months): 12 0 0 0 12
Net Income: 0 0 0 0 0
Q2:
Labor (man months): 0 12 0 0 12
Net Income: 500K 0 0 0 500K
Q3:
Labor (man months): 0 0 12 0 12
Net Income: 500K 500K 0 0 1000
Q4:
Labor (man months): 3 3 3 3 12
Net Income: 500K 500K 500K 0 1500K
Q5:
Labor (man months): 0 0 0 0 0
Net Income: 500K 500K 500K 500K 2000K
Y1 Income: $3000
Total Income for 15 months: $5000K
この例は、実際の作業環境よりも簡単です。しかし、うまくいけば、私たちがマルチタスクを行っている場合、単一の焦点やチームワークと比較して、報酬を遅らせたり減らしたりしていることを示しています。
SnOrfusが提案することは、規律のある場合、小規模で明確に定義されたプロジェクトでうまく機能します。より大規模で探索的なプロジェクトでは、プログラマーのマルチタスク処理は主に管理の神話です。ジョエル・スポルスキーは言います 人々が一度に複数のものに取り組むことを決して許さない 。プロジェクトを頻繁に切り替えるほど、達成度は低くなります。
私には「マルチタスク」だと主張する上司がいました。私の戦略は、常にプロジェクト全体に優先順位を付け、最優先事項を最初に実行し、単一のプロジェクトをできるだけ長く使用することでした。進行状況のレポートをずらして、前後に切り替えているように見せることができるように、1つのことについて進行状況のレポートを保留することもありました。それから私は嘘をつき、「はい」と言います。私はマルチタスクでした。時には、最初に本当にすばやいプロジェクトをすべて実行できるので、長いプロジェクトに集中できます（そして、長いプロジェクトに集中しながら毎日短いプロジェクトを報告する）。私は常にこの方法で非常に生産的でした、そして、私の上司は（少し誤解されたとしても）とても幸せでした。記録のために、私は彼と最初に推論を試みました、そしてそれが失敗したときだけ嘘をつきました。
このルールの1つの例外は、テクニカルサポートリクエストの処理の中断です。プログラマにとって、顧客のニーズを深く理解することほど重要なことはありません。その理解の利点は、（合理的な範囲内で）集中力を破るコストに見合う価値があります。
幸運を！