장래의 고용주가 "개발자가 버그 수정을 싫어하기 때문에 버그 수정을 아웃소싱했다"고 말하면 어떻게 생각하십니까? 당신의 관심사는 무엇입니까?
장래의 고용주가 "개발자가 버그 수정을 싫어하기 때문에 버그 수정을 아웃소싱했다"고 말하면 어떻게 생각하십니까? 당신의 관심사는 무엇입니까?
답변:
우리 자신의 버그를 수정하면 실제로 우리는 더 나은 개발자가 됩니다. 그리고 그것은 꽤 즐거운 순간입니다. 특히 그들이 잘보고 될 때.
그들이 버그를 수정하고 싶지 않다면 문제는 다른 곳에 있습니다.
문제는 경영진에 의해 버그가 어떻게 인식되는지 또는 나쁜 설계 결정 및 / 또는 (단위) 테스트가 아니 어서 버그 수정이 고통 스러운지를 의심합니다.
아웃소싱 버그 수정은 아마도 상황을 악화시킬 것입니다.
개발자는 품질 저하를 원할 수 있습니다. 무슨 상관이야? 일부 해외 사람들은 엉망을 정리하기 위해 거기에 있습니다.
해외 사람들이 해외 사람들을 교체 할 때까지.
휴가는 , 도망 빠른 ... 다시 쳐다 보지도 않을 ...
나는 그런 회사에서 일했고 그들은 똑똑하다고 생각했습니다.
야, 우리는 모든 버그를 가지고 있지만 우리 선배들은 버그를 수정하는데 너무 많은 시간을 소비한다고 불평한다.
해외 사무소를 개설하고 다른 사람들이이 문제를 해결하도록하겠습니다.
정말 좋은 계획처럼 들리는 관리자를 위해 개발팀은 마침내 다음으로 최고의 것을 만드는 더 흥미로운 과제를 해결했습니다!
호 ... 잠깐만 ...
2 년 후, 그들은 본사에서 5 명의 개발자로 구성된 팀에서 새로운 것을 만들어내는 2 명의 팀과 버그를 찾아 수정하는 30 명의 팀으로이 모든 것을 처리했습니다.
당신은 무엇을 알고 있습니다 ... 버그 수정 팀은 어려움을 겪고, 그들은 유지할 수 없습니다.
이로 인해 "노인"은 자신의 실수로 완전히 계산할 수 없었습니다. 최악의 경우, 모든 것이 지금까지 일어났기 때문에 경영진은 인식하지 못했고 코드 품질은 이미 심연의 품질 수준에서 매우 빠르게 급락했습니다.
내가 떠났을 때 그들은 이미 버그 픽스 너를 위해 두 개의 사무실을 더 열었고 여전히 그것들을 만드는 유일한 개발자 뒤에 유지할 수는 없습니다. 그들은 실제로 새로운 사람들이 충분히 똑똑하지 않다고 생각합니다 ...
그래서 예, 지금부터 회사가 버그 수정을 해외 사무소에 아웃소싱한다고 말하면 나를 믿습니다.
이것이 종이 봉지 관리 방법입니다.
철도에 서서 기차가 올 때까지 기다리십시오. 보면 머리 위로 종이 봉지를 넣고 POOF .. 기차가 사라졌습니다 !!. 마술!
회사가 다른 사람에게 내 엉망을 정리하도록 지불하는 것은 '깨끗한'코드를 가져 와서 새로운 기능을 추가 할 것으로 예상되는 경우를 제외하고는 좋은 생각처럼 들립니다. 그들이 너무 망쳐 서 고칠 수 없다면 디버깅을 디버깅하게 될 것입니다.
추가 개발자를 고용해야하므로 적절히 보상받지 않는 것이 바람직하지 않습니다.
다른 개발자가 스스로 고칠 수 있었을 때 교육하는 데 상당한 시간을 소비하는 것은 비생산적입니다.
저의 일부는 문제를 만드는 사람들이 문제를 해결하는 사람들이거나, 처음부터 버그를 만드는 것을 피할 동기가없는 것처럼 느낍니다.
장래의 고용주가 "개발자가 버그 수정을 싫어하기 때문에 버그 수정을 아웃소싱했다"고 말하면 어떻게 생각하십니까? 당신의 관심사는 무엇입니까?
나는 멀리, 멀리, 멀리 도망 갈 것이다. 개발자는 항상 자신의 버그를 수정해야 할 책임이 있습니다. 개밥을 먹는 것은 좋은 공학의 기본 교리입니다.
또한 버그 수정은 개발보다 중요합니다. 개발은 코드 작성, 테스트 및 디버깅 / 수정입니다.
내가이 회사에서 얻는 것은 버그 수정을 2 차 과제로 취급한다는 것입니다. 그것은 그 자체로 꽤 혼란스럽고 나는 그들의 작업 품질 (그리고 ergo, 그들의 작업 환경)에 대해 크게 의문을 가질 것입니다. 더 혼란 스럽습니다. 그들의 공학 과정에는 분명히 사회 계층화가 존재한다.
결함은 항상 변경으로 인해 발생하며 일반적으로 버그는 변경을 도입 한 사람의 책임입니다. 버그의 본질과 그 해결 방법을 이해하는 것이 누가 창업자보다 낫습니까?
전 세계에 위임 된 경우, 원저자를 해외 엔지니어가 사용할 수 있도록하려면 어떻게해야합니까?
그는 버그와 마감일에 대한 백로 그만 가지고 있지만 Metropole의 지원을받지 않는 역외 엔지니어를 떠날 수 있을까요? 어떤 유형의 버그 수정이 가능합니까? 누가 그의 버그를 수정 했습니까? 그리고 메트로 폴 개발자들이 사후 버그 수정을 통해 학습하는 것을 방해하는 것은 무엇입니까?
모든 분야에 병신이 있습니다. 이것은 소프트웨어에서 특히 그렇습니다. 그것은 불가피하기 때문에, 유일한 선택은 당신보다 더 잘 알고 있거나 일을 올바르게하는 병신 들을 다루는 것입니다. 이 회사는 그 설명에 맞지 않는 것 같습니다.
한마디로 도망 치십시오.
이것은 "전망 고용주"비트를 제외하고는 나의 이전 고용주와 모호하게 들립니다. 법률 및 규정 변경에 필요한 새로운 기능을 추가하는 동시에 개발자는 기존 제품을 지원하기 위해 개발자를 잃고 너무 많이 잃었습니다 (사무실 수익의 60 %는 VB6 기반 제품에서 발생하며 MS는 VB6 런타임을 언급했습니다) 향후 운영 체제에는 배포되지 않으므로 Vista가 나왔을 때와 비슷합니다. 회사를 곧 공개 할 수있는 힘은 대차 대조표를 개선하는 데 필요한 자원을 모두에게 굶주리고 있습니다. 따라서 해외에서 채용하는 것이 시장에 머무를 수있는 유일한 방법입니다.
내 경험에 따르면, 견적은 당신의 예상 고용주가 싸다는 것입니다.
"버그 수정"의 의미에 따라 다릅니다. 이것이 개발 / 테스트주기 동안 버그를 수정하는 경우에는 매우 이상합니다. 이는 최초 개발자의 작업입니다. 반면에, 출시 된 제품의 유지 관리를 아웃소싱했음을 의미하는 경우 이는 예외가 아니며 걱정할 사항이 아닙니다.
이 정책은 실제로 일부 회사에서 무의식적으로 존재합니다. 나는 아웃소싱을 위해 일합니다. 저와 제 동료들은 현장 직원들보다 더 유능한 프로그래머입니다. 그들은 우리에게 도구 등을 사용하는 방법을 가르쳐달라고 요청하지만 그 반대편에서는 코드보다 더 빨리 문제를 발견 할 것입니다.
일반적으로 클라이언트의 프로그래머는 적어도 일부 사용자와 동일한 건물에 물리적으로 위치하므로 반구에 도달하지 못하는 컨텍스트를 얻을 가능성이 높습니다. 우리는 그것이 잘 작동한다는 것을 알았습니다. 나에게 누락 된 부분은 코드를 검토하지 않기 때문에 계약이 완료되면 우리의 어리석은 관행 때문이 아니라 일반적인 문제만으로 인해 놀라움이나 질문이있을 수 있습니다. 다른 사람의 프로젝트를 인수합니다.
어쨌든 우리의 경우 공식 정책이 아니기 때문에 기쁘다. 따라서 현장 프로그래머가 BA보다 조금 더 많은 것을 침식하게 될 것이라고 생각한다.