역사적으로 노력 평가는 전문가의 평가 또는 과거 프로젝트와의 유사성에 기반하여 이루어졌습니다. 제한된 시간과 정보 속에서 시스템 분석가는 높은 수준의 모호한 요구 사항으로 작업할 수밖에 없으며, 종종 불완전성 및 과도한 기대에 직면하게 됩니다.
문제: 불확실성은 예산 초과, 고객 및 기술 팀과의 갈등, 평가 하락으로 이어질 위험을 가집니다. 계약 서명이후 입력 정보의 변동으로 인해 평가는 매우 어렵습니다.
해결책:
주요 특징:
요구 사항이 아직 명확히 정해지지 않았다면 품질을 위험에 빠뜨리지 않고 평가를 진행할 수 있을까?
아니요, 이 단계에서의 모든 평가는 위험 및 여유 징후를 명시하여 임시로 지정해야 합니다. 그렇지 않으면 초과 비용에 대한 책임이 수행자에게 돌아갑니다.
평가에 고객이 명확하게 정의한 객체만 포함해야 할까?
아니요. 정의되지 않은 모든 것은 "불확실성 버퍼"나 미래의 명확화를 위한 특별한 스토리 포인트로 평가됩니다. 중요하게도 "기타 요구 사항은 평가 제외"라고 명시하는 것이 중요합니다.
시스템 분석가는 TCO(총 소유 비용) 준비에 참여해야 할까?
네, 분석가는 초기 데이터인 요구 사항 목록, 시나리오 목록, 위험 영역, 제한 사항을 형성하며 이는 TCO를 올바르게 계산하는 데 필수적입니다.
부정적인 케이스: 시스템 분석가는 관리자에게서 받은 요구 사항을 "그대로" 수용하고 상세를 파악하지 않고 빠르게 평가했습니다.
장점:
단점:
긍정적인 케이스: 분석가는 주요 이해 관계자와 워크숍을 진행하고 일반 요구 사항조차 다루며, 불확실성 영역의 지도를 작성하고 가정을 명시하며 여유를 추가했습니다.
장점:
단점: