고가의 프로그래머를 어떻게 대해야합니까?

우리 회사에서는 모바일 UI 개발과 같이 복잡하지 않은 많은 일을해야합니다.

숙련 된 프로그래머가 초보자보다 4 배나 많은 비용이 든다고합시다.

둘 다 기본적으로 같은 시간에 겉보기에 간단한 것들을 완성 할 수 있습니다.

차이점은 숙련 된 프로그래머가 버그를 줄이고 코드가 더 안정적이라는 것입니다. 초보자 프로그래머는 다른 모든 사람 (PM, 클라이언트 등)의 많은 시간을 낭비합니다. 그러나 그들은 훨씬 저렴합니다.

반대 주장은 HTML로 테이블을 만드는 데 경험과 초보자가 같은 시간을 소비한다는 것입니다. 따라서 숙련 된 프로그래머를 고용하여 초보자 프로그래머가 할 수있는 일을하는 것이 사치입니다.

우리 분야에서 숙련 된 프로그래머와 새로운 프로그래머의 차이가 4 배가 될 수 있다는 점을 감안하여 더 많은 프로그래머 또는 더 나은 PM에 투자해야합니다.

나는 실제로 동일한 프로젝트에서 두 가지 이론이 실제 세계에서 시도되고 있다는 것을 직접 경험했습니다.

내가 도착하기 전에, 더 비싼 학사와 매우 저렴한 프로그래머를 고용하기로 결정했습니다. 그 아이디어는 훌륭한 프로그래머가 좋은 품질 사양을 따르도록하는 것이 었습니다.

6 개월이 넘는 주요 프로젝트가 난 뒤 개발 관리자로 인계되었습니다. 몇 가지 위생 요소를 수정 한 후에는 코드 품질 문제가 남아있었습니다. 나는 예산이 얼마 남지 않았고 차트에없는 의사 소통 기술과 C #의 트레이너 (프로젝트가 작성된 언어)의 트레이너로 일한 경험이 풍부한 숙련 된 프로그래머 (많은 솔루션 아키텍트)를 고용했습니다. 이 아이디어는 멘토링과 효과적으로 무료 교육을 제공하여 다른 코더의 품질을 향상시키는 것이 었습니다.

한두 달 후에는 작동하지 않을 것이기 때문에 원래 팀이 프로젝트에서 제거되고 두 명의 더 많은 서랍 프로그래머가 추가되었습니다. 그들은 원래 코드를 다시 계산할 수 없었기 때문에 처음부터 3 개월간 스프린트를 시작하여 8 개월 이상 8 개월 동안 시도하지 못한 프로젝트를 전달했습니다.

요구 사항이 매우 기본적이라면 초급 프로그래머를 사용하지 않아도 될 수 있지만 장기적으로는 더 많은 비용이 듭니다. 때때로 "간단한"요구 사항은 매우 복잡한 것으로 발전합니다.

내가 방향을 바꾸기 위해 어려운 선택을하지 않았다면, 그들은 여전히 ​​노력하고있을 것이다. 사양이지만 건축 적으로 의미 가 있는지 여부에 따라 요청받은 모든 작업을 수행하려고합니다 . 보다 숙련되고 자신감있는 개발자가 질문을하고 기본 요구 사항을 파헤쳐 서 처음 에는 올바른 솔루션을 생산하게 되었습니다.

오, 다른 것. 훌륭한 프로그래머를 즉시 고용 할 수 있다고 가정하지 마십시오. 수년간의 평범한 경험을 가진 많은 사람들이 주니어처럼 거의 나쁜 결과를 제공하지만 슈퍼 스타와 같은 비용이들 것입니다 (때로는 더 많음). 나는 "적중률"이 매우 좋지만 경험과 함께 제공되며 많이 있습니다. 그것은 주제가 아닌 완전히 다른 대화의 주제입니다 ...

TL; DR 좋은 프로그래머는 거래입니다. 어려운 점은 그들을 찾아서 유지할 수있는 매력적인 작업 환경을 만드는 것입니다.

광범위한 성능 통계가 있다면 수학으로 비즈니스 사례를 만들 수 있습니다. 이는 개발 속도가 가격 상승을 보상하거나 더 나은 설계로 후속 버전의 유지 관리 및 개발에서 더 많은 비용을 절감 할 수 있음을 보여줍니다. 불행히도 이러한 수치는 종종 최신 기술에서는 사용할 수 없습니다.

또 다른 논쟁은 시장 출시 시간이 될 수 있습니다. 이는 상위 경영진이 더 쉽게 이해할 수 있습니다. 그러나 시간이 실제로 중요하지 않으면 도움이되지 않습니다.

최후의 수단에서의 사진 찾기 레드 데어 의 유명한 소방관, 경험이 적은 사람의 여러 실패한 시도 후 주요 재해로 불렸다. 그의 유명한 인용문 :

전문가를 고용하는 것이 비싸다고 생각되면 아마추어를 고용 할 때까지 기다리십시오.

... 컬러로 인쇄하고 사무실 문에 눈에 잘 띄게 표시해야 모든 사람들이 그것이 무엇인지 이해하도록 ;-)

나는 mcottle의 대답을 좋아하고 찬성했지만 다른 대답이 아직 제기하지 않은 다른 역학과 논쟁을 다루고 싶습니다.

첫째, mcottle의 답변에 암시적인 것은 특정 기술 수준 아래에서 일부 문제는 불가능하다는 사실입니다. 불행하게도, 당신이 밖으로 찾을 방법입니다 팀 노력과 실패입니다 매우비싼. 실패한 후에는 이것으로부터 배울 수있는 두 가지 교훈이 있습니다. 한 가지 옵션은 더 유능한 개발자가 필요하다는 것을 배우므로 개발자를 고용하여 과도하게 예산을 초과하고 일정을 계획하지만 최소한 미래에는 준비가 된 것입니다. 다른 옵션은 그러한 프로젝트가 팀에게 "너무 힘들다"는 것이며, 앞으로는 프로젝트를 포기하고 유사한 프로젝트를 포기해서는 안된다는 것입니다. 물론, "우리는이 작업을하기에는 너무 멍청하다"는 말을 거의하지 않지만 대신 "우리 시스템은 매우 복잡하다"또는 "우리는 많은 레거시 코드를 가지고있다"또는 다른 것들로 합리화 될 것이다. 후자의 관점은 무엇이 가능한지, 얼마나 길고 / 비싼 개발이되어야하는지에 대한 회사의 관점을 크게 왜곡시킬 수 있습니다. "

한 가지 질문은 회사의 계획이 정확히 무엇입니까? 좋아, 그들은 저렴한 주니어 프로그래머를 고용 할 것이다. 3 년이 지난 지금 3 년 동안 개발자와 함께했던 개발자는 무엇입니까? 그들은 결코 그 / 그녀의 인상을주지 않았습니까? 여기에있는 옵션은 다음과 같습니다.

• 그들은 직원을 유지하기 위해 경쟁력을 높이는데,이 경우 왜 수석 개발자 요금을 지불하는 데 문제가 있습니까? 그래도 돌아 올게요.
• 그들은 정체 된 요금을 가지고 있으며, 결국 운전 및 / 또는 기술이 부족한 직원들에게 "비등"할 것입니다.
• 그들은 더 많은 고위 직원을 적극적으로 제거합니다.

두 번째 사례는 많은 직원 이직을 의미하며, 이는 회사 지식이 손실되고 직원을 지속적으로 증가시키기 위해 지불하는 것을 의미합니다. 두 번째 경우, 당신은 본질적으로 나쁜 개발자를 선택하고 있기 때문에 일정이 증가하는 형태로 비용이 상승합니다. 이것이 진행되는 방식은 프로젝트 X에서 모든 것이 잘 진행되고 있다는 것입니다. Jim은 더 나은 개발자 중 한 명인 갑자기 떠날 때까지 2 년 동안 모금을받지 않았기 때문에 프로젝트가 "이해할 수 있습니다" Jim만큼 좋지 않은 새로운 주니어 개발자를 고용하고 훈련시켜야합니다. 이것이 기대치를 다시 교정하는 방법입니다.

경쟁력있는 인상이 제공되는 경우에도 주니어 개발자 인 경우 어디에서 어떻게 배워야합니까? 당신은 기본적으로 그들 중 하나가 업무 환경 에도 불구하고 스스로 좋은 습관을 배우고 궁극적으로 다른 목초지 (녹색 목초지를 떠나는 것이 아니라)를 멘토링 하기를 바라고 있습니다. 좋은 개발자와 함께 "펌프를 프라이밍"하는 것이 훨씬 더 합리적입니다. 아마도 당신은 Expert Beginners 의 문화를 개발할 것 입니다. 결과적으로 주니어 개발자보다 약간 더 좋고 문화적으로 독성이있는 사람들에게 수석 개발자 요금을 지불하게됩니다.

다른 사람이 언급하지 않은 것에 대해 매우 놀랍게도 특히 훌륭한 개발자 의 한 가지 이점 은 그들이 쉽게 곱셈 요소가 될 수 있다는 것 입니다. 주니어 개발자와 상급 개발자가 테이블을 만드는 데 같은 시간이 걸리는 경우가 있습니다. 그러나 좋은 개발자는 그렇게하지 않습니다. 모든 사람 이 테이블을 만드는 시간을 줄여주는 테이블 생성기 를 만들 것입니다. 대안 적으로 또는 추가적으로, 그들은 모든 사람에게 가능한 것의 한도를 올릴 것 입니다. 예를 들어 Google의 MapReduce 프레임 워크를 구현 한 개발자는 사용자가MapReduce의 알고리즘은 자체적으로 방대한 양의 알고리즘 버전을 만들 수 없으며 이제 MapReduce를 사용하여 쉽게 수행 할 수 있습니다. 종종이 역학은 덜 야만적입니다. 예를 들어, 더 나은 소스 제어, 테스트 및 배포 관행은 모든 사람을 향상 시키지만 특정 사람을 추적하기는 더 어려울 수 있습니다.

반대편에 대해 약간 논쟁하기 위해, 아마도 고가가 맞을 수도 있습니다. 더 숙련 된 개발자가 필요하지 않을 수도 있습니다. 만약 그렇다면, 개발은 회사의 중요한 부분이 아닌 것 같습니다. 이 경우 개발자를 완전히 제거하고 상용 소프트웨어를 사용하거나 필요시 계약자를 고용합니다. 사내 팀보다는 계약자 만 사용하지 않는 이유를 살펴볼 가치가 있습니다. 어쨌든 많은 직원 이탈을한다면, 계약직 계약자는 문제가되지 않습니다.

이것은 어느 쪽도 아니거나 상황이 아닙니다.

특히 규모가 큰 프로젝트에서는 일반적으로 고위 직책에 비교적 경험이 적은 사람들과 후배에 많은 경험이없는 사람들이 있습니다. 이런 식으로 노인들은 코드를 작성하고 더 어려운 결정을 내릴 수있게함으로써 프로젝트를 직접 도울 수있을뿐만 아니라 주니어를 멘토링함으로써 간접적으로 도울 수도 있습니다.

또한주의를 기울이면 도전이나 관심이없는 작업을 지속적으로 수행하도록 요청함으로써 선임 엔지니어가 빨리 소진되는 것을 방지 할 수 있습니다. 적어도 저의 경험에 의하면, 열렬한 중급 (혹은 인턴 급) 사람들을 멘토링하는 데 약간의 시간이 있어도 스프린트를 더욱 흥미롭게 만들 수 있습니다.

공평하게, 나는 이런 종류의 입장이 모든 선임 엔지니어들에게 적합하지는 않을 것이라고 덧붙였다. 아키텍처 및 디자인, 커뮤니케이션, 문서화 등을 강조해야합니다. 특히 초창기에는 코드 작성 경력을 쌓은 사람에게는 주니어 엔지니어에게 코드 작성 방법을 가르치기보다는 코드 작성만으로 유혹하는 경향이 있습니다. 또한 코드가 개인적으로 선호하는 방식이 아닌 경우 작업에 완벽하게 적합하더라도 처음부터 완전히 다시 작성하는 경향이 있습니다.

그러나, 당신이 정말로 경험 수준의 혼합물로 가서 관리를 설득 할 수없는 경우, 당신은 것을 전혀 문제 기본적으로이 없다 가 더 많은 경험을 위해 이동은. 프로젝트를 후배 직원에게 맡기면 쓸만한 제품을 전혀 얻지 못할 가능성이 매우 높습니다. 더구나, 그들은 자신이하고있는 일이 사용 가능한 제품을 향한 실질적인 진전을 제공하지 않는다는 것을 인식하지 못하기 때문에 더 숙련 된 사람이 자신이 근본적인 실수는 초기에 이루어졌으며, 의미있는 목적지에 도착하기를 희망하기 위해 백업, 재편성, 베어링을 취하고 새로운 방향으로 출발해야합니다.

실제 프로젝트는 고객의 요구에 따라 진행되므로 복잡성이 낮고 (예 : CRUD 양식 작성) 복잡성이 높은 (예 : 이벤트 중심 알림 시스템 작성) 작업이 필요합니다. 복잡성이 낮은 작업 만 수행 할 수있는 유일한 방법은 고객에게 "아니오"라는 단어를 반복해서 알려주는 것입니다.

주니어 레벨의 개발자 만 있다면 복잡성이 적은 작업 만 수행 할 수 있으며, 따라서 가치가 낮은 제품 만 구축 할 수 있으며 시장에서 제품을 차별화하기 위해 더 힘들게 노력할 수 있습니다. 차별화를 원한다면, 고가의 기능을 구축해야하는데, 이는 필연적으로 높은 복잡성 작업으로 이어집니다. 어쨌든 그것이 쉬웠다면 가치가 없을 것입니다. 즉, 복잡한 작업을 수행 할 사람이 필요하고 상급 개발자가 필요합니다.

고위급 개발자 만있는 경우 가치가 낮은 작업에 대한 기술을 낭비하고, 해당 작업을 수행하도록 강요 할 때 기술을 유지하는 데 어려움을 겪고, 간단한 작업을 더 많이 시도 할 때 건축 천문학 분야로 넘어갈 위험이 있습니다. 작업하기에 흥미 롭습니다. 즉, 경험이없는 개발자가 이러한 작업을 수행해야합니다.

고객 중심 제품을 다루는 건전한 팀은 일반적으로 혼합입니다. 하급 개발자와 상급 개발자의 비율은 복잡도가 낮고 복잡성이 높은 작업 간의 비율에 따라 달라지며 비즈니스 전략에 따라 다릅니다. 많은 양의 저 마진 쉽게 이해되는 쿠키 커터 작업을 적극적으로 찾는다면 복잡도가 높은 작업이 많지 않으며 대부분 주니어 레벨 개발자를 고용 할 것입니다. 저소득 틈새 시장을보다 높은 수익 마진으로 적극적으로 차별화하고 목표로 삼고 자한다면, 복잡도가 높은 작업이 많으며 대부분 고위급 개발자를 찾아야합니다.

내 대답에는 수석 프로그래머가 반드시 주니어 개발자보다 더 빨리 코딩하는 것은 아니라고 주장합니다. 실제로 가장 빠른 프로그래머는 보통 대학을 떠난 사람입니다.

도메인 지식 은 선임 개발자의 열쇠입니다. 훌륭한 선임 개발자는 해당 분야에 대한 지식이 있어야합니다. 이는 주니어 개발자에게는없는 것입니다. 숙련 된 개발자는 문제, 해결 방법 및 해결 방법을 이해합니다. 그들은 대부분의 후배 개발자보다 비즈니스의 복잡한 문제를 해결할 수 있습니다.

프로그래밍은 비교적 저렴한 기술 세트이며, 그것은 중요한 지식입니다.

'사례를 만들려고하지 말라'시장은 직원들에게 가격을 책정합니다. 시장이 경험에 대해 4 배 더 많은 돈을 지불 할 의사가 있다면 회사 전체가 4 배의 생산성 향상을 가져 왔기 때문입니다.

분명히 시장은 잘못되었을 수 있습니다. 아마도 3.5 배나 5 배일 것입니다. 그러나 당신이 디지털 대행사가 아니라면, 시장과 경쟁하거나 그런 뉘앙스가 중요하지 않은 것입니다.

당신의 진짜 문제는 당신이 좋은 경험이있는 개발자와 그것을 욕하는 노인의 개발자를 구별 할 수있을 정도로 인터뷰에 능숙합니까?

PM 대 개발자 예산에 대한 두 번째 질문입니다. 개발자가 PM 없이는 할 수 있지만 PM은 개발자 없이는 할 수 없다고 말하고 싶습니다. 개발 엔진을 먼저 정렬 한 다음 PM을 가져 와서 관리자에게 맡기십시오.

당신은 자신의 나라에서 4 분의 1 정도의 훌륭한 개발자 비용을 찾지 못할 것입니다. 급여의 절반에 해당하는 사람을 찾을 수 있으며 이는 초보자에게 절대적으로 도움이됩니다. 급여의 1/4에 해당하는 사람은 국외로 나가야하며, 의사 소통, 사양을 맹목적으로 따르는 사람들 및 모든 종류의 문제에 대해 문제를 겪게됩니다.

당신은 필요 하나 좋은 개발자. 주니어 프로그래머를 더 추가 할 경우, 의사 소통 능력이 뛰어나고 주니어를 주시 할 능력이있는 훌륭한 개발자가 필요합니다. 좋은 개발자가 없으면 길을 잃습니다. 당신은 특별한 재능있는 초보자를 찾는 것이 운이 좋을지 모르지만, 일단 그들이 좋은 것으로 판단되면, 그들은 더 큰 급여를 원할 것입니다.

좋은 개발자가 없다면 더 큰 그림을 보는 사람이 없으며 stackoverflow를 사용하여 해결할 수없는 문제를 해결할 수있는 사람이 없습니다. 주니어 개발자는 유지 관리 가능한 코드를 작성하는 방법을 알지 못하기 때문에 코드가 유지 관리가 쉽지 않습니다. 그들은 그것을 배울 수 있지만, 팀의 훌륭한 개발자가 없으면 못할 것입니다.

더 나은 프로그래머를 고용하는 것이 비용 효율적인지 결정하기 전에 회사가 극복해야 할 몇 가지 장애물이 있습니다. 내가 어디에서 일하는지에 대해 부정적인 가정을한다면 죄송하지만, 그들이 무엇을하고 있는지 알지 못합니다.

1. 사용자가 구축 한 소프트웨어가 얼마나 복잡한 지 정확하게 평가 했습니까? 그들이하는 일이 매우 어렵다고 생각하지 않는 것 같습니다. 왜 더 나은 사람을 고용해야합니까? 실수가 발생한 경우와 더 나은 솔루션과 생산성으로 돈을 벌 수있는 사례를 만들었습니까? 시간을 절약하는 것은 좋지만 많은 회사에서 마우스 패드를 구입할 돈을주는 것보다 일주일 내내 프로그래머의 시간을 낭비하는 것입니다.
2. 귀사는 좋은 프로그래머에게 매력적입니까? 그들은 그들을 식별 할 수 있습니까? 시니어 개발자를 고용하는 것보다 더 나쁜 것은 없으며, 더 많은 돈을 지불하고 기술 부족 및 / 또는 리더십 부족으로 전체 팀을 끌어 내립니다.
3. 귀사에서 우수한 프로그래머를 활용할 수 있습니까? 그들이 할 모든 것이 그들에게 뻔뻔스런 사양을 던지고 그것을 만들어 가라고 지시한다면, 요점은 무엇입니까? 그들은 자신의 방식대로 일할 수있는 자유를 주려고합니까? 결국, 훌륭한 프로그래머는 자신의 시간을 더 잘 활용하는 방법을 알고 있습니다. 그들은 주변 사람들에게 영향을 미치고 다른 프로그래머들을 향상시킵니다. 그들은 제품을 훨씬 더 잘 만들기 위해 더 나은 디자인과 아키텍처를 도입합니다.

죄송하지만, 귀사에서 좋은 프로그래머와 함께 무엇을해야할지 모르겠 기 때문에 먼저 더 나은 관리자를 고용하여 이러한 내부 문제를 해결하도록 설득해야합니다.