オフショアのバグ修正

将来の雇用主から「開発者はバグの修正が嫌いなため、バグ修正を外部委託している」と言われたら、どう思いますか？あなたの懸念は何ですか？

私たち自身のバグを修正することは、実際に私たちをより良い開発者にします。そして、それは私にとって非常に楽しい瞬間です。特に、うまく報告されている場合。

バグを修正したくない場合、問題は別の場所にあります。

問題は、経営陣がバグをどのように認識しているか、悪い設計決定やテストなし（ユニット）によってバグがどのように認識され、バグ修正が苦痛を引き起こしているのかと思われます。

バグ修正のアウトソーシングは、おそらく事態を悪化させるでしょう。

開発者は、品質を低下させようとするかもしれません。誰も気にしない？いくつかのオフショアの人が混乱をきれいにするためにそこにいます。

オフショアの人がオンショアの人を置き換えるまで。

出て行って、逃げて ...速く、決して振り返らないで

私はそのような会社で働いたことがあります

• ちょっと私たちはそれらすべてのバグを持っていますが、私たちの先輩はバグを修正するのに時間がかかりすぎると文句を言います。

• オフショアオフィスを開いて、他の人がこれを処理できるようにします。

本当に良い計画のように思えるマネージャーにとって、開発者はついに次の最高のものを作成するというより興味深いタスクに取り組むために解放されました!!

ホ...しかし、待って...

2年後、彼らは本社の5人の開発者チームから、新しいものを作成する2人のチームと、バグを見つけて修正する30人のチームに移りました。

バグ修正チームが苦労しているので、追いつくことができません。

これにより、「シニア」は彼ら自身の過ちのために完全に無知になりました。最悪なのは、それがすべて遠く離れた場所で起こったため、経営陣も気づかず、コードの品質がすでに最悪の品質レベルから非常に速く落ち込んだためです。

私が去ったとき、彼らはすでにバグ修正者のためにさらに2つのオフィスを開いており、それらを作成する現在の唯一の開発者に遅れずについていくことができません。彼らは実際には、新しい人たちが十分に頭が良くないからだと思っています...

だから、はい、これから、会社がバグ修正を海外のオフィスにアウトソースしたと言ったら、私を信じてください....私は...速く走ります。

これは、ペーパーバッグの管理方法です。

鉄道の上に立ち、電車が来るのを待って、それを見たら紙袋を頭にかぶせて... マジック ！

会社に他の人に代わって私の混乱を片付けてもらうことは、「きれいな」コードを取得して新しい機能を追加することが期待される場合を除いて、良いアイデアのように思えます。そして、彼らがそれを修正できないほどめちゃくちゃになったら、デバッグをデバッグすることになります。

追加の開発者を雇わなければならないため、適切に補償されないことは望ましくありません。

自分で修正できたときに他の開発者に教育するのに不釣り合いな時間を費やすことは逆効果です。

私の一部は、問題を作成する人がそれらを修正する人でなければならない、またはそもそもバグを作成することを避けるインセンティブがないように感じます。

開発者は自分の間違いから学ぶことに興味がありませんか？特定のドメインの知識がなくてもバグを修正できますか？また、アウトソーシングパートナーはこの知識を持っていますか？ほとんどの場合、固定部分が最も簡単で、時間のかかる分析部分です。私の観点から、それは愚かな決定です。

将来の雇用主から「開発者はバグの修正が嫌いなため、バグ修正を外部委託している」と言われたら、どう思いますか？あなたの懸念は何ですか？

私は遠く、遠く、遠くに走ります。開発者は常に、常に、常に自分のバグを修正する責任があります。ドッグフードを食べることは、優れたエンジニアリングの基本的な考え方です。

さらに、バグ修正は開発よりも重要です。つまり、開発とはコードの記述、テスト、デバッグ/修正です。

この会社から得たものは、彼らがバグ修正を二流のタスクとして扱っているということです。それ自体が非常に不安であり、私は彼らの仕事の質（そして、エルゴ、彼らの職場環境）に非常に疑問を抱いています。それはもっと気がかりです。明らかに、エンジニアリングプロセスには社会的階層化がenられています。

欠陥は常に変更の根本原因であり、通常、バグは変更を導入した人の責任です。バグの性質とその解決方法を理解するのに、発信者よりも優れているのは誰ですか？

世界中に委任されている場合、どのようにして元の著者がオフショアエンジニアに利用できるようにするのでしょうか。

彼は、バグや締め切りのバックログしか持っていないが、メトロポールからのサポートは何もないオフショアエンジニアを残して、対応することさえできるでしょうか？どんな種類のバグ修正が実行される可能性がありますか？誰が彼のバグを修正しますか？また、Metropoleの開発者が事後修正のバグ修正を介して学習するのを妨げるものは何ですか？

すべてのフィールドに嫌いな人がいます。これは特にソフトウェアに当てはまります。それは避けられないので、唯一の選択肢は、あなたよりも多くを知っているか、正しいことをしている嫌いな人と働くことです。この会社はその説明に当てはまらないようです。

要するに、逃げる。

彼らは本当に多くのオフショアジュニア開発者が多くの上級開発者コードを修正できると期待していますか？看護師にすべてのニューロリギストの仕事を二重にチェックさせ、ミスをした場所にやり直すようです。悪いアイデア！

従業員が開発しているコードを実際にどれだけよく知っているか心配です。
また、これがもたらす追加コストを正当化するのに十分なバグがある理由も疑問に思うでしょう。会社の長期的な将来についても心配します。これらの会社を主張し、同じ業界であっても複数のプロジェクトに同じコードを使用していると主張する記事がウェブ上にたくさんあります。

壊れたコードを修正することは、コードを書くプロセスの一部であり、6か月前に間違ったことをよりよく理解できるようにするため、同じ間違いをしないでください。何度も何度も起こるバグ？

これは、「前向きな雇用主」ビットを除いて、私の前の雇用主のように漠然と聞こえます。彼らは開発者を人員不足で失い、法規制の変更に必要な新機能を追加しながら、既存の製品をサポートするには多くを失いました（オフィスの収益の60％はVB6ベースの製品であり、MSはVB6ランタイム将来のオペレーティングシステムでは配布されないため、Vistaが登場したときのようになります。権力者はすぐに会社を公開したいので、彼らはバランスシートをより良く見せるためのリソースを誰もが飢えています-したがって、オフショアを雇うことが市場にとどまるための唯一の方法です。

私の経験に基づくと、引用文はあなたの将来の雇用主は安いということです。

「バグを修正する」という意味に依存します。これが開発/テストサイクル中にバグを修正している場合、それは非常に奇妙です。これは元の開発者の仕事です。一方、リリースされた製品のメンテナンスを外部委託していることを意味する場合、これは異常ではなく、私が心配することではありません。

私の経験では、事後の外部チームの参加は、自分のバグを修正するのと同じくらいの時間を費やします。バグをスピードアップして開発プロセスに持ち込む必要があります。そして、継続的に速度を維持しました。コーディネーションはコードを書くよりも難しいです。

コードベースで作業する場合、コミット権限を持つすべての人が適度な能力を持っていることを保証したいと思います。これには、インドのかなりの数の人々が含まれますが、通常はオフショアの人々は含まれません。

さらに、私のバグのほとんどはコードのより複雑なセクションにあり、それらはバグ修正を適用する前にオフショアプログラマーが理解する可能性が最も低いものです。

このポリシーは、実際には一部の企業では無意識のうちに存在します。私はアウトソーサーで働いています。私自身と同僚は、現場の人たちよりも熟練したプログラマーです。彼らはツールなどの使い方を教えてくれるように頼みますが、それとは反対に、コードの問題を彼らよりも早く見つけることができます。

一般に、クライアントのプログラマーは、少なくとも一部のユーザーと同じ建物に物理的に配置されているため、半球に届かないコンテキストを取得する可能性が高くなります。私たちにとって欠けているのは、彼らが私たちのコードをレビューしていないことです。そのため、契約が終了したときに、私たちの側の見掛け倒しの慣行ではなく、あなたが持っている通常の問題のために、いくつかの驚きや質問があります他の人のプロジェクトを引き継ぐ。

いずれにせよ、私たちの場合、それが公式のポリシーではないことを嬉しく思います。そのため、オンサイトのプログラマをBAにしかならなくなると思います。