Stage2. 알파 리뷰 (Alpha Review) [프로젝트 라이프사이클]
킥오프미팅(Kickoff Meeting)으로 프로젝트를 시작하고 나서 고객의 요청사항이 수집되면 솔루션 개발이 본격적으로 시작된다. SaaS(Solution as a Service) 서비스 내에서의 솔루션 개발은 플랫폼 내에서 실행 여부를 파악하는 것부터 커스터마이제이션(Customization) 방법까지 고려하여 진행한다. 개발이 60~70% 정도 완료되면 고객의 테스트환경(Sandbox)에서 직접 서비스가 구동되는 것을 시연하고 리뷰하는 미팅을 진행하는데 이를 알파 리뷰 (Alpha Review)라고 칭한다.
Alpha Review : 60~70%의 개발이 완료된 상태에서 고객이 기대한 바와 같이 서비스가 구축 되었는지 시연하고 리뷰하는 미팅
Alpha Review 단계에서의 서비스는 불안정할 수 있다. (30% 내 아직 발견하지 못한 버그가 존재할 수 있으므로!) 그렇기 때문에 알파 리뷰를 위한 데모(Demo)를 진행하기 전에는 '개발된 범위'와 '개발중인 범위'를 명확하게 나누어두고 아직 준비되지 않은 부분에 대해서는 사전에 확실하게 언급하고 진행되어야 한다.
고객이 서비스에 대해 기대하는 점과 현시점에서 구현된 서비스에 대한 차이(Gap)에 대한 사전 확인을 한다. 미팅 시작 및 시연 전에 이를 미리 공유한다면 그 사이에 존재하는 갭을 최소화한 상태에서 리뷰를 진행할 수 있기 때문이다.
Alpha Review 미팅에서는 보다 적극적인 커뮤니케이션과 의견 조율이 필요하다. 30%의 여유를 남겨둔 상태로 전체적으로 큰 틀이 변경되지 않는 선에서는 필드 추가나 변경 및 간단한 검증 규칙(Validation Rule)을 추가하는 것은 가능하기 때문에, 열린 자세로 고객의 의견에 경청하고 기록해둔다.
종종 리뷰 미팅 중에 현재 프로세스에서 크게 벗어난 큰 토픽(Topic)이 제시되거나, 비즈니스팀 내부적으로 논의되어야 할 사항들이 미팅이 갑자기(?) 토픽으로 나타나는 경우가 있다.
예상치 못한 토픽이 미팅에서 제시되었을 경우
현재 프로세스에서 크게 벗어난 토픽이 제시된다면, 그 부분은 Out Of Scope 이며 추가적인 논의는 다른 미팅에서 모든 이해관계자(Stakeholders)를 초대하여 논의하도록 가이드하는 것이 좋다. 현재 미팅의 목적은 현재 진행중인 서비스를 리뷰하고 앞으로의 방향을 다잡는 일이 목적이므로, 논제에 벗어난 사항들은 시간적으로 모두 풀기 어려울 뿐만 아니라 미팅 참석자들이 해당 논의와 모두 관련된 것은 아니기 때문에 자칫하면 전체적인 분위기가 어수선해질 수 있다.
비즈니스팀 내부적으로 논의되어야 할 사항들이 프로젝트 미팅에서 계속 논의가 될 경우에는 상황을 지켜보다가, 해당 안건이 빠르게 마무리 될 수 있고 프로젝트 프로세스 상에 도움이 될 이야기라면 조금 더 기다려 줄 수 있을 것이다. 그러나 긴 시간 및 추가적인 이해관계자(Legal / Compliance) 등의 의견이 필요한 항목이라면, 비즈니스팀 내부적으로 논의 진행 요청을 드린 후 결과를 가지고 프로젝트팀에서 그 결과를 어떻게 반영할 것인지에 대해 고려해야 할 것이다.
서비스 데모(Demo) 단계
Alpha Review 는 요구사항(Requirment) 단위로 리뷰하며 서비스 데모 중에서도 어떤 요구사항을 기반으로 구현된 것인지 언급하는 것이 좋다. 미팅이 끝나고 나서는 전체 요구사항을 리뷰하며 현재까지 구현된 부분과 아직 구현중인 부분을 나누어 설명하고 Beta Review 에는 전체 요구사항에 대한 업데이트 및 Alpha Review 에서 제기된 추가적인 요청사항에 대해서도 포함될 것이라는 것을 언급한다.
Alpha Review 이후에는?
Beta Review 는 90% 이상의 개발과 고객의 데이터가 추가된 상태로 완성에 가까운 모습으로 리뷰를 진행하기 때문에 서비스가 변경될 수 있는 기회는 Alpha Review 미팅이 마지막(?)임을 알리는 것이 좋다. 고객의 입장에서는 필드 추가나 변경이 작은 것이라고 생각할 수 있으나 나비효과 처럼 그 변경이 여러 모듈에 영향을 끼칠 수도 있고, 스크립트나 교육용 자료가 이미 생성되었다면 모두 리뷰하고 수정하는 과정을 거쳐야 하기 때문에 추후 변경에 대해서는 전체적으로 잘 고려되어야 한다.
이 글이 도움이 되었다면 🧡 공감 부탁 드립니다 :)
댓글도 언제나 환영입니다.
[미국 IT회사 SaaS 애자일 프로젝트 라이프사이클 훑어보기 👀]
1. 킥오프 미팅 (Kickoff Meeting) - 프로젝트 라이프 사이클
소개팅과 같은 만남에서도 그렇고 비즈니스 관계에서도 처음 만나는 자리에는 조금 더 신경을 쓰는 것이 당연지사. 좋은 인상을 남기기 위해서는 외적인 부분도 중요하겠지만 비즈니스의 첫 단
lailaworld.tistory.com
2. 알파 리뷰 (Alpha Review) - 프로젝트 라이프 사이클
킥오프미팅(Kickoff Meeting)으로 프로젝트를 시작하고 나서 고객의 요청사항이 수집되면 솔루션 개발이 본격적으로 시작된다. SaaS(Solution as a Service) 서비스 내에서의 솔루션 개발은 플랫폼 내에서
lailaworld.tistory.com
3. 베타 리뷰 (Beta Review) - 프로젝트 라이프 사이클
알파 리뷰 중에 수집된 요청사항을 기반으로 수정된 버전의 솔루션을 구축하고 샘플 데이터(Sample Data)를 업로드한다. 90% 정도 완성된 시스템을 기반으로 최종 리뷰 하는 세션을 베타 리뷰라 칭
lailaworld.tistory.com
4. UAT (User Acceptance Testing) - 프로젝트 라이프 사이클
#UAT(User Acceptance Testing) 프로젝트 착수 미팅(Kick Off Meeting)부터 시작하여 개발을 완료하는 단계에 이르렀다. 마지막 리뷰에서 받은 최종 요구사항을 기반으로 업데이트된 시스템을 실제로 사용해
lailaworld.tistory.com
5. 교육/트레이닝(Training) - 프로젝트 라이프 사이클
UAT 의 Sign-Off 가 끝나면 모든게 다 끝난 느낌이다. 그러나 끝날 때 까지 끝난게 아니다. (정말 그렇다.) 프로젝트팀으로서는 마무리 단계지만 비즈니스팀 입장에서는 시스템에 대한 첫 대면이자
lailaworld.tistory.com
6. 배포(Deployment) - 프로젝트 라이프 사이클
'시원섭섭하다' 라는 말이 어울릴까? 5개월 동안 진행되었던 장기 프로젝트가 끝이 났다. 이번주 내내 배포와 유닛 테스트 (Unit Test) 과정을 거치면서 배포 과정을 마무리했다. 다음주부터는 실제
lailaworld.tistory.com