私たち自身のバグを修正することは実際に私たちをより良い開発者にします。そして、それは私にとってかなり楽しい瞬間です。特にそれらがうまく報告されたとき。
彼らがバグを修正したくない場合、問題は別の場所にあります。
問題は、管理者がバグをどのように認識しているか、悪い設計上の決定や（単体）テストがないことによってバグがどのように認識され、バグ修正が苦痛になっているのかということだと思います。
バグ修正をアウトソーシングすると、状況が悪化する可能性があります。
開発者は、品質を低下させたくなるかもしれません。誰も気にしない？いくつかのオフショアの男たちは、混乱を片付けるためにそこにいます。
オフショアの男がオンショアの男に取って代わるまで。
去る、逃げる ...速くて決して振り返らない...
私はそのような会社で働いていました、彼らは彼らが賢いと思っていました、
ねえ、私たちはそれらすべてにバグがありますが、私たちの先輩はバグの修正に時間をかけすぎていると不平を言います。
オフショアオフィスを開いて、他の人にこれを処理させましょう。
本当に良い計画のように聞こえるマネージャーのために、そして開発者たちはついに次の最高のものを作成するというより興味深いタスクに取り組むために解放されました!!
ほ...でも待って...
2年後、彼らはそれをすべて処理するメインオフィスの5人の開発者のチームから、新しいものを作成する2人のチームと、バグを見つけて修正する30人のチームになりました。
あなたは何を知っていますか...バグ修正チームは苦労しています、彼らは追いつくことができません。
これは「先輩」を彼ら自身の過ちのために完全に数えられないものにしました。さらに最悪の場合、すべてがはるかに遠く離れた場所で発生したため、管理者も気付かず、コードの品質は、すでにひどい品質レベルから非常に速く低下しました。
私が去ったとき、彼らはすでにバグ修正のためにさらに2つのオフィスを開設しましたが、それらを作成する現在唯一の開発者の後ろに追いつくことはできません。彼らは実際、それは新人が十分に賢くないからだと思っています...
はい、これからも、会社がバグ修正を海外オフィスにアウトソーシングしていると言ったら、私を信用してください。
これは紙袋管理方法です。
電車に乗って電車が来るのを待ち、それが見えたら紙袋を頭にかぶせて…POOF ..電車がなくなった!!。魔法 ！
私の混乱を片付けるために会社に他の人にお金を払わせるのは良い考えのように聞こえます。そして、彼らがそれを修正してそれを修正できないほどねじ込まれている場合は、デバッグをデバッグすることになります。
追加の開発者を雇わなければならないために十分に補償されないことは望ましくありません。
自分で修正できたときに他の開発者を教育するのに不釣り合いな時間を費やさなければならないのは逆効果です。
私の一部は、問題を作成する人がそれらを修正する人でなければならない、またはそもそもバグの作成を回避するインセンティブがないように感じます。
開発者は間違いから学ぶことに興味がありませんか？特定のドメインに関する知識がなくてもバグを修正できますか？アウトソーシングパートナーはこの知識を持っていますか？ほとんどの場合、固定部分が最も簡単で、分析部分に時間がかかります。私の見解では、それはばかげた決断です。
将来の雇用主が「開発者はバグの修正を嫌うため、バグ修正を外部委託している」と言った場合、どう思いますか？あなたの懸念は何でしょうか？
私は遠く、遠く、遠くまで走りました。開発者は常に、常に、常に自分のバグを修正する責任があります。ドッグフードを食べることは、優れたエンジニアリングの基本的な信条です。
さらに、バグの修正は、おそらく開発よりも重要です。つまり、開発はコードの作成、テスト、デバッグ/修正です。
私がこの会社から得たのは、彼らがバグ修正を二流の仕事として扱っているということです。それ自体はかなり不穏であり、私は彼らの仕事の質（そして、エルゴ、彼らの労働環境）に非常に疑問を投げかけます。それはもっと厄介です。明らかに、彼らのエンジニアリングプロセスには社会階層が祀られています。
欠陥は常に変更の根本原因であり、通常、バグは変更を導入した人の責任です。バグの性質とその解決策を理解するのに、発信者より優れている人は誰ですか？
それが世界中に委任されている場合、元の作成者がオフショアエンジニアに利用可能であることをどのように確認しますか？
バグと期限のバックログしかなく、 Metropole からのサポートがないオフショアエンジニアを残して、彼は利用可能になるでしょうか？どのような種類のバグ修正を実行する可能性がありますか？誰が彼のバグを修正しますか？そして、Metropoleの開発者が事後バグ修正を介して学習することを妨げるものは何ですか？
すべての分野に嫌いな人がいます。これは特にソフトウェアに当てはまります。それは避けられないので、あなたの唯一のオプションは、あなたよりもろくでなしそれを知っているで作業するか、正しいことをしていることです。この会社はその説明に合わないようです。
要するに、逃げる。
彼らは本当に、オフショアのジュニア開発者の束がシニア開発者のコードの束を修正できることを期待していますか？それは、看護師にすべての神経学者の仕事を再確認させ、彼がミスを犯した場所でそれをやり直すようなものです。悪いアイデア！
従業員が自分たちが開発しているコードを実際にどれだけよく知っているかが心配です。
これがもたらす追加コストを正当化するのに十分なバグがある理由も疑問に思います。また、会社の長期的な将来についても心配します。これらの会社を主張し、同じ業界の複数のプロジェクトに同じコードを使用しているとWebに記事がたくさんあります。
壊れたコードの修正は、コードを記述するプロセスの一部であり、6か月前に間違ったことをよりよく理解できるため、他の開発者が間違いを修正したとしても、同じ間違いを犯さないようにすることができます。何度も何度も発生するバグ？
これは、「将来の雇用主」のビットを除いて、私の前の雇用主のように漠然と聞こえます。彼らは、開発者を損耗に負わせ、既存の製品をサポートするにはあまりにも多くを失い、法律や規制の変更に必要な新機能を追加しました（オフィスの収益の60％はVB6ベースの製品から来ており、MSはVB6ランタイムが将来のオペレーティングシステムでは配布されないので、Vistaがリリースされたときのようになります-物事を修正するための狂ったスクランブル）。すぐに会社を公開したいので、バランスシートの見栄えを良くするために、リソースを求めて皆を飢えさせています。そのため、オフショアでの雇用こそが、市場にとどまり続けるための唯一の方法です。
私の経験に基づいて、引用が言っていることはあなたの将来の雇用主は安いということです。
それは彼らが「バグを修正する」という意味に依存します。これが開発/テストサイクル中にバグを修正している場合、それは非常に奇妙です。これは元の開発者の仕事です。一方、リリースされた製品のメンテナンスを外部委託していることを意味する場合、これは珍しいことではなく、私が心配することでもありません。
私の経験では、事実の後に外部チームを取り込むことは、自分のバグを修正するだけの時間と同じくらいの時間を費やすことになります。そして、継続的にスピードを上げ続けました。調整はコードを書くよりも難しいです。
コードベースで作業する場合は、コミット権限を持つすべての人が適度に能力があることを保証したいと思います。これには、たとえばインドのかなりの数の人々が含まれますが、通常はオフショアにいる人々は含まれません。
さらに、私のバグのほとんどはコードのより複雑なセクションにあり、それらはオフショアプログラマーがバグ修正を適用する前に理解する可能性が最も低いものです。
このポリシーは、実際には無意識のうちに一部の企業に存在します。私はアウトソーサーとして働いています。私と私の同僚は、オンサイトの人よりも熟練したプログラマーであり、ツールの使用方法などを教えてくれるよう私たちに頼みますが、その反対に、彼らが行うよりも早くコードの問題を発見するでしょう。
通常、クライアントのプログラマーは、少なくとも一部のユーザーと同じ建物に物理的に配置されているため、半球を越えて到達しないコンテキストを取得する可能性が高くなります。私たちはそれがうまく機能していることを発見しました、私にとって欠けているのは、彼らが私たちのコードをレビューしていないということです。他人のプロジェクトを引き継ぐ。
いずれにせよ、私たちの場合、それが公式の方針ではないことを嬉しく思います。そのため、オンサイトのプログラマーをBAに過ぎないものに侵食すると思います。