끔찍한 견적 다루기

내가 작업 한 최근 프로젝트는 건축가에 의해 심각하게 과소 평가 된 것으로 입증되었습니다. 추정치가 500 % 이상 떨어졌습니다.

불행히도 견적이 고객과 계약을 맺은 후 프로젝트에 참여했습니다. 선임 개발자로서 기능 및 기술 사양을 빨리 깨달았습니다. 큰 격차와 불확실성이있었습니다.

그 결과 비즈니스 및 기술 책임자와 긴급 회의를 소집하여 현실을 알려야한다는 느낌이 들었습니다. 가장 먼저 개발자로서, 나는 이것이 매우 스트레스가 많고 어려운 상황이라는 것을 알았습니다. "비즈니스"는 IT가 무능하고 메신저라고 몇 가지 "글 머리 기호"를 받았다고 비난했습니다.

고객이 계정을 해지하겠다고 위협했지만 현재까지 프로젝트는 아직 완료되지 않았으며 더 이상 직접 관련이 없습니다.

건축가는 사회적으로 좋은 사람 이었지만이 에피소드를 기반으로 단순히 무능한 사람이거나 그의 추정에 영향을 미치는 판매 / 비즈니스 압력이 많았습니다.

프로그래머로서 이런 상황에 대한 당신의 경험은 무엇이며 어떻게 다루어야합니까?

긴 답변이지만 마지막에 요약본이 있으므로 전체 내용을 읽는 데 방해가되지 않으면 요약으로 건너 뛰십시오!

개발자는 문자 그대로 다른 모든 프로젝트를 처리해야했지만 프로젝트 관리로 옮겨야 효과적으로 처리하는 방법을 배웠습니다. 효과적으로 다루는 것은 기대를 관리하고 추정이 어떻게 작동하는지 이해하는 것입니다.

먼저 실사를 제공하지 않고도 추정치를 제공하거나, 추정치를 약속하거나, 추정 정확도의 다른 표시를하는 것이 비 윤리적이라는 전제로 시작하십시오. 다른 사람들은 필요한 작업량을 예측할 수있는 전문적인 능력에 의존하며, 잘못된 표시를하면 그들과 그들의 비즈니스에 해를 끼칠 것입니다.

그러나 실제 생활에서 즉흥 모임이나 늦게 진행 한 프로젝트로 무언가를 제공해야하며, 상급자는 아마도 어떤 수치를 곧바로 내 놓거나 그들이 제공 한 추정치에 대해 언급 할 것으로 기대할 것입니다. 여기에서 기대 관리가 시작됩니다.

문제를 이해하지 않고 숫자를 직접 작성하지 않고 어떤 인물이나 표시를하는 것은 잘못이라고 설명하십시오. 그들의 수치가 매우 정확하다고 가정하면, 당신은 당신이 추정 운동을 직접하기 전에 알 수 없습니다. 그리고 언제 어디서 필요한지에 대한 좋은 그림을 볼 수 있지만 여전히 숫자를 계산할 시간이 필요하다고 말합니다. 그들이 예상 할 수있는 견적은 단 하나뿐입니다 : 견적을 제공 할 수있을 때. 반드시 그 수치를 제공하십시오.

개발자는 다른 사람들의 평가를 먼저 검토하지 않고 책임을지지 않습니다 (또는 수락 한 것으로 해석 될 수 있음을 나타내지 않음). 프로젝트 관리자로서 그것은 완전히 다른 문제입니다. 왜냐하면 실제로 추정 프로세스를 제어 할 수 있기 때문입니다. 추정이 도출되고 검토되는 방식이며 실제 작업을 수행하기 위해 다른 사람들에게 의존해야하며 그들이 최선을 다하고 있는지 확인하십시오.

실사를하지 않으면 서 견적에 대해 언급하지 마십시오. 이것은 윤리적입니다. 변호사 나 의사는 의뢰인 (또는 환자)이 규칙에 따라 행동하고 평가 절차를 먼저 거치지 않는 한 어떠한 조언도 할 수 없다는 것을 절대적으로 분명히 할 것입니다. 귀하는 전문적인 의견을 제시하기 전에 귀하의 질문을 만족시킬 권리가 있습니다.

두 번째 부분은 추정이 어떻게 작동하는지에 관한 것입니다. 소프트웨어 개발 (제조, 금융 시장, 건설) 이외의 산업을 포함하여 추정에 대한 다양한 접근 방식과 추정 프로세스의 작동 방식을 연구 할 것을 제안합니다. 이를 통해 상사 나 의뢰인이 합리적으로 기대할 수있는 것을 알 수 있으며 이상하게도 작업량에 대한보다 정확한 예측을하는 데 도움이됩니다. 그것은 당신의 견적을 방어하는 능력을 향상시킬 것입니다 그리고 당신은 그들이 건축가 또는 영업 사원이 제공 한 수치와 다를 때마다 수치를 방어해야합니다.

일반적으로 작동 방식은 예상치 못한 항목이나 비교적 큰 항목이 있는지 먼저 추정값을 스캔하는 것입니다. 따라서 "비표준"이름을 가진 것을 방어 할 준비를하십시오. 또한 대부분의 작업이 2 일이 걸리고 하나의 단일 작업이 10 일인 경우 모든 작업이 동일한 크기의 순서를 갖도록 더 큰 작업을 분할하십시오.

각 작업에 포함 된 내용, 개발자가 있고 문서를 포함한다고 가정하는 대신 개발자와 단위 테스트를 분할하는 것이 가장 좋습니다. 분명히이 방법으로 상당히 세밀한 추정치를 생성해야합니다.

다음은 시추입니다. 장기간의 업무 분석을 검토하기가 매우 어렵 기 때문에 고객 또는 상사는 다른 전략을 채택 할 가능성이 높습니다. 임의의 비트에 집중하여 전체 견적을 불신하거나 만족할 때까지 드릴 다운합니다. 답변. 전체 추정치의 신뢰성은 무작위 표본에 따라 달라질 수 있습니다! 그러므로 다시 한번, 신중하게 준비하고, 관련 비트 만 포함 시키거나, 엑스트라를 배제하거나,“좋아하기”섹션으로 옮기고, 인물을 어떻게 방어 할 것인지 생각할 시간이 필요합니다.

분명히 기능, 화면 수 등을 기반으로 추정하거나 접근 방식을 혼합하여 접근 방식에 일관성을 유지할 수 있지만, 어떤 방식 으로든 특정 추정 방법을 선택한 이유를 방어 할 수 있습니다. 또한 필요한 작업량을 예측하려는 다른 사람의 시도와 다른 이유를 설명 할 수 있도록 준비하십시오.

약한 추정치의 명백한 징후를 배우십시오.

• 템플릿에서 복사 한 일반 작업 (run-of-the-mill) 작업으로 채워짐 (추정치가 당면한 작업에 따라 다릅니다).

• 굵은 추정치 (예 : 며칠 이상의 작업)

• 프로젝트의 초기 단계 또는 관련된 요구 사항이나 작업에 대한 실제 지식이없는 사람이 추정합니다.

• 실제 행위자가 아닌 사람들이 작성한 추정치

• 모호한 추정치 (무엇이 포함되어 있고, 마찬가지로 중요하지 않은지 명확하지 않음).

• 작업 규모의 순서에 따라 상당한 차이가 있습니다.

실제 구현 세부 사항에 대한 지식없이 다른 사람의 추정치를 평가하고 수치를 뚫어보십시오. 이렇게하면 확실한 증거가 없을 때 다른 사람의 추정을 확인하라는 요청을했을 때 추가 시간 동안 청구를 뒷받침하는 데 도움이됩니다.

요약하면 다음과 같습니다.

• 실사를 할 기회를 갖기 전에 그 문제에 대해 끔찍하거나 어떤 추정도하지 마십시오.

• 처음부터 명확하게 설명하고, 다른 방법으로 생각하지 말고 귀하의 침묵을 동의의 표시로 해석하십시오.

• 이러한 외부 소프트웨어 개발을 포함하여 다양한 평가 방법의 작동 방식, 실제 응용 및 장점을 파악하십시오.

• 견적을 방어 할 준비를하십시오.

• 다른 사람의 추정치를 평가하는 방법을 배우면 크게 부정확 한 수치에 자신을 맡길 필요가 없습니다.

미래를 예측하는 것은 불가능합니다. 예측 ( "추정")을 요구하는 것은 단순히 문제를 요구합니다. 모든 사람이 그렇게하고 모든 사람이 잘못합니다.

"500 %까지"에 대한 당신의 판단은 아마도 건축가의 추정치만큼이나 잘못되었을 것입니다. 결국 "... 현재까지 프로젝트는 아직 완료되지 않았습니다 ..."여기에는 사실이 없습니다.

아무도 "올바른"답을 모른다. 그리고 그것이 끝날 때까지 아무도 알지 못할 것입니다.

완료된 후에도 "원본"추정치 (변경 제어 유무에 관계없이)는 실제로 달성 한 것과 상관이 없을 수 있습니다.

추정은 함정입니다. 조작 된 게임입니다. 당신은 이길 수 없습니다, 당신은 심지어 깰 수 없으며 심지어 게임에서 벗어날 수 없습니다.

편집하다

나쁜 추정을 다루는 것; "레거시"추정치가 잘못 나타납니다 .

거기는. 다른 사람의 추정치에 동의하지 않습니다. 그들은 당신이 필요하다고 생각하는 것을 생략했습니다. 그들은 당신과 다른 작업 범위를 가졌거나 생산성이 다릅니다. 또한 추정치가 단순한 노력 이상인 경우 비용 기준이 다릅니다. 모두 논쟁의 여지가 있습니다. 따라서 견적에 이르는 세부 사항에 대해 이의를 제기하십시오. 전체 숫자에 대해 이의를 제기하지 마십시오 . 요약 에는 실제 정보 가 없습니다 . 추정을 뒷받침하는 개별 세부 사항에 대한 분쟁. 그들이 무엇을 생각하고 있는지 알아보십시오.

당신의 가정이 그들의 가정만큼 잘못되었을 수도 있습니다. 똑같이 가능합니다.

견적 요청시 .

1. 당신은 잘못 될 것입니다.

   1. 그들은 일의 범위에 대해 거짓말합니다.

   2. 당신은 팀의 생산성을 모른다.

   3. 새로운 기술이 무엇이든간에 잘못 표시되었습니다.

2. 이러한 것들을 무작위로 덮기 위해 패딩에 넣을 수는 없습니다. 당신은 실제로 "추정"의 기초를 모르고 있지도 않습니다. 그냥 추측입니다. 극복 해

규칙 1 : 추측 만하기 때문에 조금씩 추측하십시오.

"추정"상황에서 근본적인 질문 은 미래를 예측 하지 않습니다 . 일주일 또는 2 주보다 훨씬 긴 시간 동안 어떤 정확도로도 그렇게 할 수 없습니다. 직접적이고 즉각적인 세부 지식이있는 시간대로 예측을 제한하십시오. 예를 들어 다음 릴리스입니다.

기본적인 질문은 일반적으로 구매자 또는 고객 측의 의사 결정입니다. 문제는 "비용은 얼마입니까?" -불완전합니다. 문제는 "투자 가치가 있습니까?"입니다. 실질적인 문제는 "비용 / 혜택 비율은 얼마입니까?"와 "더 많은 투자가 더 많은 수익을 창출하지 않기 때문에 지출을 중단해야하는 시점"에 더 있습니다. 그게 진짜 질문입니다.

규칙 2 : 의사 결정자를 사실적인 정보로 지원하십시오.

대부분의 사람들은 민첩한 접근 방식을 가장 잘 활용합니다. 첫 번째 릴리스 (현재부터 한 달)는 5 명 × 4 주가 소요되며 일일 손실 $ 1m를 수정하는 기능 X와 주당 2 억 달러 손실 기회를 수정하는 기능 Y를 제공합니다. 현재하고있는 일에 대한 자세한 지식이 있으므로이 예측이 적합합니다. 그 후의 릴리스는 약간 흐릿합니다.

지금부터 1 년 후의 릴리스는 미래에 지금까지 임의의 숫자로만 예측됩니다. 앞으로 6 개월 이상은 땀을 흘리지 말고 간단한 규칙을 사용하십시오.

그들이 TCO가 무엇인지 물어 보면 정직해야합니다. "개발 비용 지불을 중단하면 총 비용이 발생합니다. 지불을 중단 할 때까지 항상 비용이 발생합니다."

실제 문제는 "어떤 문제를 해결하려고합니까?"입니다. 또는 "어떤 새로운 기회를 찾고 있습니까?" "그게 무슨 가치 야?"

규칙 3 : 소프트웨어가 해결해야하는 문제보다 비용이 적게 듭니다.

문제를 잘 모르면 추정치가 인식에 맞도록 게임 화됩니다. 이것을 피하십시오.

가능성에 . 질병 또는 사고를 쇠약하게하는 것을 제외하고 소프트웨어 개발의 일부는 실제 확률에 의해 지배되지 않습니다. "위험"은 단순히 나쁜 관리입니다. 일반적으로 "우리는 비즈니스 요구 A 또는 기술 B의 복잡성을 설명하지 않았습니다"라는 형식입니다. "문제 나 기술에 대해 더 많이 배웠을 때 일정 범위를 변경했습니다"라는 형식의 경우가 종종 있는데 "scope creep"으로 처벌됩니다.

학습 내용과 범위를 변경할 가능성이 없습니다. 확실합니다.

계획에 . "계획"이 있고 "추정"이 있습니다. 무엇을 구축할지 계획하는 것이 점검표 또는 의존성 그래프로 가장 잘 표현됩니다. 필요한 노력을 "추정"하는 것은 알 수없는 요소에 기초합니다.

"계획"은 정상적인 관리입니다.

"추정"에는 알 수없는 지식이 필요합니다. "노력을 정확하게 추정"하려면 제품에 대한 소스 코드 수준의 통찰력이 있어야하며 어떤 사람이 해당 소스 코드를 입력 할 것인지와 개인이 저지르는 실수를 알아야합니다. 당신이 그것을 알 수 없기 때문에, 모든 추정은 틀렸어 야합니다. 그리고 오해의 소지가있어 잘못된 점이 종종 있습니다.

추정치가 500 % 나갔는데도 프로젝트가 계속 진행 되었다면 추정치는 얼마입니까?

없음 사람들이 불행하게 만드는 것은 전부였습니다. 그러나 어쨌든 프로젝트는 진행되었습니다.

아무도 미래를 볼 수 있기 때문에, 추정의 점점 잘하는 것은 아무 의미가 없습니다. 유용하게 만들어 사람들이 결정을 내 리도록 도와줍니다.

수평선을 짧게 유지하십시오. 최대한 빨리 가치를 제공하십시오. 고객이 언제든지 프로젝트를 취소하고 여전히 가치가있는 계획을 작성하십시오.

계획이 프로젝트에서 유일하게 "신성한 진리"가되지 않도록하십시오. 전달 가능한 기능은 신성합니다. 결과물이 바뀔 때마다 다른 모든 것이 바뀌어야합니다.

계획이 창출하는 가치를 넘어서는 것을 허용하지 마십시오.

시간이 충분하지 않으면 시간이 충분하지 않습니다. 어쨌든 프로젝트를 끝내는 마법의 해결책은 없습니다. 내 의견으로는 당신은 당신이 그것을 진술 할 수있는 일을했습니다. 그들이 어려운 길을 찾아야한다는 것이 밝혀졌습니다. 그것이 보통가는 방법입니다. 바라건대 건축가와 경영진이 실수를 통해 배우고 다시하지 않기를 바랍니다. 경영진이 당신의 주장을 듣고 적절한 조치를 취하기에 너무 무지한 경우에 이것이 평소와 같이 사업이라면 다른 프로젝트 나 다른 회사를 찾는 것이 좋습니다.

"개발자들은 장인 들이며 장인들에게 할 수있는 최악의 일은 엉터리 제품을 제공하는 것입니다." 어딘가에서 유명한 인용이지만 어디에서나 기억할 수 없습니다.

정직은 항상 존중되어야합니다. 나는 "건축가의 비전"을 받고 있었고 개발자가 전체 솔루션이 작동하지 않는다는 무서운 소식을 들었을 때 우리는 사업부로 가서 끔찍한 대화를 나 had습니다. 그런 다음 개발자는 기능의 80 %로 구성된 새로운 예상치를 제시했지만 시간과 예산에 맞춰 제공했습니다.

비즈니스 단위는 개발자가 진실하게 말하고 그의 회사의 짧은 소식을 인정하고 개를 제공하는 개처럼 일했다는 사실에 의해 인수되었습니다. 그는 항상 정직했기 때문에 우리는 지난 7 년간 우리를 위해 일한 사람입니다.

전체 시나리오는 매우 드물기 때문에 대부분의 비즈니스 단위에서는 귀하가 제공 할 수없는 바보라고 생각합니다. 당신은 바보처럼 당신을 치료하려는 크레 틴을 기쁘게하려고하는 것보다 장기적으로 더 많은 돈을 벌 수 있기 때문에 이런 방식으로 운영하지 않는 고객을 찾아야합니다.

자신의 분야를 모르는 건축가와 관련하여 전염병처럼 피하십시오. 나는 혹독한 방법으로 나와 함께 강화하는 데 사용 된 멘토를 가지고있었습니다. 그는 실수를 일찍 저지르고 수정 한 후 다시는 실수를 저 지르지 않을 경우에만 실수를 용인 할 것입니다. "기술적 인"경험이없는 사람들이 고객과의 위치에있는 것을 허용하는 회사는 "의사 소통"할 수 있기 때문에 비즈니스에서 벗어날 수 있습니다.

나는 한 번이 상황에 직면했다. 사업이 요구 사항을 변경하고 의사 소통 격차가 있었고 고위 경영진이 프로젝트를 적시에 프로젝트에 원했기 때문에 프로젝트 일정이 부족했습니다. 더 나쁘게하기 위해이 프로젝트를 진행하던 한 사람이 우선 순위가 더 높은 다른 격차를 메우기 위해 철수했습니다.

우리 팀은 프로젝트를 마치기 위해 밤을 보냈습니다. 어느 날 밤 새벽 3 시경 (19 시간 동안 일하고 있었다)에 대해 관리자에게 이메일을 보내달라고 요청했다.

그 다음날 우리는 회의를 가졌습니다 (개발자들만). 전체 팀이 주말에 와서 프로젝트가 완료되기 전에도 테스트했습니다. 빠른 수정을 위해 팀에 합류 한 사람은 거의 없습니다. 마침내 우리는 전체 팀 (프로젝트 팀뿐만 아니라)의 노력으로 프로젝트를 전달할 수있었습니다. 우리는 다른 프로젝트에서도 같은 과정을 따랐습니다.

전체 팀 (프로젝트에 참여하지 않더라도)은 응용 프로그램을 테스트하고 빠른 버그 수정을 도왔습니다.

참고 : 우리 팀은 약 25 명으로 구성되어 있으며 다른 팀에서 다른 프로젝트를 수행하고 있습니다.

저의 유일한 조언은 "관리자에게 이야기하십시오. 프로젝트를 제 시간에 맞춰 배송 할 수 없다는 것을 확실히 알려주십시오. 또한 대안을 제공하십시오. 관리자는 항상 아기가 제 시간에 맞춰 배달 될 것을 기대합니다")

비즈니스는 예상보다 시간이 오래 걸린다는 사실을 종종 좋아하지 않지만, 더 적은 비용을 지불하는 것을 선호합니다. 시간이 얼마나 걸리는지 다른 사람에게 빨리 알려줄수록 모든 사람이 상황에 대해 더 빨리 계획 할 수 있습니다. 처음에는 힘든 시간이지만 장기적으로는 더 쉬울 것입니다. 두 번째로 올바르게 가져와 우발 상황을 구축하십시오.

경영진을 다룰 때 한 가지 핵심 사항을 강조하겠습니다. 관리자는 솔루션에 감사합니다.

문제가있는 경영진에게 가야하는 경우 (예 : 추정치가 비현실적 임) 상황을 해결하는 방법에 대한 대안을 포함시키기 위해 미리 열심히 노력하십시오. 예를 들어, 시스템의 가치를 이해하기 위해 파레토 분석 (80/20 규칙)을 수행 할 수 있으며, 비즈니스 가치가 가장 높은 기능에 집중하기 위해 기능을 절단 (최소한 첫 번째 릴리스에서)하는 우선 순위를 지정할 수 있습니다. 시스템의 사용자 정의 부분 등을 대체 할 수있는 대안 (오픈 소스 프로젝트 등)을 찾을 수 있습니다.

5 파운드 가방에 25 파운드의 모래가 들어 가지 않는다는 데는 의문의 여지가 없지만, 경영진이 불쾌한 메시지를 흡수하도록 돕는 것의 일부는 당신이 동맹국이라는 증거를 제공하는 것입니다.

당신이 관심을 가질만한 IEEE 기사 내가 한 블로그 이전에 대해. 주요 내용은 다음과 같습니다.

• 프로젝트 실패의 가장 큰 원인 중 하나는 지나치게 낙관적 인 추정입니다.
• 추정치가 너무 낮은 이유 중 하나는 상단에서 너무 빨리 압력을 전달하기 때문입니다.
• 다른 하나는 견적을 다시 보지 않고 구현하는 동안 스코프 크리프입니다.

먼저 문제의 건축가와 비공식적으로 이야기하고 추정치에 대한 문제 목록을 살펴보고 문제의 위치와 해결하는 데 걸리는 시간의 차이를 확인하십시오.

그런 다음 라인 관리자 / 프로젝트 관리자에게 가서 그와 논의하십시오.

하루가 끝나면 건축가는 ESTIMATES를주었습니다. 따라서 알 수있는 한 변경 될 수 있으며 때로는 대량으로 변경되어 제품 출시와 같은 대체 계획을 세울 수 있습니다. 기능 또는 다른 수단을 줄이는 단계.

하루가 끝나면 위의 작업을 완료하면 더 이상 책임이 없습니다.

고객이나 건축가 보스에게 직접 가면 안됩니다. 이것은 나쁜 감정을 불러 일으킬 뿐이며 거의 항상 책임이 있습니다.

당신이 할 수있는 최선의 방법은 (이 경우 개인적으로가 아니라) 나쁜 추정에서 배우는 것입니다. 배워야 할 한 가지는 아이디어를 구현하는 사람 이외의 다른 사람이 소요되는 시간을 추정하지 못하게하는 것입니다. 프로그래머의 속도는 순서에 따라 다를 수 있으므로 다른 사람을 추정하는 것은 불가능합니다.

나는 당신의 고통을 느낍니다 ... 나는이 모든 좌절감을 어떻게 다룰 지 잘 모르겠습니다 :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

과거에는 영업 부서에서 고객이 지불 할 것이라고 생각한 수치를 충족시키기 위해 견적을 삭감 한 프로젝트 관리자와 거래해야했습니다. 관리자는 허락을 구하는 것보다 용서를 구하는 것이 낫다는 의견을 가지고있었습니다.

그렇기 때문에 개발자는 관리자가 예상치 못한 것을 알고 있기 때문에 추정치를 채우는 법을 배웠습니다. 따라서 추정치를 두 배로 늘리고 30 %를 추가하면 합리적인 일정을 얻을 가능성이 높습니다.

고객은 항상 더 저렴한 것을 원하며, 합리적인 견적을 받으면 고객은 그 비용을 감수하고 비용을 줄이거 나 걷기를 요구합니다. 그러나 너무 높으면 토론없이 걷기 만하면됩니다 ( "우리는이를 고려하여 다시 연락하겠습니다").

관리되는 기대치의 게임입니다.

문제는 원래 추정치가 나오지 않았다는 것이 아니라 경영진이 당신을 믿지 않았기 때문입니다.

경영진이 결정을 내리는 가장 좋은 방법은 다음과 같습니다.

1. 이를 뒷받침하는 증거로 문제를 설명하십시오. 과
2. 고객이 선택할 수있는 여러 가지 솔루션을 제공합니다 (최소에서 가장 선호하는 순서로).

(1) Scrum을 구현하고 회피 추정치에 대한 실제 추적을 위해서는 주장을 뒷받침하는 것이 좋습니다.

(2) 나의 옵션 중 하나는 "클라이언트와 함께 우선 순위 기능 목록 개발 (일명 Scrum 용어의 제품 백 로그)"입니다. 고정 가격이나 관료적 인 조직에서는 까다로울 수 있지만 가능합니다 .

희망이 도움이됩니다!

나는 (나는 코딩하는 모든 사람에 대해 확신한다) 공감한다. 내 마지막 회사는 이것에 대해 꽤 끔찍했습니다. 판매원이 들어 와서 프로젝트를 팔았을 때 당신이 들어 와서 견적을보고 웃습니다.

Tomh가 언급했듯이 하루에 너무 많은 시간이 있습니다. 자지 않아도

세 가지 생각합니다.

대부분의 시간을 당신은해야 고객의 기대를 관리 하고 투명하게 . 할 수있는 일을 잘하고 자신이 한 일을 모두 보여주십시오. Totophil이 언급 한 것처럼 너무 거칠게 요구되는 요구 사항을 처리하는 경우 특히 그렇습니다.해야 할 작업량을 볼 수 있다면 추정치가 얼마나 나쁜지를 알 수 있습니다. 그들이 생산성과 진전을 본다면 그것은 내 경험상 무엇보다 중요합니다.

기대치를 관리하고 워크로드를 투명하게하는 것 외에 다른 중요한 것은 범위 관리 입니다. 스코프 나치가되는 데 항문 / 공격과 자신의 꼬리 끝을 덮는 것 사이에는 넓은 영역이 있습니다. 누군가이 추가 기능을 원할 때 동의하십시오! 그리고 그들에게 프로젝트에 추가 것이다 얼마나 많은 시간에 상대적으로 정확한 추정 줄이의 상승은 아니다 (또는 다음 릴리스.) 하지 다른 80시간 주에 자신을 밀어 넣는 - 당신도에 그 추정의 일부 패드를 얻을 가능성 다른 사람을 따라 잡으십시오.

행운을 빕니다!

보거나 이해하지 않고는 절대로 아무것도하지 마십시오. 고객 또는 자신의 mgmt가 당신에게 그렇게 많은 돈을 줄 의향이 없다면, 그들은 당신을 성공으로 설정하지 않습니다.

세부 사항, 데이터 및 구축중인 응용 프로그램 전체에서 상호 작용하는 방식을 이해하지 못한 경우가 많았습니다. 가정은 질문을하고, 답을 찾고, 그것을 모두 못 박는 대신에 이루어진다.

내가 종종 내 고객에게 말하고 싶은 한 가지는, 만약 당신이 나를 교수형에 처하게한다면, 적어도 내 자신의 밧줄로 나를 교수형 시키거나 다른 사람이 아닌 내 자신의 총과 총알로 저를 쏘게하는 것입니다.

그것을 해결하려는 사람들의 회전문을 갖는 것은 결국에는 훨씬 더 나빠질 것입니다.

비현실적이고 열악한 계획과 예측력 부족은 조직 전반에 걸쳐 문제가 발생했다는 신호일 수 있습니다.

먼저, 프로젝트 범위를 과대 평가하고있을 가능성을 고려하십시오. 영업 사원과 건축가는 솔루션을 과장하는 경향이 있습니다. 액면가로 가져 가지 마십시오. 그들은 아마 당신이 고객에게 약속 한 것보다 적은 것을 생각 해낼 것을 기대합니다.

내가 여기서 할 일은 내가 가진 시간을 가져서 가능한 한 현명하게 쓰는 것입니다. 고객의 우선 순위를 파악하고이를 이행하십시오. 아홉 번 중 아홉 번, 고객은 자신의 최우선 순위가 충족되어 기쁘고 완료되지 않은 작업의 80 %를 간과합니다.

마지막으로해야 할 일은 긴급 회의를 부르고 사람들이 악하다고 비난하는 것입니다. 당신은 말한다 :

"현실을 알려줘"

그러나 현실은 단지 의견 일뿐입니다! 당신의 일을, 휴식, 그리고 상관 것들에 politcal 자본 지출 당신 . 승진, 더 많은 돈, 더 많은 휴일처럼.

당신의 상사는 고객을 위해 열심히 일하는 판촉을 거래하는 것이 합리적입니다. 고객을 대신하여 건초를 가지고 가지 않습니다.

기억해야 할 것은 스코프 크리프 또는 피할 수없는 지연 (또는 클라이언트가 특정 형식의 정보 파일과 같은 정보를 제공하지 않은 고객에 따른 문제)에는 추정치에 포함되지 않는다는 것입니다.

우리는 이러한 일 중 하나가 발생할 때마다 견적 및 / 또는 마감일을 모두 철회하는 법을 배웠습니다. 새로운 기능을 추가하고 새로운 견적과 새로운 마감일을 얻으십시오. 합의한 날짜에 필요한 정보를 제공하지 못하고 새로운 마감일을 얻으십시오. 정보를 제공하되 정보가 불완전하거나 부정확하거나 약속 된 것 이외의 방법으로 작성하고, 새로운 견적 및 기한을 보내고, 합의 된 기능의 요구 사항을 변경하고, 새로운 견적 및 기한을 얻으십시오. 고객이 더 높은 우선 순위로 작업하기를 원했기 때문에 프로젝트 작업을 중지하고 새로운 마감일을 보내십시오 (그리고 프로젝트가 오랫동안 보류되어 있으면 시간이 걸리기 때문에 새로운 추정치가 발생할 수 있습니다).

원래의 추정치가 개발 그룹 외부에서 왔고 그것들이 구성되지 않은 경우, 그것을 얻었을 때, 자신이 가질 것으로 예상되는 모든 작업의 ​​세부 수준에서 훨씬 더 높은 수준으로 자신의 추정치를 준비하십시오 귀하가 제공 한 견적보다 자세한 정보를 제공하고 즉시이를 체인에 제공하고 귀하가받은 견적을 충족시키기 위해 무엇을 잘라야하는지 문의하십시오.

대답이 아무 것도 없다면, 고객에게 새로운 견적을 통보하십시오. 이제 우리는 그 문제를 더 깊이 살펴 보았습니다. 경영진이 여전히 고객에게 X 시간 만 지불 할 것을 요구하는 경우, 설명 된 작업이 예상보다 적은 시간 동안 수행 될 수 없기 때문에 나머지 개발 시간에 대해 지불 할 담당자에게 문의하십시오. 회사가 적중을 감수하고 시간을 지불 할 의사가 있음이 밝혀 질 수 있습니다.

만약 그들이 이익에서 그것을 기꺼이 제거하지 않고 고객에게 더 많은 시간이 필요하다고 말하지 않으면 회사는 개발 직원의 판매량에 대한 자세한 추정치를 뒷받침하지 않을 것입니다. 프로젝트를이기려면 "추정치, 당신은 죽음의 행진 프로젝트에 있고 최선의 방법은 가능한 빨리 나가는 것입니다. 당신은 그들이 지불하기로 합의한 50 시간을 소비하고 실제로 필요한 500을 달성하기에 가까워지지 않을 때 프로젝트가 가능한 한 빨리 시간이 더 걸리는 것을 알면 고객이 더 행복 할 것이라고 지적 할 수 있습니다. 지나치게 낙관적 인 견적은 프로젝트 실패의 가장 큰 예측 요인 중 하나임을 상기 시키십시오. 이러한 유형의 회사에서는 작동하지 않지만 충분한 시간을 반복하면 결국 침몰 할 수 있습니다.

나는 또한 추정 개선을 고려할 것이다. "지금 보시다시피이 프로젝트에는 X 인 시간이 걸립니다". 20-30 % 후에 나는 다시 추정 할 것이다.

결국 파일 다운로더는 어떻게 평가합니까? 지속적으로 개선합니다.

나는 견적이 충분하지 않다고 생각합니다. "추정은 당신이 저에게 수학을 요구하고 미래를 유용한 방식으로 예측하도록 요구합니다."와 "우리가하는 약속은 우리가하는 수학과 완전히 분리되어 있습니다 우리는 어리석은 양의 작업을 수행하고, 마무리 할 수없는 것으로 보이는 것에 동의 할 수 있지만,이 중 어느 것도 솔루션 의 수학 을 바꾸지 않습니다. " 기능 B의 배치는 날짜 B에 의해 수행되어 실패 가능성이 훨씬 줄어 듭니다. "

많은 견적에는 협상의 언어가 적용됩니다. 그들은의 언어 누이 할 필요가 수학 과의 불확실성에 대해 이야기 수학 .

견적 담당자는 협상하는 비즈니스맨의 의지에 현실을 구부리지 않습니다. 그의 유일한 직업은 그들이 시도를 멈추게하는 것입니다.