PLANin

무시당하는 기획? 무시할 수 없는 기획. 기획이 무시당하는 경우는? 디자인,개발의 경우는 기획의 과정을 보는것이 아니고 결과를 보는것이기 때문에 이런 이슈가 자주 발생된다고 보면 된다. 아니, 반대로 생각해봐라. 당신이 어디서 디자인을 봤다 치자. 솔직히 누구나 뭐라고 한마디씩은 할껄? 당신이 최고의 디자인을 가져다가 사람들에게 물어봐라, 다 한마디씩은 할꺼다. 그런거다. 기획도 마찬가지다, 만들어낸 결과를 보기 때문에 "이런건 누구나 생각하지, 어디에나 있는거지"라는 헛소리를 지껄인다고 보지만, 딱히 헛소리도 아니다. 좋게 생각해라. 우와! 기획 죽이는데? 라고 하는 경우는 없다고 생각해라. 그렇게 말한다면, 그냥 당신 기분 좋으라고 하는 말이다. 왜? 당신이 테슬라 전기차를 생각했다고 치자, 그걸 기..

**** 전략 기획을 하는 기획자에게 중요한것은? 결정권자. 판단을 위한 기획서를 만들어야 하는가? 결정을 위한 기획서를 만들어야 하는가? **** 사업을 진행하고 운영하고 이끌어가면서 가장 중요한 부분이 "기획서"라는 부분이다. 이 "기획서"는 어떤 유형이 있는것이며, 잘 만든 기획서라는것은 무엇을 말하고 뜻하는것인지 포스팅해보고자 한다. 결정을 위한 기획서의 본질. 뭐 별거 있겠는가? Insight . 이것이 답이다. 인사이트를 얻기 위해서 보는 문서가 "결정"을 위한 문서다. 그렇다면. 그 문서는 누가 어떻게 만들어야 하는것인가? 대기업이라면 전략기획실 등 결정권자 하위에 있는 사람들이 만들어내는데. 여기서 어려움에 봉착하게 된다. 결정을 위해서는 "판단"이 선행되어야 하는데, 이 "판단"을 내리는..

RFP 란. - 갑 : 구축을 의뢰(지시)하는 기본적인 가이드. - 을 : 구축 범위를 정의하는 가이드. 라고 할 수 있습니다. 구축 완료 후 문제 생길때. - RFP 에 있는데 왜 안했나요? - 제안서에 있는데 왜 안했나요? 라는 질문을 받을 수 있으니 모두 해야한다고 생각하고 접근해야합니다. 그렇다면? 이 RFP 가 나오는 과정에 대해 알아보려고 합니다. 이 RFP 도 하나의 기획서라고 볼 수 있습니다 사업이 발생되는 경우 * 신규 사업에 대한 Needs 가 발생되는 사업 (신선한거) - 고객사의 CEO/ CTO 등이 외국 세미나를 다니거나 - 주변 다른 대표님들과 술을 한잔 하신다든가. - 주변들에게 요새 핫한게 뭐니? 라고 물어본다든가 - 신문 기사를 본다든가. 해서 발생됩니다. ㅋㅋ 이런경우 많..

가설검증형 기획의 프로세스 어떻게 풀어야 할지 눈앞이 캄캄한 일은 가설검증형 기획의 프로세스를 밟아라 일을 하다보면 정말 눈앞이 막막할 때가 있다. 어떻게든 해결을 해야 할 텐데 도무지 답이 보이지 않는 경우다. 자료를 뒤지고 아이디어를 짜내 보지만, 해결책은 보이지 않고 자괴감만 든다. 이럴 때는 현 시점의 정보를 바탕으로 가설을 세우고 구체적인 팩트로 검증하는 가설검증형 기획을 실시해야 한다. 낯설고 어려운 것 같지만 일상생활 속에서 수없이 많은 하는 방식이다. 식당에 사람이 많으면 ‘저 식당에 사람이 많으니 음식이 맛있을 것이다.’라는 가설을 세우고 들어간다. 그런 다음 실제 음식을 맛보며 가설을 검증한다. 결혼도 마찬가지다. 결혼 전 상대방의 됨됨이를 보고 ‘저 사람과 함께라면 평생을 함께 할 수..

사회생활의 도. 실력이 없으면 귀를 열고 능력이 없으면 손을 잡고 아래의 소리에 경청 하고 윗선의 소리에 믿음을 주고 자신이 없으면 입을 닫아라. 원론적으로 말하는 사람중에 스스로 실력있는 사람 못봤고 원론적으로 말하는 사람중에 스스로 성과내는 사람 못봤다. 성과가 없는 사람일수록 원론적으로 얘기하며 빠져나갈 구멍을 만든다. 성과가 없는 사람일수록 타인의 성과에 밥숟가락 얹으며, 성과가 없는 사람일수록 허언을 한다. 타인의 말에 귀를 기울이고, 항상 함께 한다는 마음가짐으로 생활에 임하며, 아래의 소리를 듣고 위의 소리에 신뢰를 주고 귀는 열되 입을 닫고 생활하라. 항상 매사에 명확하게 행동하고 말 하며, 타인의 성과를 축하해주고, 타인의 성과를 빛내주어라. 잊지마라, 너는 월급쟁이 기획자다.

다섯 번째 기획노트, '일정에 대한 명확한 마일스톤으로 높은 효율을 가져보자' 본문에서 설명하는 내용은 제가 직접 수행하면서 느낀 점 입니다,전혀 아니다..라는 시각에서 벗어나 이런 시각과 저런 시각이 있구나..라고 느껴주시기 바랍니다. (예제. **홈페이지 구추일정표) 컴퓨터인터넷IT용어대사전 이정표[ milestone ] 흘러드는 모든 단위 작업이 끝나기 전까지는 종료된 것으로 생각하지 않는 단위 작업 또는 사건. [네이버 지식백과] 이정표 [milestone] (컴퓨터인터넷IT용어대사전, 2011.1.20, 일진사)마일스톤과 같은 의미로 사용되는 단어 : 마감일, 1차 종료, 1차 컨펌요청 등 같은 의미로 사용되고 있습니다 마일스톤이 가지고 있는 의미기획자에게만 사용되지는 않습니다. 어떤 일을 하던..

네 번째 기획노트, '기획자와 수행자, 커뮤니케이션의 골' 본문에서 설명하는 내용은 제가 직접 수행하면서 느낀 점 입니다,전혀 아니다..라는 시각에서 벗어나 이런 시각과 저런 시각이 있구나..라고 느껴주시기 바랍니다. [정의]기획자 : 제안기획/ PM/ 화면설계서(스토리보드) 등 document 를 다루는 자디자이너 : 포토샵/ 일러스트등을 토대로 이상적인 화면을 그려내고,퍼블리싱을 하는 자 (디자이너와 퍼블리셔를 하나로 보겠습니다)개발자 : DB 등과 다양한 API 를 활용하고, 컴퓨터 프로그램의 알고리즘을 짜고 논리 정연하게 구현하는 자[기획자가 수행자에게 가지고 있는 골] * 자신의 업무범위가 아니라는 수행자 * 칼퇴.. * 기획자는 방패인가? * 기획자는 모든 것을 다 해줘야 하는 사람인가? * ..

세 번째 기획노트, '기획과 계획의 차이, 그리고 기획자와 계획자' 본문에서 설명하는 내용은 추상적으로 인지하고,기존에 알고 있지만 인지하지 못한 내용등을 기술했다고 보시면 됩니다. 단지 제목에서 보여주는 내용만을 가지고 설명을 한다면?기획이란? 컨셉이라고 볼 수 있으며,계획이란? 컨셉을 구체적으로 실행하는 방안 이라고 볼 수 있습니다. 여기서 말하는 기획이란, 지극히 추상적인 내용이 될 수도 있습니다.말이 좋아 컨셉이지, 그 컨셉이 나오게 된 정확한 결과에 대해서는 사실상 설명하기 어렵기 때문입니다. 기획이 정말 기획인가? 팩트를 중심으로 도출된 컨셉, 궁극적인 목표가 컨셉이라고 보고 그것을 기획이라고 보게 된다면.그것이 정말 기획이냐? 라는 질문을 되돌려주고 싶습니다.팩트가 중심이 되니 충분한 근거를..

두 번째 기획노트, '리더가 가져야할 능력' 본문에서 설명하는 내용은 말 그대로의 '능력' 이 아닌 구성원의 역량을 올리기 위한 방법에 대해 기술하였습니다 PM, PL, 팀장 등 누군가의 상사로써, 선도되는 업무를 담당하는 직급으로써 알아두면 좋을듯 합니다. 역량을 파악하고 그 역량을 꺼내라 그 동안 어떤 리더를 만나보셨나요? 무조건 쪼아대는 리더?구성원의 능력이 안된다고 투덜대는 리더?구성원이 업무능력이 안된다고 자신이 일을 뺏어서 하는 리더?업무에 관련된 내용이지만 함께 알 수 있도록 공유하지 않는 리더? 그럼 역으로 물어본다면위에 기술된 리더들이 잘못된 리더인가요? 아니면 구성원이 잘못된건가요? 옳다 그르다라는 잣대로 판단할 수 없는 것 입니다.경험이 부족한 구성원은 잘 모를 수 있습니다.경험이 부..

첫번째 기획노트,'앞을 내다보게 기획하라' 기획안을 꿰뚤어본다고 생각하고 있는 '사륜안을 가진 고객'을 역이용하라 여러분들이 영화를 보거나 드라마를 볼 때 '어멋, 저사람이 범이인거 같아' 아니면 '저게 나중에 문제가 될 것 같아' 등등으로 예측한 경험 있을것이라 생각됩니다.이와 마찬가지로 자신이 기획한 기획물을 발표할때, 그것을 듣는 청중은 당신이 발표하는 기획안에 대해서 예측하고 있습니다. (제가 좋아라 하는 나루토에서 나오는 사륜안을 인용해봅니다 ㅋ) 청중들은 어딘가에서 들어본 기획인데? 무슨 얘기를 할 것 같아..지루해, 뻔한얘기 또하네..등등으로 이미 당신의 기획안 발표를 듣고 보면서 머릿속에서는 다른 생각을 하고 있습니다.발표현장에서 팔짱기고 '어디 한번 뭐라고 떠드는지 들어나 보자' 라는 표..

비전서(제안 및 과업설정과정) -> 명세서(요구분석) -> 설계문서 -> 보고 문서 의 업무 프로세스 중에서 명세서 제작에 대한 정리입니다. [필요성] 1. 개발은 변경에 의한(또는 예측치 못했을 경우의) 손실이 크므로 최대한 줄일 수 있는 신중한 명세를 작성 이해할 독자 (고객,개발자,테스터,관리자,매뉴얼작성자) 2.중요한 결정을 미루지 않을 수 있다.(프로젝트 후반의 리스크 감소) [정의] 1. 기능명세 (functional specification) - 기능, 화면, 메뉴, 대화상자 문구 등 - 어떻게 동작하는지는 신경쓰지 말자 2. 기술명세 (technical specification) - 자료구조, 데이터베이스모델, 프로그래밍 언어 및 도구, 알고리즘 등 [명세의 예] 1. 면책조항 : 명세의 ..

소프트웨어 개발 실패시 중요항목으로 작용 소프트웨어 프로젝트는 낮은 품질과 지연되는 일정, 초과되는 예산으로 악명 높다. 소프트웨어 위기(Software Crisis)라고도 불리는 이런 현상의 원인에는 항상 불완전하거나 잘못된 요구사항이 있다. 스탠디시 그룹(Standish Group)이 352개 기업의 8000개 프로젝트를 조사한 결과에 따르면, 소프트웨어가 실패하는 주요인으로 사용자의 참여 부족(12.8%), 불완전한 요구사항과 명세서(12.3%), 변화하는 요구사항과 명세서(11.8%) 등 요구사항과 관련된 항목이 거의 40%에 달함을 알 수 있다. 이번 호에서는 요구사항과 관련된 최소한의 문서인 기능 명세서(Functional Specification)에 대해 알아보자.  서광열 | k..

읽기 ： 더블유비에스 스펠 ： Work Breakdown Structure 프로젝트메니지먼트로 계획을 세울 때에 이용되는 수법의 하나로, 프로젝트 전체를 작은 작업 단위로 분할한 구성도이다. [작업분할구성], [작업분해도] 라고 불려진다. WBS에서는 우선 프로젝트의 성과물을 가능한 한 작은 단위로 분해한다. 그 때, 전체를 큰 단위로 분할하고 난 후, 각각의 부분에 대해 좀 더 작은 단위로 분해하여, 계층적으로 구성화 해 나간다. 성과물의 세분화가 끝나면, 각각의 부분을 구성하는데 필요한 작업(한가지 이상의 작업일 때도 있음)을 생각하여, 최하층에 배치해 간다. 각각의 부분을 구성하는 일련의 작업 단위를 [워크 패키지]라고 한다. WBS의 각각의 워크패키지에 담당인원을 배치하면 프로젝트를 수행하는 조직..