지원 문제를 설명하면서 프로젝트를 현실적으로 계획하는 방법은 무엇입니까?

우리는 직장에서 문제를 겪고 있습니다 : 우리는 시간 척도를 평가하고 마감일을 얻을 수 있도록 작업 일정을 잡으려고합니다.

문제는 일어날 모든 것을 알지 못하면 프로젝트를 계획하기가 어렵다는 것입니다.

예를 들어, 지금 우리는 12 월 초까지 모든 프로젝트를 계획했지만, 그 때 우리는 다양한 사내 및 외부 회의, 원격 회의 및 추가 작업을 할 것입니다. 프로젝트가 3 주가 걸릴 것이라고 말하면 좋을 것입니다. 그러나 그 시간에 1 주일의 중단이있을 경우 완료 날짜가 1 주일로 단축됩니다.

문제는 3 배입니다.

1. 프로젝트를 예약 할 때 시간 척도가 문자 그대로 사용됩니다. 우리가 3 주를 추정하면, 마감일은 3 주 동안 설정되고, 고객에게 알려지며 연장 할 여지가 없습니다.

2. 중간 작업 및 프로젝트에서 작업하는 데 시간이 오래 걸리는 것을 의미합니다.

3. 때로는 고객이 업무를 수행하는 데 필요한 시간이 없기 때문에 업무가 두 달이 걸릴 것이라고 생각할 때도 가끔 우리에게 와서 월말까지 프로젝트가 필요하다고 말합니다. -우리가 이미해야 할 일이 있다는 것은 말할 것도 없습니다.

우리는 우리가 가진 모든 프로젝트를 채우려 고 노력하고 작업 표를 채우는 Gantt 차트를 가지고 있지만 Gantt 차트와 전혀 비교되지는 않습니다. "이 프로젝트를 위해 3 주를 예약했지만 여기서 일주일을 잃어 마감일이 1 주일로 되돌아갔습니다."라고 말하기가 어렵습니다.

또한 고객에게 전달한 마감 기한을 지키는 것도 전문가가 아닙니다.

다른 사람들은 이러한 유형의 상황을 어떻게 처리합니까? 프로젝트 계획을 어떻게 관리합니까? 프로젝트 중 발생하는 비 프로젝트 작업을 설명하기 위해 프로젝트에 얼마나 "추가"시간을 예약합니까? 지원 문제와 버그 및 문제를 어떻게 처리합니까? 계획 중에 설명 할 수없는 것들?

최신 정보

많은 좋은 답변 감사합니다.

문제는 앞으로 일어날 모든 것을 알지 못하고 프로젝트를 계획하기가 어렵다는 것입니다.

그것이 위험 관리의 요점입니다. 모든 것을 알 수 없으므로 알고있는 내용을 기반으로 계획하고 계획에 가장 큰 영향을 미칠 수있는 사항과 그 가능성을 식별하십시오. X가 발생하면 일정 (키워드-예상) Y 일 또는 주 단위로 일정이 미끄러질 것이라고 말함으로써 잠재적 인 일정 영향을 평가합니다.

프로젝트가 3 주가 걸릴 것이라고 말하면 좋을 것입니다.

그러한 특정 견적을 제공하지 마십시오. 범위를 지정하거나 해당 추정치에 도달 할 확률을 수량화하십시오. 예를 들어 "이 프로젝트는 2-5 주가 소요됩니다"또는 "이 프로젝트는 3 주 안에 완료 될 확률은 85 %이며 4 주 안에 완료 될 확률은 95 %입니다"라고 말합니다.

또한 마감일을 놓쳤다는 말을 계속하는 것은 고객에게 전문적이지 않습니다.

진실. 그러나 "추정", "스케줄"및 "마감"이라는 개념을 혼합하고 있습니다. 추정치는 주어진 작업이나 프로젝트를 완료하는 데 걸리는 시간과이를 충족시킬 확률에 대한 근사치입니다. 마감일은 가치를 추가하기 위해 프로젝트를 완료해야하는 고객이 부과 한 날짜입니다. 일정은 사용 가능한 자원을 사용하여 마감일을 맞추는 방법입니다.

마감일 내에 할당 된 작업을 완료 할 수없는 경우가 있으며 세계의 모든 추정 및 일정이 차이를 만들지 않을 때가 있습니다.

그래서 제 질문은 ... 다른 사람들은 이것을 어떻게합니까? 프로젝트 계획을 어떻게 관리합니까? 평균 시간에 발생하는 일을 설명하기 위해 프로젝트에 얼마나 "추가"시간을 예약합니까?

Steve McConnell : Software Estimation : Black Art Demystifying and Rapid Development : Taming Wild Software Schedules 두 권의 책을 읽는 것이 좋습니다 . Software Estimation은 고객의 견적을 제시하고 협상의 일부 측면과 비현실적인 기대를 다루는 것에 관한 것입니다. 빠른 개발은 일반적인 프로젝트 관리로 개발 수명주기, 일정, 리소스 할당 및 예상 및 마감 시간을 충족하기 위해 프로젝트를 가장 잘 예약하고 예산을 책정하는 방법을 처리합니다.

스크럼 개발 프로세스 세부 사항을 파헤치는 것이 좋습니다 . 그것은 focus factor메트릭에 의한 이러한 사이드 트래킹 활동을 다룹니다 . 기본적으로 2-3 스프린트 / 반복 작업을 한 다음 팀의 초점 요소를 측정해야합니다 (각 구성원에 대해서도 도움이 됨). 그 후에는 일상 활동을 포괄하는보다 정확한 추정치를 제공 할 수 있습니다.

이 기사를 살펴보십시오- "초점 요소"

애자일 개발에 익숙한 사람이라면 아마도 초점 요소 (또는 생산성 요소)에 대해 들어 보셨을 것입니다. 그것은 당신이 무언가에 대해 작업해야하는 "실시간"을 결정하는 데 도움을주기 위해 사용됩니다. "실시간"과 "이상적인 시간"의 차이입니다.

중단에 대한 것은 주어진 개인이나 팀에 대해 상대적으로 작은 범위의 확률 내에서 발생하는 경향이 있다는 것입니다. 예를 들어, 매주 같은 횟수의 회의가 있거나 매월 긴급한 버그 수정에 소요 된 시간과 거의 같은 시간, 또는 특히 평균 이상일 때 책상에 들리는 사람들의 질문에 답변하는 데 걸리는 시간 오랜 시간.

많은 현대식 스케줄링 기술이이를 고려합니다. 스크럼은 속도에 영향을 미칩니다. 증거 기반 스케줄링은 또한 주어진 추정치에 대한 신뢰 구간이있는 속도를 사용합니다. Pomodoro는 특정 주에 완료 할 수있는 "pomodoros"의 수를 결정할 때 중단을 고려합니다. 이 모든 것은 중단의 과거 측정을 추적하고 어떻게 든 추정치에 반영하는 데 달려 있습니다. 모든 것을 살펴보고 팀에 적합한 기술을 고안하는 것이 좋습니다.

주위에 좋은 조언.

지원 문제를 처리하는 데 도움이 될 수있는 또 다른 방법은 사람들이 고정 된 "라운드 로빈"을 기반으로 지원하도록하는 것입니다.

예를 들어, 개발자가 5 명인 경우 요일별로 1을 할당합니다. 해당 날짜가되면 할당 된 개발자는 해당 날짜에 대해서만 지원을받습니다. 다음날 다른 개발자가 지원을받습니다. 이런 식으로 모든 사람들이 자신의 "흐름"에 머무를 수있는 기회를 가지게되면 모든 사람들이 개밥을 맛볼 수 있습니다.

정기적 인 지원 작업 을 실제로 나누는 방법 은 중요하지 않습니다 (요일 라운드 로빈은 예일뿐입니다). 중요한 것은 지원 시간을 고정 된 간격으로 제한하는 것입니다. 이를 통해 지원 문제를 해결하기 위해 "모두 삭제"할 수없는 트레이드 오프로 개발 시간을보다 예측 가능하게 만들 수 있습니다.

이것은 실제로 경험과 함께 제공되는 기술이며, 사람들은 그러한 것을 정확하게 판단하기 전에 종종 질문을받습니다. 나는 항상 비공식적 인 스타일로 상당히 밀접한 그룹에서 일했지만, 우리는 잘 견디는 것처럼 보이는 몇 가지 규칙을 개발했습니다.

첫째, 일주일도 걸리지 않습니다. 작업이 완료하는 데 며칠이 걸리는 것처럼 보이더라도 항상 몇 주 안에 예상하십시오. 일주일 전에 완료되지 않는 몇 가지 이유가 있습니다.

둘째, 중단, 고객 지원 문제, 테스트 통과 등을 포함하여 작업에 소요되는 시간을 추정하는 데 최선의 노력을 기울이십시오. 이제 그 수를 두 배로 늘리십시오. 예상치입니다 (주).

셋째, 관리자가 추정치에 이미 일부 여백을 추가하지 않았는지 확인하십시오. 우리 팀은 추정치에 대해 관리자가 불만을 제기했습니다. 그가 이미 2.1을 곱한 것으로 판명되었으며 (실증적으로 도출 된 패딩 추정치), 우리는 그에게 말하기 전에 이미 두 배로 늘 렸습니다.

멋진 도구가 아니며 완벽한 방법은 아니지만 놀랍도록 잘 작동합니다.

추정의 필요성을하는 사람들은 어떤 팀이 없다는 것을 이해하는 어느 프로젝트에 100 %. 병가, 휴가, 배심원 의무, 사별 휴가, 필수 HR 회의 (시간 혜택!), 프로젝트 관련이없는 팀 회의, 피할 수없는 지연, 화장실 휴식, 이미 생산중인 품목에 대한 작업 지원, 이메일 처리, , 이전 컴퓨터가 죽은 후 새 컴퓨터를 구성하고, 향후 작업에 대한 질문에 답하고, 해당 작업에 대한 견적을 작성하고, 고려해야 할 후배, 멘토링 등. 8 시간 중 6 시간 이상을 추정하는 것은 무책임합니다 하루에 가능합니다. 마감일이 지날 수 없다는 보장입니다. 기한을 지키지 못한다고 확신하면 불행한 고객을 보장하는 것입니다.

당신은 절대적으로 맞습니다-일어날 모든 것을 알지 못하면 프로젝트를 계획하기가 어렵습니다. 그러나 규범과 사물을 추적하는 것은 매우 중요합니다. 여기에서 일정 관리 가 중요한 역할을합니다. 프로젝트 관리 예약 소프트웨어의 일부인 기능도 포함하는 Microsoft 프로젝트 관리 (표준 버전)를 사용하고 있습니다.

자세한 내용 은 http://www.microsoft.com/project/en/us/schedule-management.aspx 를 방문 하십시오 .

프로젝트 팀에서 집중력과 속도를 잃는 데 많은 숨겨진 노력이있는 것처럼 보입니다. 실제로 처리하는 작업을 분리하는 것이 유리할 수 있습니다

.. 지원 문제와 버그 및 물건?

다른 팀 구성원이 새로운 개발 작업에 집중할 수 있도록 특정 그룹의 사람들에게 이를 통해 전체 생산량이 약간 떨어질 수 있지만주의가 덜 분산되어 품질이 향상됩니다. 이에 대한 대가로 버그 수를 줄일 수 있으므로 프로젝트에 방해가되지 않는 작업입니다.

계획 부분에 대해서는 Thomas Owens의 답변에 전적으로 동의합니다.