종속성 매핑, 영향 분석 및 변경 제어를 사용하여 범위 요청이 날짜, 비용 및 용량에 미치는 영향을 승인하기 전에 보여줍니다.
종속성 관리는 모든 범위 변경을 방지하지 않습니다. 각 변경 사항이 승인되기 전에 다운스트림 일정에 미치는 영향을 표시하므로 이해 관계자는 “작은 요청”을 눈에 띄지 않게 수락하는 대신 더 많은 시간, 더 많은 용량, 축소된 범위 또는 다른 순서 중에서 선택할 수 있습니다.
2026년 8월 7일에 검토됨. 아래 예는 범용 생산성 벤치마크가 아닌 계획 일러스트레이션입니다.
종속성과 범위 확장 사이의 관계는 무엇입니까?
범위 확장은 합의된 작업의 통제되지 않은 확장입니다. 종속성은 활동 간의 일정 관계입니다. 새 작업이나 변경된 작업이 요청 자체 이상의 작업에 영향을 미칠 때 두 가지가 만납니다.
새로운 승인 화면에는 설계, 데이터 변경, 구현, 테스트, 문서화 및 릴리스 작업이 필요할 수 있습니다. 해당 관계가 계획에서 누락된 경우 요청에는 하나의 작업이 소요되는 것으로 나타납니다. 매핑된 경우 검토자는 전체 체인과 그것이 마일스톤에 미치는 영향을 볼 수 있습니다.
종속성은 투명성을 만듭니다. 거버넌스는 통제를 창출합니다. 둘 다 필요합니다.
범위 변경을 승인하기 전에 어떻게 평가해야 합니까?
짧고 반복 가능한 영향 검토를 사용하십시오.
- 요청한 결과와 승인 기준을 작성합니다.
- 새로운 결과물, 변경된 결과물, 제거된 결과물을 식별합니다.
- 제작 및 검증에 필요한 활동을 추가합니다.
- 각 활동을 실제 선행 작업 및 후속 작업과 연결합니다.
- 날짜, 부동 소수점 및 주요 경로를 다시 계산합니다.
- 인원, 장비, 승인능력을 확인한다.
- 의사결정자에게 명시적인 옵션을 제시합니다.
- 승인된 결정을 기록하고 작업 일정을 업데이트합니다.
검토는 다음 네 가지 질문에 답해야 합니다. 무엇이 변경됩니까? 무엇이 움직이나요? 비용은 얼마입니까? 누가 트레이드 오프를 수락합니까?
종속성 영향 분석은 어떤 모습인가요?
팀이 릴리스 후반에 추가 내보내기 형식을 요청한다고 가정해 보겠습니다. 눈에 보이는 코딩 작업은 2일이지만 예시 일정은 다음과 같습니다.
| 추가된 활동 | 기간 | 에 따라 다름 |
|---|---|---|
| 형식 규칙 확인 | 1일 | 이해관계자 결정 |
| 내보내기 구현 | 2일 | 규칙이 확인되었습니다. |
| 자동화된 테스트 추가 | 1일 | 구현 |
| 보안 및 개인 정보 보호 검토 | 1일 | 테스트 가능한 빌드 |
| 문서 업데이트 | 1일 | 최종 행동 |
이는 예제에서 6일 체인이며, 모든 내보내기에 6일이 걸린다는 주장은 아닙니다. 체인에 플로트가 있으면 마감재를 움직이지 않고도 맞을 수 있습니다. 중요 경로에 합류하면 팀이 다른 가정을 변경하지 않는 한 릴리스 날짜가 이동됩니다.
어떤 종속성 실수로 인해 범위 변동이 숨겨지나요?
다음 패턴을 주의하세요.
- 날짜가 있지만 선행자 또는 후임자 논리가 없는 작업
- 종료 기준이 아닌 단순한 레이블인 마일스톤
- 일정 이외의 승인 표시
- 분석, 빌드, 테스트, 릴리스를 결합한 작업 패키지
- 실행 가능한 작업 대신 요약 작업에 연결된 종속성
- 이름이 지정된 소유자나 기한이 지정되지 않은 외부 작업
- 남은 기간은 변경되지 않고 진행 상황이 업데이트됩니다.
매력적인 차트는 여전히 약한 모델일 수 있습니다. 목표는 더 많은 화살표를 그리는 것이 아닙니다. 영향을 설명하는 데 필요한 최소한의 논리를 표현하는 것입니다.
변경 제어를 어떻게 가볍게 유지합니까?
임계값을 사용합니다. 기존 범위 및 부동 범위에 맞는 팀 수준 변경에는 메모만 필요할 수 있습니다. 약정된 마일스톤, 예산, 규제된 제어 또는 다른 팀에 영향을 미치는 변경 사항은 지정된 승인자를 거쳐야 합니다.
요청, 근거, 옵션, 승인자, 날짜 및 그에 따른 일정 변경 사항이 포함된 작은 변경 로그를 유지합니다. 우발상황을 임의의 비율로 숨기지 마십시오. 어떤 위험이 포함되는지 확인하고 불확실성이 낮아지면 다시 검토하세요.
이해관계자에게 무엇을 보여주어야 합니까?
단일 경보 대신 선택 항목 표시:
| 옵션 | 범위 | 날짜 | 용량 | 주요 절충안 |
|---|---|---|---|---|
| 요청대로 수락 | 증가 | 이사할 수도 있음 | 동일 | 나중에 마무리하거나 덜 부유함 |
| 스왑 범위 | 안정적 | 보호됨 | 동일 | 또 다른 품목이 출시를 앞두고 있습니다. |
| 적격 용량 추가 | 증가 | 보유할 수 있음 | 증가 | 비용 및 온보딩 위험 |
| 요청 연기 | 현재 릴리스 안정 | 보호됨 | 동일 | 값이 나중에 도착함 |
일정은 자동으로 결정되는 것이 아니라 결정을 뒷받침해야 합니다. 중요 경로 결과는 비즈니스 가치나 위험 성향을 결정할 수 없습니다.
GanttFather는 범위 변경의 영향을 어떻게 표시할 수 있나요?
GanttFather를 사용하면 제안된 작업을 추가하고 해당 종속 항목을 연결하며 주요 경로 또는 완료 날짜가 변경되는지 확인할 수 있습니다. 결정이 내려질 때까지 명확하게 라벨이 지정된 시나리오로 요청을 보관한 다음 결과 타임라인을 시청자 및 게스트와 공유할 수 있습니다.
GanttFather은 변경 사항을 승인하지 않고, 작업량을 예측하거나, 과부하된 리소스를 자동으로 평준화하지 않습니다. 또한 전용 기준선 오버레이 기능이 없으므로 공식적인 기준선 제어가 필요한 경우 거버넌스 기록에 허용된 날짜와 결정을 보존하세요.
모델 1에서는 GanttFather에 변경사항을 제안했습니다. 그리고 그 결과를 사용하여 숨겨진 일정을 깜짝 놀라게 하는 것이 아니라 명시적인 옵션을 제시합니다.
자주 묻는 질문
종속성이 범위 확장을 막을 수 있나요?
아니요. 다운스트림 영향을 노출합니다. 명확한 범위 설명, 결정 권한 및 변경 제어는 승인되지 않은 요청이 계획에 입력되는 것을 막는 것입니다.
모든 작업에 종속성이 있어야 합니까?
아니요. 실제 일정 제약만 추가하세요. 잘못된 종속성은 계획을 경직되게 만들고 오해의 소지가 있는 중요 경로를 만들 수 있습니다.
모든 범위 변경이 나쁜가요?
아니요. 변화는 비용보다 더 많은 가치를 더할 수 있습니다. 문제는 트레이드오프를 이해하고 승인하지 않고 이를 받아들이는 것입니다.
범위 크리프(scope creep)와 점진적 정교화(progressive elaboration)의 차이점은 무엇입니까?
점진적인 정교화는 합의된 결과와 경계 내에서 세부 사항을 추가합니다. 범위 확장은 통제된 승인 없이 이러한 경계를 확장합니다.
날짜 변경 요청은 누가 승인해야 합니까?
프로젝트의 거버넌스 모델에 정의된 권한(종종 스폰서, 제품 소유자, 클라이언트 또는 변경 제어 그룹)을 사용합니다. 작업 소유자는 추정치를 제공해야 하지만 포트폴리오 수준의 절충안을 조용히 받아들여서는 안 됩니다.
종속성 네트워크를 얼마나 자주 검토해야 합니까?
계획 단계에서 그리고 범위, 순서, 추정, 외부 날짜 또는 리소스 가용성이 크게 변경될 때마다 이를 검토하세요.
