새로운 기술에 대한 학습 곡선을 포함시켜야 할 때 프로젝트를 어떻게 추정 할 수 있습니까?

때로는 기술, 개념 및 고객에 대해 사전에 알려진 것이없는 연구 개발 프로젝트가 있습니다. 그러나 관리자는 여전히 예상 시간이 필요합니다. 유용한 견적을 작성하려면 어떻게해야합니까?

솔직히, Nassim Nicholas Taleb는 자신의 저서 The Black Swan에서 '우리는 단지 예측할 수 없습니다'라고 썼습니다. 주로 미지의 미지수 때문이다. 일반적으로 견적을 전달하는 대신 예측할 수 없다는 사실을 전달하는 것이 가장 좋습니다.

Taleb는 다음과 같이 썼다. 정확하게 잘못하는 것보다 광범위하게 옳을수록 좋다. 따라서 추정하기가 어렵다는 사실을 알리고 '신기술 학습 곡선'과 같은 것을 인수 중 하나로 사용하십시오. 이는 귀하의 추정 범위가 클 것임을 의미합니다. '이 프로젝트는 100k에서 500k 사이 여야합니다.'

그러한 것을 말함으로써, 당신이 무언가를 추정하도록 요구하는 것은 일이 그렇게 간단하지 않다는 것을 깨닫습니다.

가장 먼저 필요한 것은 범위에 대한 아이디어입니다. 더 구체적 일수록 더 좋지만 모든 형태의 요구 사항을 사용하여 초기 추정치를 생성 할 수 있습니다. 고객 요구 사항, 비전 및 범위 및 개념 문서는 초기에 사용할 수 있습니다. 요구 사항과 운영 환경이보다 명확 해지면 추정치가 향상됩니다. 클라이언트 (특히 클라이언트와 개발 조직 간의 인터페이스), 작업을 수행하는 팀, 사용할 기술, 시스템 아키텍처 및 세부 설계에 대한 이해가 높아지면보다 정확한 평가에 도움이됩니다. 이것은 불확실성의 원뿔에서 볼 수 있습니다.

SLIM 또는 COCOMO와 같은 파라 메트릭 모델링 도구를 사용하는 경우 (기본은 비용 동인을 고려하지 않기 때문에 중급 또는 고급 만 해당) 기술에 익숙하지 않은 조정 요소가 있어야합니다. 예를 들어, COCOMO에는 시스템을 개발하는 데 사용되는 언어 및 도구뿐만 아니라 대상 플랫폼에 익숙하도록 특별히 설계된 드라이버 를 포함하여 많은 비용 드라이버 가 있습니다. SLIM은 또한 개발 팀의 전반적인 경험을 설명하며 여기에는 사용중인 도구와 기술에 대한 고려 사항이 포함되어야합니다.

이 기술을 사용하면 모델링 도구의 출력이 여러 조직에서 수년에 걸쳐 이전 소프트웨어 프로젝트를 성공적으로 추정하는 데 성공적으로 사용 되었기 때문에 일반적으로 검증됩니다. 그러나 출력은 공구 입력만큼 우수합니다.

추정에 모수 적 모델을 사용하지 않는 경우 추정치를 생성 할 때 이러한 요소를 간단히 고려해야합니다. 더 많은 판단이 필요하지만 문서를 읽고, 새로운 개발 환경을 설정하고, 대상 플랫폼에서 또는 대상 언어로 샘플 애플리케이션을 개발하는 등의 활동을 고려할 수 있습니다.

이러한 경우, 추정치를 작업별로 분류하고 전문적인 판단을 사용하여이를 백업 할 수 있어야합니다. 바라건대, 추정치에 근거한 과거 데이터 및 기타 구체적인 증거가 있기를 바랍니다. 그렇지 않으면, 오르막 전투에 가깝습니다.

주요 교육 및 연구 시간을 개발 시간과 분리하십시오. 프로젝트를 행복한 결말을 가진 여러 하위 프로젝트로 나눕니다. 교육 후에 개념 증명을 작성해야합니다.

이 기술을 처음 사용한다면 실제 개발 시간에 근접하지 않을 것입니다. 프로젝트 시작시이를 위험으로 제기하고 추정치에 관대하십시오. 이는 귀하와 귀하의 팀이 잘 모르는 핵심 기술에 적용됩니다.

필자는 대부분 FPA ( Function Point Analysis )를 사용 했지만이 "엔터프라이즈 웹 개발"에 참여 했으므로 Forbes 500 웹 회사를 알게되었습니다.

작업은 항상 두 부분으로 나눌 수 있습니다. 하나는 FPA에 매우 적합합니다. 입력 인터페이스, 출력 인터페이스, 내부 논리 파일 (일명 데이터베이스 테이블 / 내보낼 유형) 및 복잡하고 알려지지 않은 시스템이 있습니다. .

쉬운 버전에서 복잡한 작업은 이미 작성된 구성 요소이며 인터페이스와의 인터페이스는 어렵고 알 수 없습니다.

하드 버전은 언제 작성해야하는지, 파일럿 기반 평가, COCOMO 등이 필요합니다.

그러나 중요한 두 가지 :

1. 모든 종류의 평가 시스템에는 조직에 대한 교정 시간이 있어야합니다. 적어도 혼자서 개발하지 마십시오. 최소한 고객이 코드를 기다리고 있습니다. 문제는 "얼마나 빨리 개발 될 수 있습니까?"가 아니라 "모두 얼마나 빨리 개발할 수 있습니까?"입니다.

2. 그 검은 백조 소설을 읽고 그것에 대해 미치광이가 된 관리자가있었습니다. 그는 우리에게 추정하는 것이 불가능하다는 것을 말하고 있었고, 나는 평소 정밀하고 + -10 %의 추정을 끊임없이 반복하고 있었다 ...

나는 그 설명에 어느 정도 규칙적으로 맞는 프로젝트를하는데 아직 이것을 이해하지 못했습니다! 고맙게도 내가 일하는 곳에서 쓸데없는 시간 제한이 없어야 할 일을 할 수있는 위도가 주어졌습니다. 프로젝트가 항상 성공적인 것은 아니며 많은 미지의 사람들이하는 일의 일부일뿐입니다. 회사는 매번 지식을 얻습니다.

전혀 도움이되지 않습니다 죄송합니다.

익숙한 기술을 사용하여 유사한 프로젝트를 수행하는 데 걸리는 시간을 추정하십시오. 4를 곱하십시오. 학습 시간을 더하십시오.

추정치가 너무 짧으면 순진하고 거만 해 보일 것입니다. 추정치가 너무 크면 무지하고 무능한 것으로 보일 것입니다. 현명하게 선택해.