[edit]
프로그램/프로젝트 계획과 관리 #
준비 평가
- 강력한 스폰서는 확보되었는가?
- 강한 비즈니스 동기가 있는가?
- 데이터에 대한 실행 가능성이 있는가? (데이터 품질에 문제가 있다면 상당 시간 클린징해야 함)
- 비즈니스 조직에게 의미있고, IT조직이 관리 가능한 범위(비즈니스 조직과 IT조직의 공동 협업 필요)
- 초기에는 하나의 비즈니스 프로세스로부터 추출한 데이터에 집중하는 프로젝트를 해야 함.
- 비용 산정은 단기 성장을 고려한 여유 비용을 확실하게 확보한다.
- 단순히 비용 절감에 초점을 두면 안됨.
- 'single view', '유연한 정보 접근'으로는 부족함.
- 비즈니스 스폰서, 비즈니스 드라이버, 비즈니스 리더, 비즈니스 사용자
- 비즈니스 분석가, 데이터 담당자, BI 어플리케이션 설계/개발자
- 프로젝트 관리자, 테크니컬 아키텍트, 데이터 아키텍트/모델러, DBA, 메타데이터 코디네이터, ETL 아키텍트/설계자, ETL 개발자
- 각 단계와 산출물들로 프로젝트가 정상적으로 진행될 수 있음을 확인되어야 함.
- 수용 가능한 체크 포인트 식별
- 요구사항 범위 변경 시 옵션
- 범위 증가(시간, 자원, 예산)
- 제로-썸(원래 범위를 유지하거나 다른 것을 포기)
- No(개선 요건으로 처리)
- 범위 증가(시간, 자원, 예산)
[edit]
비즈니스 요구사항 정의 #
요구사항 사전 계획
- 그래뉼래러티와 차원수에 대해 질문하지 말 것
- 무엇을 하려고 하는 지, 왜 그래야 하는지, 어떻게 결정을 내리는지, 미래에 어떻게 결정을 내리고 싶어하는지 등의 질문
- 토론 방법의 선택
- 경험상, 설문조사는 적적치 않음
- 인터뷰를 통해 상세 요건을 수집 후, 그룹 미팅을 통해 요구사항에 대한 동의를 이끌어 냄
- 경험상, 설문조사는 적적치 않음
- 공통 데이터와 비즈니스 어휘를 이해할 필요가 있음
- 비즈니스 파워 분석가의 직관이 가치가 있을지라도, 중간 관리자나 고위 경영진을 무시할 수 없음. 안 그러면 전술부분만 강조됨.
- 하루에 3~4개 이상의 회의를 잡는 것은 좋지 않다.
- 친절, 친절, 친절
- 회의 목적을 설명할 사람이 회의 전에 결정되어 있어야 함.
- 비즈니스 중심의 언어를 사용. IT용어는 최대한 자제
- 인터뷰의 목적은 비즈니스 부서가 무엇을 하는지, 왜 하는지를 말하게 하는 것
- 비즈니스 관리자는 표준화된 분석 환경의 전달에 더 관심이 있다.
- 비즈니스 지원 가능성을 평가하기 위해 원천 시스템 전문가나 주제 영역 전문가와의 회의를 중간중간에 배치하는 것도 도움이 된다.
- 회의록은 바로 공유
- 업무프로세스/이해관계자 메트릭스를 종종 공개
- 잠재적인 비즈니스 영향력(y축), 실행가능성(x축)을 바탕으로 우선순위 정함