01
문제를 업무의 장면으로 설명합니다.
‘데이터를 통합하고 싶다’는 요청만으로는 필요한 플랫폼과 구성을 정하기 어렵습니다. 누가 어떤 자료를 읽는지, 어떤 지점에서 업무가 멈추는지, 다음 사람에게 무엇을 넘겨야 하는지 설명하면 해결해야 할 일이 보입니다. 현재 작업을 따라가며 문제를 구체화하는 것이 출발점입니다.
칼라모피톤의 도입 검토는 현재 문제, 영향을 받는 업무, 필요한 결과와 일정에서 시작합니다. 플랫폼명이 정해져 있지 않아도 어떤 일을 개선하려는지 먼저 설명할 수 있습니다. HARBINGER·PÓLYA·RAIFFA는 각기 다른 목적을 갖기 때문에, 모든 검토가 세 플랫폼의 동시 도입을 전제로 하지는 않습니다.
02
원하는 결과와 적용 조건을 함께 정합니다.
같은 기능도 어느 자료와 시스템에 연결하는지에 따라 구축할 일이 달라집니다. 사용자가 일하는 장소, 자료의 출처와 접근 조건, 기존 시스템, 역할과 승인 범위를 함께 살펴야 합니다. 필요한 결과를 정할 때 그 결과를 만들어낼 환경도 같은 문맥에서 다룹니다.
HARBINGER의 경우 플랫폼의 공통 역량, 도메인의 업무 규칙, 고객별 자료와 흐름, 배포 환경을 서로 다른 층으로 구분합니다. 플랫폼 설명을 읽는 단계에서는 공통 역량을 이해하고, 실제 적용 검토에서는 어떤 구성을 선택할지 구체화합니다. 특정 환경을 요구사항에 적었다는 사실이 곧 그 환경의 지원을 확정하지는 않습니다.
03
확인할 결과가 있어야 검토가 이어집니다.
첫 검토에서 어떤 변화가 있으면 일이 나아졌다고 볼 수 있는지 정해야 합니다. 예를 들어 같은 대상의 변경 이력을 함께 읽는 것이 목적이라면, 단순히 화면이 열리는 것과 담당자가 필요한 변경을 찾아 이해하는 것은 다른 확인입니다. 필요한 결과를 사용자 행동으로 표현하면 무엇을 살펴볼지 선명해집니다.
일정, 필수 요건과 결과의 범위를 맞추는 일은 사업 협의의 일부입니다. 소프트웨어 자체의 기능과 구성·연동·교육·운영 지원의 책임을 구분해 읽어야 무엇을 함께 정해야 하는지 알 수 있습니다. 실제 제공 범위와 조건은 해당 프로젝트의 적용 범위에서 확인합니다.