추가 개발자의 수익 감소

10

더 많은 개발자를 소프트웨어 프로젝트에 추가 할 때 수익이 감소하는 시점을 설명하는 용어가 있습니까?

높은 수준에서 프로젝트가 생산 능력 (예 : 프로젝트의 상태 / 상태, 추가 된 개발자의 품질)에있을 많은 개발자가 더 복잡하다는 것을 알고 있지만 이를 반복을 통해 비 기술적 관리와 관련시키는 방법. 나는 기본적으로 Brook의 법칙을 제외하고 "터미널 속도"와 같은 강한 정신적 이미지를 불러내는 용어를 찾고 있습니다.

project-management terminology brookslaw

— smp7d
소스

2

그 점을 "지금"이라고합니다. 진지하게, 당신은 그들에게 새로운 개발자가 추가되는 순간과 프로젝트 타임 라인에 미치는 영향을 나타내는 그래프를 보여 주어야합니다 (기존 회원 멘토링으로 인한 생산성 손실, 새로운 회원 실수 및 재 작업 등) ... )

— Oded

14

"한 달에 아기를 낳는 9 명의 여성"은 경영진에게 자원 대 타임 라인 문제를 설명하는 데 사용되는 일반적인 비유입니다.

— dasblinkenlight

2

@dasblinkenlight- "그러나 교대 근무 여성이 있다면 어떨까요?" (일반적인 비 기술적 관리 대응).

— jfrankcarr

6

but senior management tends to view it as aggressively negative귀하의 경우 고위 경영진 의제는 두 가지 가능성이 있습니다. 가능한 모든 방법으로 프로젝트 완료 데이터를 줄이고 개발자를 통제하는 것입니다. 선입견과 반대되는 견해는 부정적인 것으로 간주되며, 얼마나 적극적으로 "설득"하려고하는지에 따라 "팀 선수가 아님"으로 표시됩니다. 예 : 경영진은 통제 할 수없는 사람을 말합니다.

— maple_shaft

1

일정, 위험 또는 $ 또는 이들의 조합에 관심이 있습니까? 그들이 가장 염려하는 부분을 찾고 더 많은 개발자들이 그 문제를 해결하지 못하는 이유를 해결하고 심각하게 받아 들여질 대안 솔루션을 제안하십시오. 종종 순수한 돈이나 시간표보다 더 미묘합니다.

— mattnz

7

귀하의 질문에는 답이 포함됩니다 : 수익 감소 지점. 자원을 더 추가하면 이러한 자원의 생산적인 효과보다 비용이 많이 듭니다. 이것이 기본적인 경제 개념이므로 경영진은 이것을 마음껏 알고 있어야합니다 ...

— 미라 쿨리
소스

3

당신이 설명 한 것은 경제학자들이 부정적인 수익 의 지점이라고 부르는 것입니다 -자원을 추가하면 악화됩니다. 수익 감소 의 요점은 더 많은 자원을 추가하면 여전히 생산량이 증가하지만 더 적은 양입니다. 따라서 리소스를 추가하면 조금 나아지지만 예상보다 적습니다.

— MarkJ

@MarkJ 좋은 지적입니다. 필자는 규칙에 따라 감소 또는 마이너스 수익을 찾고 있지는 않습니다. 선임 개발자 / 프로젝트 관리자가 더 많은 리소스를 거부 할 것이라는 점을 찾고 있습니다. 불행히도, 그것은 항상 자르고 건조하지는 않습니다.

— smp7d

6

" 늦은 소프트웨어 프로젝트에 인력을 추가하면 나중에 작업을 수행 할 수 있습니다. 월간 작업 시간은 작업 시간에 곱한 직원 수에 비례하는 작업 단위의 개념입니다. Brook의 법칙에 따르면 이러한 관계는 신화이며 따라서이 책의 핵심이다. "- 출처 : 위키 Mythical_Man_Month .

— 기회 없음
소스

1

"IT 컨설팅 회사를 관리하는 내 골프 친구는 현재 사용할 수있는 두 개의 '블랙 벨트'프로그래머가 있다고합니다. 둘 다 컴퓨터 과학 석사 학위를 가지고 있습니다. 아무 문제없이 데려 올 수 있어야합니다. 시간을 더 잘 예약하는 방법에 대해 배우게 될 것입니다. "

— jfrankcarr 2009 년

1

@kevincline- "팀 플레이어가 아닌 것 같습니다. 14 살짜리 VB6 앱을 유지 관리하도록 다시 지정하고 있습니다. 다음은 누가 내 치즈를 움직였습니까? "

— jfrankcarr

3

"팀 선수가 아닌 것 같습니다.":이 의견도있었습니다. 저의 대답은 축구와의 비교였습니다. 좋은 팀은 스스로를 5 평방 미터에 몰아 넣지 않으려 고 노력하지만 각 선수가 더 효과적 일 수 있도록 전체 필드를 차지하려고합니다. 플레이어는 종종 필요에 따라 공을주고받습니다. 팀에서 일한다는 것은 팀 구성원이 활동을 조정하지만 프로젝트의 독립적이고 겹치지 않는 영역에서 작업한다는 것을 의미합니다. 이것이 가능하면 더 많은 개발자를 추가하고 생산성을 높일 수 있습니다.

— Giorgio

1

@ kevin cline : 아마도 이것이 새로운 개발자를 팀에 추가하는 것이 쓸모없는 이유 일 것입니다. 아마도 프로젝트의 나머지 부분과는 독립적 인 영역을 찾을 수 없다면 새로운 개발자 추가를 중단해야 할 것입니다.

— Giorgio

2

팀의 태도, 프로젝트 규모, 상황이 얼마나 좋은지, 신입 회원의 경험, 요구 사항의 현재 상태 등이 여기에서 고려해야 할 중요한 요소입니다.

— NoChance

4

반복 운명

불쌍한 Fred Brooks는 Homer 's Illiad의 Cassandra 와 같습니다 . 트로이 영화가 나온 책을 읽으면 그녀는 (트로이 목마)를 신경 쓰지 않은 사람이었습니다. 그녀는 미래를 정확하게 예측하지만 예측이 완료 될 때까지 아무도 자신을 믿지 않고 스스로 본 적이 없습니다.

관리 / 수동적 저항 또는 신중한 고용과 싸우지 않습니까?

제 조언은 아마 죽기 좋은 날이 아니며, 만약 당신의 매니저가 당신이 더 많은 직원을 고용하기를 원한다면, 그것을하십시오. 특정 경험을 가진 사람을 확보하고 빠른 화면 출력 기술을 사용하는 것과 같은 일부 매개 변수를 제안하면 검색 시간이 3 배가되고 방해자가 도착하기 전에 최종 기한에 도달 할 수 있습니다.

가능성이 낮은 후보자에게 보내는 시간을 최소화하면 많은 시간이 절약됩니다. 예를 들어, 이력서의 첫 1/3에 3 가지 요구 사항이없는 이력서가 제출되면 응시자는 현장 인터뷰 전에 30 분 전화 화면을 통과해야하며 필요에 따라 사전 심사를 수행하지 않는 채용 담당자는 무시해야합니다. 다른 기술도 풍부하므로 사용하는 것이 효율적이고 효과적이어야합니다.

새로운 고용 통합 부담 제어

마감일 전에 고용을하고 신입 사원을 처리해야하는 경우, 교육에 참여해야 할 중요한 길을 가지지 않은 사람들의 예산 시간을 정하십시오. 팀원이 하나를보고, 수행하고, 보여 주도록하는 것이 도움이됩니다. 경험이 부족하거나 중간 정도 인 팀 구성원이있는 경우 프로세스, 도구 세트 및 코드 기반에 대한 이해가 강화되어 이러한 영역에서 새로 채용 할 수 있습니다.

바라건대, 당신은 약간의 문서를 가지고 있기 때문에 새로운 사람에게 문서를 읽도록 지시하는 것이 좋은 단기 및 장기 투자입니다. 그것들은 점차적으로 당신의 프로세스로 가져와야하며 대담하지만 유해한 변화로 암석에서 프로젝트를 운전하지 못하게 할 수있는 사람들이 그들의 작업을 검토해야합니다.

신규 채용을위한 최고의 최악의 과제

별도의 프로젝트 또는 일부 기술 개발이있는 경우 향후 프로젝트에서 사용할 수 있도록 준비 할 수 있으며 이는 큰 이점이 될 수도 있습니다. 특정 도구 세트를 배우고 자체 빌드, 단위 테스트, 유용성 테스트, 문서화 및 검토 참여는 모두 신입 사원의 훌륭한 후보 작업입니다. 신입 사원은 새로운 관점을 가질 수 있으며 팀이 함께 배우고 더 이상 볼 수없는 것에 대해 귀중한 비평을 제공 할 수 있습니다.

신규 직원에 대한 덜 유익한 사용에는 관리자 및 비 개발자 이해 관계자와의 팀 회의, 평가, 요구 사항 도출 및 관리 (경쟁 업체에서 근무한 후 전문가가 아닌 경우), 특허, 새로운 후보자 인터뷰 또는 직원 채용 등이 포함될 수 있습니다.

팀에서 조화를 유지하고 미래의 기대를 설정

새로운 고용 우선 순위는 여전히 유효합니다. 형성, 폭파, 규범, 수행 진화를 거친 팀이있는 경우, 신입 사원에게 팀의 성과 및 계획된 책임에 대한 기대치를 부여해야합니다. 신입 사원의 직업이 팀의 다른 역할보다 덜 까다로워 보이게해서는 안됩니다. 팀이 기한을 향해 적극적으로 추진하는 경우 새 직원은 그가 통합을 향해 적극적으로 추진하고 있음을 보여줄 방법이 있어야합니다.

— DeveloperDon
소스

1

나는 인력에 대한 수익이 감소하는 시점에 대한 표준 용어를 모른다. 사람들을 설득하는 것이 목적이므로 대신 문구를 바꿔보십시오.

"분해성 한계"는 특히 중간 규모 프로젝트와 관련이있을 수 있습니다.
"통신 오버 헤드 장벽"은 대규모 프로젝트에 대한 고전적인 Brook의 법칙을 연상시킵니다.
"디자인 반복 요구 사항"은 "폐기물이 아닌 것을 원한다면 반쯤하는 데 약간의 시간이 걸릴 것입니다."

— 다가오는 폭풍
소스

0

합리적으로 가까운 용어는 " 탄력성 범위"가 될 것입니다 . 가격 비 탄력성 지역에 대한 비유는 가격을 더 낮추더라도 매출이 증가하지 않을 경우 경영진과 함께 종을 울려 야합니다.

— Dasblinkenlight
소스