すべての人に良い新年を！
記事Businessに触発されて、私はあなたの Verovirの同僚と彼女自身の記事が大好きです 。 レイオフについての毎晩の話 （後者については個別の詳細な回答に値するが）。
同僚、あなたはこの記事で、IT（だけでなく）ビジネスで満たすことができる重要な問題点をよく特定しています。
しかし、これらの各ポイントに対する客観的な評価と推奨事項（「実際に何が起こったのか、何をすべきか」）は議論の余地のある問題です。
//ちなみに、以前の記事でも同じことが言えます
たとえば。
あなたはチームのリードを簡単に散らし、カリフォルニアに去ったVMKの卒業生について話しました、そして、痕跡は失われます。
これは、ソビエト時代のよく知られた物語であり、工場は単位時間あたりいくつかの規範を作った熱烈な卒業生を好まなかった。
「今日は偉業であり、明日は計画である」ため、彼らはそれを好まなかった。
明日、この卒業生はカリフォルニアに向けて出発するか、家族と住宅ローンに成長し、彼のために解雇したのと同じ非マウスキャッチのチームリーダーになります。
あなたは熊手を踏んだが、額に打撃を感じなかった。
これは、それらのチームリーダーの本当の品質とは関係ありません（解雇があなたの間違いであるか、VMKの卒業生とは関係なく解雇される必要があるかによって異なります）。
あなたはビジネスについて書いていますが、ビジネスは、バスの要因が高く、単一のタスクでの衝撃の悪用だけではありません。
ビジネスとは、ゆっくりと動いているチーム（はい、あなたのようなチームリーダー、幼稚園の子供を連れ去りたいと思っている従業員など）によって大規模なタスクを解決することです。砕氷船のように、その経路内のすべてを不可逆的にスイープし、高い確率で計画された結果に到達します。
この問題を研究した私の同僚によると、5人のやる気のある天才ロックスターのチームはN時間で、5人のチームは3xNで行います。
そして、この評価は私には十分なようです。
価格の合計上昇は約15xNになることに注意してください- 5つの給与を支払うだけでなく、3倍の給与を支払う必要があります。 そして、それは他の費用を数えていません-より大きなオフィス、より多くのコンピューターと他の費用。
しかし、これはチームです。 適切に管理すれば、計画された結果に到達することが保証されます。
そして、 ビジネスについて話している場合、チームは、量と規模の点でタスクを処理できます。
別の例。 同僚のOlegGelezcov は 、あなたの記事は「 ロウズには何の価値もない」というシリーズのものであるとよく述べています（ところで、以前の記事は同じステップにあります）。
つまり、ほとんどの場合、「あなたがどのように扱われようとも、自分自身を一掃し、結論を導き、先へ進む」と書きます。
rowぎ手について話しましょう
どうやら、私たちは開発者（プログラマー）について、そして部分的にQAエンジニアについて話している
最近、開発者をrowぎ手だけでなく、機械の労働者とも比較することが流行しています。
これが本当かどうか見てみましょう。
そもそも、開発者はエンジニアであり、労働者は最も熟練した労働者でさえも労働者です。
そして、これは根本的な違いであり、180度の違いまで、他のすべてがそれに続きます。
開発者はテスター、アナリスト、PMを置き換えることができますか？
テスターは簡単です。
コードのテストケースを作成し、すべてをクリックして自動テストを作成します。
さらに、開発者はまだ単体テストと統合テストを作成しています。
はい、それは少し悪くなります、なぜなら 作成者は目をつぶってコードをテストします（ただし、別の開発者に渡すこともできます）。
分析-簡単ではないにしても、難しくはありません。
開発者のトレーニングコースの一部は、対象分野、問題の記述、およびモデリングに関する調査のみです。 そして今、今日の流行遅れのOOPはまさに「これ」についてです。
PM'a？ まあ、開発者が多かれ少なかれ「上から」タスクを見ることができ、多かれ少なかれ社交的で、一般的に頭と友達であれば、経験がなければ、困難で、品質は低下しますが、彼はできます。
逆の交換は可能ですか？ 特に、私たちが自分自身に正直で、テスター、アナリスト、PMが、プログラミングを率直に「引っ張っていない」主に工業大学の卒業生であると認識している場合（そして最近、人々はまったく「ITに参入」するようになりました）政党、そしてそれはまさにこれらの立場にあります;例外は開発に入ってきます））？
テスター-困難を伴いますが、ほとんどの場合、ジュニアポジションから学習言語と開発プラットフォーム、開発パターン（テストではなく）、コンピューターサイエンス全体、思考のパラダイムを変更しますが、それは可能です。
言い換えれば、彼はすべてではありませんが、非常に大きな困難と費用がかかります。
アナリスト？ 工学教育と仕事の背景がある場合、おそらく可能ですが、テスターよりも確率は低くなります。
なぜなら、強力なアナリスト（そして実際には「アナリスト」ではなくアナリスト）の例外を除いて、開発をマスターしていない人はいわゆるアナリストに行くからです。
そして、開発には特定の心理的構成が必要であるという事実（内向性、忍耐力、高濃度;はい、今では逆に多動性が要求されるように業界を作り直す試みがありますが、私たちはこの問題も議論しています）アナリストは「この意味で、明らかにテスターよりも開発者から遠い。
一般に、 分析の概念は、現代の開発プロセスで「分析」と呼ばれた役割に関するものではありません。
つまり、yesではなくnoです。
PM？ sayingにもあるように、「説明する時間はありません。」 高い確率で、いいえ、例外はほとんどありません。
そして、テスターやアナリストからではなく開発者からPM /ラインマネージャーを意図的に正確に成長させたときに、システムについて話していなければ。
しかし、工場と労働者の場合、状況はむしろ鏡のようなものです。
概して、監督、会計士、マーケティング担当者を3か月のコースに派遣すると、少なくとも、初級のターナー、溶接機、錠前屋を交換することができます。
しかし、労働者は3か月のコースの後にこれらの役割を置き換えることができますか？
おそらく、高度に熟練した労働者は、コースの後に会計士（メインではない）を交換し、借方を借金を減らし、口座間で資金と資金を転送することができます（彼にとって興味深いかどうかは別の質問です）。
ディレクター、マーケティング担当者など？ 明示的な例外について言わない限り、これは明らかに困難です。
どちらかといえば、上記のさまざまな職業や役割についての議論は、誰かを他の人よりも昇格させるためではなく、その逆も同様です。
これは、生産プロセスに特定の役割があるという事実と、各役割の客観的価値に関するものです。 （非）他の役割の代表者による交換可能性。
これは、近年のこれらすべてのファッショナブルな話が「ロウアー」、「マシンの開発者」について語られているという事実です-これは開発者の役割を軽視するための体系的な試みです。
他のすべてのものが流れるものの性質があるため、このトピックを移動する人は最終的に成功しません。 開発者はエンジニアであり、workerぎ手や労働者ではありません（後者を尊重します）。
そして遅かれ早かれ、すべてが正常に戻るか、別の方法では機能しないか、または全員がQA、アナリスト、PMに出て、誰も開発者に行きたくないときにすべてが壊れます（そして誰もいないでしょう） ）