이것은 종종 계약적 애자일 또는 워터-스크럼-폴(Water-Scrum-Fall)이라고 불리는 혼합 방법론 접근 방식을 요구합니다. 비즈니스 분석가는 하급 Waterfall 산출물을 Epics에 매핑하는 요구 사항 추적 매트릭스를 수립해야 하며, 계약 기반을 유지합니다. 고정 가격 제약을 위반하지 않기 위해 이해관계자 검증 요구를 충족하기 위해 설계 이정표 내에 개념 증명 단계(Proof of Concept)를 구현합니다. 엄격한 변동 기준을 가진 변경 관리 위원회를 구성하고 가정을 명시된 계약적 제외 사항으로 문서화합니다.
제조 회사에서 우리는 복잡한 구성 가능 기계에 대한 Salesforce CPQ 롤아웃 중에 정확히 이 갈등에 직면했습니다. 200만 달러의 고정 가격 계약은 두 번째 달까지 서명이 완료된 기술 설계 문서를 요구했지만, 영업 운영팀은 라이브 시스템과 상호작용하지 않으면 가격 규칙을 검증할 수 없다고 주장했습니다. 공급업체는 우리가 Apex 코드가 원래 예상된 행렬 가격 복잡성을 처리할 수 없다는 사실을 발견한 후 범위 조정을 요청할 때마다 벌칙 조항을 발동하겠다고 위협했습니다.
솔루션 1: 사전 설계의 순수 Waterfall
우리는 개발이 시작되기 전에 철저한 문서를 완료하고자 했습니다. 모든 가격 시나리오에 대한 상세한 Visio(process maps) 프로세스 맵과 UML 다이어그램을 만들었습니다. 이 접근 방식은 계약 이정표를 만족시키고 범위 동결을 통해 벌칙 위험을 최소화할 수 있었습니다. 그러나 단점은 심각했습니다: 이해관계자는 UI 흐름을 시각화할 수 없어 UAT 동안 발견된 각각의 가격 규칙에 대해 40시간의 재작업이 필요했으며, 비즈니스는 테스트할 수 없는 이론적 설계에 서명하는 것을 거부했습니다.
솔루션 2: 계약 재협상을 통한 순수 Agile
대안으로 우리는 Scrum 스프린트로 전환하고 작업 명세서를 시각-소요계약(time-and-materials)으로 재협상하려 시도할 수 있었습니다. 이것은 Lightning Web Components로 반복 프로토타이핑과 이해관계자의 진정한 피드백을 허용할 것입니다. 그러나 법적 불가능성은 단점으로, 조달 팀은 서명된 계약을 변경할 권한이 없었고, CFO는 분기 말 마감 압박 때문에 무기한 예산 노출을 받아들이기를 거부했습니다.
솔루션 3: 설계 프로토타입 이정표와 혼합 모델
우리는 기술 설계 문서를 "정적 설계"(데이터 모델, 통합 아키텍처)와 "동적 프로토타입"(클릭 가능한 Figma 모형과 Salesforce 샌드박스 데이터)로 이분화하기로 결정했습니다. 우리는 설계 단계 내에 4주 동안의 스프린트 제로를 포함시켜 세 개의 대표적인 제품군에 대한 작동하는 CPQ 구성을 제공했습니다. 이것은 기능적인 프로토타입을 포함한 상세 설계 사양을 제공함으로써 계약 의무를 충족시켜주었으며, 프로토타입을 작동 소프트웨어가 아닌 설계 아티팩트로 취급하여 고정 가격 범위를 유지했습니다.
결과는 성공적이었습니다: 이해관계자는 가격 논리를 조기에 검증하여 UAT 결함을 70% 줄였습니다. 우리는 TDD 부록에서 모든 비 프로토타입 된 기능을 2단계 제외 항목으로 문서화하여 10% 변동 창 내에서 완료되었습니다. 이 혼합 접근 방식은 향후 고정 가격 Agile 계약에 대한 표준 템플릿이 되었습니다.
이해관계자가 프로토타입 검토 중 "작은 기능 하나 더"를 요구할 때 범위 확장을 어떻게 방지합니까, 계약적 벌칙을 유발하지 않고?
후보자들은 종종 단순히 거절하거나 즉시 변경 주문을 발동하라고 제안합니다. 올바른 접근 방식은 모든 데모 세션 전에 범위 분류 프로토콜을 설정하는 것입니다. 모든 요청을 결함(기존 기능이 작동하지 않음), 명확화(모호한 요구 사항 해석), 또는 향상(새로운 기능)으로 분류합니다. 향상만이 변경 관리 프로세스를 유발합니다. 모든 것을 Confluence에 문서화하고 결정 로그를 특정 계약 조항에 귀속시킵니다.
10% 버퍼 보호를 위해서, 명확화 작업을 위해 특정 스토리 포인트의 위험 준비금(일반적으로 스프린트 용량의 15%)을 유지합니다. 이 준비금은 범위 변경으로 처리하기보다는 예산 내 불확실성을 흡수합니다. 이러한 준비금을 Jira에서 레이블 또는 별도의 버퍼 에픽으로 추적하여 가시성을 유지하면서 계약 변동 한계를 보호합니다.
계약에서 요구하는 설계 사양에 맞춰 Waterfall BRD 섹션을 Agile Epics에 매핑하는 구체적인 기법은 무엇입니까?
많은 후보자들은 단순히 BRD를 Jira 티켓에 첨부하라고 제안합니다. 이는 감사 요구 사항을 충족하지 못합니다. 대신, 계층 분해를 사용하여 쌍방향 추적 매트릭스를 사용합니다. 비즈니스 요구 사항을 Epics에 매핑하고, 기능 요구 사항을 Features에 매핑하며, 기술 사양을 User Stories에 매핑합니다. 각 BRD 요구 사항에 고유 식별자(예: BRD-3.2.1)를 할당하여 모든 Jira 버전에서 계속 유지합니다.
계약에서 설계 사양을 요구하는 경우, Epic 설명, 수용 기준 및 Figma 링크를 정식 문서로 내보냅니다. 버전 관리를 유지하기 위해 서명에는 DocuSign을 사용합니다. 이는 Agile 작업 항목을 참조하면서 Waterfall 문서 기준을 충족하는 법적 아티팩트를 생성하며, 감사인에게 필요한 문서 추적도 제공합니다.
공급업체가 표준 구성이라고 주장할 때 계약에서 가정한 복잡한 가격 모델을 Salesforce CPQ가 지원하지 않는 기술 발견을 어떻게 처리합니까?
후보자들은 종종 당황하고 플랫폼을 전환하거나 패배를 수용하라고 제안합니다. 전문적인 접근 방식은 기술 스파이크 문서화 및 제약 분석을 포함합니다. 즉시 특정 Apex governor 제한이나 CPQ Quote Calculator 플러그인 제약을 방지하는 원인을 문서화합니다. 세 가지 옵션을 비교한 결정 기록을 작성합니다: 사용자 정의 Lightning 구성 요소 개발(높은 비용, 높은 위험), 프로세스 우회(비즈니스 영향), 또는 제3자 AppExchange 솔루션(라이센스 비용).
이것을 변경 관리 위원회에 제출하고 제약이 해결되지 않으면 위험에 처할 수 있는 수익에 대한 비즈니스 영향 평가를 제시합니다. 제약이 계약상 가정에서 비롯된 경우(예: 시스템은 무한 계층 가격을 지원해야 함), 이것은 카디널리티 가정 위반으로 간주될 수 있습니다. 이 재분류는 항목을 범위 변경에서 계약상의 명확화로 이동시켜 벌칙을 피할 수 있으며, 동시에 실행 가능한 기술 솔루션을 제공합니다.