기획자들이 설계단계에서 가장 많이 실수 하는것이 화면설계서 하나로 커뮤니케이션을 하는데 있다. 
분명한것은 설계 이전에 제안이 있어야 한다. 
제안으로 각 담당자들의 의중과 담당자들이 원하는 건설팅을 해야 한다. 
모든 클라이언트는 이전과 다른, 경쟁업체와 다른 사이트 시스템을 원한다. 이런 충족이 없을때 그들은 설계서를 이해하지도 못할 뿐 아니라 믿음도 줄어들게 된다. 
적어도 중요한 시스템 기능에 대해서는 설계이전에 기획안을 PT 하고 그리고 화면흐름도와 같은 UML을 이용한 추가적인 설 계안으로 기본적인 초기설계를 완료해야 한다. 뒤에 화면설계서를 통해 클라이언트와 작업자들간의 커뮤니 케이션을 진행 하는것이다. 

기획자들이여 설계는 제안 이후에 진행하라.


Posted by 김상환

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

개인적으로 웹기획에 있어서 메뉴 구조를 정리하는데 가장 심혈을 기울이는 부분중에 하나이다. 그만큼 시간도 많이걸린다.

기존사용자에게는 기존의메뉴구조에 익숙해 있는 인식을 깨지 않도록해야하며 잠재고객들에게는 컨텐츠별로 의미전달이 쉽도록 그리고 시선을 흐틀어지지 않도록 해야한다.



다음의 사항들을 주의하여 진행한다면 조금 편한 메뉴구조를 만들 수 있다.

1. 컨텐츠 분석
모든 컨텐츠의 성격과 내용을 100% 이해해야한다.

2. 컨텐츠 마다 레이블링 붙이기
모든 컨텐츠에 사용자가 이해 하기 쉽도록 메뉴명을 붙인다. (내용을 메뉴명만으로도 이햐하기 쉽도록 붙여야 한다)

3. 레이블링의 완성도 높이기
매뉴명이 올바르게 되었는지 확인을 한다. 기존사이트로도 확인해야하며 경쟁사의 사이트 들도 비교 분석한다. 이때 비교분석할 레퍼런스를 많이 한다면 더 좋은 기준 값을 찾을 수 있다.

4. 각 레이블링된 컨텐츠에 그룹핑하기
의미전달하기 쉬운 레이블로 각 컨텐츠에 그룹을 잡는다. 한번에 다 진행하기는 어려우니 여러번 반복해서 진행하면 10개 내외로 메뉴명을 그룹으로 잡을 수 있다.

5. 그룹의 수를 줄여라.
사이트의 성격에 따라서 달라지나 보통 4~7개 정도의 메인 메뉴를 잡는것이 좋다. 그렇게 나올 수 있도록 그룹을 다시 그룹핑한다.

6. 메뉴를 나열하고 전체적로 수정한다.


Tip : 카드소팅 기법
컨 텐츠별 레이블링이 완료 되면 카드에 레이블링된 메뉴를 모두 적은뒤 5~10명 가량의 사용자(현사이트의 회원, 비회원, 성별 다양한 분류의 사용자)를 대상으로 카드를 정렬하는것 사용자에게 메뉴의 그룹핑을 물어 더 자연스러운 메뉴 구조를 만들 수 있다.


Posted by 김상환

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

기획자들이 가장 신경많이쓰는 문서가 화면설계서이다.
SI 업체에선 화면설계란 이름을 쓰고 웹에이전시에선 스토리보드(SB)란 이름을 많이쓴다.
두 문서의 차이를 많이 물어 보는데 개인적으로 화면설계서가 더 맞지 않나 싶다.
스토리보드는 광고쪽에서 넘어온 듯하여 화면설계서라는 문서를 개인적으로 사용했다.



화면설계서는 화면상의 기능과 디자인을 작업자와 현업들과 대화하는 문서이다.
설계서에서 가장 중요한부분은 discription이다.
기능에대한설명 그리고 기획의도, 요구사항 등을 문서에 남기고 작업자들과 문서 리뷰를하여 기획의 의도를 분명하게 전달해야 한다.

개인적으로 화면설계서에 이미지나 컬러톤을 넣지 않도록 권하고 싶다.
혹시라도 디자이너의 몫을 침범하는것 같아서이다.
그러나 개발자를 위해서는 많운 내용을 보여주는것이 좋다.

요구사항ID도 표시하여 감리에도 대비하여야한다.
요구사항의 이행에대한 표시를 해주어야 요구사항 추적표에 남길수 있다.
실제 감리에서 가장 많이 보는 문서가 요구사항 추적표이다.


Posted by 김상환

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

일정관리는 전체 진척율에대한 근거 자료가 됨으로 프로젝트의 보고 단계에서 가장 중요 하다고 할수 있다.

 

보통 MS-Project 를 많이 사용하며 스크립트를 이용한 목표대비 진척율과 실제 진척율로 나누어 문서화 할수 있다.

MS-Project 는 무료로 제공되는 뷰어가 있어 작성후 관련자들과 문서를 공유하는데 어려움이 없다.
뷰어 다운로드 : http://file.naver.com/pc/view.html?fnum=282171&cat=30


다음으로 많이 사용하는 프로그램으로는 MS-Office의 엑셀이 있다.

마찬가지로 진척율을 체크하기 위해 목표와 수행으로 나누어 진척율을 잡을 수 있다. 다양한 함수를 사용하여 문서의 자동화를 만들수 있으며 뷰어도 제공되어 문서 공유하는데 어려움이 없다.

뷰어 다운로드 : http://file.naver.com/pc/view.html?fnum=235304&cat=30

 


진척율을 체크하는데 중요한체크포인트는 다음과 같다.

 

1. 작업의 프로세스로 Task 를 만들라.

- 어느 누가 보아도 이해하기 쉬운 프로세스로 Task를 잡고 진행율에대한 체크를 한다.

 

2. 작업의 단위(Task)는 최소 단위로 해라.

- 작업자들은 자신의 작업에 대한 상세한 내역을 알 수 없다. 각 작업자들이 진행 될 수 있는 작업에 대한 리스트를 뽑고 그 작업에 대한 협의는 각 작업자들과 진행 해라 그리고 작업자들에게 예상되는 일정을 체크 해달라고 하면 자연스러운 작업 진행이 될 수 있다.  혹시 빠진 Task가 있다면 이후 일정에 추가 하면 된다. 너무 걱정 안해되 된다.

단위별로 나누기 힘들다면 전체 페이지(IA 정의서, 메뉴구조도)를 기준으로 진행하면 된다.

 

3. Task에 각 작업자에 대한 일정을 체크 하고 작업자별 검수와 Task별 검수를 진척도에 포함 시켜라.

- 작업자들이 놓치기 쉬운 부분이 완료 후의 단위 테스트다. 단위테스트는 각 작업자들의 몫이며 각 작업자들이 검수 하는것이 맞다. 완성도를 높이기 위해서는 각 단위별 테스트를 진행 하고 체크 하는것이 중요 하다. 또한 하나의 Task가 완료 되었을때 이에 대한 단위 검수를 진행하여 클라이언트를 작업에 포함 시켜라. (진척율이 올라가지 않는 이유가 클라이언트의 검수 때문임을 보고 한다면 클라이언트는 검수를 진행할 수밖에 없으며 단위 검수가 진행 되면 최종검수는 그대로 넘아가는것.

 

4. Task별 중요도를 체크 하라.

- 작업에 대한 중요도를 체크 하지 않으면 작업자의 리소스에 대한 체크(M/D)밖에 진행되지 않는다. 메인페이지와 서브페이지의 중요도가 다르듯이 각 작업들의 중요도를 체크 하고 중요 분류별 중요도도 체크 하는것이 좋다.

 

5. 주 1회 이상의 진척도를 체크 하라.

- 각 파트별 진척도를 PL에게 요구 하고 PL은 각 작업자들에게 체크 하도록 한다. 분명한것은 자주 하는것보다는 주 1회 또는 2회로 PL을 신임하는것도 중요하다.

 

6. 진척도에 대한 대응방안을 마련하라.

- 목표치를 못미쳤을때의 해결 방안을 마련 하고 그 대응방안은 미루면 안된다 빠른 조치를 취함으로써 도미노현상(하나의 파트의 작업이 완료되지 못할때 다른파트의 작업 진행이 안됨으로써 일어나는 리스크 현상)에 대한 대비를 해야 한다.

 

마지막으로..

일정관리는 무엇보다 작업자들의 목표대비 완료율을 체크 하는데도 중요하다.

이 프로젝트가 마지막이 아니니 각 인력에 대한 목표대비 완료율을 표시하는것이 리소스 관리하는데 필요한 부분이다.

다음 프로젝트에 리소스관리를 하는데 도움이 될것이다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

요즘 PM의 역할이 얼마나 중요한지를 세삼 깨닫는 이유 중에 하나가 업무의 역할 분담인듯 하다.

사람이 하는 일이다 보니 작업자들 간의 언쟁과 각팀간의 업무 진행상의 문제점도 생기게 마련이다.

이럴때 가장 중요한것은 각 업무 분장에 대한 작업 진행의 체크 이다.


초기 프로젝트 진행 시 각 작업자들의 배정을 받은 후 작업 진행에 대한 프로젝트관리대장이 필요 하다.


프로젝트 관리 대장에는 다음의 것들이 포함되면 좋은데.


1. 프로젝트 개요 (프로젝트 명, 목적, 간단한 컨셉, 기간, 주요사항... 등의 개요)

2. 수행내역서 (프로젝트의 범위 분석(RFP, 제안서, 기술협상, 착수보고(수행계획서), 요구사항정의서 등의 전체 프로젝트의 범위)

3. 작업자의 조직도 (TFT(Task Force Team)의 모든 작업자의 위치(PM, PL... )를 명확하게 표시)

4. 업무 분장 (상세하게 업무 단위별(Task)로 나누고 각 담당자의 역할 및 담당자의 이름을 명시)

5. 프로젝트 컨셉 정의서

6. 프로젝트 일정표

7. 리스크관리(위험관리)


간단하게 프로젝트 진행 시 필요한 내용들을 정리하여 하나의 문서로 가지고 있다면 이후 히스토리관리 및 프로젝트 완료 후 검수 진행 시에도 명확하게 검수를 받을 수 있을것이다.


이 중에  프로젝트 작업자들간의 업무의 분쟁을 줄일 수 있는 부분이 조직도 및 업무 분장이 되겠다.

업무 분장을 알려줌으로써 서열이 나눠지게 되고 각 작업자의 책임있는 진행이 이뤄지게 되는것이라 하겠다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

SLA(service level agreement) 적용

 

요즘 공공기관의 RFP에서 자주보는 단어가 SLA다.

언제부터인지 SLA로 사업의 성공여부를 따지는듯 하다.

SLA를 높게 잡으면 그만큼 사업의 범위가 커질 수밖에 없다.

가능한 SLA범위를 잡는것이 중요하며 이범위는 사업의 전체 성공여부까지 결정할 수 있다.

솔찍히 SLA가 있어 검수단계가 깔끔해지는 경우도 있다.

SLA보고만 지나면 검수는 당연한결과이기 때문이다.

다만 기준치에 못미쳤을때의 대비가 가장 중요하다.

일별, 주별, 월별 기준치 체크를 하여 못미쳤을때의 대비방안도 마련하여 SLA의 기준치를 넘어서야 한다.

 

(예시 : 월별 SLA보고를 통하여 전반적인 서비스의 진척도를 나타낼 수 있다)

예를 들면 유지보수의 프로젝트에서 회원가입수와 PV수를 가지고 체크 하는 SLA의 기준을 잡았다면 유지보수 기간에 SNS의 활용과 각종 이벤트를 이용한 대비 방안을 마련하여 꾸준한SNS 활용(트위터, 블로그, 페이스북..)을 진행 하고 회원가입을 유도하는 다양한 이벤트를 진행 하여 SLA의 수치를 맞출 수 있어야 하는것이다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

RFP(Request For Proposal)분석은 SWOT분석, 요구목록분석, 업무별분석(서비스별분석), 평가방식분석 후에 제안서를 작성해야 한다.



제안작업을 하다보면 기본을 지키지못하는경우가 있다.
제안서의 기본은 제안요청서에 있다.
제안요청서의 분석뒤에 제안서의 러프한 방향을 잡고 제안의 컨셉을 정한다.
뒤에 목차와 업무분장을 나눠 세부 장표를 도출한다.
뒤에 모든 장표를 확인하고 손을 봐야한다.
그리고 이 제안의 핵심을 클라이언트를 통해 습득하고 그에대한 장표가 돋보이도록 포장 그리고 추가제안을 하는것이다.
기본은 지켜야한다. 본전부터 시작해야 승산이 있다.
제안요청서를 분석하는 방법에는 다음의 방법이 있다.

  1. SWOT 분석
    기회의 요인과 위협의 요인을 장점과 약점으로 나누어 분석함으로써 제안요청서의 내용과 제안 수주의 확율을 확인할 수 있다.
  2. 요구목표 분석
    제안요청서에는 이번 사업의 목표가 있다. 이런 목표에 부합되는 제안서가 나와야 한다.
  3. 업무별 분석(서비스별 분석)
    업무(서비스)의 리스트를 나열하고 그에 대한 중요도를 체크 하여 제안서의 목차에 알아보기 쉽도록 작성 한다.
  4. 평가방식 분석
    보통 기술부분에 중점을 주어 평가를 하게 되는데 기술부분에도 이사업에서의 중요한 부분을 점수로 표시한다. 중요도에 따른 제안이 되어야 한다.

Posted by 김상환


Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

이전버튼 1 2 3 이전버튼