반응형
어떤 기똥차고(=돈이 될만한) 획기적인(투자대비 수익이 높은)아이디어가 있다면, 이것을 문서화(Documents)하여 다른 사람들의 흥미와 관심을 이끌어 내야합니다. 이 부분은 기획자와 PM이 해야 하는역할중에서도 어려운 편에 속하는데, 이것을 제대로 하기 위해서는 논리적이고(반박 당할 꺼리를 없애고)현실성 있으며(돈과 시간을 조금 들여 더 많은 돈을 벌 수 있는) 사업주가 쉽게 도장을 찍어 줄 수 있는 그럴듯한(혹 이것이 50%의 거짓이 섞여 있다 해도) 문서가 필요합니다.
왜 “말”이 아닌 “문서” 일까요. 그것은 논리적인 것을 장기간 유지할 수 있는 유일한 수단이기 때문입니다. “말”은 당장은 효과가 좋을지는 몰라도 시간이 지날수록 그 허점을 들어내게 되어 있습니다. 하지만 문서는 허점이 들어나도 “재고”의 여지가 있다는 점이죠. 사실 사람의 마음은 갈대 이기 때문에 처음에 홀깃하더라도 시간이 지나면 불안해 합니다. 그렇기 때문에 “보험”차원에서 문서가 필요한 것이고, 업무추진과 진행에 있어 “문서”라는 증거는 사업주에게 대항할 수 있는 효과적인 수단이기도 합니다.
그렇다면, 효율적인 “문서” 의 근거는 어디서 나오는 것인가? 그건 최초의 아이디어를 “얼마나 체계적이고 효율적으로 정리하였는가”에 기인합니다.
내 생각을 “누가,언제,어디서,무엇을, 어떻게, 왜?” 육하원칙에 따라서 정리하면 향후 프로젝트를 진행함에 있어 발생되는 트러블을 효과적으로 대처할 수 있는 좋은 자료가 됩니다. 통상적으로 아이디어를 문서화 시키는 대부분은(저를 예를 들자면..ㅡ.ㅡ) 생각나는대로 수첩에도 기록했다가, 포스트 잇에도 기록했다가, PC의 메모장에도 기했다가 하는등 생각나는걸 써놓고 후에 기획서나 제안서 개발문서등 작성할 때 와 아이디어 회의 때 참고하는데, 사실 이것이 그리 좋은 버릇이라고는 할 수 없습니다.
아이디어에서 메모(Meno)는 아주 훌륭한 기록 방법이긴 하지만 제대로 정리되지 않은 메모는 이후 혼란을 불러 올 수 있는 “덧”이기도 합니다. 그리고 아이디어가 나오기 시작하면 다른 사람과의 “연동”과 “첨삭” 과정을 거쳐야 합니다. 이때부터 “문서”의 중요성이 강조되기 시작합니다. 두서없이 작성된 메모들, 여기저기서 튀어나오는 개선점들, 잘못된 점들 등등 수많은 내용이 추가되고 사라지고 수정되어 집니다.
이때 많은 기획자들과 PM들이 자신이 만든 함정에 스스로 빠지기 시작합니다 머리속에 생각이 들어가 있는 건 많으나, 뜬 구름잡듯 모호한~사태, 이른바 자가당착에 빠지기 시작하는데, 기록해놓은 메모는 이것 같기도 하고 저것 같기도 하고… 처음에 생각했던 그 기발한 아이디어는 점점 누더기가 되가고…
이런 상황을 겪은 사람은 비단 저만이 아니라 많은 경험많으신 분들도 마찬가지라고 생각합니다. 이런 상황을 벗어나서 효율적이고 체계적인 “메모 버릇”을 가지는게 매우 중요합니다. 기획자(PM)치고 메모나 수첩에 회의내용이나 아이디어를 정리하지 않는 사람은 없습니다.
제가 생각하는 가장 효율적인 메모 방법은
1)내가 메모한 내용 그 자체가 그것을 자료(Data)로써 가치가 있는가?
2)메모를 다른 사람에게 보여주어도 이해할 수 있는가?
3)일별로(혹은 순서대로) 정리가 되어 있는가?
4)다른사람의 의견이나 수정방안이 나올 경우 첨삭할 여지(여분의 공백)이 있는가?
아이디어 메모들이 모여 "데이터"가 되고 데이터들이 모여 문서가 되고 문서는 프로젝트의 기반이 되어갑니다. 본격적으로 문서(개발기획서, 제안서 등등)를 만들게 되면 이제부터 "문서"는 PM의 강력한 방어수단이자 공격 수단입니다.(어째 전쟁하는 느낌...) 보다 강한 공방 수단이자 지침서로 만들기 위해서는 해당 프로젝트의 디자이너/개발자/기획자/마캐팅담당과 PM이 머리를 싸메면서 완성을 하는데 이때 중요한 것은 "보여주기" 위한 문서와 "각 담당자용" 이 따로 존재하는것이 좋을 때도 있고 "보여주기"위한 문서와 "각 담당자용"문서가 동일하는게 좋은 경우가 있습니다.
(재차 말씀드리지만 교과서적인 이야기는 생략합니다. 뭐가 꼭 필요하고 이건 이렇게 해야되고..이런건 서점가서 찾는게 빠릅니다. 제가 이야기 하고 싶은건 현실적인 이야기 입니다....가끔 현실이 결여된 이야기도 좀 하지만요..히힛~)
우선 기본적으로 프로젝트의 결정권자가 어떤 취향과 출신을 파악해 둘 필요가 있습니다.
실 예로. 개발자 출신의 오너들은 "보여주기"문서를 그리 달가워 하지 않는것이 보편적입니다. 이미 IT계에서 산전수전우주전 다 겪어서 CEO가 되면 실무적인것을 좋아하는 경우가 많습니다. 보고서를 쓰더라도 서술형 보다는 단답형으로 Yes Or No를 확실하게 해주는 보고서를 선호하게 되지요. 마찬가지로 기획서를 보더라도 실제로 어떻게 "만들것" 에 중점을 두고 보게 됩니다.
이와는 반대로 마캐팅 출신의 오너들은 "어떻게 표현할것인가"를 더 중시합니다. 기술적인 부분보다는 디자인, 홍보효과,부수적인 것에 더 신경을 씁니다. 이분들의 기본 베이스는 "기술은 가능할것이다. 중요한건 어떻게 팔아먹느냐!" 입니다. 이런분들에게는 "보여주기"를 위한 문서를 따로 작성하는게 여러모로 편합니다. :-D
마지막으로 이것도 저것도 아닌 타업계 오너형들은 짧은 지식과 어중간한(?) 귓동냥으로 인해 아주 어려운 경우입니다. 문서작업은 물론 기반 지식이 적기 때문에 단어선택에도 신중해야 하며 간단한 내용에도 반드시 "근거"가 존재해야 합니다. 제일 까다로운 CEO 형태이며, 또 가장 보편적인 형태입니다.(적어도 제가 겪어보기론...)
오너(혹은 "갑")에게 프로젝트를 진행하기 위한 OK 사인(또는 자금을..) 받아내기 위해서는 오너의 취향이 어떤지, 무엇을 선호하는지, 어떤 글꼴을 좋아하는지, 공백의 미를 중요시하는지 등까지 모두 파악해야 합니다. 특히 한국말은 "아" 다르고 "어" 다르다는 속담처럼 애매한 문장으로는 자승자박의 형태가 될 가능성이 높습니다.
두번째로, 충분히 검증이 되거나 반드시! 구현가능한 혹은 DeadLine(마감일)에 대한 명확한 근거가 마련되야 합니다.
기획단계에서 모든게 확정되고 결정될수는 없습니다. 중간에 잦은 업데이트와 수정은 불가피한데, 수정되는 것을 미리 감안하여 유드리있는 문서를 작성하다보면 되려 프로젝트를 진행하는 원래의 목적이 티미해지는 경우가 발생합니다. 또한 어떤 일을 진행하는데 근거가 약해지기도 합니다. 유들있는 문서는 차후 수정이나 업데이트에 보다 쉬워지고 빨라 질수 있으나 원 프로젝트에 대한 본질을 흐리게 합니다. 또 원 프로젝트의 개발을 어렵게 할 수도 있습니다. 이는 두마리 토끼를 쫓다가 둘 다 놓치는 우를 범할 수 있으니 문서 작성시 최대한 확정을 짓되 변화가 불가피한 부분에 대해서는 그부분에 대한 명확한 설명과 대처방안 돌발상황등을 허락하는한 자세히 기록하는것이 좋습니다.
또 마감일은 DeadLine이라고 불리는 만큼. 반드시 지켜야 합니다.(사실 이건 금강석에 꽃피길 바라는 것일수도 있습니다...현실적으로..)
이 프로젝트의 마감일이 왜 이렇게 나왔는지, 해당 마감일을 지키기 위해서는 어떤 일련의 과정이 필요한지등을 반드시 정리하여 "문서"에 기록해야 합니다.
제가 생각하는 "프로젝트의 기본 = 잘 짜여진 문서" 입니다.
"잘 짜여진 문서 =
1)잘 정리된 메모를 기반으로 실무자가 가장 보기 편한 방법(그것이 메모장으로 작성한것이라도 개발자/디자이너가 편하면 장땡)으로 작성된 실무자용 문서.
2)결정권자의 맘에 들게 작성한 문서.(허풍이라도 구현할 확신만 있다면 오너에게 주머니를 열게할만한 화려한 문서 혹은 세세한 스캐줄)
3)세분화 된 스캐줄(최악의 상황을 고려한 스캐줄링, 프로젝트 진행시 항상 최악의 경우로 일을 한다고 생각해야야 합니다.)
입니다.
이외에도 프로젝트의 기본 이라고 할 수 있는 것에는
1) 커뮤니케이션 로그를 남길수 있는 Tools( Program이든 Web이든 수단과 방법을 가리지 말고 대화기록을(또는 구두로 대화한 내용을) 저장할 수 있는)
2) 다른 팀원이 남긴 "메모"나 "기록"을 I/O가 편하게 이루어 질 수 있는 수단.
3) 화자간(개발자/기획자/디자이너/마캐터등) 가장 빠르게 대화할 수 있는 수단.
입니다.
아이디어를 정리하는 방법이나 문서화 시키는 방법은 개인과 취향에 따라 가지각색의 모습을 가지고 있습니다. 그러나 그 여러가지 방법을 살펴보면 기본은 모두 동일합니다.
"잘 정리된 메모" + "명확한 근거"에 추가적으로 "보는사람 맘에 드는 스타일의 문서" 정도만 갖추면 어디다 내놔도 일할 기분이 들게 하는 문서를 갖추게 될 수 있습니다.
반응형
'Computing..' 카테고리의 다른 글
| 너무나도 잘 정리된 UNIX 자료 (0) | 2007.05.17 |
|---|---|
| 인터넷 보안 (0) | 2007.05.07 |
| 전자상거래의 보안기술 및 암호알고리즘 (0) | 2007.05.07 |
