프로그래머는 프로젝트 개발 시간을 어떻게 추정합니까?

프로젝트 시간 예측은 프로젝트의 성공 또는 실패에 매우 중요합니다. 프로젝트 시간 관리에는 프로젝트를 제 시간에 완료하는 데 필요한 다양한 프로세스가 포함됩니다. 그러나 실제 프로젝트에서는 프로젝트 지연이 자주 발생하고 견적이 심각하게 부정확합니다.

시간을 가늠하는 것 자체가 어렵습니다. 모든 프로그래머의 추정치는 실제 필요한 시간과 약간 다를 수 있습니다. 예상 시간이 짧습니다. 이는 일부 항목(컴파일, 테스트, 코드 제출)이 무시되었음을 의미합니다. 초과된 시간은 작업이 너무 크고 이해하기 어렵다는 것을 의미하는 것으로 추정됩니다.

주니어 프로그래머에게는 이 추정 오류가 혼란스럽습니다. 그들은 종종 일부 작업을 과소평가하고 약간 더 어려운 작업을 과대평가합니다. 숙련된 프로그래머의 경우 작업은 30분에서 24시간 정도 소요되어야 한다고 생각합니다. 24시간을 초과하는 작업은 분할해야 합니다. 프로그래머들이 머릿속으로 생각하면 60시간이 걸린다고 생각할 수도 있지만, 사실 경험이 많은 프로그래머라도 작업을 제어 가능한 모듈로 나누어 분석하고 의사결정을 내려야 합니다.

깨달아야 할 또 다른 중요한 점은 프로그래밍 경험이 시간 추정 경험과 동일하지 않다는 것입니다. 기간 추정을 한 번도 해본 적이 없는 프로그래머는 시간 추정에 능숙하지 않습니다. 실제 소요 시간과 예상 소요 시간을 비교하지 않고는 다른 피드백 정보를 통해 정확하게 소요 시간을 추정하는 경험을 얻을 수 없습니다.

평가 기술은 모든 프로그래머가 사용합니다. 이 기술을 향상시키기 위해 수행하는 모든 작업을 연습할 수 있습니다. 작업 시작 시 개발에 소요되는 시간을 추정하고 최종적으로는 실제로 소요되는 시간과 비교해 보세요. 이런 방식으로 작업의 세부 사항에 대한 이해도가 향상될 뿐만 아니라 시간 예측 기술도 향상됩니다.

호프스태터의 법칙: 호프스태터의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다.

PM은 왜 회사 개발자가 자신의 프로젝트 시간을 절대 예측할 수 없는지 불평하는 경우가 많습니다. ! 그러나 기민한 프로그래머들은 오랫동안 이에 익숙해져 왔습니다. 심지어 이틀 안에 완료될 것으로 예상했던 프로젝트가 결국 4개월이 걸리는 경우도 보았습니다. 이는 경험상 "시간의 두 배" 법칙에 따르면 상당히 과장된 것입니다. 높은 수준에서 문제는 엔지니어와 PM 또는 다른 사람들이 시간 추정에 대해 서로 다른 접근 방식과 사고 방식을 가지고 있다는 것입니다.

대부분의 엔지니어의 첫 번째 반응은 모든 것이 계획대로 진행될 경우 프로토타입을 작성하는 데 걸리는 최소 시간입니다. PM이나 다른 다운스트림 직원이 알고 싶어하는 것은 프로젝트가 언제 준비될 것인지, 그리고 이때부터 출시까지 얼마나 걸릴 것인가입니다. 그래서 이것은 완전히 다른 두 가지 이야기입니다.

따라서 엔지니어에게 마스터링 시간 추정은 필수 기술입니다. 이는 전문적이고 안정적이며 효율적인 개발자임을 의미합니다.

시간 추정이 왜 필요한가요?

외부 종속성

공백 상태에서는 유효한 일이 발생하지 않습니다. 프로젝트에는 일반적으로 기능팀(재무, PR, 고객 지원)과의 커뮤니케이션 및 고객과의 커뮤니케이션과 같은 외부 종속성이 있습니다. 이러한 외부 의존성을 조정하는 것은 PM이나 CEO의 일인 경우가 많습니다. 즉, 시간 추정에 가장 적합한 사람(엔지니어)이 이러한 계산을 가장 많이 수행해야 하는 사람이 아니라는 의미입니다. 이러한 비대칭성은 근본적인 긴장을 야기합니다.

우선순위

시간 측정도 우선순위를 결정하는 데 중요합니다. 비용 효율성은 엔지니어링 분야에서 중요한 지표입니다. 작업 중인 기능이 세계에서 가장 강력하더라도, 시간을 계산해 보면 구현하는 데 오랜 시간이 걸릴 것으로 나타나면 이 기능의 우선순위는 중요하지 않습니다. 너무 높다.

완료 후 웹 사이트 속도를 50% 더 빠르게 만드는 프로젝트를 진행하고 있지만 동시에 2개의 프로젝트를 완료하고 각 프로젝트마다 웹 사이트 속도를 40% 더 빠르게 만들 수 있다고 가정해 보겠습니다. 예비 계산을 수행하는 데 시간을 들이지 않으면 어디에서 더 빠른 웹사이트를 구축할 수 있는지 결코 알 수 없습니다!

기본 시간 추정

시간 추정이 매우 중요하다는 합의에 도달했다고 가정하고 계속해서 추정 방법을 살펴보겠습니다. 종종 우리는 "프로토타입을 작성하는 데 시간이 얼마나 걸릴까?"라고 생각하기 때문에 시간이 얼마나 걸릴지 과소평가합니다.

그러나 전달되는 내용은 프로토타입보다 큰 경우가 많으며 테스트, 디버깅 및 최적화에 소요되는 시간도 고려해야 합니다. 회의, 인터뷰, 코드 검토, 심지어 시간이 걸리는 이메일 보내기도 있습니다.

필요한 시간을 과소평가하는 또 다른 이유는 환경을 구성하는 데 하루가 더 걸리는 IDE 업데이트와 같이 종종 완전히 고려되지 않는 예상치 못한 문제 때문입니다.

이를 바탕으로 소위 경험과 직관을 너무 믿지 않는 것이 가장 좋습니다.

1단계: 기술 계획 개발

중요한 프로젝트를 시작하기 전에 기술 계획이나 설계 문서가 있어야 합니다. 이 문서의 목적은 귀하가 하고 있는 일을 다른 사람들에게 알리고 피드백을 받는 것입니다. 기술적인 세부 사항을 확인하면 소요된 특정 시간을 더 명확하게 알 수 있습니다. 예를 들어 특정 라이브러리를 새 버전으로 업데이트하는 데 하루가 더 걸릴 수 있습니다. 라이브러리를 직접 작성해야 할 수도 있습니다.

여기서는 세분성이 매우 중요합니다. 뭔가 불분명하다고 느껴진다면 그것에 대해 더 많이 알고 있거나 더 자세한 단계로 나누어야 합니다. 동시에, 한 단계가 너무 세세하면 너무 취약해져서 전체 계획이 비효율적일 수 있으므로 이 정도를 파악해야 합니다.

문서에서 고려해야 할 사항을 알고 싶다면 AliciaChen의 이 기사를 읽어보세요. PM과 명확하게 소통하고 모호함을 없애는 것이 핵심이다. 그래야 뒤집어지고 처음부터 다시 시작해야 하는 일이 없기 때문이다.

2단계: 각 단계의 예상 시간을 추가하세요

문서의 각 단계를 구현하는 데 시간이 얼마나 걸리나요? 이미 완료되었나요? 라이브러리가 있나요? 따라서 프로젝트의 성격에 따라 간단한 프로토타입을 먼저 수행하면 잠재적인 문제점을 많이 드러내는 데 도움이 될 수 있습니다.

3단계: 내결함성 시간 추가

이제 예비 시간 추정이 완료되었으므로 고려해야 할 다른 요소가 많이 있습니다.

이동 중 디버그: 버그는 불가피하며 특정 코드베이스에 대한 개발자의 경험과 코드베이스의 성숙도에 따라 달라집니다. 회의 및 휴일: 일반적으로 회의나 휴일에는 코딩을 하지 않는데 실제로 코딩하는 데 얼마나 걸리나요? 그러므로 시간을 추정할 때 일정을 잘 살펴보세요. 최종 테스트: 일반적으로 코드를 작성하면서 테스트해야 하지만 많은 팀에서는 출시 전에 통합 테스트도 수행해야 하므로 추정 시 이 부분의 시간을 허용하십시오. 코드 검토: 이 코드 베이스에서 일반적으로 몇 라운드를 수행합니까? 각 라운드는 얼마나 걸리나요? 몇 명의 리뷰어를 거쳐야 하나요? 코드 검토 시간을 보장하기 위해 검토자의 일정에 주의를 기울이십시오.

배송 시간 비용을 고려하면 예상 시간이 프로젝트의 실제 출시 시간과 훨씬 더 일치한다는 것을 알 수 있습니다. 실제로는 더 길어질 수도 있지만 일정을 단축해야 한다는 압박을 받을 수도 있습니다. 그러나 사람들이 귀하의 추정치가 더 정확하다는 것을 이해하면 귀하를 더 신뢰하게 될 것입니다.

4단계: 출시 후 검토 시간 예측

검토는 상당히 고통스럽지만 검토는 다음 번에 더 잘하는 데 도움이 됩니다. 실제 프로젝트와 예상 시간이 일치하지 않는 모든 프로젝트에서 발생하는 문제는 원인을 찾아 개선하는 것입니다.

간단히 말하면 모든 것은 의사소통에 관한 것입니다. 서로의 일정과 요구 사항의 변화를 이해할 수 있도록 사전에 자주 소통하세요.

PM 및 기타 관련 참가자와 소통하면 견적에 영향을 미칠 수 있는 중요한 정보를 제공할 수도 있습니다. 디자이너는 애니메이션을 완성하는 데 일주일이 걸리므로 잘라야 한다고 말할 수 있습니다. 또 다른 PM은 이 프로토타입이 단지 사용자 조사를 위한 것이며 이 반복에서는 너무 많은 버그를 처리할 필요가 없다고 덧붙일 수도 있습니다.

엔지니어의 경우 건설 기간 단축에 대해 비현실적인 타협을 하지 마세요. 개방적이고 정직한 것이 더 전문적입니다. PM 등이 그 추정치를 존중하는 과정일 수도 있지만, 잔소리로 일정을 단축할 수는 없다는 점을 알아두시기 바랍니다.

프로젝트 시간 예측은 쉽지 않습니다. 원활한 의사소통과 공감, 기능의 우선순위만 있으면 됩니다.