요점은 '기획서를 중복, 누락없이 쓰자.'인것 같네요.

중복없이 누락없이 구체적으로~

다른 사람의 눈으로 볼 때에 누락이나 중복을 금방 찾아내는 경우가 많다.

이 부분이 마음에 와닻는것 같습니다.

게임 기획뿐만 아니라 다른 모든 일의 기획에도 MECE 하게 기획하면 좋을것 같네요.

(게임 기획 연습도 되겠죠)

이 게시판의 글들이 ME,CE 했으면 한다는 학규님의 메시지인 것 같기도 해요 ^^;

어려운 말 같지만...
무자게 가슴이 뜨끔한 이야기....
기획서를 자세히 쓰려고 하면 마구자비하게 중복되고
중복을 안하게 하면... 왠지 허전한 느낌...
그래서 파트가 다른 부분에는 중복을 많이 사용하고 있지요.
인터페이스 부분에 나온 상세 설명이...
세부기능 기획서에도 나온다는 말씀 ...
어차피 파트가 다른 곳에서 사용하기 때문에...
여태 이렇게 작업했는데요.
안그러면 이곳에서 이것 빠져서 물어보고.
다른 곳에서 저것 빠져서 물어보고.
그럼 사람이 몸이 2개라도 모자라는 경우가 생겨요.
저는 말에는 동의하지만 파트가 다르면...중복은 불가피 하다고 느낍니다.

일딴 닥치는데로
책부터 (그냥 소설책 ;) 읽어서
문장력이나 길러야지 ㅇㅈㅇ!
문장력이 제일 중요한거 같기에

MECE의 압박으로 글을 못올린지 꽤 되었네요.[별로 나쁜뜻은 아닙니다;]
최근 좋은 아이디어도 안떠오르고... 유연한 사고방식과 독창력의 원동력은 어디서 오는걸가요....

한마디로 '체계적' 으로 서술하자 그것이군요.

MECE하게 ~ 문제의 근원을 명백하게 해결해나가기 위한 맥킨지식 대표적 사고방식중 하나군요. 개인적으론 why? so what?!이 하루에선 더 채용되는 부분이 많은데 ^^ 위키에서 김학규님이 추천해주신 MECE를 체화하기 위한 '로지컬 씽킹'을 읽고도 여전히 갈증이 있으신 분께는 『세상을 매혹하는 기술』-컨셉(기획출판 : HR연구소 지음)을 후속타로 권해드립니다. '로지컬 씽킹'이 본질 탐구에 대한 스킬의 길을 잡는 방법을 제시한다면 이 책은 새로운 가치를 창출해내는 스킬에 대한 이야기를 풀어나가고 있습니다. 오늘도 행복하세요~

몇 년전부터 멕킨지의 사고 방식에 관련한 책들이 여럿 나온것 같습니다.
막상 실행하기 위해서는 참 많은 노력이 필요한것 같더군요... ^^

그라나도 에스파다 홈피를 통해서 이곳에 왔는데,
생각보다 재미있는 글이 많아서 종종 오게 될것 같군요 ^^

로지컬 씽킹이란 책을 읽어봤는데, 어렵더군요. 내용의 이해가 아니라 내용의 실천은 상당히 어렵웠습니다. 제가 부족하기 때문이겠죠.

MECE 좀복잡하고 귀찮은게 아니던데...

MECE 하게 기획안을 내는것이 정말 중요 하죠.

음... TFT안 문서에도 MECE하게 서술해야 할까요?

PPT문서로는 그렇게 할수 있지만 중복 되는 것도 있어야 강조 되는 경우도 종종 있는데


기획안에만 해당 하는 글인가...

공감하는 글입니다만, 솔직히 원론적인 내용이라는 생각이 듭니다. 이런내용은 누구나 다 한두번쯤은 들어봤을법한 얘기이고
또한 대학생활을 해보신분들은 더더욱... 그러나, 이는 알고있다고, 들어보았다고 되는 얘기가 아니라, 관련된 일을 할때 항상
머리속에 염두해두어 몸에 베일정도의 연습이 없으면 상당히 어렵겠네요. 일단, 단순하게 게임을 즐기고, 생각들을 정리하고
글을 게재하려는 유저들에게는 왠지모를 포스 -_-;가 느껴지는 글이기도 하구요.
MECE라는게 깊숙히 들어가면 책한권일정도로 간단하지는 않네요. 일단, 여기까지! ^^

몇번 기획서를 시도해 보았지만 가장 중요한 것은 보는이로 하여금 의사전달을 확실히 하기 위해서 길게 줄줄이 쓰는 것 보다 전달하고자 하는 주제에 대해 간단명료하게 작성하는 것이라고 생각합니다.. (당연한 말인가.. -.,-)

물론 기본 룰은 간단명료하고 이해가 쉽도록 간결하게 쓰는것이 좋겠지만, 가장 좋은 방법은 읽는 사람의 수준에 맞추어서 써주는것이 가장 좋다고 생각합니다. 경험상. 회사내의 모든 사람들이 기획자처럼 게임에 대해서 많이 알고 있지는 않으니까요. 경우에 따라서는 (이해의 목적 같은 경우...) 소설처럼 줄줄 써주는것도 좋은 방법중의 하나라고 생각합니다.

그리고 글을 쓰는 실력을 늘이는 것은 상당한 시간을 요구합니다. 일반적인 지식을 습득하는 것처럼 읽고 외운다고 습득이 되는 것이 아니라, 무의식적으로 손끝에 습득이 되어야 합니다. 많은 책을 읽고 직접 써보는 것이 가장 중요합니다. 글의 종류에 따라 문체는 매우 다릅니다. 그리고 상황에 맞는 단어의 선택과 활용도 중요합니다. 단어의 선택이 별로 중요한것 같지는 않지만, 문서에 무게감을 실어주는데는 중요한 역할을 합니다. 문서의 종류에 따라 알맞는 분위기를 연출해 내는것도 단어의 선택이라고 생각합니다.

기획의 어려움은 기획을 해본 사람만이 알겁니다.
오랜기간 동안 해도 어려운것이 기획이죠
제가 대학에서 경험있는 교수와 경험 없는 교수의 차이를 들자면
우선 그 디테일성 입니다.

아는것이 힘이지만, 전혀 필요없는 것을 아는체 하는경우가 많습니다.
프로그램도 마찬가지 입니다.
단순이 D3D,정도나 C++ 정도만 가르치면 되는줄 아는 교수거나 강사들이 많아서
비경험자와 경험자의 차이는 자신도 개발을 안해봐서 그저 프로그램 내용에서도 메뉴얼 식입니다.

무엇을 기획하려거든 먼저 많은 자료에 대해서 이해를 해야하고 그 자료가 없다면 개발은 그저 꿈이 될겁니다.
개발 경험이 오래된 경력자 중에서도 디테일하게 들어가면 쓰러지는 친구들이 바로 게임을 완성 못해본 친구들 입니다
이 친구들은 거의 프로토타입 이후의 게임은 완성이 안되는 경우가 허다해서 일 저지르는 스타일 이죠
경력자 분들은 다 공감 하시리라 봅니다.

나누자 ///////////////////////////////////////////
2/1 =? 아시는분

공감하기 힘듭니다. 윗분중에 어느분이 말했듯이 강조에 필요성에 의해 중복할 수도 있는 것은 사실이며
또한 중요한 것이. 타팀에게 하나의 작업에 수어개의 문서를 동시에 보면서 하라는 것은 무책임함 입니다.
다른곳에 설정 했더라도 한 문서에서 다른 문서의 정보까지 가지고 있으면 일을 처리하는데에 어려움을 덜해줍니다.
MECE(Mutually exclusive, collectively exhaustive) 보다는 MCCE(mutually compatibility, collectively exhaustive)로 바꿔야
할 것입니다.
[서로 겹치는 부분이 공존하나 모순되지 말아야 하며, 모아 놓으면 커버한다.]
실무 기획자의 마인드는 제가 수정한 글이 실질적입니다. MECE는 단지 많은 그저 오너로써의 설정 수행으로 밖에 보여지지
않습니다. 실무 기획으로 타팀의 기본적 작업원활성을 따진다면 MCCE여야 한다는 것입니다.
기획에서 중요하다 할 수 있는 문서의 표현은 타팀의 배려입니다. 내용을 전달하기 위해서 글을 잘쓰는 것이 기획 스킬의
한 테마이기에 내용이 중복되어 한눈에 모든 정보를 알아볼 수 있도록 해야 합니다. 대체로 기획문서를 작업 시행하기전에
꼼꼼히 머리속에 외워가면서 이해해 두는 기획 이외의 파트사람들은 그리 만나기 쉽지 않습니다. (모라 하는 것이 아니라 당연히
그들도 신경써야 하는 자신들의 고유 일이 있다는 것이죠)
솔직히 MECE를 오너로써의 설정수행 이라고 표현했는데, 그것도 너무 과분하게 말한것 같군요.

basic(gw basic 아님)을 모르면서 base를 논하고는 almost를 정의하여 totality를 말할 수 없습니다.
BBAT의 배열대로 진행되는 멋진 기획자 분들이 되시기 바랍니다.

- 우연히 뭔가 찾다가 글보고 성깔상... 글 써내린.............Eldomilk -

한가지 더. 무슨 말을 하고 싶은 지는 아는데 MECE로 논하지 말고 객체지향설계(UML)로 논했던 것이
더 지당하신 말씀 이셨을 겁니다. 제가 보기엔 말하고 싶은 내용을 잘못 설정 한듯 합니다.

엘도님 의견에 동감합니다. 기획서나 기획이란 커다란 피자에서 한조각의 피자를 떼어내고 그피자를 전문적으로 남의 피자조각과 비교하는것입니다.
때문에 커다란 의미의 분류에서 강조나 발전을 위한 중복분류는 필수라고 생각합니다.

엘도밀크 -.-

음.. 저자가 바바라 민토인 논리의 기술 책을 읽어 보면 링크 내용을 보다 구체적으로 기술하고 있으며 연습도 가능합니다. ''; 전 좀 이책이 졸리긴하지만 ㅎㅎㅎ

조 뜬금 없는 말이긴 하지만 어떤 방식이던 간 그 프로젝트르 이해하고 그 프로젝트에 맞는 문서를 작성하는게 아닌가여~
mece/mcce던uml이던 전 문서의 컨펌은 작업자가 본다구 생각합니다. 실질적으론 아니지만 결국 어떤 작업자와 어떤 일을 하느냐에따라서
바뀔수도 있다구 생각이 드는데여 넘 어려운 말로 포장되어진 느낌두 있구여 기획&디자인서에는 정도가 없다구 생각합니다.
이야기 주제와 빛나갔나.

굳이 기획에 한정시키기 보단 '나누어 접근하자'가 좋은 것 같습니다.

컴퓨터 알고리즘을 설계하는 방식 중에도 'Divide & Conquer'라는 말이 있지요.
필요한 것은 나누어 분석하고, 필요없는 것은 덩어리로 보자. 라는 내용되겠습니다.

사실 일정이 급한 일이 있다면, 그에 대해서는 어떤 것을 버려야 할지 선택의 과정이 필요한 것이고,
어떻게 개발해야 할지를 결정하는 과정이 반드시 필요합니다.

모든 문서와 토론, 작업은 '공감하는 결과물을 내기 위함'입니다.
UML을 이용한 표현이나 MECE한 고민은 전부 그를 위함입니다.
이런 면에서 뇌를 공유할 수 있다면 가장 좋겠지요. (정말로 그리된다면 그다지 좋지는 않겠습니다만...-_-;;)

#
문서는 중복이 조금씩 있을 수 있습니다.
사실 필요한 내용이라서 들어갔다면, 중복이라기보단 참고겠지요.
(링크일 수도 요약일 수도, 세부적인 설명일 수도 있습니다만...)

쓸데없는 곳으로 흘러가고 있음을 느낍니다만, 제 이야기의 결론은
'문서'는 보는 사람을 고려하고, '문제'는 나누어 접근하자

는 식으로 생각하면 되지 않을까. 하는 얘깁니다. ㅎㅎ

#
UML을 비판하는 내용은 아닙니다만, 개인적인 꽁지를 달자면...

전 개인적으로 프로젝트에 UML을 적용하는 것을 좋아하지 않습니다.

UML이 좋은 도구인 것은 분명하지만...
그를 이해하기 위해서는 많은 노력이 필요합니다. (저 역시 노력이 많이 필요한 부류입니다.)

정말 필요해서, 모두가 UML 기술을 습득한 상황이라면 말이 다릅니다만...

오랜 시간 같이 일할 수 있는 동료거나, 전반적인 프로그래머들이나 기획자들이
UML에 대한 접근을 할 수 있다면 적용하기 좋겠지만, 현실은 그렇지 않군요. ;;
(게다가 알아도 사용하는 목적이나 개념이 틀리면 싸움만 나더군요.)

#
본 내용과 관계는 없으나, 일정에 개발이 오도되는 (밀어넣는 식의) 기획은 저도 아니라고 봅니다.

실생활에도 적용하는 겁니다.

규칙적인 걸 좋아하는 저로써는 me,ce가 왠지 확 와닫는군요.

[그러면서 탱자탱자 놀고있네;;]

네... MECE를 잘 못 오해하셔서 기획서를 소설이나 다큐 리포트 정도로 쓰시는 분이 없길.. (잠시 묵념..)

UML적 사고가 범용적인 기획과 연관이 될 수는 있으나, 범용적인 기획서를 쓰는 것은 아니라고 봅니다.
그리고 MECE적 사고 방식은 기획자가 자신의 제안기획서 혹은 통합기획서를 구축할때는 고려할 수 있으나,
실제 작업 문서에는 적합하지 않다고 생각합니다.

왜냐하면 기본적으로 MECE가 되기 위해서는 기획전반에 걸쳐서 계속적인 숙지가 필 수 조건인데..
문제는 작업자들 입장에서 게임에 전반적인 라인은 알 수 있지만, 그 속에서 돌아가는 나사 하나 하나 까지 알기란 쉽지 않기때문입니다.

즉, 현실적으로 기획서의 중복 기입은 해당 작업자에게 참고로 혹은 다시한번 숙지하게 만들어 주는 반복 학습과 같다고 생각이 드네요.

어느 책에 나와 있는 말이군..

Mutually Exclusive
Collectively Exhaustive

이거 확률 및 통계 이런 분야의 과목에 나오는 말 같은데 -_-;;

Sample space 의 연관성을 설명할 때 쓰는 개념.. 벤 다이어그램이랑 같이 나와있는.. 아닌가요

아이디어는 가로채는 쪽이 승자다.

동인녀 유저를 발견한건 나뿐인가

저~ 위에 퓨퓨님 말씀에 6년이 지났지만 제가 공감을 해봅니다.
저도 지금 작은 프로젝트에 혼자서 기획을 하고 있는데 디자이너도 한명, 프로그래머도 한명입니다.
그런데 이 디자이너도 큰 프로젝트 7년정도 하다가 이렇게 혼자서 캐릭터,배경,UI 등등 모든 작업을 혼자 다 하게 되었는데도, 아직도 자신의 경력을 과신하고 있습니다 ㅠㅠ
프로그래머는 신참이라 완전 무개념이구요;;

특히 디자이너분이 기획서 중복이 많다며 보기 힘들다고 하는데... 여러파트를 다 작업하다보니 중복되지 않기가 불가능합니다...
물론 더 더 더 열심히 하면 어느정도 가능하겠지만, 완벽히는 불가능하고, 게다가 이렇게 작은 프로젝트에, 그것도 한 디자이너가 모든 그래픽을 작업하는데, 중복되지 않는 문서를 줄수 있을까요...
그저 답답했는데 , 여기서도 저와 같은 생각을 가진 분들이 많아 안심됩니다 ㅠ ㅎㅎ