서명 된 계약으로 시간 견적을 고정하려는 프로젝트 관리자

이전 고용에서 프로젝트 관리자 (PM)는 내가 진행중인 프로젝트의 코드 배달 시간에 만족하지 않았습니다. 나는 프로젝트 책임자에게 PM이 내가 과제와 배달 날짜에 대해 내 추정 시간을 고정하기 위해 계약을 체결하는 것을 고려하고 있다고 들었다.

프로젝트의 상황은 우리가 새로운 기술, 코드베이스, 코딩 표준 및 변경하기 쉬운 요구 사항을 다루고 있다는 것이 었습니다. 나는 새로운 것을 배우고 계속 변화하는 요구 사항에 가장 잘 적용했습니다. 반복 전체의 요구 사항은 2-3 배 증가했으며, 예상 한 결과는 약 5-8 배 증가했습니다. 변경되지 않은 유일한 것은 추정 및 배달 날짜입니다.

예, 마감일이 거의 없었습니다. 그리고 전체 개발 팀의 다른 누구도 익숙하지 않기 때문에 실제로 도울 수없는 매우 새로운 기술을 연구하고있었습니다. 적어도 쉽지는 않습니다.

그 당시 PM은 자신의 숫자가 더해지기를 원했기 때문에 항상 제 시간에 작업 코드를 제공 할 수 있도록 "계약"에 서명하기를 원했습니다. 서명 된 계약을 통해 제 시간에 배달 할 수없는 경우 PM이이 계약을 사용할 수 있다고 가정합니다.

다음에 일어난 일은 다른 프로젝트 관리자 및 / 또는 프로젝트 책임자가 나를 변호 한 것이라 믿었습니다.

내 질문은, 이것이 관리자에 대한 적기를 제기해야 하는가? 관리자가 계약서에 서명 한 소프트웨어 개발자의 예상 시간을 고정시키는 것이 일반적인 관행입니까? 또는이 경우 시도하십시오.

저는 독립 컨설턴트가 아닌 전임 직원이었습니다.

업데이트 : 매주 새로운 견적을 제공했다고 덧붙이고 싶지만 원래 견적과 배달 날짜가 ​​PM이 수정 된 것으로 보입니다 .

내 질문은 관리자에 대해 적의를 제기해야 하는가?

예 . 이제 이력서 / CV를 최신 상태로 유지하고 새로운 일자리를 찾기 시작할 때입니다. 또는 귀하의 관리자가 귀하 와 함께 매우 불쾌한 게임 을 시작하려고 함을 의미 합니다.

관리자가 계약서에 서명 한 소프트웨어 개발자의 예상 시간을 고정시키는 것이 일반적인 관행입니까?

나는 이것이 직원에게 적용되는 것을 들어 본 적이 없습니다.

시간과 노력 추정은 항상 어렵다. 특히 우리의 직업은 지나치게 낙관적입니다. 추후 추정에 도움이 될 수있는 몇 가지 추정 시스템이 있지만, 과거 통계를 수집해야합니다. 하나는 PSP 입니다. 또 다른 기능 포인트 입니다. 많은 개발자는 둘 다 좋아하지 않으며 둘 다에 대해 매우 강력한 의견을 찾을 수 있습니다.

시간과 노력을 추정하는 데있어 가장 어려운 점은 추정 휴리스틱에 피드백이 없다는 것입니다. 열쇠 중 하나는 추정치가 무엇인지, 추정하는 데 사용한 모수를 기록하는 것입니다. 그런 다음 실제로 수행 한 작업에 따라 생각한 내용과 비교하십시오. 이를 사용하여 추정 매개 변수를 수정하십시오. 엔지니어링에서는이를 " 피드백 "이라고 합니다 .

그렇습니다. 알람 벨 소리가 절대적으로 들립니다.

제가 개인적으로 접할 수있는 입장에 있었으면, 모든 요구 사항을 동결하는 계약서에 서명하도록 관리자에게 요청했을 것입니다. 관리자가 보석금을 낸 것 같습니다. 그런 다음 떠날 것입니다.

간단합니다. 관리자에게 사양 잠금에 서명 할 때 예상 시간을 잠그겠다고 서명하면됩니다. 당신이 할 수 없기 때문에, 알 수없는 것에 대한 견적을 제공하십시오. 시작하기 전에 전체 프로젝트 사양, 변경 사항 없음-시간 내에 완료 할 수 있습니다. :)

spec => 계약을 한 번 변경하면 무효입니다. 아마도 첫날 10 분 후에 문제가 사라질 것입니다 :)

예, 이것은 적기입니다. 관리자가 소프트웨어 프로젝트에서 위험을 관리하는 방법을 이해하지 못한다고 알려줍니다. 그가해야 할 일은 처음에 정확히 지연을 일으킨 원인을 파악한 다음 소프트웨어 프로젝트 중에 발생할 수없는 스케줄 위험을 효과적으로 관리하기위한 프로세스를 계측하는 것입니다.

어떤 상황에서도 관리자와 일정을 보증하는 계약에 서명하지 않습니다. 다른 사람들은 사양에 대한 서명에 서명하는 것을 언급했습니다. 내 의견으로는 이것으로는 충분하지 않다. 이는 도구 나 기술, 불완전하거나 열악한 디자인, 다른 팀원의 성능 등에 대한 예기치 않은 어려움을 설명하지 않습니다.

이것은 붉은 깃발이 아니며 무기 등급의 어리 석음입니다.

추정치와 마감일이 지속적으로 불면, 합리적으로해야 할 일은 원인을 식별하고 프로세스를 개선하는 것입니다.

당신이 어디로 가고 있는지 모르기 때문에 말을 탓하고 차는 경우, 말이 당신을 물고 도망가더라도 놀라지 마십시오!

관리자가 그의 요구와 일치하지 않는 동안. 그는 완전히 비난하지 않습니다. 익숙하지 않은 지역에서 일하고 있다면 "모름"이라고 말하는 데 아무런 문제가 없습니다. "모름"이 완벽하게 받아 들일 수있는 대답이라는 것을 깨닫기까지 시간이 걸렸습니다. 그래서 나는 그 말을하는 것이 얼마나 많은지 알고 있습니다. 그러나 당신이 정말로 모른다면 그것은 그 대답입니다. 그리고 그들이 그 일에 뛰어 들면 시어스 (윌리스) 타워만큼 높이 쌓아 올리는 데 몇 페니가 필요한지 추정 해 줄 것을 요청합니다. 그리고 그들은 그들이 쉬었던 모든 돈을 지불하는 계약에 기꺼이 서명 할 것입니까?

급여를받을 가치가있는 프로젝트 관리자라면 스프레드 시트에 적합하지 않은 것들이 있다는 것을 알아야합니다. 때로 일이 끝날 때가 있습니다. 나는 당신이 한 일에 진전을 보임으로써 당신이 잘하고 있다고 생각합니다. 숫자 업데이트를 중단하십시오.

또 다른 연습은 큰 작업을 더 작은 추정 단위로 나누는 것입니다. 이 연습은 당신이해야 할 일을 더 잘 이해하는 데 도움이 될 것입니다. Steve McConnell의 Software Estimation 및 Stephen Withall의 소프트웨어 요구 사항 패턴 에서 각각 작업을 분류하고 숨겨진 요구 사항을 발견하는 방법에 대한 팁을 확인하십시오.

추정치로 엉덩이에서 쏘지 마십시오. 시간을내어 분해하십시오. 많은 수의 작은 작업을 추정하면 큰 작업의 전체 추정치가 더 높아집니다 (평균 법칙으로 인해 일부 추정치는 미달하지만 일부는 끝났고 서로 무게를다는 경향이 있음).

"프로젝트 관리자"에게 문의하십시오 : 소프트웨어 나 마감일을 판매합니까?

나는 프로젝트 관리자이자 프로그래머입니다. 여기가 아닙니다. 대신 여기 실제로 무엇을해야하는지에 대한 긴 논쟁이 있습니다 (Mr Mod, 너무 길면 무엇을 하시겠습니까?). 나는 이미 여기에 언급 한 의견에 동의합니다. 어떤 사람들은 다른 사람들보다 먼저해야 할 것이지만, 여기에 내가 처음으로 생각한 것이 가장 좋습니다 . 아, 그리고 귀하의 질문에 대한 명백한 대답은 그렇습니다.

비록 시작하기 전에 PM은 다른 사람들이 먹이 사슬을 더 많이 슬퍼하기 때문에 당신에게 슬픔을 줄 가능성이 높습니다. 그들은 (우리) 단순한 생물입니다 ... 당신이 묘사 한 상황을 피할 수있는 방법이 있습니다-Mike Brown은 꽤 잘 다루고 있습니다. 시작하기 전에 3/4/5 .. 시간 동안 무언가를 제작하는 데에는 아무런 문제가 없습니다. 실제로 이런 일이 발생하지 않으면 모든 종류의 경보가 울려 야합니다. 알 수없는 영역으로 이동하는 경우, 뒤로 밀고 일주일 동안 지역 및 기술을 연구하여 합리적인 견적을 내릴 수 있도록 요청하십시오 (신기술이 배우고 돈을 가지고 놀고 있기 때문에이를 올바르게 수행하고 싶을 것입니다) 그렇지 않습니까?) 당신이있는 곳의 PM과 경영진이 이것을 이해하지 못한다면 ... 이력서를 업데이트하고 가장 가까운 출구를 찾으십시오. 그들이 너무 풍성한 운명에 처하게했습니다. PM이 풀 타임 직원에게 계약서에 서명하는 것도 나쁜 나쁜 징조라고 생각할 것입니다.완전히 무능하지 않을 수도 있습니다. 그들은 실제로 프로젝트 리더와 당신과 함께 마인드 게임을하고 있다는 것입니다 (내가 읽은 것에서 그들은 이것을 당신에게 직접 넣지 않았으며 궁극적으로 위협을 따르지 않았습니다). PMing은 결국 표준 기업 정신병의 안식처입니다. 당신이 한 말에서 다른 사람들이 당신을 위해 박쥐로 들어간 것이 좋았으므로, 아래의 조언은 아마도 당신에게 긍정적 인 결과를 낳았을 것입니다. 나는 그것이 말하는 것 이상으로 판명되면 그들의 손에 혁명이 있었을 것이라고 생각합니다.

그래서 실제 상황 / 구멍에 대해 , 누군가 어딘가에 다시 일어날 것이기 때문에 (약 5 분 전에, 또 다른 5에서는 scheduleRepeat ()) 다시 발생하기 때문입니다. 계약 어리 석음이 없을 수도 있지만 기본 스토리는 항상 동일합니다. 회의를 조직하십시오 (!). 중대한:회의 초대에 기술 프로젝트 책임자 / 팀장 / 건축가 / 디자인 관리자를 포함시켜 이미 문제를 극복하고 참여하도록하십시오. '계층'의 누군가를 위해 갈 수있는 계층 구조가 높을수록 좋습니다. 당신의 PM은 그것을보고 디자인 관리자와 동등한 것을 시도하고 일치시키기 때문입니다. 그렇지 않다면, 그들은 바보이며 이미 이겼습니다. 그 자체는 일반적으로 그것들을 줄로 끌어 올릴 것입니다. 그들이 당신과 함께 게임을하는 경우, 당신은 호의를 반환 할 수 있습니다.

회의에서 다루는 내용과 시간이 걸리는 이유에 대한 기술적 세부 사항을 살펴보십시오. 그들은 이것을 알고 (그리고 그들이 당신을 도울 수있는 방법을) 알고 싶어하지만 슬픈 사실은 일반적으로 이런 일이 일어나지 않는다는 것입니다. 눈이 머리로 돌아 가기까지 10 분 정도 걸릴 것입니다. 자, 내가 여기서하고 싶은 것은 아마 합법적이지 않을 것입니다 ... 네, 확인했습니다. 실제로는 불법이며 당신은 오랫동안 감옥에 가고 싶지 않습니다. 요점은 당신이 적극적으로 행동하기 위해 최선의 노력을 기울였으며, 만약 당신이 고가의 사람들을 만나게되면, 당신의 고통은 이제 그들 자신의 것입니다. '에스컬레이션'이 일어날 일이기 때문에 상황이 어떻게 진행될 지에 대한 판단을해야합니다. 당신이있는 곳의 지도력이 절반 정도라면, 올바른 일을 할 것입니다. 당신도 옳은 일을하세요 그렇지 않다면, 당신은 사전에 시장에서 이력서를 가지고 있었을 것입니다 ... 어쨌든 첫 기회에 떠날 것입니다 (그리고 궁극적으로 한 것처럼 보입니다). 리더쉽은 두 그룹으로 나뉩니다. 기술적으로 정통하고 자신의 관점을 즉시 볼 수 있습니다. 아니면 그들은하지 않고 그들은 웃지 않고 그것을 위해 무엇을 할 것인가? 그들이 당신이하는 일을 할 수 있다면, 그들은 이미 그렇게했을 것입니다. 그리고 그들은 웃지 않고 그것을 어떻게 할 것인가? 그들이 당신이하는 일을 할 수 있다면, 그들은 이미 그렇게했을 것입니다. 그리고 그들은 웃지 않고 그것을 어떻게 할 것인가? 그들이 당신이하는 일을 할 수 있다면, 그들은 이미 그렇게했을 것입니다.

변화하는 요구 사항 문제를 마지막에 사용할 트럼프 카드로 유지하십시오. 모든 사람에게 도움이 될 것입니다. 프로젝트 자체와 망할 고객 / 이해 관계자의 이름은 헛된 것입니다. 가장 고통스럽지 않은 방법은 프로젝트에서 일종의 재설정을 수행하는 것이며 PM이 다른 영역으로 조용히 재배정 될 수 있습니다. 기적은 때때로 발생합니다. PM이 회의에서 계약 문제를 제기 한 경우 요구 사항 동결 카운터 계약 요구로 반발하십시오. 내가 우려하는 한, 그들은 이미 당신과 다리를 불태 웠고 개발 팀 전체가 시작했을 때 그런 종류의 마음 게임.

로그 오프하기 전에 : 범위 / 요구 사항 변경-애자일 방법론을 채택하는 가장 좋은 이유 중 하나이므로 고객 / 이해자는 원하는 것에 대해 마음이 바뀌는 것에 대해 책임을 져야합니다.

아, 또 하나 : "나도 모르겠다"진술에서, 항상 내 프로젝트 팀 중 한 곳에서 동료 기술 자나 구성원의 가치를 측정하는 방법에 대한 개인적 벤치 마크였습니다. 나는 당신의 얼굴에 똑바로 있다고 말할 수있는 유일한 사람들을 발견합니다. 주로 그들이 자신의 깊이를 벗어난 것을 아는 사람은 결코 그렇게 말하지 않을 것입니다. 실제 능력이있는 사람에 의해 명확하게 노출 될 수 있습니다. 하트 비트. 다른 한편으로, 정면에 서서 말할 사람은 미지의 문제를 해결하는 방법에 대한 기본 계획을 세울 것이므로 24 시간 내에 더 유용한 답변을 얻을 수 있습니다. 그리고 일주일 안에 더 좋은 것. 아폴로 13 호가 달의 어두운면을 날아 다니면서 "모르는 것"이 ​​많이있었습니다.

그렇습니다. 특히 상근직 직원 인 경우 특히 적기가 발생할 것입니다. 계약 조건은 무엇입니까? 마감일을 놓치면 실제로 해고됩니까? 아니면 보너스를 놓치시겠습니까? 그들은 무엇을 할 것인가?

이것이 제기하는 플래그는 관리자가 새로운 / 친숙하지 않은 기술을 다루는 프로젝트를 관리하고 추정 된 노력에 직접 영향을 미치는 요구 사항을 변경하는 방법을 모른다는 것입니다. 어려운 마감일이 종종 발생하지만 상황을 알고있는 관리자는 직원이 계약을 체결하도록 강요해서는 안됩니다. 늦은 밤과 크런치 시간은 나쁘지만 아마도 코스에 필적 할 것입니다. 그리고 때로는 마감일이 미끄러질 것입니다. 다른 사람이 게시 한 것처럼 일정을 고수하는 유일한 방법은 타임 라인을 유지할 공간이 충분하도록 요구 사항을 조기에 동결하는 것입니다.

당신이 말한 것으로부터, 알람 벨은 몇 달이 너무 늦습니다. 직원들이 이미 잘 모르는 기술을 바탕으로 시간에 민감한 프로젝트를 만드는 것은 일반적으로 위험합니다. 요구 사항 수집 및 범위 관리에 대한 이해가 없다면 그렇게하는 것은 어리석은 일입니다.

즉, 나는 다른 답변에 동의합니다. 또한 이력서를 아직 업데이트하지 않은 경우 업데이트 할 수 있습니다.

다른 모든 응답자와 마찬가지로 나는 이것이 적기를 제기해야한다는 것에 더 동의 할 수 없었습니다.

PM이 개발 과정에 참여하고 싶지 않은 것 같습니다.

개인적으로 저는 세부적인 사전 사양, 사인 오프, 전체 프로젝트 견적 또는 고정 입찰 가격 (컨설팅 관점에서)을 다루지 않았습니다.

그 이유는 많은 애자일 소프트웨어와 린 소프트웨어 전문가들이 소프트웨어가 고정 된 제조 가능한 실체가 아니라 대부분의 발견 과정이라는 사실을 깨닫고 있기 때문입니다.

많은 사람들이 여전히이 개념에 어려움을 겪고 있으며 PM도 마찬가지입니다. 트레이드 오프에 대한 간단한 이해로 귀결됩니다.

엄격한 선행 사양 및 고정 견적은 변경 비용이 높은 시스템에서 작동합니다. 고층 건물처럼. 엘리베이터 샤프트를 앞쪽으로 지정하는 것을 잊어 버린 경우 일단 건물이 세워지면 실제로 개조하기가 어려울 것입니다. 높은 변경 비용에는 많은 사전 계획, 구성 요소 및 기술의 미지의 학습, 사전 실험이 필요합니다. 이 모든 숙제를 한 후에 만 ​​예산과 비용을 추정 할 수 있습니다.

소프트웨어에서 사람들은 변경 비용이 저렴하다는 생각에 매우 익숙해 져서 릴리스를 보았을 때 변경 사항을 적용하고 응용 프로그램, 비즈니스, 고객에 대한 새로운 이해를 통합하는 것을 활용하고 싶어합니다. 지속적인 기초. 올바르게 활용하면이 모든 것이 좋고 기회가 많습니다. 내가 만나서 함께 일한 대부분의 소프트웨어 사람들은 실제로 계획하거나 조사하는 데 많은 시간을 소비하는 것을 좋아하지 않습니다. 우리 대부분 (PM 포함)은 지속적인 견인력을보고 싶어합니다. 여기에는 작고 점진적인 기능 릴리스로 반복 개발이 시작되었습니다. 변경 비용 이 낮고 기술 부채가 포함 되도록 보장하기위한 테스트 중심 개발과 같은 다른 방법도 있습니다 .

이 작업을 수행하려면 제품 소유자 (PM 또는 고객 또는 QA 팀을 위해 민첩한 발언자)와 개발자 사이의 "계약"이 필요합니다. 개발자는 주어진 반복에서 가장 중요한 것으로 우선 순위가 매겨진 작업에 대해서만 작업하고 그 작업을 영원히 수행하지는 않지만 완전히 통합 된 기능 덩어리를 자주 (예 : 매주 또는 매월) 릴리스하려고 노력합니다. 반대로 제품 소유자는 증분 릴리스를 지속적으로 검토하고 즉각적인 피드백을 제공하는 데 동의합니다. 또한 다음 반복의 우선 순위를 설정하고 반복 기간 동안 마음이 바뀌지 않도록 설정하는 데 동의합니다.

계약의 후반 부분은 PM이 이해하지 못하는 내용입니다. 많은 전통적인 PM은 실제로 그렇지 않습니다. 그들 중 일부는 사양을 제거 할 때 작업이 완료된 것으로 생각합니다. 그들은 문제, 대안, 더 나은 방법 등에 대해 듣고 싶지 않습니다. 단점은 이것이 소프트웨어 개발의 흐름을 방해 할뿐 아니라 테이블에 많은 기회를 남겨서 조직을 해친다는 것입니다.

Agile Manifesto ( http://agilemanifesto.org/)를 살펴보십시오 . 읽을만한 좋은 책은 Mary Poppendieck의 "Lean Software Development"입니다.

행운을 빕니다.

관리자가 상사에게보고 할 때 탓할 사람을 찾고있는 것 같습니다.

'추정'이 '고정 기간'과 같다고 생각하는 불합리한 관리자가있는 경우 가장 좋은 방법은 매우 관대 한 추정 기간을 생각한 다음 두 배로 늘리는 것입니다!

또한 관리자가 요구 사항이 완전히 상세하고 수정되도록 강제하십시오. 그때부터 변경 사항은 새로운 완료 시간의 프로젝트 관리자와 '공식 재협상'없이 해결되지 않습니다.

결국 프로젝트 관리자는 아이디어와 계획을 얻습니다.

이런 종류의 일에 대한 나의 개인적인 경험은 프로젝트 관리자가 해고를 자신의 잘못으로 만드는 동안 당신을 처분하기 위해 종이 흔적을 설정하려고한다는 것입니다. 그것은 매우 붉은 깃발이 될 것입니다. 물론 마일리지는 약간 다를 수 있습니다.

주위에 좋은 답변이지만 내 2 센트를 추가하겠습니다.

확률을 연구하면 "임의 변수"와 같은 것이 있습니다. 그 값을 모르는 숫자이지만 정규 (벨 곡선) 분포 또는 다른 분포와 같은 분포를 모르는 것으로 설명 할 수 있습니다.

요점은, 직업은 어느 정도 시간이 걸리 겠지만, 부정적인 추정이나 긍정적 인면에서, 이전의 추정치가 조금 또는 많이 잘못 될 수 있기 때문에 위험이 있으며 누군가가 위험을 감수해야한다는 것입니다. 일반적으로 사람들이 위험을 감수하면 돈을받습니다. 보험료는 돈이 든다.

컨설턴트로 일할 때는 보통 시간과 재료 계약과 고정 가격 계약에 서명 할 수있었습니다. 시간과 재료로 고객은 위험을 감수합니다. 고정 가격으로 위험을 감수합니다. 고정 가격으로 목표를 달성하지 못하면 아무도 이길 수 없기 때문에 안전 마진이 높아집니다.

고정 된 납기일, 특히 고정 된 요구 사항없이 약정을 요구하는 것은 실제로 위험이 무엇인지 확실하지 않더라도 위험을 이전하려고하는 것처럼 들립니다. 어쨌든 하나의 반응은 단순히 안전에 대한 여유를 두는 것입니다.

추신 당신은 항상 정부 계약과 함께 이것을 참조하십시오. 제안서에 대한 초기 요청, 입찰, 낮은 입찰이 수락 된 후 변경 요청이 들어 오기 시작하여 비용 풍선 및 계약자가 책임을집니다. 적대 관계가 아닌 고객과 계약자 사이에 팀워크 관계가있는 경우 상황이 훨씬 잘 작동합니다.

예, 물론 이것은 전 상사의 경험과 능력에 대한 깃발을 올립니다. 그렇습니다. 대부분의 사람들이 제안했듯이 CV를 업데이트하기에 좋은시기입니다.

예, 다른 답변에서 알 수 있듯이 대부분의 상황에서 해당 계약에 서명하고 싶지 않습니다. 그러나 서명을 고려할 수있는 상황이있을 수 있다고 제안하고 싶습니다.

대부분의 개발자와 관리자는 기능, 마감일 및 예산 사이의 지속적인 마찰을 알고 있습니다. 또한 많은 사람들이 품질을 4 차원으로 지명 할 것입니다 ( "저는 예산이 부족할 경우 원하는대로 모든 요구 사항을 이행 할 수 있습니다.

그러나 또 다른 차원은 위험입니다. 시간의 50 % 만 성공적으로 제공해야하는 경우 예상치를 크게 낮출 수 있습니다. 그들은 훨씬 더 높은 배송 률을 처리하기 위해 채워졌습니다.

여러 가지 방법으로 위험을 해결할 수 있습니다 (패딩 추정값 중 하나임). 관리자는 위험을 기꺼이 받아들이지 않으며 귀하의 어깨에 위험을두기를 원합니다. 일반적으로 보상이 제대로 이루어지지 않으면 그러한 움직임을 거부해야합니다.

예상치 못한 지연을 처리하기 위해 상호 수용 가능한 양의 패딩으로 마감 기한을 지킬 수 있고, 적중시 (매우 큰) 보너스를 협상 할 수 있고, 재정적 인 입장에서 위약금 (예 : 해고 등)을 할 수없는 경우, 요구 사항 변경을 처리하기위한 적절한 조항과 함께 위험을 감수하고 계약에 서명하는 것이 가치있는 "도박"이라는 것을 알 수 있습니다.

이것은 멍청한 일입니다. 궁극적 인 목표가 무엇인지 모르겠지만 소프트웨어 제품을 담당하는 모든 중간 정도의 프로젝트 관리자는 추정치가 정확히 소위 추정치라는 것을 알고 있어야합니다. 그들은 약속이 아니며 소프트웨어 개발자에게 모든 에너지를 배출하거나 어쨌든 그들의 "약속"을 깨뜨리지 않으면 서 그런 약속을 할 수 없습니다.

그러한 계약이 얼마나 터무니 없는지 보여주고 싶다면 다음 두 가지 제안이 있습니다.

a) 계약없이 추정 할 때 프로젝트가 5-10 배 걸리는 지점까지 지나치게 과대 평가하십시오. 프로젝트 관리자가 추정치가 너무 높은 이유를 물으면 계약을 이행 할 수 있다는 것을 말하는 것입니다.

b) 이것은 이미 제안 된 것입니다 : 단일 요구 사항이 변경되지 않도록하는 계약을 요청하고 철자 실수 수정이 포함되는지 확인하십시오. 내 경험상 개발 중에 어느 시점에서 요구 사항이 변경되지 않는 단일 소프트웨어 프로젝트는 없습니다. 프로젝트 관리자는 귀하보다 계약을 위반해야 할 가능성이 높습니다.

프로젝트 관리자가이 두 가지 제안 중 어느 것에 든 동의 할 경우 자신의 생각이 틀렸다는 것을 확신 할 수 있습니다.

그건 그렇고, 어떻게 정규 직원 계약이 어떻게 작동합니까? 다른 국가의 노동 규정에 대해서는 잘 모르지만 회사의 정규직 직원은 누구도 구속력있는 계약서에 서명하여 기한을 맞추고 유효한 사건을 갖도록 강요 할 수 있다고 생각하지 않습니다. 물론 마감일을 지키지 않으면 그들은 당신에게 지옥을 줄 수 있지만 계약을 할 필요는 없습니다. 아무도 당신을 해고하거나 돈을 줄 수 없었습니다. 그들은 최악의 경우 합의 된 보너스를 줄일 수 있습니다. 따라서 다른 국가에서는 이것이 다르지 않으면 심각하게 고려해야 할 것보다 빈 위협처럼 보입니다.

나는 곡물에 반대 할 것입니다.

설명하는 상황은 엔지니어링 팀 수준에서, 특히 늦은 프로젝트 / 릴리스 이후에 이례적인 것은 아닙니다 . 많은 상황에서 경영진과 조직 전체가 실제로 특정 릴리스 날짜에 가입 했을 수 있으며 조직의 다른 부분도 해당 날짜에 맞춰 조정됩니다. 해당 날짜에 관리 체인에 엄청난 압력이 가해질 수 있습니다.

여기에는 일반적인 엔지니어링 프로세스가 시작됩니다. 폭포 모델에 대해 들어 보셨을 것입니다. 이 다른 모델이 있지만, 그들 모두의 최종 목표는 지속적으로 무언가를 제공하는 것입니다 때 이 예상 포함되어 무엇 에 동의했다. 기능 사양, 디자인, 작업 목록 등은 모두이를 예측 가능한 프로세스로 만듭니다. 의사 소통, 위험 분석 및 일정에 대한 기대치를 정기적으로 업데이트하면 놀라움을 줄이고 가능한 빨리 정보를 제공하여 계획을 조정할 수 있습니다. 그리고 네, 기능이 추가되거나 제거 될 때마다 계획이 조정되어야합니다.

내가 함께 일한 일부 팀에서는 추정치에 서명 한 약속으로 취급하는 것을 망설이지 않고 팀과 경영진의 품질을 반영하며 추정하는 데 특별한 기술이 없습니다. 팀 기꺼이 계약서에 서명 시간을 제공하기위한이 잘 작동 팀의 지표가 아니라 붉은 깃발입니다.

나는 자신의 신발에 자신을 넣고 동기가 무엇인지 이해하려고 노력합니다. 예상되는 관리자 / 회계사로부터 현재 상황과 상황을 정당화하기 위해 숫자가 필요합니다.

마감일을 옮기고 마감일을 너무 많이 잃어버린 보드룸에서 조롱 당했을지도 모른다. 그는 막을 수있는 가장 간단한 방법을 시도했다. 여기에 숫자와 서명을 줘! 당신은 다른 쪽 끝에 있고, 그것이 당신에게 불리한 것이라고 만 인식 할 수있었습니다. 견적을 작성하고 조정이 필요하다는 사실을 깨닫는 것이 더 유용합니다. 요청의 동기가 무엇인지, 그가 직면 한 실제 문제가 무엇인지 이해하면 그와 자신을 도울 수 있습니다. 프로그래머로서 우리는 문제를 해결합니다. 이것은 다르지 않으며, 그의 문제를 이해하고 해결하며 그는 가장 친한 친구가 될 것입니다. 할 일이 너무 많아서 개인 벤데타를 그릴 시간이 없습니다! 그는 자신의 작업에 도움이 필요합니다. 가장 간단한 해결책은 누군가가 종이에 서명하는 것입니다! 아마 그는 인형 관리 책에서 "노동자들이 서명하고 숫자에 대한 책임을 지도록 도와주십시오." 재밌지 만 슬픈

"물을 걷거나 사양에서 소프트웨어를 개발하는 것은 둘 다 얼어 붙으면 쉽다."

에드워드 V. 베라 드

요구 사항이 변경되면 초기 추정치가 정확할 것으로 예상 할 수 없습니다. 예, 이것은 붉은 깃발이어야합니다.

계약에 마감 시한을 지키지 않은 것에 대한 벌칙이 명시되어 있습니까? 그렇지 않다면 전혀 문제가되지 않습니다. 당신은 단지 당시의 지식을 바탕으로 견적에 서명하는 것입니다.