프로젝트 실행
신사업 프로젝트 lesson & learned (6)
MGY 프로젝트는 초기 자사의 시스템을 기반으로 한 구축을 계획했다. 이 안을 토대로 구축안을 잡다보니, 서비스 구축에 15억, 자사 시스템의 수정에 18억, 총 33억의 예상 비용이 산출됐고 구축 기간은 8개월이라는 기간이 산정되었다. 이건 전혀 가볍고 빠르지 않았다. 때문에 ‘가볍고’, ‘빠르게’ 진행할 수 있는 방안을 원점에서 다시 고민하기 시작했고 대대적인 방향의 전환을 시도했다.
1. 핵심적인 서비스만 남기기
초기의 MGY의 서비스안은 커뮤니티와 동영상, 개인화, 광고, 집적정보 제공등 여러 서비스가 복합적이고 유기적으로 연결되면서 차별화되고 경쟁력을 갖는 안이였다면 지금의 MGY는 ‘궁금해요’라는 차별화 포인트를 통해 SNS와 커머스가 연결된 간결한 서비스를 하고 있다. 개념상으로는 계속 덜어내야 한다고 하지만 현실은 고민을 하면 할수록 기능을 더하게 되고 세부적인 요소들이 점점 추가 되는 것이 현실이다. 프로젝트를 하면서 이런 딜레마에 빠진다면 기능 단위로 이것이 필요한지 아닌지를 검토하기 보다는 완전히 원점에서 재검토하는 것을 권장한다.
궁금해요 : 1020세대들이 SNS를 사용하면서 작성자의 정보를 궁금해하고 알려달라고 댓글을 다는 패턴에서 착안한 서비스로 MGY의 핵심 차별화 서비스로 기획.
2. 기존과 다른 구축 방안
자사 시스템을 활용한 안으로는 도저히 빠르고 가벼운 안을 찾기 어려웠다. 이것도 원점에서 재검토가 필요했다. 빠르고 가볍게 할 수 있는 방법을 찾기 위해 생각해 낸 방법은 '상용 e커머스 솔루션'을 활용하는 것이었다. MGY 프로젝트는 크게 두 가지의 핵심 요건이 있었다. 하나는 '입점형 오픈마켓'이고, 또 다른 하나는 인스타그램처럼 유저간 관계 관리(팔로우/팔로잉)가 가능한 'SNS형 커뮤니티'였다. 이 두가지 요소가 제공 가능한지를 기준으로 업체 서칭을 시작했다.
표 4. e커머스 솔루션 제공 회사 검토 리스트※ 본 자료는 18년 기준 자료로, 현재는 C**를 비롯하여 대부분 서비스를 제공하는 곳이 많은 것으로 확인됩니다.
업체 컨텍시 시간 절약을 위해서는 우리가 서비스 하고자 하는 '필수 조건'을 보유하고 있는지를 체크하고 필터링해가면서 좁혀가는게 좋다. 상용화된 e커머스 솔루션의 주요 고객은 소호몰이다 보니, 대다수의 회사들이 입점형 오픈마켓 서비스를 제공하지 않고, 전문몰 형태의 자체 상품을 판매 하는 기능으로 구성되어 있었다.
또한 SNS형태의 유저간 관계 관리(팔로우/팔로우) 기능은 온전히 신규 개발이 필요한 영역이라 커스터마이징의 개념 보다는 SI 성격이 강했다. 이렇게 1차적으로 A사와 B사 2개를 선정하여 내부 평가를 진행했다. 평가자는 총 15명으로 내부 팀원 5명, 유관부서 팀원 10명으로 총 15명이 진행하였으며, ‘A사’ 71.7점, ‘B사’ 61.0으로 최종 ‘A사’가 선정되었다.
표 5. 솔루션 선정 주요 정보3. 확장성 고려
e커머스 상용 솔루션들은 개발 언어가 PHP 인 솔루션들이 대다수였다. 선정된 A사는 PHP와 JAVA 버전 두가지 솔루션을 모두 보유하고 있었다. 비용 측면에서만 놓고 보면 PHP 솔루션이 JAVA 보다는 저렴했지만, 확장성 및 추후 내재화 등을 고려하여 다각적인 부분에서 검토가 필요했고 다음과 같은 기준으로 비교를 해서 JAVA를 선택했다.
표 6. 개발언어 비교 검토4. 외주사 선정 절차
여건이 된다면 가능한 협력사를 통하지 않고 팀 내에서 직접 개발하는 것이 가장 좋다. 이것이 지속적인 환경과 비즈니스 변화에 빠르게 대응하기 위한 가장 적합한 방식이다. 하지만 상황상 협력사를 통해 개발해야 한다면 규정과 절차를 지키는 범위에서 가장 빠르게 진행할 수 있는 방안을 찾아야 한다. 자사의 정식 절차는 RFP를 보내고 제안설명회를 가진 후 참여업체들의 경쟁 PT를 통해 평가하여 선정하는 것이나 이 경우 업체 선정에만 최소 1~2개월이 소요 된다.
따라서 MGY 프로젝트에서는 미리 '체크리스트'를 만들어서 업체들에게 보내고 이를 항목별로 점수화해 비교하고 선정했다. 이렇게 하면 경쟁 PT를 통한 비딩 없이도 업체간 명확한 기준을 통해 비교가 가능할 뿐 아니라, 업체 선정에 대한 근거가 되기 때문에, 빠른 진행이 필요한 경우 유사 절차를 고민해봄직하다. 간소화하더라도 업체 선정과 협상 및 계약까지 꽤 많은 시간이 소요 되니 Kick-off 일정을 역산하여 1개월전에는 업체 컨텍과 평가 준비가 되어 있어야 한다.
5. 요구사항 도출
새로운 서비스를 구축하는 경우 초기에 모든 요구사항을 상세히 도출하기는 어렵다. 설사 도출하더라도 여러 이유로 쉽게 변경되기 마련이다. 때문에 필수 요구사항만 확정하고, 나머지는 TASK 단위로 타당성을 파악해 우선 순위를 조정하며 개발하는 것이 필요하다. 프로젝트 초기에는 무엇이 필요한지 정확히 모르기 때문에 모든 기능을 담고 싶어 한다. 이 경우 프로젝트의 가치를 높이기 보다는 쓸데 없는 기능만 늘려 오히려 품질을 떨어뜨리기 쉽다.
기능이 많으면 복잡성이 증가하고 테스트 분량은 제곱의 제곱 형태로 기하 급수적으로 늘어난다. 비즈니스 상황에 따라 프로젝트 중간이라도 요구사항은 얼마든지 변경할 수 있다고 보고, 초기에는 개략적인 일정과 비용을 추정할 수 있는 상위 수준의 요구사항만 도출하여 초기 투자의 낭비를 줄이고 출시 후에 고객의 피드백을 받아 개선하는 방식으로 개발하는 것이 필요하다.
6. 요구사항 정의
팀 구성원 모두와, 가능하다면 고객도 함께 참여하여 요구사항을 도출한다. 어떻게, 무엇을 만들 것 이냐에 대한 문제는 단순히 기획을 담당하는 특정 팀원만 고민할 것이 아니다. 영업, 마케팅, UX 기획, IT 개발, 디자인 등 팀원 모두가 같이 논의 하다 보면 고객의 니즈를 다양한 측면에서 바라볼 수 있기 때문에 창의적인 아이디어가 나올 확률이 높다. 또한 현재 시스템에 대한 이해를 기반한 요건 정의가 필요하다. MGY 프로젝트는 커머스 솔루션 활용했기 때문에 기본 시스템에서 커스터마이징 범위가 적을수록 빠르고 가볍게 구축할 수 있었다. 때문에 기본 커머스 영역의 요건은 줄이고 커뮤니티에 주력할 수 있도록 요건을 구체화 하는 것이 필요했다.
7. Kick-off
프로젝트는 협력사까지 포함한 구성원 모두가 프로젝트의 목적과 목표에 대해 공감하고 이해 하는 것이 매우 중요하다. 따라서 킥오프 시에는 1~2시간의 프로젝트 개요가 아닌, 프로젝트 관리자, 현업, 협력사 모든 프로젝트 팀원을 대상으로 반나절 이상의 워크숍을 진행하는 것이 좋다. MGY 프로젝트에서도 팀원들의 눈높이와 방향성은 맞았지만 외주사와는 프로젝트를 하는 동안 눈높이를 맞추기가 어려웠다. 단순한 강의나 나열이 아닌 프로젝트의 배경 및 목표, 관리 방법 등을 모든 관계자가 이해하고 공감하는 것이 상당히 중요하다.
8. Co-work
앞서도 언급했지만 Co-work에 있어서 물리적 거리는 매우 중요하다. 협력사와도 마찬가지다. SI 회사와는 다르게 솔루션 회사들은 자사내 커뮤니케이션이 중요하다는 것을 이유로 파견을 잘 하지 않는다. 때문에 물리적인 거리로 인해 회의를 비롯한 커뮤니케이션이 일부 제한적이고 원활하지 못했던 아쉬움이 있다. 그렇다 한들 업체를 선정 시 기술적인 부분 외에 위치까지 고려해서 선정하기는 쉽지 않다.
이에 향후 상용 솔루션 활용 방식으로 프로젝트를 진행 할 경우, 두 가지를 고려 해보길 제안한다. 첫번째는 협력업체의 PM/기획자 중 한두명을 오전 또는 오후만 파견해서 근무를 하는 것이다. 프로젝트 전체 기간은 아니더라도 잘 협의한다면 얼마든지 가능한 방법이다. 두번째는 반대로 우리 팀원이 오전 또는 오후에 협력사로 가서 근무하는 것이다. 파견 근무시 지켜야 할 법적 규정과 관련 절차도 상당히 많은데, 이 경우 일부 시간만 한정해 방문하는 것으로 공식적인 근무지로 인식하지 않을 수 있어 법적으로 챙겨야 할 부분도 훨씬 적다.
9. Paperwork
문서 작업은 정보 공유에는 일정 부분 도움이 되나 업무를 지연시키는 요인이 되기도 한다. 전적으로 문서에 의존해서는 안되며 꼭 필요한 수준에서 커뮤니케이션 하는 용도로만 활용하는 것이 좋다. MGY 프로젝트에서는 공식적인 회의록을 기재하지 않았다. 거의 대부분의 회의를 모든 팀원이 모여서 했으니 제3자에게 회의 내용을 공유할 필요가 없기도 했고, 회의로 도출한 결과는 대부분 그 즉시 실행에 옮겼기 때문에 이해도의 차이로 논쟁이 발생할 소지도 적었다. 업무에 회의록이 필요 없다는 의미는 아니지만 Paperwork을 줄이고자 하는 상징적인 표현으로 활용했다. 꼭 회의록이 아니더라도 상징적인 의미를 갖는 문서 한가지를 제거하는 것도 좋다.
10. R&R
여건이 된다면 와이어프레임 형태의 기획이라도 팀에서 직접 하고 외주사와 커뮤니케이션 하는 것이 좋다. 특히 솔루션사의 특성상 기존에 있는 시스템의 커스터마이징을 전제로 하기 때문에 일반적인 SI와 다르게 기획 산출물이 초기에 다 나오지 않고 개발과 기획이 병렬로 진행되어 프로젝트 중간에 산출물 확인이 쉽지 않다. 따라서 필요 요구사항의 정확한 전달과 소통을 위해 가이드가 되는 기획은 내부 팀에서 담당하기를 권장한다. 아무리 구체적인 요구사항이라도 서면과 와이어프레임 형태의 UI 기획과는 차이가 있기 때문에, 화면 기획이 있으면 원하는 방향을 최대한 정확히 디렉팅하여 커뮤니케이션 시간을 단축할 수 있다.
11. 프로젝트의 목표
전통적인 프로젝트 관리의 목표가 ‘범위’, ‘일정’, ‘비용’, ‘품질’ 준수라면, 애자일 프로젝트 관리의 목표는 ‘고객에게 가치 있는 서비스 개발’, ‘지속적인 혁신’, ‘서비스 적시 출시’, ‘확장성 있는 서비스’라고 할 수 있다. 적시 출시는 정해진 일정에 무조건 맞춘다는 의미보다는, 오히려 프로젝트 초기에 출시 일정을 정했어도 비즈니스 상황 변화에 따라 조정할 수 있어야 한다는 것이다. 프로젝트 초기의 환경과 판단이 출시를 앞둔 시점과는 짧게는 몇개월 길게는 몇년의 차이도 있을 수 있다는 것을 직시해야 한다.
12. 차선 선택
최선의 안이 나오지 않을 때, 이를 위해 고민하여 시간을 허비하기보다는 빠르게 차선의 안을 찾으려고 노력했다. 가능한 대안 리스트를 작성하고 팀원들간의 논의를 통해 최적의 해결책을 찾아 가는 방법이 낫다고 본다.
