기획자들이 DFD(Data Flow Diagram) 또는 ERD를 그려주나요?

웹사이트 개발이나 SI나 정보시스템 개발을 위해서는 데이터베이스의 개념을 빠뜨릴 수 없죠. 10여년 전에 WWW 서비스를 구축할 때는 DB에 대한 개념없이 HTML 페이지 개념으로만 서비스를 만들었기에 서비스의 Flow와 사용자가 보는 Front 페이지의 프로세스에 대해서만 신경썼을 뿐입니다.

하지만, 지금 WWW 서비스는 데이터베이스 없이는 생각할 수 없습니다. 사용자의 회원정보와 서비스에서의 활동 내역은 데이터베이스에 저장되어 관리됩니다. 그렇다보니 WWW 서비스 기획에도 데이터베이스를 고려한 시스템 디자인과 설계가 필수적이죠. 그렇다면, 서비스 전략을 수립하고 기획을 하는 기획자들은 스토리보드를 그리면서 데이터베이스에 대한 개념적인 디자인 or Context에 대한 다이어그램을 그리고 있을까요?


뭐 굳이 그리지 않는다면 과연 DFD나 ERD, UML에 대한 인식은 제대로 하고 있나요? 사실 SI나 소프트웨어 개발을 전문적으로 하는 정보시스템 기업이나 IT 관련 컨설팅사라면 기획자(컨설턴트)들이 시스템 디자인과 설계에 대한 지식은 물론 직접 작성도 하리라 생각됩니다. 그렇다면 WWW 서비스를 운영하는 서비스 업체들은 어떨까요?

제가 아는 상식과 주변의 들은 풍월로 보건데 기획자들이 DFD를 그리고 ERD를 읽을 수 있는 경우는 거의 없습니다. 대개 파워포인트로 스토리보드를 그리며 사용자들이 어떤 페이지를 봐야 하는지 WWW 페이지의 레이아웃과 프로세스를 정리하고, 기능 정의를 하는 수준입니다. 이렇게 작성된 내용을 보고 개발자들이 시스템 디자인을 하게 되죠.

이렇다보니 문제가 종종 발생합니다. 시스템을 설계하기 어렵거나 논리적으로 맞지 않은 스토리보드가 나오곤 합니다. 그러니, 스토리보드를 그린 후에 바로 개발에 착수할 수 있는 것이 아니라 핑퐁 게임처럼 기획자와 개발자가 왔다갔다하며 개발할 수 없다느니, 기간이 오래 걸린다느니, 기획이 말이 안된다느니 하는 불필요한 시간 낭비가 발생합니다.

더 큰 문제는 웹 서비스라는 것은 유기체처럼 사용자들의 반응을 봐가며 성장해가는데, 처음에 잘못 설계된 데이터베이스 구조로 인해 확장이 어려운 경우에 처하곤 합니다. 처음 스토리보드만으로 보면 완전히 구현되었는데, 나중에 새로운 페이지나 기능을 추가하려면 데이터베이스 자체를 완전히 다시 뒤집어 엎어야 하기 때문에 서비스의 개편이 서비스를 새로 만드는 것이나 다를바 없을만큼 많은 시간이 걸리게 되는 것이죠.

이런 문제를 해결하는 가장 좋은 방법은 기획자들이 시스템 분석과 설계에 대한 기본적인 지식을 함양하는 것입니다. 비록 DFD와 ERD를 그리진 못하더라도 문서를 이해할 수는 있어야 합니다. 데이터베이스에 대한 개념을 바탕으로 비즈니스 혹은 서비스를 정보시스템의 기본이 되는 DATA의 흐름으로 설명할 수 있어야 합니다. 서비스가 주는 가치와 사용자 편의성만을 고려할 것이 아니라 개발자들이 고민하는 시스템 설계와 개발 구현의 프로세스를 이해하려고 해야 합니다.

그래야만 프로젝트의 퀄리티는 물론 불필요한 시간과 리소스를 줄일 수 있습니다. 물론 웹 서비스 기획자들은 일반 IT 컨설턴트나 SI의 마케터들과는 달리 B2B가 아닌 B2C 대상으로 일반 사용자를 고객으로 모시고 서비스를 지속적으로 운영하는 업무를 하고 있고 업무 역할이 설계보다는 제안쪽에 가깝기 때문에 전문적인 스킬을 습득할 필요는 없습니다.

하지만, 계속 스토리보드만 그리고 있다가는 한국의 웹서비스 기획자들이 설 자리는 점점 잃어갈 것입니다. 대박 서비스, 효자 비즈니스에 대해 시스템적으로 표현할 수 있는 표현력(개발자들과 대화할 수 있는 언어의 습득)이 요구됩니다.

혹, 이 글을 읽는 당신은 기획자이신가요? 개발자이신가요? 웹 서비스 기획자는 시스템 개발에 대해 어느 정도까지의 상식이 필요할까요? 최소한 DFD는 그려야 한다고 보시나요?
스마트플레이스의 글을 편리하게 구독하세요. 한RSS 추가 구글추가
크리에이티브 커먼즈 라이센스
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

트랙백 (2) | 덧글 (25)
트랙백 주소: http://www.smartplace.kr/trackback_post_230.aspx
스마트플레이스의 트랙백은 스팸방지를 위해 관리자 승인 후 등록됩니다.
개발자와 기획자의 경계란?
웹서비스개발에서 보통 팀을 구성할때 다음과 같은 형태로 나누고 있습니다. 프로젝트 매니저, 기획자, 개발자, 디자이너 프로젝트 규모에 따라 기획자가 프로젝트 매니저가 되기도 할때도 있고 별도로 구성하게 될때도 있습니다. 하지만, 그 경계와 책임이란게 사실 딱 구분되면 좋겠지만 그렇지 못할 상황이 많습니다. 물론 그래픽 디자이너와 같은 완전히 별도로 작업과 ...
yuna - rainbow weblog 2008-12-11 16:37:52
서비스 기획자는 뭘 하는 사람인가
얼마 전 우연히 이 글을 읽었다. 요지는 '기획자도 ERD를 읽을 수 있을 정도로 데이터 흐름에 대해 잘 알고 개발자와 커뮤니케이션할 수 있어야 한다'는 것이었던가. 우리나라에서는 '기획자'라는 사람에게 너무 많은 역할을 기대하는 것이 사실이지만 난 그게 좋다. 기획자가 정보를 설계한다는 것 자체가 사이트를 사용하는 사람들의 행동의 흐름과 그에 따르는 데이...

promise4u 2007-10-01 10:57:18     답글 삭제
개발자 출신 기획자지만 DFD나 ERD를 그리면서 기획서를 만들어주고 있지는 못하는 것 같네요..

개발을 하면서 생기는 이슈들을 과거의 경험을 통해 그때그때 실시간으로 피드백 해주고 알려주고 이렇게 진행하고 있지만 뭔가 주먹구구식으로 진행하는 것 같아서 비효율적이라고 느끼고 있습니다.

이 글을 읽고 참고할 수 있는 책이 있나 했더니 DFD나 ERD로는 책이 검색이 안되네요, 혹시 좋은 문서나 책을 추천받을 수 있을까요?
oojoo 2007-10-01 20:12:46     삭제
네, 사실 모든 Industry에 DFD, ERD, UML 등이 필요할 것 같지는 않습니다. 회사 규모에 따라서도 다르고, 또한 기획-개발 프로세스에 따라 다르구요. 하지만, 아무튼 기획자나 개발자간에 업무 협력 시에 이러한 DB 디자인이나 비즈니스 프로세스에 대한 논의가 있어서 나쁠 것은 전혀 없을 것입니다. DFD 등에 대한 서적은.. 저는 해외 저널에 실린 논문 등을 추천드립니다. 국내 서적으로는 마땅한 것들이 눈에 띄지 않더라구요. 구글에서 검색해보시면 저널에 실린 논문을 쉽게 검색하실 수 있습니다. (예> dfd data design diagram filtype:pdf)

스피닉스 2007-10-01 11:30:22     답글 삭제
항상 느끼는 거지만 기획자와 개발자 사이의 관계는 서로 다른 사람이 하는 일에대해 이해하려고 얼마나 노력하느냐에 달려있는것 같습니다. 서로 모르는 부분에 대해 자주 이야기하고 토론해서 좀 더 좋은 방향으로 나아가는것... 너무 이상적인 이야기인가요?
oojoo 2007-10-01 20:15:00     삭제
사람은 이상을 실현하기 위해 노력하고 그것이 기술과 문명의 발전을 야기하는 것 아닐까요? ^^ 말씀하신 것처럼 DFD 같은 그런 정형화된 포맷으로 얘기하는 것보다는 한 번이라도 더 커뮤니케이션하면서 상대를 이해하려고 노력하는 자세가 더 요구된다고 봅니다. 사실 현업에서는 DFD같은 것을 잘 그리는 사람보다는 커뮤니케이션 능력이 탁월한 사람이 더 필요하죠. 물론 커뮤니케이션을 잘한다면 비즈니스 프로세스를 디자인할 수 있는 능력을 갖춘다면 너무 욕심이 큰 걸까요? ^^

골룸 2007-10-01 13:33:57     답글 삭제
제가 생각하기론 기획자들의 설자리가 없어지는 것이 DFD나 ERD를 작성하여 웹개발과정에 한단계 더 깊숙이 관여하지 않기 때문이 아니라, 점점 기획과정이 불필요해지는 환경 때문이 아닐까 생각합니다. 컨셉만 나오면 모듈별로 잘해놓은 사이트들의 요소요소를 벤치마킹하고 기본적인 부분들은 라이브러리화되어 있어 불러쓰기만 하면 되기 때문에 굳이 파워포인트를 그릴 이유가 없는 경우가 많습니다. 게다가 요즘 사이트들은 메가급으로 기획하기보다 프로토타입으로 만들어놓고 피드백을 통해 살을 붙여나가는 케이스가 많기도 하구요. (DFD나 ERD에 대해서는, 유능한 기획자라면 반드시 그려야한다고 생각지는 않습니다. DB 구조를 파악하고 이런 기능이 가능한지 가능하지 못한지 알면 되지 않을까 싶습니다. ERD를 읽을줄만 알아도 괜찮습니다. ERWIN 사용법을 익히기가 그리 쉽지 않고 가르쳐주는 곳도 찾기 힘든것이 현실입니다.)
oojoo 2007-10-01 20:19:30     삭제
기획자들의 설자리가 없어지는 것은 개발 환경이 더욱 쉬워지고, 애자일 방법론처럼 빠르게 사용자들의 요구 사항을 파악하며 진행되는 OPEN된 개발 방법론이 대세가 되어가기 때문일 것입니다. 또한 말씀하신 것처럼 개발 모듈들이 오브젝트화되면서 쉽게 가져다 사용할 수 있게 되었기 때문이기도 하구요. 그렇다면 이 와중에 기획자는 아예 필요없을까요? 아무리 개발이 중요하다지만 이렇게 개발되어 나온 산출물은 Product로서 시장에서 비즈니스에 실질적 도움이 되어야 합니다. 즉, Product를 매니지먼트하고 BM을 만들어가는 그런 전략적 기획자가 필요합니다. 물론 그 역할을 개발자가 해도 되구요. 만일 비즈니스에 대한 통찰력이 높은 기획자들이 상기와 같은 비즈니스 프로세스와 DB Design에 대해 알고 있다면 금상첨화이겠죠. 이러한 부분을 기획자들이 찾아 나선다면 설 자리가 있을 것이라고 생각합니다.

해피씨커 2007-10-01 14:07:04     답글 삭제
SI에서 포탈로 옮기면서, 아쉬웠던 부분. 물론 SI에서 형식적으로 하는 경우도 많이 있지만, 양쪽다 의지를 가지고 하면 당장은 수면 위로 들어나지 않은 잠재적 문제를 많이 제어할 수 있었습니다.
oojoo 2007-10-01 20:20:38     삭제
120% 공감합니다. 제가 드리고 싶은 말씀도 바로 그것입니다. 기획자가 비즈니스적, 서비스적 관점에서 DATA 설계와 Data Flow를 이해한다면 수면 아래에 숨겨진 문제점들을 개발자와 빠르게 해결하고 그런 문제가 수면 위로 올라오지 않게 할 수 있죠.

Meryl 2007-10-01 18:50:24     답글 삭제
제가 알기에는, DFD와 ERD, 그리고 UML 을 가르치는 곳이 거의 공대계열의 전산이나 MIS 전공자들뿐인거 같더군요.
(저는 운영부터 시작한 기획자 출신이구요,경영학 비전공자였다가 공부를 좀더 했습니다) 친구놈이 유능한 개발자한테 UML을 공부하다 물었더니 그친구는 아예 모르더군요, S대 출신 닷넷 개발자인데.
그때 느낀 결론은 다 자기하기 나름이라고 생각됩니다. UML을 배운 개발자 놈도 그걸 왜하냐고.. 되물은 놈도 있었어요 ;;;
제 주변의 아는 사람들 중에도 개발자 출신을 포함해서 UML이나 DFD를 할 줄 알거나 이해하는 사람은 닷컴쪽엔 매우 드물고, SI에서 PMP를 갖고 있는 분에게서 이야기를 전수받을 수 있었거든요.
무척 필요한 부분이라고 생각하고, 배워본 저로써는 좋다고 인정은 하나 시대가 그것을 배워서 써먹을 필드가 많이 좁아진것이 맞는거 같습니다.
개인적으로 그래서 전 제가 런칭하는 프로젝트에는 기획이면서도 서비스 프로세스와 기능정의, 데이터 자료 타입, 인터페이스 각각을 을 다 정의하곤 합니다. 좀더 디자인과 개발의 갭을 줄여서 의사소통을 할 수 있게 워크샵도 하고, 정기 회의도 하구요. 여튼 고감되는 부분이지만 요즘 인스턴트화된 PPT 전문 기획자들에겐 요원하군요. 가르치는 곳이 어디 있나요? 모듬으로 할만한 책도 드물구요. 그게 현실이죠.
oojoo 2007-10-01 20:24:05     삭제
의견 감사합니다. SI가 아닌 WWW 사이트 운영 업체는 말씀하신 것처럼 DFD 등에 대해 모르는 기획자가 허다하죠. 비록 안다고 하더라도 함께 일하는 상대가 모르면 무용지물인 것이구요. 하지만, 이러한 프레임웍을 알게 되면... 논리적인 사고를 할 수 있게 됩니다. 즉, 서비스를 기획하고 비즈니스를 바라볼 때에 DB 중심의 사고, 논리적 사고를 하게 됨으로써 비즈니스의 문제점을 진단하고 체계적인 프로세스를 마련하는데 큰 도움이 됩니다.

miriya 2007-10-01 20:39:54     답글 삭제
비밀 댓글이 등록되었습니다.
우주 2007-10-01 21:00:42     삭제
^^ 감사합니다. LINK 오류 정정했습니다~

5throck 2007-10-02 08:25:23     답글 삭제
말씀하신 내용에 일견 수긍을 하면서도 완전하게 동의를 하기는 좀 어려울 것 같습니다. 물론, 기획자가 기술적인 부분에 대한 내용을 잘 알면 많은 도움이 될 수 있지만, 반대로 기획에서 가장 중요한 Creativity에 대한 많은 제약을 받을 수 있다고 생각합니다. 디자인과 기술 모두 중요한 부분이긴 하겠지만, 앞으로 사회에서 요구되는 트랜드를 볼 때 기획자가 기술적인 측면을 더 고려하기보다는 창조력에 많은 노력을 기울여야 하는 것이 아닌가 하는 의문을 던져봅니다.
oojoo 2007-10-02 23:23:13     삭제
창의력이야 기획자 뿐만 아니라 개발자, 마케터, 영업가.. 모든 직종의 사람에게 필수적으로 요구되는 기초적인 역량인 것이죠. 기술적 Skill과 창의력은 충분히 병행할 수 있다고 생각하고, 기획자라면 기본적으로 창의력과 Detail, 서비스 마인드가 있어야 하고 여기에 추가적으로 HW와 SW(프로그래밍)를 이해하는 혜안이 필요합니다. 물론 개발자만큼의 기술을 알 필요는 전혀 없죠~
oo 2007-11-22 07:52:37     삭제
oojoo님!
시스템을 설계하기 어렵거나 논리적으로 맞지 않은 스토리보드..
일반 유저는 이렇게 깊이 생각하지 않습니다. 본인이 원하는, 그리고 바라는 구조를 원할 뿐이죠.
그 시각을 기획자는 맞추고 따라가며 때론 앞서야 합니다.
설계하기 어렵다..참 많이 하는 말이죠? 그러면 개발자는 뭐하는 사람입니까? 개발 아닙니까?
논리적으로 맞게? 이 또한 개발 아닙니까? 코더와 개발자의 차이는 뭡니까?
개발자가 무슨 마법사냐 하시려면 기획자는 그럼 슈퍼맨입니까?
불필요한 시간 낭비 발생? 서비스와 전략을 이해하기 위한 정말 중요한 커뮤니케이션 과정 아닌가요?
창의력을 기초적인 역량이라고 표현하시니 놀랍습니다. 기본이지 기초는 아니지 않나요? 님이 말하시는 혜안은 기획자에게만 요구되는 것이 아니라 개발자와 디자이너에게도 기획이라는 범위안에 들어가는 지식과 식견을 갖춰야 하고 이는 곧 기획자, 개발자, 디자이너라는 영역이 없이 어느 포지션에 투입되도 처리할 수 있는 인력이 되라는 결론이겠죠. 개발자의 '개발'이라는 말에 당당할 수 있는 개발자와 유행만 쫓는 것이 아닌 순수 신디자인을 내놓는 디자이너가 몇%나 될까 합니다. 곧 무너져도 당장 눈에 보이는 결과물이 있다는 것만으로 당당하고 언성높이는 분들..쯧
5throck님의 의견에 동의하면서 추가적으로 몇백억대 총알과 국내 내놓으라는 개발자들이 다 모였다는 프로젝트에서 개발자들이 설레발치는 부분을 2년차 접어드는 개발의 '개'자도 모르는 기획자가 풉디다. 일반적인 유저로서의 시각으로.. 또 다른 프로젝트의 PM이었던 오랜 개발자가 그럽디다. 다수의 경험으로 느낀건데 개발을 아는 기획자일수록 기획이 갖히더라고..본인 경험 추가로 15년차부터 2년차까지 여러 개발언어의 개발자들과의 회의에서 정말 단순한 구조인데 본인들 틀에 갖혀서 그 이상을 생각못하는 것을 보고 놀랬답니다. 기획자의 최종은 CEO죠. 비즈니스범위까지 보려면. 그리고 높은 역량을 바랄수록 그에 걸맞는 대우도 따라야죠. 이 시장은 눈만 높아..쯧
마지막으로 기획자=PM은 아니라고 봅니다. 진정한 PM이 얼마나 될꼬..

실버리버 2007-10-02 11:43:47     답글 삭제
웹쪽으로 옮기고 놀란게...일단 '웹기획'이라는 직업이 웹에이젼시에 존재한다는 것 자체가 놀랍습니다.
자체 서비스를 하는 회사라면 '웹 기획'이라는 직무의 존재를 그런데로 받아들일 수 있겠는데 아웃소싱 업무를 수행하는 웹에이젼시에 왜 '웹기획'이라는 직업이 버젓이 존재하는지 잘 이해가 안되더군요. 대체 기획을 아웃소싱하면서 어떻게 좋은 서비스가 나오길 바라는지 알 수가 없습니다.
굳이 하는 일을 보면 웹기획자는 Biz Dev.와 개발자의 중간정도의 위치인것 같기도 한데요. 독자적인 직업군을 형성하기엔 좀 기형적이고 어중간한 직무라 생각되네요. 어떨땐 슈퍼맨을 필요로 하는게 아닌가...라는 생각이 들때도 있네요 ^^
oojoo 2007-10-02 23:26:59     삭제
적절한 지적입니다. 그래서 결국... 기획자의 설자리, 아니 정확히 표현하면 기획이라는 직군 자체가 무의미해질 듯 합니다. WWW 서비스에서 필요한 것은 개발자, 영업자, 마케터 그리고 서비스를 운영하는 사람들과 PM(전략과 개발의 중간자적 역할을 할 수 있는 Product Manager)이 아닐까 싶습니다. 웹기획자의 역할이 정말 갈수록 애매해지고 있으니, 이를 극복하기 위해서 기획자들의 새로운 포지셔닝이 필요합니다. 그를 위해서 비즈니스 프로세스를 논리적, 디지털 코드로 이해하기 위한 프레임웍에 대한 이해가 필요한 것이죠~

학생 2007-10-03 00:37:01     답글 삭제
솔직히 너무 주먹구구식으로 한다는 느낌을 가지고 일했던 기억이
나네요. 무엇보다 이해를 하고 못하고의 문제가 아니라 애초에 너무 관심자체가 없다는 생각을 합니다. 구체적인 물건이 아니라서 일까요. 너무 쉽게 생각하는 것 같습니다. 사람이 일하는게 딱 나뉘어져 있는게 아닌데 이건 우리 관심이 아니다하고 선부터 긋고 하는 것은 웹서비스 뿐만아니라 어느 분야에서건 아니라고 생각하는데..
oojoo 2007-10-03 13:23:43     삭제
경영학에서 최고의 팀을 꼽을 때, Cross Functional Team을 언급하곤 합니다. 기업이 최고의 인재로 손꼽는 인재상 역시 T자형 인재죠. Specailist하면서 Genral한 인재. 그런 면에서 기획자에게 기술적인 백그라운드는 중요한 재능의 하나임에 틀림없습니다.

김민수 2007-10-03 16:31:27     답글 삭제
저는 우리나라에서 개발과 기획을 나누는 자체가 사실 문제라고 생각하는 쪽입니다.

기획자는 사실 마케팅적인 문제에 대한 지원만 해주면 되고 나머지는 개발자가 그냥 다 하는쪽이 문제가 덜 발생한다 생각합니다.

자세한 내용은 제 트랙백을.. ㅋㅋㅋ
oojoo 2007-10-04 10:28:31     삭제
저 역시 웹 서비스에 있어서는 기획과 개발의 경계가 모호해지고 있다고 생각합니다. 저는.. 전략 / 기획-개발 / 마케팅 / 운영 이렇게 나누어야 한다고 봅니다. 이중 기획자의 포지셔닝은 상기 4가지 어디에나 있을 수 있지만, 위 4가지 포지셔닝에 맞는 SKILL과 지식을 연마해야겠죠.

나씨 2007-10-11 11:33:23     답글 삭제
그리고 있어요.
dbdesigner 4 / java로 된 freeware

kaleidoscope 2007-10-15 21:56:21     답글 삭제
글 잘 읽었습니다. 공부를 해야겠다는 생각이 들면서 참 막막하기도 합니다. 예전에는 무조건 개발 책을 들여다보기도 했었는데... 몇 줄 읽지도 않고 덮었던 적도 있습니다. 댓글들을 보면서 드는 생각이 있습니다. '기획자'가 무슨일을 하는가?? 의 기준이 나름 모두들 다르다고 생각합니다. 그렇기에 기획자의 포지셔닝이 불분명하고 점차 설 자리를 잃어가게 될 것이라는 이야기도 나오구요... 기획자가 무슨일을 해야하는가? 참.. 어려운 문제라고 생각합니다. 넓게 보면 만능까지 그 범위가 확장되기도 하고 좁게 보면 단순 문서 작업자까지로 그 범위가 좁아진다고 생각합니다. 현실에서는 회사마다 그 기획자의 업무가 바뀌는 듯합니다. 서비스 기획부터 문서작업까지, 어떤 곳은 PM 역할까지 하구요.. 전 개인적으로는 기획자는 반드시 필요한 사람이라고 생각합니다. 문제는 그 기획자가 얼마나 확장성을 가지고 있느냐-그 회사가 원하는 역할을 할 수 있느냐?(지금 당장은 아니더라도 그 기획자는 발전가능성이 있느냐?의 개념도 포함될수도 있죠)-가 될 것이며, 기획자에게 시대가 요구하는 덕목이 될 수 있겠다는 생각이 듭니다.
이렇게 말하면서 공부를 게을리하기는 하지만.. 항상 공부하는 기획자가 되도록 노력해야겠다는 결심을 다시 하게 되는군요.

2007-12-12 15:24:09     답글 삭제
과연 그걸 그려주면 그대로 하는 개발자가 몇이나 있을까요? 그리고 웹에이젼시든, 운영을 하는 업체든 웹기획자의 현위치에서 가능할까요? nice to know! 라는 말이 떠오릅니다.. 알면 조은~ 하지만 몰라도 무방한.. 그 시간에 매출을 더 올릴 방안을 찾고는 것이 더 현실적이라고 생각합니다. 개발자가 그려오면 논리적으로 수정하는 정도.. 기획자는 마케팅그림을 더 그리는 것이 맞다고 생각합니다

너블너블 2011-12-06 09:23:48     답글 삭제
각자의 전문성을 버리고 상대를 이해하기 위해 상대의 스킬영역까지 알아야 한다는 본글에 반대 합니다.

예전에 웹의 태동기에 본문의 예를 벗어난 웹마스터란 개념이 있었습니다 디자이너의 개념까지 포함한 웹 전문가였죠.
그로 인해 웹은 아무나 인력투입되면 다 개발도 되고 디자인도 되는
인식의 패러다임 속에서 이제야 약간씩 전문성을 자리 잡고 있습니다.

지금은 어떻습니까?
프로그래밍에서 코더-개발자-아키텍쳐
디자인에서 코더-디자이너-UI컨설턴트
기획에서 스토리보드를 그리는 웹기획자-사업관리자
또 접근성 관련 퍼블리셔

누가 앞으로 ERD를 깔끔하게 그리는 스킬을 가져가야 할까요?
컨설팅쪽으로 가야하는 기획자보다는 현직 개발코더나 개발자가
당연히 해야 하는 영역이죠.

각자의 영역의 전문성이 세분화 될수록 그 분야가 발달하는겁니다.

서비스 기획자는 고객의 니즈를 정확히 판단해서 전달하고 개발진의 의견을 전달하면 되지, ERD요? 그걸 왜 기획자가 그립니까?
그대로 개발하면 개발자의 위치가 흔들리는겁니다.

개발자 출신 기획자, 사업관리자로써 한말씀 올립니다.
ERD 그리는것 어렵지 않습니다.

개발자로써 인정받으려면 기획자의 의도를 정확히 설계할 줄 알고,
이에 대해 현업에서 벌어지는 리스크 및 불합리성을 정확히 전달해서
각자 일을 해야지,

기획자가 ERD도 모르면서 기획을 하기 때문에 문제다. 라는
생각은 편협한 생각이라고 밖에 생각이 안드는군요.

이름 비밀번호
홈페이지
덧글
비밀글
RSS 피드
전체글한RSS 추가 구글추가
스마트가젯북스타일
Demo Day