웹기획자는 무엇을 하는 사람이고 어떤 결과물을 내놓아야 할까요?

이번에는 웹개발자의 역할에 이어 웹기획자의 역할을 포스팅 합니다.


정확히 말해서 개발 세상에서 '웹기획자'라는 직분은 모호합니다.

고객의 요구사항과 개발에 대한 모든 것을 모든 개발자가 알고 개발을 하면 이상적이겠죠. 
하지만, 개발 도메인 자체가 너무 큰 이유로 이상대로 한다면 개발자들은 커뮤니케이션만 하다가 프로덕트는 나오지 않고 볼짱 다보고, 회사는 문을 닫겠죠.  국민들 모두가 직접 정치를 하는 것과 같습니다.

  그래서 시니어 개발자(경험/경력이 있는 선임 개발자)가 전략 및 요구사항 분석에 참여 하여 개발의 큰 틀을 짜는 역할을 합니다. 개발이 진행 되는 동안 이해 관계자들과 지속적인 커뮤니케이션을 통해 개발을 보정(수정)하고 개발 진행을 지휘하게 됩니다. 간과 하지 말아야 하는 것은 이 일을 하면 능력의 대부분을 커뮤니케이션 하는데 보내야 한다는 것입니다. 이런 역할을 소프트웨어 엔지니어링에서는 '소프트웨어 아키텍트'라고 하죠.

'웹기획자'의 대두
이 과정에서 '웹기획자'라는 역할이 대두 됩니다. 개발자는 기술적인 부분을 전문화 하도록 뇌가 프로그램 되어 있습니다. 개발 세상의 전략이 아닌 실세계의 전략을 세우는 사람이 필요해 지는 것입니다.
 
프로젝트의 목표를 달성 , 개발자가 개발 할 수 있도록 
1. 개발로 번역 가능한 언어로된 문서를 작성 할 줄 아는
2. 실세계의 전략을 세울 수 있는
3. 개발 이외의 세상과의 대화능력을 가지고 있는
4. 프로덕트를 부드럽게 완성시키는데 조율 능력을 가지고 있는.

 개발 이외의 전문적으로 그 일들을 할 수 있는 그런 역할이 필요하게 된겁니다. 
- 마틴 파울러의 [소트웍스 앤솔러지]에서 '반복관리자'라고 표현하고 있는 역할이 이와 비슷하다고 말할 수 있습니다.


이런 역할을 하는 사람을  개발 세상에서는 "웹 기획자"라는 명함을 박아 줬습니다.


또는, 대한민국에서 '소프트웨어 아키텍트'를 거세하고 '개발자(Developer)'만을 남겨두고 '소프트웨어 아키텍트'의 역할을 '웹 기획자'에게 주었습니다. 그럼 "소프트웨어 아키텍트" ≒ "웹 기획자"의 개발 역할이 무엇일까요.

물론, 소프트웨어 아키텍트가 존재하고 논리적인 전략 차원에서 기획자가 존재하는 회사가 존재할 수도 있습니다.

하지만, 개발자가 기획요소에 참여하는 것을 월권으로 여기고, 코딩 이외의 일(도메인 분석, 아키텍처, 소프트웨어 디자인)을 하는 것은 놀고 있다는 시각을 인정한다고 가정하고, 그럼 웹기획자 ≒ 소프트웨어 아키텍트 의 역할이 무었인가 입니다.

제대로 된 프로덕트가 나오기 위한 개발 TASK를 폭포수(waterfall)방식으로 살펴 본 후 웹기획자의 역할을 말하겠습니다.


개발 TASK 폭포수
1.프로덕트가 달성해야 하는 비지니스 목표와 전략을 도출 합니다.
2. 고객의 요구사항을 분석합니다. Requirements Analysis
3. Use Case를 도출 합니다.
4. 1~3을 만족 시키기 위한 IA를 설계합니다.(인포메이션 아키텍처, UI, UX)
5. 1~4를 만족시키기 위한  플렛폼, 언어를 선택합니다. 또는 1~4의 과정 동안 잠재적인 플렛폼과 언어는 선택되어 있습니다.
6. 오브젝트 모델링, 데이터 모델링을 합니다.
7. Use Case를 구현 합니다.
8. 프로덕트를 릴리즈 합니다.
9. 1~8을 반복합니다.



웹 기획자 ≒ 소프트웨어 아키텍트 역할에게는 어떤 산출물을 기대하나
1~4 까지의 산출물을 내놓아야 합니다.
1. 프로덕트가 달성 해야 할 비지니스 목표와 전략, 컨셉 문서
2. 요구사항 명세서 ( Software Requirements Specification, SRS) : SRS 위키
     1) 고객 요구사항
     2) 기능 요구사항
     3) 비기능 요구사항
     4) 성능 요구사항
     5) 디자인 요구사항
     6) 파생 요구사항
     7) 배치 또는 구성 요구사항

3. Use Case 명세서
시스템에서 '누가' '무엇'을 할 수 있는지 , 행위, 룰, 결과물을 기술 하는 것 입니다.

1) Use Case 이름
2) 버전
3) 목적
4) 요약
5) 행위자 (사람, 시스템 또는 디바이스)
6)  이해 관계 계층 - 요구 사항  끼리의 연관 계층
7) 트리거
8) Basic course of Event - 최소한 하나의 주 시나리오
9)  대안 패쓰
10) Postcondition : Use Case가 달성 해야 할 출력
11) 비지니스 룰 : Use Case가 준수 해야 하는 비지니스 규칙, 도메인 내에서 Use Case끼리 상충 되지 않도록 해야 함.
12) Notes
13) 작성자 , 작성일

4. 화면 설계서
사용자가 1~3을 달성 할 수 있도록 통로를 제공하거나 네비게이션 패스, 정보의 구성을 담은 화면 설계서를 의미 합니다. 디자이너는 이 설계서를 기반으로 그래픽 디자인을 수행하고, 개발자는 Use Case 프리젠테이션 레이어를 구성합니다.

실무 개발자는 위의 1~4를 가지고 데이터 모델링을 하고, 프리젠테이션을 구성하고, 유즈케이스에 기술된 기능을 구현합니다. 이 과정이 진행 됨에 따라서 눈에 볼수 있는 프로덕트가 나온게 되는 것이죠.
이제 부터는 개발자가 웹사이트 개발하기 과정: 웹 개발자가 하는 일을 밟아 갑니다.



자! 현실로 돌아와 봅시다.



개발자가 전달 받는 산출물은 어떻습니까?  "1~3이 약간씩 첨가된 [산출물 맛] 4번의 스토리 보드" 입니다.

기획자는 "자 스토리 보드 건넸으니 일정을 주시죠"라고 말을 하죠. 개발자는 "이 기능은 어떻고, 저 기능은 결과가 어떻습니까?" 등등의 수천가지 확인 해야 하는 일이 남아 있습니다.

도저히 뭘 만들고자 기획 했는지 모를 문서를 받아 드는 경우가 많습니다. "좀 더 세부 정의를 해 주세요" 라는 개발자에 요구에, 기획자는 "여기에 그림 다 그려 놨는데 뭘 더 달라는 겁니까?", "뭘 더 줘야 하는지 설명해 보세요!", 개발자는 설명을 위한 설명을 시작합니다.



자! 제가 모든 기획자와 개발자들을 위해 "뭐가" 필요한지 말해 드립니다.

"바로 1~4를 말하는 겁니다. 1~4", 그리고 "부드러운 조율"

위의 과정을 열심히 해도 "소프트웨어 위기 Software Crisis"라는 것이 옵니다. 부정확한 요구사항 분석, 빈번한 요구사항 변경, 구현 실패 등. 위에 언급한 것들이 프로젝트 성공의 "필요조건" 이라는 것이죠. 절대 "충분조건" 이 아닙니다.


싫다 좋다 말씀 마시고, "바로 1~4를 말하는 겁니다. 1~4", 그리고 "부드러운 조율" 입니다.




추신:

"네가 언급한 것 들은 개발자들인 해야 할 일 아니야?" 라고 말씀 하시는 분들도 있으실 겁니다. 개발팀은 코딩 이외에도 위에 언급한 1~4의 작업을 개발을 위해서 , 유지보수를 위해서, 작성합니다. '개발 관점'이라는 것으로 작성됩니다. 귀사에 '소프트웨어 아키텍트'라는 TO가 있습니까?, '소프트웨어 디자이너'라는 TO가 있습니까? 개발팀이 모든 것을 다 해야 한다면, 그럼 님께서 생각하시는 기획자는 뭘 하는 사람인거죠? 


"어느 사이트에 있는 그 기능을 넣어 주세요!"는 고객의 사전에 있는 용어이지, 기획자에게 허락된 용어가 아닙니다.