Project Charter를 꼭 써야 하는 이유 #2

프로젝트 챠터, 프로젝트 헌장을 꼭 써야 하는 이유는 뭘까?
두번째로 생각을 정리해 본다.


  1. 프로젝트의 기간을 정확하게 명시할 수 있다


- 언제 시작을 할 것이고, 언제 끝나는 것을 목표로하는지 명시적으로 알 수 있다. 이후에 프로젝트가 늘어지더라도, 얼마나 늘어지고 있는지 알 수 있다.

  2. 산출물, 즉 제품의 품질을 정확하게 명시할 수 있다.

- 제품을 인수하는 조건이 뭔지를 확실하게 명시하므로써, 이거는 되야되느니, 이정도는 해줘야 되는 것 아니냐 등등의 소리를 미연에 방지할 수 있다.

  3. 투입 인원을 끝까지 지킬 수 있다.

- 초기에 투입한 인원들이 어느세 다른 곳으로 슬금슬금 이동하거나 회사를 나가서 더이상 진행할 수 없을 때, PM으로서 회사에 인원 보강을 요청할 수 있는 구실이 된다. 이때, 개발자 2명이 더 필요하다는 것이 아니라, 이전에 있었던 팀원과 같이 이런 이런 능력이 있는 새로운 개발자가 필요하다고 명시적으로 이야기 할 수 있다.
그렇지 않으면, 전혀 다른 팀에서 2명 차출해서 팀에 넣어주고는 인원 넣었으니, 빨리 프로젝트 진행하라고 할 것이다. PM만 죽어난다..

  4. 할 수 있는 일, 할 수 없는 일을 명시할 수 있다.

- 프로젝트 차터에 이 프로젝트 어디에 뭘 하는 것인지 정확하게 작성하고 그것이 이해 당사자, 즉 '갑'에게 보여줘서 그것이 정확한지를 확인 받으면, 이후에 '갑'이 다른 소리를 하더라도 그에 대응할 수 있다.
정말 이상한 '갑'들은 Email을 전혀 쓰지 않고, 전화로만 이야기 하는 사람도 있다. 증거를 안남기기 위해서...
이런 사람들을 위해서라도 프로젝트 차터를 쓰고, 그 사람들에게 확인 메일을 보니고, 받았다는 확답 메일을 달라고 하는 것이 확실한 방법이다.

  사실 프로젝트를 시작하다보면, 이건 알고 있겠지 하는 것들이 있다.

'갑'에게 이야기 하는 것은 마케팅 팀이고, 일을 하는 것은 개발팀이기 때문에 그 사이에 어영부영 지나가는 것들과, 정확하게 양사하 합의하지 않고 지나가는 것들이 있다. 나중에 개발팀장인 PM에게 모든 것들이 돌아온다.
이러거나 저러거나 프로젝트가 실패하면, 귀책사유를 들어서 '갑'은 닥달할 것이고, 그 때 PM은 꼼짝없이 당할 수 밖에 없다.
프로젝트 차터에 가능한한 모든 것들을 적고, 그것에 합의가 되면, 계약서를 진행하고 견적을 주고 받는 일들이 진행되어야 할 것이다.

개발자가 편해지는 그날까지...

Project Charter에 대한 생각들..

Project Charter에 대해서..

회사에서 시작하는 프로젝트의 Project Charter를 만드는 것이 어떤 의미와 도움이 될까?

• 프로젝트의 목적을 분명히 할 수 있을까?

만약 내부 프로젝트라면 Project Charter를 작성하므로써 그 프로젝트가 무엇을 하는지를 명확하게 할 것이다.

• 프로젝트의 관리자에게 권한을 위임하는 효과를 볼 수 있을까?

- 음.. 회사 내의 Sponsor인 경영진에서 그렇게 인식을 해야 권한위임이 될 것이다. 만약 경영진이 권한을 위임한 생각이 없고, Project Charter의 그런 역활에 대해서 알지 못한다면... 별로 권한과는 거리가 있는 Expeditor정도의 권한만 가지게 되겠지..

• 프로젝트에 참여하는 인원들이 시작 단계나 진행 단계에서 프로젝트의 목적을 잊지 않게 할수 있을까?

- 명시해 놓고, 계속적으로 Project Charter를 관리한다면, 팀원들이 이 프로젝트에 참여하는 목적에 대해서 잘 알고 어떻게 참여할지를 스스로 판단할 수 있으리라..

• 프로젝트의 완료 조건에 대해서 명확해 질까?

- 프로젝트의 완료 조건을 최대한 알기 쉽게, 그리고 자세하게 적어 놓는다면, 팀원들도 그 완료조건을 만족하게 하기 위해서 프로젝트에 참여하리라.. 좀더 생각이 있는 팀원이라면, 그 조건에 만족하지 않는 방향으로 프로젝트가 흘러 가는 것에 대해서 참지 못하고, 바로 잡으려 하겠지..

• 프로젝트 기한에 대해서 더 명확해 질까?

- 두가지 측면에서 명확해 질 수 있겠지.. 하나는 Sponsor가 맘대로 일정을 앞당길 수 없을 것이고, 또 다른 하나는 PM이 그 기한에 대해서 꼭 지켜야 하겠지..
하지만, 기한을 명시하지 않는 Project Charter가 있다면... 기한을 명시를 해야 되겠지..

• 담당자가 누군지 확실해 질까?

- 참여하는 사람들의 이름을 명시를 해 놓는다면, 정확하게 그 사람들은 참여를 하고 있다고 생각하겠지.. 그리고 PM의 이름을 명시한다면 이 프로젝트의 진행은 누가 책임진다고 공지하는 효과가 있겠지..

팀 내에서 업무 롤에 대한 것은 관리 계획서에 조직도를 넣고, 그 업무를 명시하면 더 확실해 질 것이다.

.. 더 생각을 해보자..

Project charter를 꼭 써야하는 이유를....

Mac App Store 둘러보기

오늘 Mac App Store를 업데이트로 설치를 하고 실행을 해 보았습니다.
혹시나 궁금해 하실 분들이 있을 것 같아서 간단하게 정리해 봅니다.
먼저 업데이트를 하면, 아래와 같이 App Store가 설치되어 있습니다.

왼쪽 위에서 2,2 에 있는 AppStore가 보이시죠?

신기하네요.

실행을 하면 아래와 같이 실행이 됩니다. 첫보기에는 아이튠즈와 비슷하네요.

 여기에서 MindNode를 설치해 보겠습니다.
설치를 누르면, App Store ID와 암호를 넣으라고 합니다. 기존에 있던 것을 넣으시면 되겠죠.

 입력을 하면, 아래 그림에서 오른쪽 중간 쯤에 아이콘이 날아가는 것이 보이시죠?
이거 캡춰하는데 좀 걸렸습니다.
설치하면서 슝~ 날아가서 Dock에 척 붙습니다.

그리고 실행을 하면

이렇게 실행이 됩니다.

참... Mac사용하기 쉬운 세상이 왔네요.

지금 CES 2011에서 안드로이드 허니컴으로 탭이 많이 나올 거라고 다들 들떠 있는데,

애플은 Mac App Store로 PC 어플리케이션 시장을 선점(?), 확대(?)하겠네요.

이제 Visual Studio로 앱 개발하시던 분들이 XCode로 Mac앱을 만드시겠어요.

iPhone/iPad와 호환 되는 Mac App이 많이 나오는 시기가 올것 같습니다.

국내에 게임 개발 회사들은 맥OS용으로도 게임을 만들어서 판매할 수 있을 것이고, 또 다른 시장을 국내에서 손쉽게(?) 참여할 수 있을 것 같습니다.

초기에는 iPhone/iPad의 앱들이 그대로, 맥용으로 이동이 되겠지만, 점차 키보드와 마우스로 더 편리하게 할 수 있는 앱들이 개발이 될 것이고, 더 나아가 iPhone/iPad와 연동해서, 할수 있는 앱들이 나올 것 같습니다. 

특히 전자책과 기업용 앱들은 기본의 윈도우 PC시장에서 Mac용 시장으로 그 활용이 더 넓어 질 것 같습니다.

Mac App Store는 한마디로 편리하지만 섬뜩한 느낌 입니다.

게임 배급사 혹은 애플케이션 배급을 하던 곳들은 타격이 크겠습니다.

Free Vector Graphic이 있는 곳

오늘은 이미지가 있는 곳을 많이 올리는 군요.
Free Vector Graphics 사이트 입니다.
http://www.vectorvaco.com/

Fitness Image를 찾을 때 사용할 수 있는 곳~

앱 기획 하실 때, 운동 관련한 앱을 만들 경우가 있습니다.
그 때 사용할 수 있는 여러가지 이미지들 이 있는 곳입니다.

http://www.fotosearch.com/photos-images/fitness.html

관련한 이미지들을 Free로 사용할 수는 없고, 가격 또한 만만치 않게 비싸겠지만, 필요한 이미지들을 찾아서, 가공하거나, 아니면, 그렇게 다시 찍으면 좋겠죠.

실제 이미지 말고, Free로 사용할 수 있는 실루엣 이미지들이 있는 곳입니다.
http://all-silhouettes.com/vector-fitness-poses/
Free이긴 하지만, 몇개가 없고, 티셔츠 등에 넣을 수 있는 벡터이미지를 공개한 곳입니다. ai로 되어 있습니다.

좋은 정보가 되실길 바랍니다.

화면 디자인 할 때 사용할 수 있는 Photoshop Brush들

Photoshop에서 사용할 수 있는 무료 브러쉬 들 입니다.
http://dezignus.com/brushlovers-free-photoshop-brushes/

App개발 할 때 디자인용으로 사용하면 좋을 것 같습니다.

제안서 쓰는 과정 정리 - 제안서 이렇게 쓰자

어느 회사에서든 제안서 쓰는 것에 대한 요구가 있습니다.
사장님께서 갑자기 오셔서,
- "이런거 이런거 되는 제안서 써서 가져가야 되니까. 만들어봐"
- "예, 사장님"
- "내일까지 알겠지?"
- "예?!!!!"

뭐 이런 대화가 다반사 일 겁니다.
이런 경우, 사장님의 의도와 제출하는 대상자가 어떤 것에 포커스해서 관심을 가지는지가 가장 중요해서, 그것을 알아내는 것이 제안서로 사랑받는 지름길이라 생각 되네요.

근데, 이런거 말고~

어떤 회사인 "갑"에서 RFP가 발송이 되고, 그것에 따라서 제안서를 작서하는 것에 대한 과정을 정리해 보고자 합니다.

우리 이통사의 경우에, 회사에서 친분이 있는 사람들에게 먼저 관련 주제에 대해서, 설명해 줄 수 있는지에 대한 요청이 먼저 들어옵니다.
그러면, 위의 과정과 같이 대략적인 정보만을 가지고, 대략적인 제안서 초안을 만들고, 들어가서 담당자를 만나게 되죠.
그러면 큰 그림이 나오고, 관련 정보를 "갑"담당자에게 주면, 머지않아서
RFP(Request For Proposal) 요청이 메일로 오게 됩니다. 안오면 뭐.. 내부 드롭된거고..
어떤 회사에서는 RFP를 Request For Payment로 사용하는 회사가 있지만, 대부분 제안요청서로 사용이 되죠.

http://blog.hrinmotion.com/wp-content/uploads/2008/06/rfp.jpg

1. RFP 분석

• 먼저 RFP의 내용이 무엇인지 파악해야 됩니다.
• RFP에 있는 문구 들 중에서 이해가 되지 않는 부분에 대해서는 담당자에게 전화 등으로 문의를 해서 그 부분이 뭔지 확실하게 이야기를 들어야 합니다.
• "갑"에서 RFP 제안 설명회를 하게 되는데, 그 전에 1차 분석을 마치고, 문의할 내용을 제안 설명회에서 문의할 것들을 정리해야 합니다.
• 정부과제가 아닌 경우, 공개적으로 RFP 대상 기업들을 불러서 설명회를 하는 경우가 드뭅니다. NIPA경우에는 설명회를 하지만... 대부분 서로 알면, 짜고 칠까봐 안 알려 줍니다.
• 이 경우, 회사를 차례로 불러서 질문을 하게 되는데, 이 경우 의도적으로 마지막 부분에 문의하는 경우가 좋습니다.
• 왜냐! 설명회를 먼저한 회사들의 질문들을 담당자가 다 알고 있기 때문에 "이런건 이렇게 해달라, 저건 이런거다" 등등을 다 들을 수 있습니다.
• 이 설명회에서 "갑"담당자에게 꼭 문의해야 되는 부분은 바로
• RFP에서 가장 중요하게 생각하는 부분이 뭔지 담당자의 생각을 들어야 합니다. 그래서, 중요하지 않은 부분과 중요한 부분을 확실히 구분하는 것이 제안서 쓰는 인원들을 중요한 곳에 집중할 수 있게 해 줍니다.
• 그리고, RFP에서 요구하는 사항들을 나열해 보고, 그 사항이 맞는지 RFP담당자에게 문의를 해야 됩니다. 후에 이 요구사항이 개발할 때, 협상 대상이 되기 때문입니다.
• 요구사항들을 보고, 개발해야 되는 것의 명칭/이름을 생각해 보고, 그것을 구현하였을 때는 어떤 형태가 될 것인지 생각하고, 그림으로 표현할 수 있어야 제안서의 내용이 구체적인 것이 될 수 있습니다.

http://www.lenfantplazahotel.com/images/meeting_RFP_img.jpg

2. Go Point - 갈건가? 말건가?

• RFP를 보고, 이번 제안이 회사에 도움이 되는지, 실현가능성은 인지를 결정해야 합니다.
• 이 때 결정을하고, 제안을 포기할 지, 전적으로 인원을 투입할 지 결정을 해야 됩니다.
• 또한 "갑" 내부에서 이미 회사를 선정했을 경우도 있습니다. 이 경우, 뒤엎을 가능성이 얼마나 있는지 조사한 후에 제안서 작업에 들어가야 합니다.
• 꼭 알아야 합니다. 선정이 이미 결정되있는데, 제안서 쓰느라 힘은 힘대로 빼고, 제안서 통과 못했다고 인사고과 밀리고, 욕먹고.. 쩝  

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCFxNgndpmpyMgdUy2l3ejzdkvpjavK-pM9Bo5zS5aCiuLMGaBorOu_bFL8HY55KbDilTl6ivy9v4gyqxk88f2iOBxjLn16PSVc6c7Ox0WAFdgrkt41LmEwebBZgom3oPJizJkMfVCV4Ez/s1600/RFP.gif

3. 제안서 쓰기

1. 제안서 틀을 만들자
• 제안서의 구성을 어떻게 할 지 생각하고, 전체 흐름을 잡아야 합니다.
• 틀에서 추가할 부분과 강조할 부분을 생각하고, 요구사항들을 빠짐없이 넣고, 어떻게 구현할 것인지, 실행할 것이지, 제공할 것인지 대략적인 흐름이 나와야 합니다.
• 이 흐름을 만들 때, 기획, 디자인, 개발팀에 팀장이나 담당자들이 참석해야 후에 수월합니다.
• 제안서로 쓰일 PPTX파일의 Template을 마련합니다. 나중에 합칠때, 수월하게 하기 위해서, 마스터 보기에서 Template들을 만들어서 배포해야 합니다. 아니면 나중에 정말 노가다 작업을 하게 되고, 보기에도 이상하게 됩니다.
2. 제안서 1차 초안에서 담당자 선정
• 제안서 초안이 만들어 지면, 각 부분별로 담당자를 선정하고, 그 사람들에게 제안서를 쓰도록 지시를 해야 합니다.
• 이 때! 담당자들을 다 불러서 모아 놓고, 이번 제안서의 당위성과 가능성, 이후 어떤 일들이 있을지에 대해서, 이야기를 해 줘야 합니다.
• 이 과정이 제안서의 Quality를 좌우합니다.
• 제안에 참여하는 사람들이 제안서가 왜 중요한지 그리고 정말 어떻게 써야 가능성이 있는지를 공감할 수 있어야 올바른 제안서가 나오고, 좀더 창의적인 제안 내용을 모아 낼 수 있습니다.
• 필요하다면, 개발하는데 문제가 있음을 인정하고, 그것을 뛰어 넘을 방법을 수주 한 다음에 만들자고 인정하는 것도 필요합니다.
• 각 파트를 담당하는 담당자들이 해당 부분을 정확하게 이해 했는지, 반드시 확인을 해서, 다른 방향으로 흘러가지 않도록 해야 됩니다.
• 담당자에게 꼭 물어봐야 합니다. "이 파트는 어떻게 쓰실 거에요?"
3. 제안서 1차 버전을 바탕으로 도식화 작업
• 제안서에 있는 각 부분을 설명하기 쉽도록 그림으로 표현하는 것이 중요합니다. 그림으로 초안을 잡고, 그 후에 디자이너가 작업을 하면 됩니다.
• 해당 페이지에서 제안하는 핵심이 뭔지 아래 부분에 1줄로 정리가 되어야 합니다. 제안 내용이 확실하지 않을 때는, 그 파트의 담당자를 불러서 설명을 듣고, 확실하게 이해를 해야 합니다.
• 이거 안되면, 나중에 발표할 때, '어버버' 거리게 됩니다.
4. 제안서 내용에서 비교우위를 가질 부분을 체크
• RFP에서 중요하게 생각하는 부분에 대해서, 다른 제안 회사들과 차별화 되는 부분이 뭔지 정확하게 나와야 합니다. 다른 회사에서도 이렇게 하면 되는 것이면, 차별화가 되지 않고, 별로 주목도 못 받습니다.
• 일단 우리 회사에서만 제공할 수 있거나, 우리회사가 이 부분에서는 경험이 많음으 증명할 수 있으면 좋습니다.
• 이것도, 저것도 없으면, 담당자에게 뭐가 중요할 것 같냐고 물어보는 것도 한가지 방법입니다. "갑"담당자가 까칠하게 나올 수 있지만, 안되면 질문을 해야죠.
5. 제안서 작성 후에 전체적인 흐름에 따러서 재 배열
• 중요한 것을 어디서 강조할 것인지를 결정해야 합니다.
• 강조하는 부분에서 우리의 강점이 뭔지 확실하게 표현해야 합니다.
6. 전체적인 틀이 나오면, 디자인 작업에 들어갑니다.
• 대부분 시간이 많지 않기 때문에, 제안 발표하기 5일 전이면, 제안서 작업을 많이 서둘러서 끝낸 편이라 생각됩니다.
• 경험상, 하루, 이틀 전에 디자인 작업에 들어가게 되는데, 이 때 디자인 팀의 반발이 대단합니다.
• "우리는 뭐 발로하는 줄 아냐, 하루만에 이 많은 것을 어떻게 하냐!" 등등의 불만이 나오게 됩니다.
• 그래서, 위에 1번, 2번을 할 때, 디자인 팀장이나 디자인 담당자를 회의에 참석을 시켜야 합니다. 그러면 이런 작업이 언제까지 이뤄 질 것이며, 어떤 내용으로 진행되는지 알 수 있게 되므로, 필요한 작업을 준비하게 됩니다.
• 첫 페이지라도 디자인을 해두게 되므로 반발이 덜하고, Quality도 좋게 됩니다.
• 디자이너에게 회사의 분위기와 특징들, 제안서의 성향들을 말해 주고, 그거에 맞게 TP를 구성하도록 하면 좀더 Quality를 높일 수 있습니다.

http://www.webstock.org.nz/blog/2009/garr-reynolds-presentation-zen-master-class/

4. Presentation 준비

• 이제 어려운 부분이 남았습니다.
• 누가 할 것인가? 당연히 제안서를 중심에서 준비했던 사람이 해야 됩니다.
• 혹자는 잘 생긴 사람이 해야 된다고도 하는데, 잘 생기고 말 잘하면 금상첨화죠. 개인적으로는 기획팀 여성팀장이 발표하면 IT업계의 생기를 불어 일으킬 수 있고, 듣는 사람들이 대부분 남자들이므로, 더 어필이 가능할 것으로 보입니다.
• 전적으로 개인적인 생각입니다. 기획팀에 여자분이 안계셨던 관계로...
• 발표를 준비할 때, 듣는 사람이 편하게 들을 수 있도록, 어떤 스토리로 발표할지를 결정해야 합니다.
• 그리고 RFP를 어떤 배경에서 나오게 되었는지, RFP에서 가장 중요한 것이 뭔지, 스토리로 풀어서 설명을 시작하면서, 든는 사람들이 '제대로 이해하고 왔군' 이라고 고개를 끄덕이게 만들어야 합니다.
• 발표 시나리오 데로, 페이지를 그림으로 쉽게 쉽게 설명할 수 있도록 다시 만들고, 핵심 글자와 간단한 도식화 그림으로 표현하는 것이 좋습니다.
• 전체 요구사항을 카테고리로 나눠서 큰 묶음들로 각 부분을 설명하면 이해가 더 쉽게 됩니다.
• 마지막에 이 제안서에서 가장 강조할 것을 3가지로 압축해서 요약할 필요가 있습니다. 듣는 "갑"의 담당자들이 중요한 것을 어떻게 만족시킬 수 있는지 각인 시킬 수 있으면, 제안서 작업이 성공한 것이죠.
• 만약 잘못하면?????

http://www.sequenceweb.co.uk/resources/image/Poor%20presentation.jpg

지금까지 제안서를 작성하는 담당자 입장에서 정리를 해 봤습니다.

이통사 관련한 제안서를 중심으로 만들었기 때문에 다른 분야에서는 좀 다를 수도 있습니다만, 제안서를 만드는 사람들이 잘 뭉쳐서 어떻게 기발한 제안서를 만드냐에 성패가 있다고 보입니다. 

 그래서, 제일 중요한 것이 참여하는 사람들의 마음을 한 곳으로 집중 시키는 것이라고 생각됩니다.

제안서의 성공을 위해서~~ 파이팅!

http://www.salesedgellc.com/uploadedImages/Home/Solutions/WOW-Accelerated-RFP-Response.jpg

- David Bae