프로그래머에게 필수: 프로젝트 시간 예측 기술

소개

한 PM은 최근 자신이 직면한 딜레마에 대해 말했습니다. "소프트웨어 엔지니어는 자신의 프로젝트가 얼마나 걸릴지 결코 예측할 수 없습니다. 최근 다른 CEO 두 명이 나에게 같은 말을 했습니다. 높은 수준에서 문제는 엔지니어, PM, 관리자, PR 및 기타 모든 사람이 시간 추정과 관련하여 서로 다른 관점을 가지고 있다는 것입니다. 대부분의 엔지니어가 본능적으로 생각하는 것은 모든 것이 계획대로 진행될 경우 사용 가능한 프로토타입을 작성하는 데 걸리는 최소 시간입니다. 그러나 다운스트림 사람들이 알고 싶어하는 것은 프로젝트가 언제 출시될 준비가 되는지입니다. 이는 완전히 다른 이야기입니다.

한 PM은 최근 자신이 직면한 딜레마에 대해 말했습니다. "소프트웨어 엔지니어는 자신의 프로젝트가 얼마나 걸릴지 결코 예측할 수 없습니다. 최근 다른 CEO 두 명도 저에게 같은 말을 했습니다.

"프로그래머는 왜 프로젝트 시간을 정확하게 예측하지 못하는 걸까요?" 》(http://blog.jobbole.com/24924/), 우리 모두는 그것을 깊이 이해하고 있습니다. 한번은 완료하는 데 이틀이 걸릴 것으로 예상됐던 프로젝트가 4개월이 걸린 적이 있습니다. 이 경우 "이중 시간"이라는 경험적 추정을 사용하더라도 여전히 한 자릿수 정도의 차이가 있습니다. 이는 실제로 비즈니스에 영향을 미칩니다. 나는 회사 전체가 출시 행사를 주최하기 위해 애쓰다가 몇 달 동안 연기해야 ​​하는 것을 보았습니다.

전체적으로 문제는 엔지니어, PM, 관리자, PR 등 모든 사람이 시간을 추정하는 데 있어 서로 다른 관점을 가지고 있다는 것입니다. 대부분의 엔지니어가 본능적으로 생각하는 것은 모든 것이 계획대로 진행될 경우 사용 가능한 프로토타입을 작성하는 데 걸리는 최소 시간입니다. 그러나 다운스트림 사람들이 알고 싶어하는 것은 프로젝트가 언제 출시될 준비가 되는지입니다. 이는 완전히 다른 이야기입니다.

엔지니어에게 프로젝트 견적에 필요한 시간을 파악하는 것은 평생의 여정입니다. 이 문제를 무시하면 귀하와 귀하가 직간접적으로 접촉하는 모든 사람에게 문제가 발생할 수 있습니다. 프로젝트에 소요되는 시간을 정확하게 추정하면 귀하가 눈에 띄게 될 것이며 동료들은 이를 귀하의 전문성, 안정성 및 작업 품질과 연관시킬 것입니다.

시간 추정이 필요한 이유

먼저, 엔지니어들이 자주 묻는 질문인 "시간을 추정해야 하는 이유는 무엇입니까?"에 답해 보겠습니다. 많은 엔지니어들은 이것이 간접적인 비용이라고 불평합니다. "전력을 다하면 프로젝트를 더 빨리 끝낼 수 있어요!

"

외부 종속성과 우선순위라는 두 가지 주요 이유가 있습니다.

외부 종속성

공백 상태에서는 효과적인 캠페인이 운영되지 않습니다. 프로젝트에는 엔지니어링 팀이 아닌 팀(커뮤니케이션, 재무, PR, 고객 서비스), 기타 엔지니어링 팀 또는 최종 사용자 자신과의 협업과 같은 외부 종속성이 있는 경우가 많습니다. 이러한 외부 종속성을 조정하는 것은 일반적으로 관리자, PM 또는 CEO의 책임입니다. 이는 시간 추정에 가장 적합한 사람(엔지니어)이 추정을 위한 시간 정보가 가장 필요한 사람이 아니라는 것을 의미합니다. 이러한 비대칭성은 근본적인 모순을 초래합니다.

우선순위

시간 추정은 작업 우선순위의 핵심이기도 합니다. "돈이 돈만큼 가치가 있는지"는 프로젝트에서 중요한 지표입니다. 실제 견적이 없으면 돈이 돈만큼 가치가 있는지 판단하는 것이 불가능합니다. 작업 중인 기능이 세계 최고라고 하더라도 시간을 들여 철저하게 견적을 내보면 완료하는 데 오랜 시간이 걸린다는 것을 깨닫게 될 수도 있습니다.

웹 사이트 속도를 50% 더 빠르게 만드는 하나의 프로젝트를 진행하고 있는데, 같은 시간에 웹 사이트 속도를 각각 40% 더 빠르게 만드는 두 개의 프로젝트를 완료할 수 있다고 가정해 보세요. 초기 견적을 작성하는 데 시간을 투자하지 않으면 더 빠른 웹사이트를 만들 수 있다는 사실을 결코 알 수 없습니다!

시간 추정 시작하기

이제 대부분의 경우 시간 추정이 필요하다는 점에 모두 동의했으니 이제 기술에 대해 이야기해 보겠습니다.

우리는 "이 기본 버전을 작성하는 데 얼마나 걸릴까?"라고 생각하기 때문에 시간을 과소평가합니다.

하지만 기본 버전 이상의 기능을 제공합니다. 또한 작성, 테스트, 디버깅 및 개선에 필요한 시간도 고려하세요. 회의, 인터뷰, 코드 검토, 이메일 보내기 등의 작업에도 시간이 걸린다는 점을 잊지 마세요.

시간을 과소평가하는 또 다른 이유는 코딩 중에 완전히 예측하고 고려할 수 없는 "알 수 없는 내용"이 거의 항상 발생한다는 것입니다. IDE가 업데이트되어 프로젝트가 중단되고 문제를 해결하는 데 하루가 걸릴 수도 있습니다. 이는 예상 시간에 고려할 수 없습니다.

그러나 우리는 여전히 초기 직관보다 더 잘할 수 있습니다. 제가 하는 방법은 다음과 같습니다:

1단계: 기술 계획 개발 작업을 시작하기 전에 중요한 프로젝트에 도움이 될 수 있는 기술 계획이나 설계 문서가 이미 있어야 합니다. 이를 사용하여 다른 사람들에게 자신이 하고 있는 일을 알리고 피드백을 받을 수 있습니다. 기술 계획을 개발하는 것은 출시 시간 예측을 위한 이상적인 단계입니다. 디자인의 기술적 세부 사항을 완료하면 알려지지 않은 문제가 발견되고 예상 시간이 마술처럼 수정됩니다. 아마도 사용 중인 라이브러리를 새 버전으로 업그레이드해야 할 수도 있으며, 이로 인해 작업에 하루가 추가될 수도 있다는 것을 깨닫게 될 것입니다. 사용하려는 라이브러리가 실제로 존재하지 않으며 직접 작성해야 한다는 사실을 깨닫게 될 수도 있습니다.

여기서 세분성이 중요합니다. 어떤 단계가 모호하거나 불분명하다고 느껴진다면 해당 단계를 건너뛰었거나(자세히 알아보아야 함) 더 작은 단계로 나누어야 할 수도 있습니다. 동시에, 단계가 너무 세분화되면 실제로 취약할 수 있으며 전체 계획이 효과적이지 않게 될 수 있습니다.

기술 계획에서 어떤 측면을 고려해야 하는지에 대해서는 Alicia Chen의 "'시간이 더 필요하다'는 게 무슨 뜻인가요?"라는 기사를 참조하세요. 핵심 포인트 중 하나는 뭔가 잘못했기 때문에 다시 시작하지 않아도 되도록 PM이나 다른 이해관계자와의 잠재적인 모호성을 제거하는 것입니다.

2단계: 각 단계에 시간 예산 추가

기술 솔루션의 각 단계를 실행하는 데 걸리는 시간을 추정하세요. 여기에는 일반적으로 세부 사항을 파헤치는 작업이 포함됩니다("이 라이브러리의 기능을 이미 구현한 사람이 있습니까?"). 프로젝트의 성격에 따라 간단한 프로토타입을 배치하면 미래에 발생할 수 있는 많은 문제점을 노출하는 데 도움이 될 수 있습니다.

3단계: 추가 시간을 많이 추가하세요

이제 예비 견적이 나왔지만 앞서 언급한 모든 사항을 여전히 고려해야 합니다.

• 이동 중 디버그: 항상 버그가 있습니다. 디버깅은 주로 특정 코드베이스에 대한 경험과 코드베이스의 성숙도에 따라 달라집니다.
• 회의, 인터뷰, 휴가 등: 아마도 워크스테이션에서 항상 코딩을 하고 있지는 않을 것입니다. 실제로 코딩하는 데 몇 시간이 걸리나요? 견적을 낼 때는 최소한 달력을 살펴보아야 합니다.
• 최종 테스트 및 버그 정리: 일반적으로 코딩하는 동안 테스트를 작성해야 하지만 많은 팀에서는 출시 전에 일련의 다듬질 작업이나 통합 테스트를 수행해야 합니다. 견적에서 이러한 작업에 대한 적절한 예산을 허용하십시오. 단계적으로 출시할 경우 콘텐츠의 초기 1%에서 수정이 필요한 버그가 노출될 수 있으므로 이 점을 고려해야 합니다.
• 코드 검토: 프로젝트에 몇 번의 코드 검토가 필요합니까? 보통 얼마나 걸리나요? 충분한 수의 리뷰어가 있는지 확인하세요(그리고 그들의 일정도 확인하세요). 검토자가 한 명뿐인 프로젝트인 경우 검토자가 휴가 중이거나 중요한 시점에 너무 바쁠 경우를 대비해 대기하도록 사전에 동의하도록 요청해야 합니다.

이 모든 시간 오버헤드를 프로젝트에 추가하기 시작하면 프로젝트가 실제로 시작될 때보다 예상 시간이 훨씬 더 잘 일치하는 것을 볼 수 있습니다. 네, 실제로는 예상보다 시간이 더 걸릴 수도 있고 마감일을 단축해야 한다는 압박감을 느낄 수도 있습니다. 그러나 사람들은 귀하를 신뢰할 수 있다는 것을 알면 귀하의 견적에 감사할 것입니다.

4단계: 프로젝트가 출시된 후 예상 소요 시간을 검토하고 요약합니다

프로젝트가 끝나고 지금까지의 작업을 되돌아보면 괴로운 것 같아요. 하지만 이런 종류의 검토를 통해 많은 것을 배울 수 있고 다음에는 더 나은 결과를 얻을 수 있습니다.

어떤 과정이 예상과 다르게 나왔나요? 통합 테스트가 예상보다 두 배의 시간이 걸리는 경우 이를 기록하고 다음 테스트에 더 많은 시간을 할애하십시오. 아니면 통합 테스트 시스템을 개선해 보세요.

시간이 지남에 따라 추정치가 향상되는 것을 볼 수 있습니다. 그 과정에서 팀 전체에 도움이 될 수 있는 훌륭한 통찰력을 얻을 수도 있습니다.

결국 중요한 건 소통

일정 및 기타 변경사항은 미리 다른 사람에게 알려주셔야 합니다. 릴리스하기 한 달 전에 사용 중인 라이브러리에 새로운 보안 취약점이 존재하고 처음부터 시작해야 한다는 사실을 관리자에게 알리면 관리자는 릴리스에 필요한 사항을 PR, 재무 또는 사용자에게 알릴 시간을 갖게 됩니다. 연기되다.

다른 공동작업자들과의 소통을 통해 얻은 중요한 피드백은 예상 시간을 조정하는 데 도움이 됩니다. 디자이너는 "아, 이 멋진 애니메이션이 일주일 내내 걸릴 것 같으면 완전히 빼버릴 수도 있어요."라고 말할 수도 있고, PM은 "이건 사용자 연구에 있어서 프로토타입 실험일 뿐이에요. 너무 많이 필요하지 않아요."라고 덧붙일 수도 있습니다. 이번 반복을 위해 버그를 제거합니다.” 관리자는 “회의에 절반의 시간을 소비했나요? 제가 고쳐드릴까요?”라고 말할 수도 있습니다.

엔지니어의 경우 상사를 기쁘게 하기 위해 비현실적인 일정에 타협하지 마세요. 예상 시간과 변경 사항을 미리 알려주는 것이 더 전문적입니다.

누구나 예상 시간을 지키는 것은 어렵고 과정이 필요합니다. 시간을 단축하라고 잔소리를 하는 것이 아니라, 실제로 출시할 필요가 없는 기능이나 단계를 앉아서 잘라내는 방식으로만 예상 시간을 단축할 수 있습니다.

프로젝트에 소요되는 시간을 완벽하게 예측할 수는 없습니다. 이를 수행하는 유일한 방법은 개방적이고, 소통하고, 공감하고, 결단력 있게 우선순위를 정하는 것입니다.

위 내용은 프로그래머에게 필수: 프로젝트 시간 예측 기술의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!