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


13

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

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

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

문제는 3 배입니다.

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

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

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

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

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

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

최신 정보

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


1
Liquid Planner ( liquidplanner.com )를 살펴보십시오 . 작업에 대해 낙관적이고 '현실적인'근무 시간을 입력하고 예상 릴리스 날짜 (50 %, 90 %, 98 % 정확도)를 계산할 수 있습니다. 그리고 그것은 훨씬 더 많은 일을합니다. 그래서 제가 당신이라면 데모를 시도 할 것입니다
jao

2
귀하의 프로필에서 나는 당신이 개발자임을 봅니다. 경영진은이 문제와 고객을 처리해야합니다. 당신의 임무는 문제가 발생했을 때 얼마나 많은 양의 정보를 투명하게 전달하고 전달할 수 있는지 추정하는 것입니다. 경영진은 거기에서 가져옵니다.
JohnDoDo

1
포인트 3에 관하여 : 고객에게 프로젝트 삼각형 을 설명하십시오 : 싸고 좋으며 빠릅니다 : 둘 중 하나를 선택하십시오.
mouviciel

1
Mouviciel-이론적으로는 좋지만 불행히도 실제로는 아닙니다. 우리는 이미 이것을 염두에두고 있습니다.
Thomas Clayson

3
@ThomasClayson 프로젝트 삼각형이 사실이라는 사실은 변하지 않습니다. 회사에서 간단한 프로젝트 관리를 이해하지 못하면 떠나야 할 때가 있습니다.
Thomas Owens

답변:


14

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

그것이 위험 관리의 요점입니다. 모든 것을 알 수 없으므로 알고있는 내용을 기반으로 계획하고 계획에 가장 큰 영향을 미칠 수있는 사항과 그 가능성을 식별하십시오. 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은 고객의 견적을 제시하고 협상의 일부 측면과 비현실적인 기대를 다루는 것에 관한 것입니다. 빠른 개발은 일반적인 프로젝트 관리로 개발 수명주기, 일정, 리소스 할당 및 예상 및 마감 시간을 충족하기 위해 프로젝트를 가장 잘 예약하고 예산을 책정하는 방법을 처리합니다.


매우 유용하고 좋은 통찰력. :) 대단히 감사합니다. 그 책을 봐 주셔서 감사합니다.
Thomas Clayson

4

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

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

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

여기에 이미지 설명을 입력하십시오


3
프로젝트 및 팀의 성격을 모르고 특정 SDLC를 제안하는 것은 위험합니다 (예 : Scrum은 5 명 이하의 팀 또는 10 명 이상의 팀에 적합하지 않으며 적절한 조사, 바이 인 및 문화 조정은 실패에 대한 프로젝트를 설정하고 있지만) 초점 요소 측정에 대한 논의는 실제로 관련이 있으며 계획 중심의 방법론을 포함한 모든 방법론에 유용 할 수 있습니다.
Thomas Owens

@Thomas Owens : OP는 방금 살펴볼 수 있으며 아마도 이와 같은 생각이나 다른 생각을 측정하는 방법에 대한 통찰력을 얻었을 것입니다.
sll

감사합니다.이 모든 것을 확실히 살펴볼 것입니다. 우리는 3 팀으로 구성되어 있지만 실제로는 스스로 프로젝트를 진행하고 있습니다. 포커스 팩터 논쟁은 흥미 롭습니다. :) 감사합니다.
Thomas Clayson

1

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

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


그래도 우리의 방해는 그런 식으로 일어나지 않습니다. 예를 들어 이번 주에는 X를해야했지만 80 %의 시간을 방해했습니다. 이번 주에는 평소보다 많은 회의가 있었고 많은 지원을 받았습니다. 또한 이번 주에 발표 된 일부 웹 사이트를 만들도록 개발되었으며 개발 서버를 설정하고 나머지 사무실에 대한 기술 지원을 제공해야했습니다. 다음 주에는 회의와 지원이 없었습니다. 또는 라우터를 업그레이드하거나 랩톱 등을 백업해야 할 수도 있습니다. 여기에는 다양한 종류의 프로브가 있습니다.
Thomas Clayson

1
일주일 또는 하루에 걸쳐, 그것은 예측할 수없는 것이 맞습니다. 그러나 그것을 한 달 이상 추적하면 아마 고르지 않을 것입니다. 당신이 정말로 평소보다 더 열광적이라면, EBS의 신뢰 구간 아이디어를 살펴보십시오. "시간의 90 %, 하루 5 시간 동안 업무를 중단하지 않고 다른 10 %는 하루 종일 아무 것도하지 않습니다."와 같은 역사적 확률을 고려합니다. 그 역사에서 어려운 날짜 대신에 "한 달에 85 %의 확률이 있지만 6 주 안에 99 %의 확률"과 같은 결과가 나옵니다.
Karl Bielefeldt

1

주위에 좋은 조언.

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

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

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


0

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

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

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

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

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


0

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


0

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

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


-1

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

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

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.