ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 패스트캠퍼스에서 배워 본 서비스 기획
    창업실무/기획 2020. 1. 3. 00:59

    외주사에 의뢰하기 전에 창업자가 서비스 기획하는 법에 대한 글을 썼었지만 이제 개발자를 채용하고(현재 웹과 앱개발자를 채용 중이다.) 서비스를 발전시키기 위해서는 나 역시 인하우스 기획자로서 역량을 갖춰야겠다는 생각이 문득 들었다.

     

    단기속성을 좋아하는 나는 이번에도 역시나 애정하는 패스트캠퍼스에서 웹/앱 서비스 기획 강의를 수강했다. 이 패키지는 UX디자인, 서비스 기획, 프로젝트 기획으로 구성되어 있어 개인적으로는 가장 많이 도움이 된 강의였다.

     


    필기노트

    1. UX디자인

    페르소나를 지정하는 것을 필수다. 예를 들면 이렇다. 26세의 제니는 출퇴근을 지하철로 하고 저녁 7시에는 운동도 하고 맛있는 것도 먹고 워라밸에 충실한 사람이다. 이런 식으로 아주 자세하게 페르소나를 지정하고(현업자들은 퍼소나라고 많이 하는 것 같다.) 상품에 반영하고 피드백하는 과정을 반복한다.

     

    UI를 구성할 때 처음부터 아이콘으로 보여주는 것은 좋지 않다. 텍스트가 가장 확실하며 아이콘으로 표시하고 싶다면 텍스트와 함께 보여주다가 1:1 매핑이 되면 그 때 텍스트를 빼야한다. Login, 로그인 이런 식으로 같은 정보를 다르게 표시하는 등 통일되지 못한 UI는 좋지 않다. 사람들은 텍스트가 많은 것을 싫어하며, 시선이 왼쪽에서 오른쪽으로, 위에서 아래로 이동한다.

     

    클릭 등 어떤 액션을 취할 때 무슨 일이 벌어질지 알려주는 단서를 피드포워드라고 하고 어떤 일이 벌어졌다는 것을 알려주는걸 피드백이라고 한다. 무의미한 뎁스는 만들지 않는 것이 좋으며 많은 기능은 사용성을 떨어뜨리고 더 헷갈리게 만들며 하나도 제대로 되는 것이 없게 만든다.

     

    (+추가적으로 서비스 기획을 할 때 검색과정에서 결과를 보여주기까지 걸리는 시간동안 어떤 기획이 필요할지 생각해보다가 인터랙션 디자인이라는 책을 찾아보게 되었는데 유저들은 1초 이상 반응이 오지 않는다면 작업이 중단되었다고 판단한다고 한다.)

     

    2. 서비스 기획

    일단 서비스 기획자는 인하우스와 에이전시라는 2가지 진로가 있는데 인하우스는 자체 서비스를 기획하는 것이고 에이전시는 외주를 받아 타업체의 서비스를 기획하는 것이다. 인하우스는 한가지 프로덕트에 매몰될 수 있지만 그로스해킹을 통해 시장에 안착하는 과정까지 경험할 수 있는 반면 에이전시는 다양한 구축 경험을 가질 수 있을지 몰라도 디벨롭하는 과정은 경험하기 어렵다고 한다.

     

    - 폭포수 방법론

    가장 보편적인 방법론인 폭포수 방법론은 기획하고 디자인하고 개발하고 테스트하고 오픈하는, 흔히들 알고 있는 형태의 방법론을 지칭한다.

     

    폭포수 방법론에서 기획자의 산출물은 정책서, 요구사항정의서, 정보구조도, 기능정의서, 플로우 차트, 화면설계서 등이 있는데 이중 끝판왕은 단연 화면설계서이다.

    ITlab에서 가져온 화면설계서 예시

     

    물론 위에 언급한 산출물을 모두 작성해야하는 것은 아니고 각자의 환경에 따라 필요한 것만 작성하면 되겠다. 내 경우에는 한정된 자원으로 인해 정보구조도와 기능정의서를 하나의 서류로 만들고 카카오oven으로 프로토타입을 만들면서 주석을 달아 화면설계서를 대체했다. 하지만 이후에는 요구사항정의서와 플로우차트까지 활용할 계회이다. 각 산출물의 예시나 서식이 필요한 경우에는 www.itlab.co.kr에 들어가면 참고할 수 있다.

     

    안내메세지

     

    www.itlab.co.kr

     

    - 애자일 방법론

    JIRA나 Trello 같은 툴을 많이 들어봤을텐데 애자일 방법론 도구라고 한다. 애자일 방법론은 2주 정도 짧은 기간에 개발할 수 있을만큼 작은 스프린트 단위로 쪼개서 개발과 테스트를 통해 기획과 검토를 여러 번에 걸쳐서 하는 방법론이라고 하는데 사실 들어도 잘 모르겠다.

     

    요즘 핫한 린 스타트업이나 그로스해킹에서의 A/B테스트처럼 빠르게 반응을 보고 피드백을 반영하려는 방법론의 개발자 버전이라고 생각된다.

     

    애자일에서는 문서작성할 시간에 개발을 하자는 주의여서 기능정의서, 화면설계서같은 산출물은 없다. 대신 이용자가 어떤 순서로 어떤 감정을 가지고 무엇 때문에 이용한다는 것을 설명한 유저스토리와 화면이나 기능을 자세하게 찢어놓은 백로그를 작성한다. 개발자의 이해를 돕기 위해 프로토타이핑을 하기도 한다. 폭포수의 정책서는 위키 정책서로 대체한다는데 정책서는 업데이트가 힘든만큼 폭포수에서도 위키 정책서를 도입하는 것이 좋을 것 같다.

     

    who, what, why를 디테일하게 작성하여 유저스토리를 만들고(how는 개발자의 몫) 우선순위에 따라 스프린트를 나눈다. 우선순위는 BUC(비즈니스 베네핏 + 유저 베네핏 - 코스트) 에 따라 선정하는데 피보나치 수열 1,2,3,5 와 같이 차이가 나도록 점수를 메기고 선정한다. 우선순위만 잘 나눠도 일 잘한다는 소리를 듣는다고 한다.

     

     

    3. 프로젝트 기획

    프로젝트에 투입될 때 우선 WBS(업무분류체계)를 작성한다. 단계별 작업기간을 명시한 사업계획서의 마일스톤과 같은 형태이다. 그리고 R&R을 작성하는데 발주사와 수행사 구분없이 주요업무를 명시하여 커뮤니케이션이 원활하도록 한다. 

     

    메뉴 네이밍을 할 때 경쟁사가 사용하는 메뉴명을 그대로 사용해야 한다. 경쟁사의 고객이 우리의 고객이 될 수 있기 때문에 새로운 학습을 하지 않아도 되게끔 한다.

     

    기획과 디자인, 개발을 완료했으면 테스트를 해야한다. 테스트 시에는 오류 체크리스트로 진행사항을 관리하라는데 이거 정말 유용하다. 구글독스로 외주사에 처리결과를 실시간으로 작성하게끔 했는데 디버깅에 소요되는 시간을 대폭 줄여주었다. 

     

    테스트를 완료하고 배포 시에는 운영서버로 어떻게 이관할지 시나리오를 준비해야한다. 시나리오에는 오류가 발생했을 때 누가 몇시간 안에 as-is(기존 상태)로 롤백시킬지, 오픈 후에는 상황실을 몇시간 운영할 것인지, 부하는 없는지 모니터링은 어떻게 할건지, 장애 대응 시 대응인력의 비상연락망은 어떻게 되는지 등 모든 프로세스에 대한 내용을 담는다.

    댓글 0

ⓒ 2019. 도니박의창업활동로그. All rights reserved.