웹 기획, 문제를 찾고 개선하기 위한 방법

문제가 무엇인가? 문제점을 찾아내는 방법

웹사이트는 지속적으로 개선 되어져야 한다. 완벽한 시스템은 존재하지 않는다. 또는 그 순간 완벽했다 할지라도 시간의 영향을 받는 e비즈니스, IT업계에서는 시간이 흐름에 따라 전략과 전술일 달라져야 하기에 완벽에 가까워지기 위해서는 끊임없이 문제점을 찾아내고 개선해야 한다.

 

그렇다면 문제점을 어떻게 찾아 낼것인가?

 

기획자의 머리속으로 구상하여 "이것이 문제점이겠지!!" 라는 것을 개선점으로 잡을 것인가? 아니면 옆부서사람의 의견을 듣고? 그것도 아니면 상사의 의견? 또는 고위직 상사의 지시로? 누가 봐도 이런 방법은을 합리적이고 논리적이지 못하고 주먹구구식의 웹사이트 운영이라고 밖엔 볼수 없다. 단순히 회사의 브로셔 기능을 하는 홈페이지라면 그렇게 해라! 그러나 웹사이트를 통해 무엇인가 고객이 가치를 창출하고 가길 원한다면 이런방법은 백번 지양해야 함이 옮은 것이다.

 

가장 일반적인 문제점을 찾아내는 방법은

• 설문(Research)을 통한 문제발견과
• 사용자 입장에서 바라보는 기획자의 발견

 

일 것이다. 물론 로그분석도 있고 기타 방법들도 있지만 가장 손쉽게 정보를 얻을 수있다는 점에서 이 두가지 방법을 우선 선택하였다. 우선 두번째 방법은 "기획자의 통찰력"에 의존하는 방법인다. 이 방법은 얼마나 기획자가 유능하냐에 따라 문제를 발견할 수 있는 정확도가 높아진다. 그러므로 변수가 많다고 할 수있다. 첫번째 문제는 가장 대표적인 문제 발견 방법으로써 설문지를 어떻게 개발하느냐에 관건이 있다. 사회조사 방법론의 이론을 바탕으로 설문지를 잘 개발하는것도 쉽지 많은 않은 문제 이다.

 

설문과 기획자의 통찰력과 더불어 문제점을 발견할 수 있는 방법이 몇가지가 더 있다.

 

• FGI, 포커스 그룹 인터뷰를 통한 문제발견
• VOC, 고객의 소리를 분석하여 문제를 발견
• VOB, 회사 내부 경영진 및 비즈니스 전략에 따른 전략적 문제 발견
• Usability TEST, 유저빌리티 테스트를 통한 문제 발견
• log 분석, 로그분석을 통한 문제발견

 

포커스그룹 인터뷰 경우는 웹사이트 이용자과 같은 부류의 인원을 4~5명 선정하여 상세한 질문으로 된 질문지로 문제점을 찾아내며 기타 구두로 여러가지 논의를 통해 문제점을 발견해 낸다. VOC기법은 6시그마에서 가장 중요하게 사용되는 방법으로써 평소에 고객의 소리를 데이터베이스화 하여 가장많고 Critical한 VOC를 골라내는 방법이다. VOB는 회사내부의 의견으로써 중장기적인 전략과 관련된 전략적의견으로써 개선점을 찾는 방법으로써 이는 VOC와 함께 쓰인다. 유저빌리티 테스트는 사용자의 사용형태를 여러가지 방법을 통해 지켜봄으로써 사용자가 이용하기 어려워 하는 부분을 직접적으로 묻거나 설문하지 않고 찾을수 있는 방법이다. 또한 로그분석을 통하여 문제점을 발견 할 수도 있다.

 

 

문제를 찾았다면. 동일한 문제를 잘 해결한 곳을 벤치마킹 하라.

사실 문제의 해결점을 찾기위한 방법에 벤치마킹만큼 좋은 방법이 없다.

"벤치마킹이란 내가 가지고 있는 것들을 토대로 다른것들의 일류요소를 접목시켜 새로운 구성을 만들어내는것"이라 정의 할 수 있다." 이를 제대로 수행하기 위해서는 1)평가기준이 명확해야 하며 2)객관적인 데이터를 수집할수 있어야 한다. 또한 3)어떻게 벤치마킹해야 한다는 구체적인 방안이 제시되어야 하며 4)철저하게 외부적인 관점에서 진행 되어야 한다.

 

데밍 "벤치마킹 4단계" 를 살펴 보겠다.

계획 -> 수행 -> 전략 수립 -> 리모델링의 4단계로 이루어져 있다.

 

계획, 현존하는 시스템의 프로세스를 분석하고 수행절차에 대한 계획수립,평가모델개발, 대략적인 벤치마킹 영역을 설계하고 수행, 벤치마킹 대상, 벤치마킹 영역, 벤치마킹항목, 벤치마킹기준을 시트로 작성하여 수행 하도록 한다. 전략수립, 수행된 시트를 기준으로 사이트를 분석하여 경쟁력확보를 위한 방법을 수립하고 차별화된 전략수립, 성과차이와 동인분석을 실시한다. 리모델링, 앞의 결과를 기준으로 재 설계를 실시한다.

 

문제 해결 방법을 구체화 하라

문제가 정의 되었다면 해결 방법 찾아야 한다. 일단 벤치마킹을 통하여 몇가지 해결 방안을 찾을 수 있을 것이다. 그 이후에는 기획자의 "통찰력"을 많이 필요로 하는 부분이다. 여러가지 리서치, 로그분석, 유저빌리티 테스트 등을 통하여 나온 정보들을 기준으로 해결방법을 구체화 시켜야 한다. 이는 웹기획자의 직관에 의해 바로 "해결방법"이 나오는 경우도 많이있고 여러가지 사고를 통하여 해결 방법을 찾기도 한다.(가장 일반적인 방법이다. 기획자가 모두 컨설턴트는 아니므로)

 

체계적으로 해결방법을 찾는 방법론도 존재 한다. 간단하게 도식화 하면

"생각하고 -> 정리하고 -> 분석한다."라고 표현할 수 있는데

생각하는 법은 제로베이스사고, 프레임워크사고 등이 존재한다.

정리하는 법은 커미트먼트, 스트럭쳐,컨셉의 방법 등이 존재한다.

분석하는 법은 로직트리(what,why,how), 매트릭스, 프로세스방법이 존재한다.

 

이들 내용에 대한 상세내용은 차후에 다루기로 하겠으니 "웹기획 기초" 부분인 이 단계에서는 이쯤에서 넘어가도록 하자.

 

 

 

설계하라 어떻게? 제대로!!

이제 드디어 눈에 보이는 웹기획자의 작업영역에 들어간다. 초보 기획자는 이것으로 능력의 유무가 판단될 만큼 겉으로 보이는 유일한 부분이다. 많은 설계문서를 접해보고 자신만의 설계방법을 찾아 나가도록 하자(웹기획 커뮤니티에 보면 관련문서들이 많이 보이므로 많이 벤치마킹하여 자신만의 설계방법을 만들어 나가자)

 

IA설계

새로 구축하는 것이 아니고 개선하는 것이기 때문에 기존의 IA에 대한 전반적인 이해를 필요로 한다. 개선될 사항에 대하여 정보구조를 재설계 하는데 이는 정보를 분류하는 분류법에 대한 기준과 매뉴의 분류등을 포함한다. 네비게이션 설계는 방향성이 존재하는 아이콘, 텍스트, 메뉴 등에 대해 어떻게 표현할 것인지를 설계하는 것이다. 레이블링 설계는 각 메뉴 및 텍스트의 명명법이며 사용자의 언어로 사용자가 직과적으로 알수 있도록 네이밍 하는 것이다. (차후 구체적으로 논의 하자)

 

관련 문서로는 IA설계서를 작성하여 각 데이터간의 관계를 명시해주고 네이밍을 명시해 준다. 메뉴 구조도 같은것도 첨부 할 수 있다.

 

UI설계

드디어 나왔다. 스토리보드를 설계하는 것을 말한다. 화면이 어떻게 구성되어지고 어떤항목이 어떻게 나열되며 IA설계된 항목들이 어떻게 유저빌러티가 증가하는 방법으로 배치될 것인가의 문제를 정의 하는 부분이다., 또한 그래픽 유저 인터페이스(GUI) 도 고려하여 시각적인 부분도 모두 기술하여 웹디자이너나 개발자들이 보고 쉽게 파악할 수 있도록 명시해야 한다.

 

내가 언젠가 이야기 한적이 있다. "스토리보드만 그리는 것이 웹기획자가 아니다." 스토리 보드를 제대로 설계하기 위해서는 이전에 배운 여러가지 웹기획자의 임무를 수행해야 하며 무수히 많은 노력을 기울여야 한다. 눈에 보이는것은 기획안과 스토리보드지만 거기에는 철학과 방법과 피땀이 녹아 있어야 하는 것이다.

 

프로그램의 로직컬 설계

개선되는 기능에프로그램 기능들이 늘어갈 경우에는 로직컬한 순서도를 그려줘야 한다. 예를들어 회원가입과 같은경우의 순서도, 채팅프로그램이라 한다면 채팅을 하기위한 로직컬한 순서도를 그려줘야 한다. 이런 부분을 개발자가 순간적으로 판단하여 본인들의 생각으로 그냥 개발을 진행해 버리는 경우가 많이 존재하는데 이렇게되면 사용자의 유용성은 현저하게 떨어지고 중장기적으로 사용자를 떨어뜨리게 하는 주요 요소 이므로 반드시 기획자가 사용자 입장에서 설계 해야 한다.

 

데이터베이스 모델링 및 설계

DBA 또는 개발PL이 한다. 개발자 출신의 경우 설계는 아니더라도 모델링 부분에 개입되어 관계형데이터베이스의 기초부분을 논의 할 수 있다면 금상첨화라 할 수 있다. 데이터베이스 모델링 분야만해도 굉장히 난해하고 어려운 분야이다. 여기서 모든걸 다 다룰 수 없으므로 간단하기 이야기 하고 넘어가도록 한다. 관계형 데이터베이스 구조로 만들기 위해 기초로 데이터 베이스 모델링을 한다. 논리적인 객체를 정의 하고 이들의 관계를 논리적으로 설정하여 기본윤곽을 만들어 나가는 단계이다. 이를 가지고 데이터베이스 설계자는 구체화 시켜 테이블과 칼럼들을 설계해 나가면 된다. 이 분야에 어느정도 안다면 웹기획자가 어느정도 모델링에 개입되어 의견을 전달하는것이 좋다. 데이터베이스 모델링은 사이트의 근본을 만드는 뼈대 작업이므로 매우 중요하다 할수 있다. (기회가 되면 차후에 관계형데이터 베이스에 대해 강의 하기로 하겠다.)

 

기술적인 설계

개발 PL과 상의 해야 하고 개발PL이 설계해야 하는 부분이다. 이것도 마찬가지로 웹기획자와 혐의 후에 진행 되어져야 한다. 어떤기능들을 어떤 기술로 구현할 것인지에 대한 협의가 이루어 져야 한다. 이부분에서 개발자들과의 마찰이 굉장히 많다. 우선 기술들에 대해 많이 아는 것이 중요하며 적제 적소에 제대로 쓰일 수 있도록 해야 한다. 어떤 기술들은 너무 고난이도라 구현하기 어려울 수도 있고 솔루션을 구입하려면 금액이 많은 경우도 다수 존재한다. 이러한 사항들을 어느정도 알고 있어야 개발자와의 커뮤니케이션에서 무시당하지 않고 리딩할 수 있는 것이다.

 

디자인과 개발 코딩

일반적으로 설계가 이루어지고  스토리보드가 나온 항목에 한해서 웹디자인 작업에 들어간다. 웹기획자와 구도로의 커뮤니케이션을 통해, 스토리보드의 문서화를 통해 의견을 전달하며 그것들이 원하는데로 제대로 이루어지고 있는지 수시 확인 해주어야 한다. 기획의도를 디자이너가 잘못 파악할 수도 있다.

 

또한 중요한 화면인 경우 시안1,시안2등과 같이 몇가지 대안을 제시하도록 요구해야 한다. 최종의사결정자에게는 2가지 정도의 디자인 안을 주어 선택하도록 한다. 3개 이상의 시안을 제시하지 않도록 한다. 시안이 많아지면 선택에 혼란이 가중되어 이도저도 아닌 또다른 디자인을 요구 할 때가 많아진다.

 

또한 디자인 작업이 어느정도 진행이 되면 개발 코딩이 들어가야 된다. 개발이 최초 시작되어야 할 부분이 있기 떄문에 그것과 맞추어 디자인작업의 우선순위도 정해야 한다. 이와 같은 사항들을 웹기획자는 WBS와 간트 차트로 일정을 만들어 디자이너와 개발자에게 배포 하여야 하며 제대로 진행이 된는지 수시 체크하여야 한다.

 

개발이 단위별로 마쳐질때마다 개발자는 기획자에게 보고하여야 하며 기획의도에 맞게 개발이 되었는지 바로 체크하여야 한다. 이 부분에서도 커뮤니케이션이 매우중요하다. 아무리 커뮤니케이션이 잘 되었다 하더라도 오차는 있는법, 의도했던 설계되로 안된 경우도 많이 존재하고 처음에는 이렇게 생각하다가 나중에 의도가 바뀌거나 전략이 바뀌어 다시 수정해야 하는 상황이 벌어지기도 한다. 이때 개발자는 많이 짜증이 나므로 개발자를 최대한 이해시켜 다시 작업하도록 해야 한다. 평소에 신뢰가 있었다면 서로 이해하고 넘어갈 수 있을것이고 평소에 서로간의 신뢰가 없었다면 많은 뒷 담화(?)가 일어날 것이므로 주의깊게 중복작업이 이루어지지 않도록 고심초사 설계해야 할 것이다.

 

검수 및 테스트

검수를 제대로 하고 테스트를 정확히 함으로써 오픈이후 발생될 사용자오류를 최소하 할 수 있다. 사용자오류, 버그의 발생은 웹사이트의 신뢰도에 상당한 영향을 미치므로 정확히 세세하게 테스트 해야 할것이다. 아래는 여러가지 테스트 방법론에 대한 것들이므로 그때 그때 상황에 맞게 응용 하면 되겠다.

 

파일럿 테스트(단위 테스트)

개발이 진행되면서 완성되지 않은 어느정도 완성된 모듈에 대해서 테스트 하는 것으로써 사전적 의미는 "처음으로 만든 견본시작품(見本試作品)에 대한 수용자의 반응조사. 거리에서 무작위로 뽑은 수용자를 대상으로 파일럿 프로그램에 대한 선호도를 조사한다" 이다.

 

블랙박스 테스트(개발자가 주로 함)

내부 기능 구조는 살펴보지않고 함수와 같이 INPUT 'X'를 넣었을 경우 OUTPUT 'Y'가 나오는지 확인하는 테스트 이다. 블랙박스 테스트는 다음 과 같은 부류의 오류를 발견하기 위해 시도 된다.

 

1)부정확하거나 누락된 기능

2)인터페이스 오류

3)자료 구조나 외부 데이터베이스 접근에 따른 오류

4)행위나 성능 오류

5)초기화와 종류 오류

 

화이트 박스 테스트(개발자가 함)

코딩된 소스에 대한 테스트를 의미 한다.

 

알파 테스트

내부필드테스트라고도 한다. 신제품을 개발한 회사가 자사 직원을 대상으로 실시하는 자체 검사를 뜻한다. 알파버전의 소프트웨어·하드웨어·인터넷서비스·온라인게임 등을 실제 사용환경에서 동작시키는 방식으로 이루어진다. 테스트 계획을 세워 내부인력으로 테스트 한다. 물론 테스트범위및 테스트 시트를 만들어 테스트 한다.

 

베타 테스트

베타 테스트란 하드웨어나 소프트웨어 제품을 정식상품으로 내놓기 전에 오류가 있는지를 발견하기 위해 미리 정해진 사용자 계층들이 써보도록 하는 것을 말한다. 외부 몇 계층의 베타테스터를 선정하여 문제를 찾아 낸다.

 

프로토 타이핑 패러다임 방법론으로 시스템을 개선하자

소프트웨어 공학적 관점에서 보면 시스템 분석부터 최종완료까지 나름대로의 학문적인 정의가 많이 이루어져 왔다. 그동안의 대부분의 웹팀에서는 폭포수 모델을 기본으로 프로세스가 진행되었으리라 생각이 된다. 본인들 팀이 이제 좀 성숙해졌다 생각하면 원형 모델이나 나선형 모델을 시도하여 생산성과 퀄리티를 동시에 높이기 바란다.

 

폭포수 모델

워터폴 모델·폭포수 모형·선형순차 모형·단계적 생명주기라고도 한다. 한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 다음 단계로 넘어간다는 의미에서 붙여진 명칭이다. 전통적인 시스템 생명주기 모델로 소프트웨어를 개발할 때 가장 널리 사용된다.  가장 고전적인 모델로서 우리도 너무나 당연히 이 모델을 이용하고 있다. 일반적으로 분석->설계->구현->시험->유지보수의 단계를 거치며 각 단계 완료후 그다음 단계로 이동한다.

 

원형(프로토타이핑) 패러다임 모델

시스템 개발시 고객이 목표를 정의 하였으나 요구되는 속성을 어떻게 만족시킬지 잘 모르는 경우, 구체적이지 않을 경우, 수시로 변경이 되는 경우 사용되는 방법으로써 시제품(프로토타입)을 보여주고 다시 작업에 들어간다. 원형 패러다임 모델은 폭포수 모델의 단점을 보안하기 위해 점진적으로 시스템을 개발해 가는 방법이다.

 

나선형 패러다임 모델

폭포수 모델과 원형패러다임의 장점에 새로운 요소인 위험 분석(Risk analysis)을 추가하여 만든것으로써 이방법을 선택할 것인가의 문제는 위험수위의 판단으로 결정한다. 나선을 돌면서 점진적으로 완벽한 시스템을 개발하는 것이 목적이고 비용이 많이 들거나 시간이 오래걸리는 큰시스템에 적합하다.

 

일반적으로 최초 웹사이트 구축시 원형 패러다임과 목포수 모델을 섞어가며 구축하는 것이 좋을 듯하다. 각 단위 모듈별로 그에 알맞는 방법을 선택하여 퀄리티를 높이도록 해야 겠다.

 

문제를 찾아내고, 해결방법을 찾고, 분석하고, 설계하고, 방법론을 거쳐 개발과 디자인을 하고, 검수 및 테스트마치고, 고객의 앞에 다가서도록 하는 일. 웹기획자가 모두 관여해야 하는 기본적인 업무임을 명심해야 한다.