견적을 요청할 때 어떻게 응답합니까?

우리는 프로그래머로서 '얼마나 오래 걸립니까?'

그리고 상황은 거의 항상 다음과 같습니다.

• 요구 사항이 명확하지 않습니다. 모든 영향을 심층 분석 한 사람은 없습니다.
• 새로운 기능은 아마도 코드에서 가정 한 일부 내용을 어 기고 리팩토링해야 할 모든 것을 즉시 생각하기 시작합니다.
• 과거의 과제에서해야 할 다른 일이 있으며, 다른 일을 고려한 견적을 내야합니다.
• '완료'정의는 불분명 할 수 있습니다. 언제 수행됩니까? 코딩을 마친 것처럼 '완료'또는 "사용자가 사용하고있는"것과 같이 "완료"?
• 당신이이 모든 것들에 대해 얼마나 의식적이든간에, 때때로 "프로그래머의 자존심"은 당신이 원래 생각했던 것보다 더 짧은 시간을주고 받도록 만듭니다. 특히 마감 시간과 관리 기대에 대한 압박감을 느낄 때.

이들 중 다수는 간단하고 해결하기 쉽지 않은 조직적 또는 문화적 문제이지만, 실제로는 귀하가 견적을 요청 받고 합리적인 답변을 제공 할 것으로 기대합니다. 그것은 당신의 일의 일부입니다. 당신은 단순히 말할 수 없다 : 나는 모른다.

결과적으로, 나는 항상 내가 성취 할 수 없다는 것을 나중에 알게된다. 그것은 여러 번 일어 났으며 항상 다시는 일어나지 않을 것이라고 약속합니다. 그러나 그렇습니다.

견적을 결정하고 전달하기위한 개인 프로세스는 무엇입니까? 어떤 기술이 유용하다고 생각하십니까?

에서 실용주의 프로그래머 : 저니부터 마스터까지 :

견적 요청시 할 말

"다시 연락하겠습니다."

프로세스 속도를 늦추고이 섹션에서 설명하는 단계를 수행하는 데 시간을 투자하면 거의 항상 더 나은 결과를 얻을 수 있습니다. 커피 머신에서 주어진 견적은 커피와 같이 귀신을 다시 데려 올 것입니다.

이 섹션에서 저자는 다음 프로세스를 권장합니다.

• 필요한 정확도를 결정하십시오. 기간에 따라 추정값을 다른 정밀도로 인용 할 수 있습니다. "5-6 개월"은 "150 일"과 다릅니다. 당신이 7 개월에 조금 빠져도 여전히 정확합니다. 그러나 180 일 또는 210 일에 빠지면 그다지 많지 않습니다.
• 무엇이 요청되는지 이해해야합니다. 문제의 범위를 결정하십시오.
• 시스템을 모델링하십시오. 모델은 정신 모델, 다이어그램 또는 기존 데이터 레코드 일 수 있습니다. 이 모형을 분해하고 구성 요소에서 추정치를 작성하십시오. 각 값에 값과 오류 범위 (+/-)를 지정하십시오.
• 모형을 기반으로 추정치를 계산하십시오.
• 견적을 추적하십시오. 추정중인 문제, 추정치 및 실제 값에 대한 정보를 기록하십시오.
• 기타 요구 사항으로는 요구 사항 또는 요구 사항 사양의 변경 사항 개발 및 문서화, 디자인 문서 및 사양 작성 또는 업데이트, 테스트 (단위, 통합 및 수락), 변경 사항이있는 사용자 매뉴얼 또는 README 작성 또는 업데이트가 있습니다. 2 명 이상의 사람들이 함께 일하는 경우 커뮤니케이션 (전화, 이메일, 회의) 및 소스 코드 병합에 오버 헤드가 발생합니다. 작업이 긴 경우 배달 날짜를 선택할 때 다른 작업, 휴업 (휴일, 휴가, 병가), 회의 및 기타 오버 헤드 작업과 같은 항목을 고려해야합니다.

소프트웨어 추정은 소프트웨어 엔지니어링에서 가장 어려운 단일 작업입니다.

좋은 요구 사항을 먼저 얻는 것에 기초하여 그것들을 만들기위한 많은 전술이 있습니다. 그러나 등이 벽에 닿아 더 자세한 정보를 제공하지 않으면 가짜입니다.

1. 요구 사항을 잘 살펴보십시오.
2. 그들이 원하는 것을 가장 잘 추측하여 차이를 메울 수 있다고 가정하십시오.
3. 적어 모든 당신의 가정을
4. 그들이 앉고 읽고 읽게하고 당신의 가정에 동의하도록하십시오 (또는 운이 좋으면 그들에게주고 실제 요구 사항을 제시하십시오).
5. 이제 추정 할 수있는 자세한 요구 사항이 있습니다.

내가 어렸을 때 어머니가 위협하곤했던 것처럼 "서둘러 옷을 골라 내거나 내가 골라 줄게 !"

정확한 견적을 원하는 것에 대해 매우 단호한 사람을 위해 개발을 수행했습니다. 우리가 잘 해결 한 것은 다음과 같습니다.

• 견적을 보내는 동안 항상 청구했습니다. 내가 청구 한 것의 약 20-25 %가되었습니다.
• 나는 작업에 대해 매우 자세한 조사를 수행했습니다. 엉덩이에서 촬영하지 않습니다. 코드로 들어가서 변경해야 할 줄, 프로그램의 다른 부분, 영향을 미치는 테스트의 양을 파악했습니다. 각 부분을 0.1 시간 (6 분) 단위로 추정합니다.
• 나는 그에게 세부적인 분석과 함께 각 작업에 대한 나의 추정치를 보냈다.

청구의 20-25 %가 많이 들립니다.

그러나 그는 약 2 시간이 걸릴 것이라고 생각하면서 XYZ를 변경하도록 요청했습니다. 1 시간 동안의 자세한 추정에는 8.5 시간이 걸린 것으로 판단됩니다. 그래서 그는 8.5 시간의 지불 가치가 있는지 여부를 결정했습니다. 그렇지 않다면 추정치없이 수행했을 경우 비용을 7.5 시간 절약했습니다.

그가 만약 않았다 8.5 시간을 투자하고 싶은, 내가 추정치를 위해 한 세부 작업은 어쨌든해야 할 일을했을 텐데 일이었다.

이 방법을 사용하면 과도하게 과대 평가하지 않고도 대부분의 작업을 제 시간에 또는 초기에 시작할 수 있음을 알았습니다. 시간이 너무 세분화 되었기 때문에 미끄러지는지 일찍 알 수있었습니다. 3 시간 후에 8.5 시간 작업에 12 시간이 걸리는 것을 알 수 있도록로드 블록을 쳤다면 더 많은 시간이 지나기 전에 그에 대해 이야기 할 수 있으므로 비용에 대해 우려 할 경우 기능을 재평가하고 중단시킬 수 있습니다. .

그는 니켈과 디밍 이었습니까? 아니요, 저는 그가 가장 큰 혜택을 얻은 곳에서 돈을 적용 할 수 있다고 생각했습니다. 그리고 나는 항상 끔찍했던 견적에 대한 경험을 갖게되어 기뻤습니다.

우리는 종종 그들이하고 싶은 일에 대한 매우 광범위하고 모호한 아이디어가 제공되는 회의 중에 "볼 파크 추정"을 요구받습니다. "오늘 답변을 원하면 1 년 백만 달러가 필요합니다. 더 자세한 내용과 시간을 검토해보고 싶으면 그 수를 세분화 할 수 있습니다."

그들은 거의 항상 포인트를 얻습니다.

추정치에 따라 다릅니다.

비즈니스 사례에 대한 초기의 높은 수준의 추정을 위해서는 주요 사항은 다음과 같습니다.

1. 속도. 어떤 방법을 사용하든 빠르게 사용해야합니다. 요점은 이해 관계자가 프로젝트를 수행 할 가치가 있는지 확실하지 않다는 것입니다. 이것이 비즈니스 사례에 필요한 숫자가 필요한 이유입니다. 비즈니스 사례가 탄탄한 경우에는 추정치가 필요하지 않습니다. 이러한 프로젝트의 대부분은 진행되지 않으므로 견적을 제공하기 위해 너무 많은 노력을 기울이지 않는 것이 중요합니다.
2. 범위를 제공하십시오. 넓게 만드십시오. 요구 사항을 분석하고 이해 관계자와의 워크샵을 수행하고 가정을 검증 할 시간이 없었습니다. 넓은 범위는 견적을받는 사람에게 "소프트웨어 프로젝트는 당연히 복잡하고 위험합니다. 적절한 견적을 원하면 더 자세한 정보와 시간을 주어야합니다". 단일 숫자 또는 좁은 범위를 제공하는 문제는 실제 분석을 수행하기 전에 기대치를 설정하여 코너에 페인트한다는 것입니다.

필자는 같은 느낌을 가진 비슷한 프로젝트를 선택하는 가장 좋은 기술을 찾았습니다. "느낌"은 완전히 주관적이지만 이러한 종류의 추정치로 객관적인 측정을 찾을 수 없다는 것을 알게되었습니다. 그런 다음 넓은 범위를 제공하십시오. 나는 -50 %에서 + 100 %의 범위가 좋다고 말하는 책을 읽었지만 많은 요인에 달려 있습니다.

자세한 저수준 추정치 :

1. 기준이 필요합니다. 기준이 안정적이지 않으면 추정값이 의미가 없습니다.
2. 상향식이 가장 좋습니다. 자세한 작업 내역을 확인하고 각 구성 요소를 추정 한 다음 더 큰 숫자로 롤업하십시오. 나는 포커를 계획하는 것이 훌륭한 기술이라고 생각합니다.
3. 문서 우발성. 우발 사태 (있는 경우)가 추가 된 곳을 명확히하십시오. 각 광고 항목에 추가됩니까? 아니면 전체 견적으로? 아니면 특정 위험에? 아니면 아무도 없습니까?
4. 가정을 진술하십시오. 시간 프레임이 주어지면 가능한 한 많은 것을 검증하십시오.
5. 견적에 포함 및 제외 된 내용을 명시 적으로 명시 예를 들어 리뷰가 포함됩니까? 기술적 인 지연이 포함됩니까?

어려운 길을 배운 사람의 어두운면에서 몇 가지 조언.

요구 사항이 명확하지 않습니다. 모든 영향을 심층 분석 한 사람은 없습니다.

이 시점에서 추정하지 마십시오. 적의 수에 대한 실마리가없는 전투에서이기려면 얼마나 많은 군인이 필요한지 추정하지 않습니다. 정찰 후 정찰이 이루어집니다. 당신이 이미이 적과 싸운 경우가 아닙니다.

새로운 기능은 아마도 코드에서 가정 한 일부 내용을 어 기고 리팩토링해야 할 모든 것을 즉시 생각하기 시작합니다.

다른 사람이이 분야에 대한 전문 지식을 갖기를 기대하지 않는 한이를 고려해야합니다.

과거의 과제에서해야 할 다른 일이 있으며, 다른 일을 고려한 견적을 내야합니다.

거의 존재하지 않는 테스트 절차를 사용하여 옆에있는 슬롭 팀 동료가 만든 예기치 않은 작업의 경우에도 위와 동일하게 사전에 완벽하게 예측할 수없는 코드가 고장 나게됩니다. 일기 예보입니다.

'완료'정의는 불분명 할 수 있습니다. 언제 수행됩니까? 코딩을 마친 것처럼 '완료'또는 "사용자가 사용하고있는"것과 같이 "완료"?

여기서 사용자 엔드 요구 사항을 이해하고 사용자처럼 생각하십시오. 사용자가 용납 할 수없는 기본 워크 플로가있는 일부 기본 기능이 "완료"된 것으로 간주되기 때문에 동료가 "완료"된 것으로 추정하는 경우 동료가하는 일을 수행하지 마십시오 . 사용자 관점에서 생각하십시오. 일반적으로 고객이 추정하는 모든 클라이언트가 이해하기 때문입니다. 기본 기술 요구 사항이 아닌 완전한 사용자 엔드 요구 사항을 예측하십시오. 그리고 고객이 견적을 요구하는 것은 고객이 어떻게 말을하고 어떻게 말하는지의 기술적 측면을 이해하는 데있어 정확하지 않을 것입니다.

당신이이 모든 것들에 대해 얼마나 의식적이든간에, 때때로 "프로그래머의 자존심"은 당신이 원래 생각했던 것보다 더 짧은 시간을주고 받도록 만듭니다. 특히 마감 시간과 관리 기대에 대한 압박감을 느낄 때.

이러지 마! 당신은 자발적인 열심히 일하는 사람, 아마도 강압에 쉽게 굴복하는 사람처럼 들립니다.

여기서 문제는 이것입니다. 당신과 Joe가 같은 작업에 대한 시간 추정을했다고 가정 해 봅시다 (그러나 한 번에 두 추정값을 모른 채 두 명의 개별 직원 사이에서). 용감하게 "일주일"을 추정 합니다. 일주일에 100 시간 이상, 무급 초과 근무를하게 될 것입니다. 이제 3 일 늦었 어.

한편 Joe는 5 개월로 추정됩니다. 당신은 이것이 말도 안된다고 생각합니다. 일주일 안에 이것을 풀 수 있다고 생각합니다. Joe는 얼마를 일합니까? 일주일에 10 시간? ... 정확하게 5 개월 만에 제 시간에 끝나는 것을 제외하고.

누가 멍청이로 인식 될까요? 맞습니다. 조는 훌륭한 일꾼 인 것 같아요 Joe가 소요 한 시간의 ~ 7 %에서 더 나은 결과를 얻었을 수도 있습니다. 중요한 것은 당신이 일주일 추정에서 3 일 쉬었다는 것입니다.

더 엄격한 추정치에 실수하지 마십시오. 더 느슨한 추정치의 측면에서 오류가 발생했습니다. 회사에는 명성이 있으며, 추정의 정확도만큼 추정의 길이를 기준으로하지는 않을 것입니다. 예상 시간이 너무 길면 정확하기가 쉽고 문제에 대해 더 많은 시간을 할애하여 더 잘 해결할 수 있습니다. 너무 짧은 추정치는 호흡 실을 전혀 남기지 않습니다. 필사적으로 만났거나 망쳤습니다.

"2 주!"

진심으로. 나의 첫 견적은 항상 2 주입니다. 나는 어떤 종류의 기괴한 정신 블록이 있기 때문에 모든 것이 2 주일 것이라고 생각합니다.

나는 정말하려고 그것을 해결하려고 생각 도 블랙 박스-Y 나를 정확하게 추정 될 찾는 모든 잠재적 인 문제 지점과 비트를 식별하기 위해 노력하고, 뭔가 걸릴 것이라고 생각하는 시간에 대해. 그리고 나의 대답이 "2 주일!"이라면, 나는 그렇게하지 않았다는 것을 인식하려고 노력하십시오.

내가 가진 모든 훌륭한 관리자는 "2 주!"를 인식하는 법을 배웠습니다. 응답으로 가벼운 구두 포주 때리기를 요구하는 답변으로.

이 블로그 항목 이전 추정 사라 얼마나 정확한 기록을 유지하고 당신이 누군가에게 말 다음에 "2 주있을거야", 당신은 이전의 역사를 볼 수 있습니다 볼 방법에 대해 설명합니다 얼마나 실제로 "2 주일 것"이라고 말한 시간이 실제로 걸렸습니다.

나는 그것을 직접 시도하지는 않았지만 내 추정이 얼마나 정확한지 알고 싶습니다.

조직 및 추정치 사용 방법에 따라 다릅니다.

견적이 언제 준비가 될지에 대한 일반적인 아이디어를 제공하는 것이라면 일반적으로 내 경험을 바탕으로 빠른 견적을 할 수 있습니다. 종종 변경 사항이 시스템의 다른 영역에 미치는 영향과 회귀 테스트 범위에 대한 추정치와 함께 불확실성 또는 가능한 변형을 포함하는 경우가 종종 있습니다.

견적이 계약 상 또는 더 정확한 타이밍이 필요한 시나리오에 사용되는 경우 전체 작업을 수행합니다. 이것은 더 많은 작업이며 시스템의 설계 및 변경에 대해 더 깊이 생각할 필요가 있지만 특히 더 큰 작업에 대해서는 훨씬 더 정확합니다.

두 경우 모두 지속적인 커뮤니케이션이 핵심입니다. 예상치 못한 일이 발생하면 마감 시한까지 기다리지 말고 알려주십시오. 요구 사항이 명확하지 않은 경우 요구 사항과 제공하려는 기능에 대한 이해를 문서화해야합니다. 이것은 또한 모든 가정에 도움이됩니다. 또한 경쟁 우선 순위에 따라 한 작업이 다른 작업에 충돌 할 경우 일정에 어떤 영향을 미치는지 명확하게 알 수 있습니다.

무엇에 대한 견적? 소규모 작업 또는 완벽한 솔루션.

후자는 거의하지 않지만 조금만 추측하고 비트를 추가하고 관리자가 비트를 추가하고 범위를 만들도록하십시오. 옆에 위의 내용이 추측이라는 작은 메모가 있습니다.

작은 작업- 내가 정말 잘 작동하는 것으로 알려진 포커 계획

오늘 알고있는 것을 기반으로 범위를 제시하십시오. 불확실성 원뿔을 사용 하여 초기 추정치 주변의 범위를 제공하십시오.

매주 얼마나 남은 일을 계산하고 아는 바에 따라 재 추정하십시오. 매주 얼마나 많은 작업을 수행했는지에 대한 표본 크기가 충분하면 프로젝트가 진행됨에 따라 (일반적으로) 좁아진 날짜 범위와 남은 작업량에 대한 90 % 신뢰 구간을 제공하십시오. )가 줄어 듭니다.

자신있게. 견적을 내릴 때 전문성을 갖지 않음으로써 고객과의 초기 회의를 몇 번이나했는지 몇 번이나 말할 수 없습니다. 얇은 공기에서 숫자를 날려도 항상 추정값을 유지하십시오. 즉, 구멍에 자신을 추정하지 않도록주의하십시오. 서로 다른 일을하려면 서로 다른 시간과 노력, 자원이 필요합니다. 좋은 방법은 다음과 같습니다.

그들 : 비용이 얼마나 듭니까?

나 : 그것은 당신이 원하는 것을 따라 달라집니다. 일반적으로 이런 종류의 프로젝트를 약 $ X에서 시작합니다.

때로는 소프트웨어 프로젝트 추정에 대해 이야기 할 때 추정이 귀사와 팀에게 큰 도전이되기도합니다.

우리는 우리의 경험과 소프트웨어 평가 프로세스에 대한 우리의 지식을 공유하기로 결정하고 정의 한 후 추정의 네 가지 유형을 :

• 어림 잡은 수치
• 서비스 견적
• 기능 추정
• 성분 추정

물론 이러한 유형은 다릅니다. 야구장은 종종 "추측" 이라고 불립니다 . 따라서 대략적인 비용 또는 범위로 비용에 대한 일반적인 아이디어를 제공하며 잠재 고객이 논의를 계속 진행할지 여부를 결정하는 데 도움이 될 수 있습니다.

일반적으로 고객은 프로젝트 시작시 야구장 수치가 필요합니다. 우리의 조언은 프로젝트에 대한 토론과 야구장 수치 제공은 구성 요소 추정치 를받는 단계에 불과한 단계 여야한다는 것 입니다 (유연성, 전체 개발 프로세스에 구성 요소 유형 추정치를 사용할 수 있음). 기능, 서비스 등을 추가, 제거 또는 교체하려는 경우).

과소 평가, 과대 평가, 총체적인 실패 시나리오 등 소프트웨어 개발 예상에 따른 위험을 모두 염두에 두어야합니다 .

블로그에서 더 많은 것을 읽을 수 있습니다!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

이 정보가 도움이 되길 바랍니다.

나는 항상 내가 성취 할 수 없다는 것을 나중에 알게된다. 그것은 여러 번 일어 났으며 항상 다시는 일어나지 않을 것이라고 약속합니다.

견적이 아닌 약정을 요구받는 것처럼 들립니다. 이것들은 서로 다르지만, 약속을 확실하게 관리 할 수 ​​있다면 신뢰와 경력에 실제로 도움이 될 것입니다.

~ 10 년의 경험을 바탕으로 한 몇 가지 조언 :

• 항상 범위를 제공하십시오 (예 : 하한 및 상한). 이것은 당신의 불확실성 수준을 알려줄 것입니다
• 불확실성이 매우 큰 경우 연기를 요청하십시오 (예 : 1 일 분석을 수행 한 후 더 좁은 범위 제공)
• 작업이 너무 큰 경우이를 분해하여 각 조각에 대한 범위를 제공하십시오.

첫째, 일부 작업이 나에게 할당되면 하위 작업으로 분류하고 각 하위 작업의 시간을 추정하고 하위 작업을 사용하여 문제가있는 영역을 찾을 수 있으므로 얼마나 오래 걸릴지 예측할 수 있습니다. 어느 정도 취하십시오.

그러나 여전히 모든 계획은 어느 정도 도움이 될 것입니다. 코딩을 시작할 때만 정확한 문제를 찾을 수 있습니다

동일한 보스 또는 클라이언트에 대해 많은 프로젝트를 수행하는 경우 몇 주 또는 몇 달이 아닌 t- 셔츠 크기로 복잡한 복잡성으로 추정 할 수 있습니다. 몇 가지 과거 프로젝트를 식별하고 S, M, L, XL 크기를 지정하십시오.

그런 다음 자신에게 물어보십시오. 범위와 비슷한 프로젝트는 무엇입니까? 그런 다음 "2 개월"로 대답하는 대신 "나에게 L과 같은 소리"(또는 프로젝트에 대한 교정이 무엇이든)로 대답 할 수 있습니다.

이것은 이해하기가 쉽고, 그 추측에 많은 불확실성이 있음이 분명합니다.

그런 다음 요구 사항이 변경되면 "그 변경으로 인해 XL처럼 들리게됩니다"라고 말할 수 있습니다.

조금 늦었지만 군대에있을 때는 PERT를 사용하여 견적을 결정하라는 지시를 받았습니다. 그것은 당신의 분야와 당면한 일에 약간의 경험이 필요합니다. 전자 장치 (복잡한 라디오 및 위성 통신 장비)를 유지 보수하고 수리 할 때 예상 완료 시간을 결정할 때 놀랍게도 정확했습니다. 여기서 많은 수의 문제가 있거나 잘못 발견되어 일상적인 유지 보수 중에 수정해야합니다. 다른 장치는 통신 장비를 다시받을 때까지 작동하지 않을 수 있으므로 추정이 중요했습니다. 내가 사용한 것 중 하나는이 무료 온라인 PERT 계산기입니다