問題点の切り分け。

問題が発生した場合、解決をしなければなりません。・・・が、その前に必要なのが問題の適切な把握です。
一つの問題点が本当に一つの問題しか存在しないのであれば平気そうですが、たいていの場合、複数の問題が絡み合った上で発現します。

解決を考えるとき、最低でもその手順は頭の中なり裏紙の上なり、ホワイトボードなりに書くと思います。その時に書き出されたプロセスが、一つ目の問題点の切り分け基準です。

書き出したプロセス上のタスクそれぞれに、

• 実施するタスクの計画に不備はないか。
• 実施するタスクの結果を検証できるか。

という視点で検討を加える必要があります。
そして、

• 必要な全てのタスクが洗い出せたか。
• 並列で実施できないか。

という視点で、対処が問題なかったかどうかを検証します。

タスクに対する検討の視点は、「タスク実施前」と「タスク実施後」に焦点を絞りました。その後の２つは、タスクそのものの検証と、その実行計画に対して焦点を当てています。これだけで、慌てて問題に立ち向かうよりずっと整理された計画的な手順になります。

さらに、タスクそれぞれが必要とする技能が違う場合、プロジェクト・メンバーのスキルも視野に入れて適切なアサインを行えば、並列でタスクを消化していくことが出来ます。

もしその問題に直面した際の立場が、プロジェクト・マネージャやプロジェクト・リーダーだった場合は、タスクごとに適した人材をアサインする権限を持っているでしょうから、アサインのみ決め、取り纏めに専念する事が出来るかも知れません。
その時の立場がエンジニアであったら、時間に余裕がある場合、自分の苦手な分野を克服する為に専門外のタスクを担当したいとリーダーやマネージャに打ち明けられます。時間的に厳しい状態であれば、自分の苦手な分野をもっと効率よくこなせる人にアサインしなおせないか、調整することが出来ます。後者の場合、一見他人に迷惑をかけているように見えますが、一人で調べて、悩んで、やってみたら駄目でした、または間に合いませんでした、って結果が一番メンバーに迷惑をかけますから、問題視すべきではないでしょう。（全てに対して消極的過ぎても困りますけど）

タスクとリソースの配分をきちんとやりくりして、効率的にタスクをこなしていくチームにするには、タスクそのものを的確に把握することと、タスクに対して適材適所にメンバーをアサインしていくことが不可欠だと思います。