プログラマーが複数のプロジェクトに同時に取り組むのは普通ですか
現在の仕事では、2つのプロジェクトに取り組んでいます。 1つ目は非常に巨大なシステムで、2つ目は小規模ですがそれも大きいです（最初のプロジェクトは12年間、2年目は4年間開発されています）。
最初は最初のプロジェクトだけに取り組んでいて、それに慣れるように努めていました。それから私は2番目のプロジェクトに移ってそこで試してみたので、最初のプロジェクトについての私の知識は疑わしくなりました。今、私は両方のプロジェクトに同時に取り組む必要があります。
どちらもJavaを使用しているにもかかわらず、異なるフレームワークを使用しており、理解するコードとビジネスロジックの量が非常に多いため、両方のプロジェクトを頭に抱えることはできません。
それは正常で、慣れる必要がありますが、専門知識が非常に低くなりましたが、単一のプロジェクトでのみ作業するとどうなりますか？それとも、懸念を提起すべきでしょうか、それとも雇用主を変更すべきでしょうか？
「はい、マルチタスクは正常です」と人々が言ったとき、私は完全に同意しません
それはではない正常です！開発者が複数のプロジェクトでマルチタスクを実行するのは非常に不自然です（後で詳しく説明します）。一方、マルチタスクは開発者の間で非常にcommonです。これは間違いなくあなたが慣れるべきものです。だからあなたの質問への本当の答えは：マルチタスクする方法？
まず第一に、「あなたはとても優れた従業員」であり、それはあなたが処理できるよりも多くのタスクをとる必要があることを意味するので、あなたは単に運命を受け入れるべきではありません。まったくそうではありません。他の人がいないために、人は複数のタスクを与えられることがあります。 theyがプロジェクトスケジュールを適切に処理できないため、マネージャーは仕事を処理できないため、委任し、チームにマルチタスクを強制します。したがって、それがあなたの仕事の一部であるので、または他の人々が無能であるので、マルチタスクを求められているかどうかを確実に判断する必要があります。どちらの方法でも、それが許容できるかどうかを自分で判断できます。 [仕事に慣れていない]場合は、仕事を探すために他の場所に行くことができます。 [開発者であるあなたが商品です。雇用主はこれを知っており、あなたがそれを決して実現しないことを祈ります。
マルチタスクについて、「はい、前後に切り替えて、各プロジェクトで同じ量を実行していることを確認してください」と人々が言ったとき、私は100％同意しません。 申し訳ありませんが、それは非常に悪いアドバイスです。
最初に、ソフトウェアを開発しているときに脳がどのように機能するかを理解する必要があります（他のタスクが含まれていることはわかっていますが、そのタスクに焦点を当てましょう）。最初に「ワイヤード」にする必要があります。つまり、多くのことに集中し、すべてを頭の中でマッピングした位置に頭を動かす必要があります。すべての変数名とメソッド名、コードのワークフロー、オブジェクトモデル、並列するスレッドなどすべて。通常、「ゾーン内」に到達するには15分、おそらく20分かかります。
その状態に到達すると、実際に自転車に乗っているような気分でコードを書いています。中断された瞬間、すべてを失う可能性があります。中断が十分に長い場合（5、10多分30分）、その精神状態を失い、最初からやり直す必要があります。
したがって、マルチタスクは「ゾーン」を離れて別の場所に移動することを強制するため、ひどいものです。常に切り替えている場合は、新しいタスク/プロジェクトに変更するたびに、ゾーンに再び入るために15〜20分を失う必要があるため、生産的ではありません（脳がゆっくりと溶けるとは言いません）。
これはマルチスレッドのようなものです。ある時点で、カップルサイクルごとにスレッドコンテキストを切り替えるコストが高すぎるため、CPUは実際のタスクを実行するよりもコンテキストの切り替えに多くの時間を費やします。
この問題に関するJoel Spolskyの記事を読むことを強くお勧めします。
http://www.joelonsoftware.com/articles/fog0000000022.html
ですから、私のアドバイスは、マルチタスクの方法を学習することです。しかし、それが快適に行えることも確認してください。一部の人々は集中するのにより多くの時間を費やすことができ、マルチタスクを行うときに他の人よりも多く苦しむでしょう。それも大丈夫です。それが正常であると考えられるべきであることが一般的であるからではありません。
ジョエルは彼が言ったときそれをうまく言いました：
実際、これらすべてからの本当の教訓は、人々が一度に複数のものに取り組んではならないということです。彼らがそれが何かを知っていることを確認してください。優れたマネージャーは、自分の責任を障害を取り除いて、人々が1つのことに集中して本当にそれを成し遂げることができると考えています。
はい、それは予想されます。そして歓迎されます。
これを見るにはいくつかの方法があります：
あなたはマルチタスクを期待されており、集中することはほとんど不可能です。その結果、エンジニアリングプロセスが最適化されず、切り替えの際に時々混乱が生じ、悪用される感覚、欲求不満、ストレスなどが生じます。もちろん、これはすべて否定的です。しかしながら、
あなたは複数のプロジェクトで信頼されています。これは、あなたが生み出した結果と雇用主があなたの能力に持っている信頼をよく反映しています。それは彼らに信頼が保証されていることを示す機会です。
私のアドバイスは冷静な判断を育てるすぐに注意を必要とするタスクと待つことができるタスクのことです。時々答えはどちらも待つことができず、結果を提供するために創造的なアプローチを取る必要があるということです（プロジェクトAに少し、プロジェクトBに少し、そしてすすぎ、繰り返し）。このような状況で成功するためのスキルを養います。
通常（常にではありませんが）、これにはより多くの責任、より多くのプロジェクト、そしてより多くの期待が報われます。ある時点で、この作業の一部を委任できるようになり、期待できるようになります。 それは成功の尺度です。
だから、あなたの成長するジャグリングスキルがあなたの現在の会社によってのみ利用されているとしても、これらは持つのに良いスキルであり、あなたのキャリアにおいてあなたに役立つでしょう。
価値があることについては、私は通常、主要なプロジェクト、小規模なプロジェクト、古いプロジェクトのメンテナンスとサポート、および少なくとも1つの他のプロジェクトに取り組んでいます。それはイライラし、混乱し、面倒であり、そして私は非常に感謝しています。
はい！サービス会社xDで作業する場合、これは完全に「通常」/通常です
また、オープンソースプロジェクトとコラボレーションする場合、それがルールです
多分、理想的な状態ではないかもしれませんが、毎日のパンです。
それは一般的です。しかし、あなたが概説した理由から、それは良くありません。コンテキストを切り替えると生産性が低下するため、可能であれば、1つのプロジェクトで長い時間をかけて作業してください。日。
私は毎日2〜3種類のプロジェクトに積極的に取り組んでいます。そして、さらに数十を維持します。数週間は少し圧倒されます。いくつかのプロジェクトは巨大で、いくつかは非常に小さいため、数日でコーディングされ、めったに変更を必要としません。状況はさまざまですが、さまざまな考え方、問題の解決方法、さまざまなテクノロジー、ビジネス分野にさらされています。楽しいです。
だから、あなたの質問に答えるために、はい、それは非常に一般的です。
Multitasking Gets You There There と呼ばれる記事をご覧ください。このグラフは物語を伝えます：
言い換えれば、同社はプログラマーが一度に複数のプロジェクトに取り組むことで時間を浪費しています。たった3つのプロジェクトで、無駄は40％です！残りの時間は3つのプロジェクトに分割されます。
マルチタスクの理由は、「より多くのことを成し遂げる」としばしば言われます。しかし、それは誤った推論です。マルチタスクを実行しても、すべてのリリースが遅延するだけです。この画像は、デュアルタスクの効果と、一度に1つのプロジェクトを完了する効果を示しています。
（画像はオーバーヘッドを完全に無視しています。実際には、無駄な時間は両方のプロジェクトを20％遅くするでしょう。）
はい、私の経験では正常です（同じプロジェクトのメンテナンスプロジェクトや機能プロジェクトなど、一部の「プロジェクト」が非常に類似している場合でも）。競合や非現実的な期待を回避するには、プロジェクトマネージャーとマネージャーに同意して、時間の特定の割合を各プロジェクトに割り当てます（例：プロジェクトXに3日間、プロジェクトYに2週間）。通常は、これらの割り当てを好きなように配分できます。 Xは月〜水、Yは木〜金。
1つのプロジェクトが「例外をスロー」し、今で作業する必要がある場合があります。ここで行うことは2つあります。
- それが単なる強引なプロジェクトマネージャーではなく、本当に例外であることを確認してください。後者の場合はプッシュバックしてください。
- 時間の割り当てを入れ替えて、各プロジェクトで同じ割合で作業できるようにします。
それは会社に依存します。 IMOは主に1つのプロジェクトのみで作業することが望ましいですが、それは、特に小規模な企業では不可能であることがよくあります。
もちろん、バグ修正などはいつでもどのプロジェクトでも起こり得ます。
プロジェクトのフレームワークやビジネスロジックに戻ったときに、その速度に戻るのが難しいと感じた場合は、作業中にできるだけ多くのドキュメントを書く機会を得るべきです。複雑なシステムがどのように機能するかを自分の言葉で詳しく説明すると、後でプロジェクトに戻るのがはるかに簡単になります。さらに、このドキュメントは同僚が支援する必要がある場合に役立ちます。
プロジェクトにすでに技術文書が十分に網羅されている場合でも、複雑な領域に取り組んでいるときに、考えを書き留めておくとよいでしょう。そうすれば、次に切り替えたときに、思考プロセスを理解できます。
まあそれは普通ではないはずですが、私は現在の雇用主の肩に多くのプロジェクトを抱えています。それは私が認めるのにいくらか慣れる必要があります。私が与えることができる最も重要なヒントは、常に作業に優先順位を付けることです。上司に優先課題を教えて、それだけに取り組みます。他のプロジェクトについて不平を言っている人からの圧力を与えないでください。必ずしも履歴書を更新する必要はありませんが、負荷が適切に処理できる範囲を超えてエスカレートしないようにしてください。
それは正常だと思います。現在の仕事のやり方（私は約40人の開発者がいる会社で、会社の合計サイズは約700です）。そして、私は通常、1つの「長期」プロジェクトを抱えており、多数の小さなチケット/欠陥が発生するため、通常、最終的に50％の小さなチケットと50％が長期プロジェクトに取り組みます。困難なのは、絶え間ない中断により、長期的なプロジェクトの速度が低下し、脱線する可能性があることです。
複数のプロジェクトに取り組むのは普通だと思います。重要なのは、最初にシステムの全体像に関していくつかのあいまいさに直面することを受け入れることです。
全体像を把握しようとすると、システム内の可動部分や固定部分を明確にし、変更がシステムにどのように影響するかを見つけることができます。
しばらくすると、作業しているさまざまなシステムの一般的なパターンを見つける方法を学びます。これらを他のプロジェクトに適用すると、一度に頭に残しておく必要がある詳細な情報の量を減らすことができます。
重要なプロジェクトには、複数の人が割り当てられています。これは、あなたが他の人と協力して、彼らが彼らの仕事をするのを待つ必要があること、そして彼らはあなたを待つ必要があることを意味します。
人々をアイドル状態にするのではなく、複数のプロジェクトをアクティブにして、必要に応じて常にオープンなタスクを実行できるようにするのが一般的です。
ただし、各プロジェクトのかなりの部分で作業する必要があります。そうすれば、「ゾーン内」になって生産性を高めることができます。