플랜인

다섯 번째 기획노트, '일정에 대한 명확한 마일스톤으로 높은 효율을 가져보자' 본문에서 설명하는 내용은 제가 직접 수행하면서 느낀 점 입니다,전혀 아니다..라는 시각에서 벗어나 이런 시각과 저런 시각이 있구나..라고 느껴주시기 바랍니다. (예제. **홈페이지 구추일정표) 컴퓨터인터넷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)에 대해 알아보자.  서광열 | kwangyu..

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