시간 추정이 잘못되면 어떻게해야합니까?

사례의 예상 시간이 3 일이라고 가정 해 보겠습니다. 둘째 날에는 사건이 커지고 있고 시간을 계산할 때 계산되지 않은 새로운 시나리오가 나타납니다. 새로운 결과는 2 일 추가 (총 5 일)로 이어집니다. 이것은 개발자로서 조만간 직면하게 될 전형적인 문제입니다.

• 새로운 인도 시간을 프로젝트 리더에게 알릴 때 어떤 전략을 사용할 수 있습니까?
• 왜 당신은 왜 질문을합니까? 새로운 배달 시간에 어떻게 동기를 부여합니까?

사실 많은 프로젝트는 SDLC 동안 분석 및 설계에 많은 시간을 투자하지 않습니다.

편집 : 매우 복잡한 프로젝트에서는 비즈니스 규칙이 너무 복잡하기 때문에 Analysis & Design에 얼마나 합리적인 시간을 투자하든 항상 놀라움이 있습니다. 그러나 그러한 경우 프로젝트 리더는 복잡성을 알고 예기치 않은 놀라움이 발생할 때 올바른 태도를 가져야한다고 생각합니다. 문제는 복잡성을 이해하지 못하는 프로젝트 리더를 다루는 방법입니다.

나쁜 소식 전달

문제를 신속하게 제기해야하지만, 합리적인 시간 척도 (몇 시간이 아닌 몇 시간)로 그렇게 할 수 있다면, 약간의 영향 평가를 수행해야합니다.

모든 나쁜 소식과 마찬가지로 자세한 정보를 제공하는 것이 가장 좋습니다 ( "늦게 나올 것임").

1) 미끄러 진 작업에 대한 추정 / 시간 척도를 수정했습니다.

2) 일부 작업이 이미 과도하게 실행되었다는 사실을 고려하여 현재 생각하는 향후 작업에 대한 추정 / 시간 척도를 수정하면 시간이 더 걸릴 수 있습니다.

3) 미끄러짐이 발생한 매우 간단한 이유 (회전하지 말고 진실 만 말하지만 변명하는 것처럼 들리지 않음). 이 경우 "규칙 X 및 Y를 기준으로 추정했지만 이제는 언급되지 않은 Z가 포함되었습니다"라고 말합니다. 그는 고객에게 지연을 설명하고 처음부터 철저하게하는 것의 중요성에 대해 교육하는 데 이것을 사용할 수 있습니다.

4) 가능한 대안으로 상황을 되돌릴 수있는 경우 (보통 범위를 줄이지 만 다른 옵션이있을 수 있음-프로젝트의 다른 부분이 미리 진행되어 작업을 이동할 수 있음).

미끄러짐으로 심리적 / 신뢰성에 미치는 영향이 결정적임을 기억하십시오. 당신은 하나를 벗어날 수 있지만 두 번째는 훨씬 더 힘들고 세 번째는 더 힘들 것입니다.

이것이 바로 포인트 2가 중요한 이유입니다. 이미 미끄러 져 온 것뿐만 아니라 현재 예상했던 것보다 오래 걸릴 수있는 미래의 과제도 수정하십시오. 실수는 IT에서 발생하지만 실수로부터 배우지 않는 것이 더 큰 죄입니다.

나쁜 소식을 전하지 않아도 됨

여기에는 두 가지 시나리오가 있습니다. 첫째, 추정을 직접 수행하지 않은 경우 다음 번 추정에 참여하기 위해 푸시하는 것 외에는 할 수있는 일이 많지 않습니다.

둘째, 추정을 직접 수행 한 경우 더 나은 추정을 수행하는 방법을 살펴 봐야합니다. 나에게 문제의 핵심 문구는 "비즈니스 규칙이 너무 복잡하기 때문에 항상 놀라움이있다"는 것이다.

이와 관련 하여 항상 발생한다면 놀랄 일이 아닙니다 . 비즈니스 규칙의 절반 만 얻은 경우 추정치로 가정하고 기능 크리프를 허용해야합니다.

당신은 당신이 가진 규칙에 대한 추정치를 증가 시켜서 이것을 할 수 있습니다 (작동하지만 실제로 무슨 일이 일어나고 있는지에 대해 아무에게도 교육하지는 않습니다). 그들이 언급 한 규칙을 구현하는 데 3 일이 걸리지 만 아직 언급되지 않았지만 개발 및 테스트 중에 발견 될 수있는 규칙에 대해 3 일의 우연한 시간을 허용해야합니다. "

PM이 이것에 의문을 가지고 있다면, 당신은 그에게 항상 사실임을 상기시켜 줄 필요가 있습니다 (예를 들어-예를 논쟁하기는 어렵습니다). 보수적 인 편이 낫습니까?

그러나 결론 : 특정 요인 (이 경우 특징 크리프)으로 인해 항상 과소 평가되면 추정치로 계산하십시오.

시간 기반 예측은 미래에 대한 추측이며 장기적으로는 항상 실패합니다. 이길 수없는 무의미한 전투입니다.

일 단위로 추정을 중지 하고 대신 상대 추정을 사용하십시오. 다음은 간단한 예입니다.

1. 각 작업에 번호를 지정하십시오. 가장 어려운 작업은 10이고 가장 쉬운 작업은 1입니다.
2. 프로그래밍을 시작하여 작업을 완료하십시오.
3. 일주일 후 작업을 중지하고 완료된 모든 작업 번호를 합산하십시오. 14로 끝났다고 가정 해 봅시다. 주간 속도입니다.

다음 주에이 과정을 다시 반복하십시오. 나는 당신의 속도가 변할 것입니다. 이것으로 몇 주 후, 당신의 속도는 꽤 안정적이어야하며 그것이 우리가 목표로하는 것입니다. 이제 자신감있게 계획을 시작할 수 있습니다. 자신의 속도에 맞는 작업을 선택하면 PM이 약속 한대로 완료 될 것임을 확신 할 수 있습니다. 이것이 프로젝트 리더를 다루는 방법입니다.

추정치가 잘못되면 알람 벨을 올려야합니다. 배송이 지연 될 것으로 예상되는 사람들에게 알리십시오.

가능하면 팀원에게 도움을 요청하십시오. 가능한 한 고품질의 소프트웨어를 계속 제공하십시오.

지름길은 결국 더 많은 해를 입힐 가능성이 높으며 관련된 모든 사람은 이것을 알아야합니다. 또는 설명 할 수 있어야합니다.

이것은 경험이 많은 프로젝트 관리자가 많은 일을하지 않을 정도로 자주 발생합니다. 그것에 대해 정직하고 너무 낙관적 인 새로운 추정을하지 마십시오. 당신이 그것을 볼 때 훨씬 오래 걸릴 것이라고 말하십시오. 매일 "시간이 더 필요합니다"라고 말하지 마십시오.

관리자에게 설명해야 할 것입니다. 추정이 처음에 잘못되었거나 불리한 상황 (하루에 버그를 사냥 한)이 지연 이유 인 이유는 무엇입니까? 첫 번째 경우, 추정 과정에 문제가있을 수 있습니다. 너무 낙관적이거나 순진한 것일 수 있습니다. 두 번째 경우, 프로젝트 계획에 포함 된 버퍼의 경우입니다.

추정치가 지나치게 낙관적이라는 사실을 포함하여 (특히!) 진행 상황을 항상 관련 이해 관계자에게 알리십시오. 그들은 행복하지는 않지만 프로젝트가 실제로 어디에 있는지 알 수 있으며 그에 따라 계획을 세울 수 있습니다.

이상적으로는 기능 목록이 있어야합니다.-필수,해야 할 것, 할 수없는 것입니다.

오버런을하려고 할 때는 Coulds를 잘라 내고 Musts를 잘라내십시오. 기능을 잘라 적시에 출하 할 수 있습니다. 프로젝트는 일반적으로 독립 상태로 유지되지 않으며 릴리스 날짜가 지날수록 다운 스트림 프로젝트도 이제 일정을 초과합니다.

이상적으로는 ~ 60 %의 머스트 만있을 것입니다. 당신이 그들을 잘라야하는 경우 당신은 매우 심각한 문제 (매우 심각한 오버런)에 처한 경우, 코너를 잘라야합니다.

모서리를 자르면 엉망을 제거 할 수 있도록 석방 후 충분한 시간을 확보하십시오!

프로젝트 추정은 도박, 단순하고 단순합니다. 위험이 없으면 보상이 없습니다.

관리자가 이것을 이해하지 못한다면 그것이 가장 먼저 설명 할 것입니다.

문제는 누가 위험을 감당 하는가?

고정 가격 계약을 체결 한 경우 위험을 감수하고있는 것입니다.

시간과 재료면 위험을 감수하고 있습니다.

따라서 추정 할 때 추측하고 있음을 이해하는 것이 중요하며 추정치가 얼마나 불확실하고 누가 위험을 감수하는지에 대한 아이디어가 필요합니다.

최선의 전략은 지속적으로 귀하의 견적을 수정하는 것 입니다. 나는 알고 있습니다 : 귀하의 질문은 어떻게 든 잘못되었습니다.

읽기 고의적 인 발견을 소개 댄 북한 I에 의해 것은 처음 단계에서 추정 노력을 배치하는 것은 당신의 문제의 무지와 도메인이 항목 최대 수준에있을 때 정확히 예측하기 위해 동일하다는 결론에 도달했다. 현실을 직시, 당신은 아직 불명 특히, 불확실 예측할 수 없습니다 .

민첩한 방법론은 이 문제를 해결하여 프로젝트의 수명을 여러 조각 (스크럼에서 스프린트)으로 나누고 매주 추정 (사이징 스토리)을 반복합니다. 매주 문제에 대해 아는 것은 개선되고 추정치도 마찬가지입니다.

나에게 추정은 참 또는 거짓이 될 수 없습니다. 그것은 단지 매우 세련 될 수 있습니다 . 추정은 약속이 아닙니다. 이것이 바로 평가라고하는 이유입니다.

늦었을 때 (및 문제가 동일하기 때문에 "미리 전달해야 할 위험이있는"경우에 최선을 다하는 것은 가능한 한 빨리 에스컬레이션하고 사실을 고객에게 알리는 것입니다. 이를 리스크 관리라고합니다. 피드백을 빨리 줄수록 카운터 효과가 더 효과적입니다. 즉, 모든 것을 전달할 수없는 증거가 있으면 고객과 대화하고 약속의 70 % 만 제공 할 수 있다고 말하고 그녀에게 더 많은 비즈니스 가치가 있는지 먼저 결정해야합니다 .

나는 그것에 대해 여기에 썼다 잘못된 추정, 도움! 나는 늦었다! 기능을 줄이고 폭포를 멈추십시오!

그것은 교육받은 추측이기 때문에 추정이라고합니다. 미래에 대한 완벽한 설명은 아니며 소프트웨어 견적을 그렇게 취급하는 사람들에게는 인내심이 거의 없습니다. 궁극적으로 많은 것들이 예상보다 오래 걸리지 만, 드문 경우지만 시간이 더 오래 걸릴 수 있습니다. 이것은 세계 최고의 프로그래머에게도 발생합니다. 관리자가 어떻게 그런 일이 발생하지 않을 것으로 예상 할 수 있습니까? 관리자가이를 이해하지 못하면 경험이 많지 않습니다. 일정 압력을 가하기 위해 이해하지 못하는 척하는 경우, 그녀는 합리적이지 않습니다.

가장 좋은 방법은 가장 분명합니다. 기능이 예상보다 오래 걸릴 것이라는 명확한 아이디어가 나오면 관리자와상의하십시오. 종종 문제와 관리자 모두를 해결하는 방법이 있습니다. 즉, 기능 속도를 늦추는 기능의 일부는보다 빠른 진행을 가능하게하는 방식으로 상대적으로 중요하지 않거나 수정하기 쉽습니다. 그럼에도 불구하고 두 번째 낙관적 ​​추정치로 괴롭히지 마십시오.

모든 팀에 알리고 해결책을 찾으십시오. 우선 순위가 높은 것부터 낮은 것까지 3 가지 솔루션을 권장합니다.

에이. 임시 핫픽스 또는 빠른 해결 방법을 찾으십시오.

비. 당신이 할 수있는 일은 최선을 다하십시오. 고객에게 작업의 훌륭한 부분을 보여준 후 도움을 요청하십시오.이 작업을 수행 할 수 있지만 약간의 문제가 있으며 작업의 생산성이 저하 될 수 있습니다. 떨어 뜨릴 수있는 기능.

그들의 문제에 대한 대안적인 접근법을 제안하는 것이 좋습니다.

기음. 초과 근무

옵션 :

• 컷 기능
• 품질 저하 (나중에 버그를 수정)
• 생산성 향상
  • 차단제 찾기 및 제거
  • 휴식 / 휴식
  • 개인 / 수면 시간 단축
  • 더 많은 인력 확보
  • 더 나은 도구를 얻으십시오
  • 훈련
  • 동기 부여 증가
    • 공짜 음식
    • [약속] 인상 / 홍보 / 휴가 / 보너스 등
    • 위협
    • 작업 조건 개선 (하드웨어, 가구 등)
    • 환경 변화 – 커피 숍에서 일하거나 팀 전체를 서늘한 곳으로 이동 – 산장 또는 호수 집?

이것은 일반적인 문제입니다 :)

보다 간단한 접근 방법 중 하나는 예상치 못한 문제가 항상 발생하므로 추정에 버퍼를 추가하는 것입니다. 버퍼의 크기는 팀의 크기와 기술 및 문제 자체의 불확실성에 따라 다릅니다.

규모가 큰 팀에는 병든 사람이 많고 "모든 것"을 아는 사람이 적습니다.

새로운 기술은 항상 이미 알고있는 것보다 위험합니다.

예상 날짜에 완료되지 않을 경우 이해 관계자와 조기에 의사 소통하십시오. 고객 / 이해 관계자와 대화 한 후 우선 순위를 정하거나 특정 기능을 지연시킬 수 있습니다.