사진을 만화 캐릭터 스타일로 만들어주는 13개 웹사이트 리스트

사진을 만화 캐릭터 스타일로 만들어주는 13개 웹사이트 리스트 입니다.

서비스를 만들거나, 애플리케이션 만들때, 캐릭터가 필요할 경우가 많은데, 대부분 저작권이 걸려있으므로 자체적으로 만들어야 합니다. 이럴때 좋은 도구가 될 수 있습니다.
자신의 사진을 바탕으로 캐릭터를 만들어 넣을 수 있겠죠.

자세한 내용은 아래 링크를 참고하세요~

13 Websites That Converts Photo Into a Cartoon Character

1. WeeWorld

2. South Parker Studio

3. Portrait Illustration Maker

4. Joystiq

5. Befunky

6. SuperPortraits

7. Meez

8. zwinky 

9. Simpsons Movie 

10. FaceYourManga 

11. Kuso Cartoon 

12. IMVU 

13. SuperAvatar

[팁] WindowsXP SP2를 설치하고 SVN에 접속이 안될 때..

어느날 갑자기 개발팀의 SVN에 접속이 안되는 경우가 있습니다.
네트웍으로 공유한 공유 폴더도 접근이 안되고...
SVN서버에서는 외부로 다 나가는데, 외부에서 서버로 접속이 안되는 경우가 발생할 때가 있습니다.

혹시, Windows XP SP2를 설치하지 않으셨나요?
혹시, 방화벽을 실행해 보면, 실행이 되어 있지 않다고 나오지 않나요?
혹시, 관리>서비스 에서 방화벽을 실행해 보면, 시작할 수 없다고 나오지 않나요?
 (로컬 컴퓨터에서 Windows 방화벽/인터넷 연결 공유(ICS) 서비스를 시작하지 못했습니다."
 (오류 0x80004015: 클래스가 호출자와 다른 보안ID로 실행되도록 구성되어 있습니다."

이런 경우 SVN에 접속이 안 될 수 있습니다.
이유는 검색해 보시면....
"
특정 경우에 이 문제가 발생할 수 있습니다 관리 템플릿 Windows XP 보안 가이드에서 Windows는 컴퓨터에 적용 된 XP sp2는 설치 합니다. 이 문제는 Windows XP 보안의 일부로 게시 된 몇 가지 보안 템플릿의 문제로 인해 발생 가이드입니다.


Windows XP sp2에서 원격 프로시저 호출 (RPC)을 사용 하 여 실행 되는 NT Authority\NetworkService 계정입니다. 기본 보안 설명자에 대 한 서비스를 Windows XP sp2에서 Authenticated Users 그룹에 읽기 액세스를 제공 합니다. 여기에 NT Authority\NetworkService 계정이 포함 됩니다.
"
가 원인이 될 수 있습니다.


"특정 관리 템플릿 Windows XP 보안 설명서에서 Windows XP 서비스 팩 2에서 Windows 방화벽 서비스를 시작을 하지 못할 수도 있습니다."
라는 것이죠.
방화벽이 안되니, 접속하는 모든 것을 막아버리는 것 같습니다. 내부에서 나가는 것은 나가고...

일단
http://support.microsoft.com/kb/892199/ko
에 가셔서, Microsoft Fix it 50638 을 해보세요.

그리고, 리부팅 후에, 네트웍 드라이브가 접속되는지 확인해 보세요. 될겁니다.

SVN은? HTTPS로 접근하신다면, 방화벽에 HTTPS의 포트인 443을 추가해 주시면, 접속이 될 겁니다.

[링크] 무료 디자인 리소스를 손쉽게 구하는 방법

마루[maru]님이 정리해 둔, 무료 디자인 리소스 손쉽게 구하는 방법 블로그 입니다.
http://www.designlog.org/2512235

자료가 좋아서, 링크를 걸어 둡니다.

iOS에서 sqlite3 관련 Framework 추가하기.

안녕하세요. iOS 관련 개발을 하면서, sqlite3을 사용하고 있는데, Framework을 등록하지 않아서 Linking Error가 발생했습니다.
에러 내용은 아래에 있습니다.

Undefined symbols for architecture i386:

  "_sqlite3_open", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_prepare_v2", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_column_int", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_column_text", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_step", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_errmsg", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_finalize", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

  "_sqlite3_close", referenced from:

      -[MemoPadAppDelegate readMemoFromDatabase] in MemoPadAppDelegate.o

ld: symbol(s) not found for architecture i386

collect2: ld returned 1 exit status 

위에 나온 것과 같이 sqlite3_open 과 같은 SQLite3관련 함수를 사용하면 Symbol을 찾을 수 없다고 나옵니다.
참 당황스럽더군요. 왼쪽에 보이는  Frameworks에 관련 프레임워크를 넣으면 될 것 같은데, 어떻게 넣는지... Apple의 개발자 사이트를 찾아보니...
먼저 XCode4.0의 왼쪽 Project Navigator에서 제일 위에 있는 프로젝트를 선택합니다.

위 그림처럼 프로젝트 선택하면, 프로젝트에 대한 설정을 변경할 수 있습니다. 거기에 Build Phase부분에서 Link Binary With Libraries 부분에 Sqlite3관련 라이브러리를 등록하면 됩니다.
+로 되어 있는 부분을 선택하면, 아래와 같이 추가할 수 있습니다.

 libsqlite3.0.dylib를 찾으면 됩니다. 아니면, 서치부분에 sqlite3을 입력하면 2개만 나옵니다.
여기서 하나를 선택해서 넣으면 됩니다. (다른 dylib 둘의 차이는 ??? )
 추가를 하고 나면...

라이브러리가 추가 되어 있고, Cmd + b 로 빌드를 하면 에러 없이 빌드 됩니다.

참고되시길~

맥초보를 위한 기초적인 팁 모음( 링크 )

맥을 사용하다 보면, 어려운 것이 많은데요.
정리가 잘 되어 있는 곳이 있어서, 링크를 걸어 둡니다.

맥초보를 위한 기초적인 팁 모음( 링크 )

Project Charter 샘플..

사내 프로젝트용 Charter

회사에서 Symbian에 프로젝트를 할 때, 예제 App을 만들어 보려고 시작한 사내 프로젝트의 Charter 입니다.

 템플릿은 인터넷에서 구했던 것으로 생각나는데, 찾아 보시면 될 것입니다. 내용이 좋아서 약간 수정해서 만들던 것으로 기억합니다.

 필요하신 분들은 아래 링크에서 받으시면 됩니다.

(참고 파일은 요기에서 받으세요. http://blog.naver.com/bjh3958/120056865800)

OnePageReport처럼 거의 한장으로 되도록 만드는 것이 보기도 좋고, 관리도 편리합니다.

• 프로젝트 명: 
• 프로젝트 이름으로 잘 만들어서 보기에 좋고, 무슨 프로젝트인지 호기심이 확~ 나도록 만드는 것이 참여하는 사람들의 기분도 좋게 만드는 것 같습니다.
• 작성자, 문서 버전: 
• 보통 PM이 작성하고, 버전으로 관리를 합니다.. Revision으로 관리해도 되고..
• 프로젝트 개요 및 배경: 
• 뭘하는 것인지, 하게 된 배경이 뭔지를 간결하게 작성하는 것이 좋습니다.
• 프로젝트 목표: 
• 이 프로젝트가 결과물을 내는 과정에 뭐를 중요하게 보는지 적는다. 3가지의 목표를 가지는 것이 좋을 것 같다. 프리젠테이션에서도 3가지로 분류하듯이 이것도 3가지로 하는 것이 이해하기 편할 것으로 생각합니다.
• 주요 산출물: 
• 진행되면서 어떤 결과물들이 나올지 적어야 한다.
• 프로젝트 관리: 
• 뭘로 관리할 것이며, 어떤 단위로할 것인지 명시한다. 이거 명시하면 PM은 꼭 지켜야 한다. 일일업무보고는 안하는 것이 현명.. 하죠.
• 가설, 제약조건, 위험요소: 
• 이 프로젝트를 진행하는데, 어떤 전제조건이 있는지, 제약 조건으로 뭘 둘지, 위험요소는 어떤 것이 있는지 여기서 명시하는 것이 좋습니다.
• 소요자원: 
• 개발자 누가 필요한지, 물 구매해야 되는지 명시한다. 만일 VS2008 Team System이 필요하면 여기에 적어야 합니다.
• 의사소통 및 보고 체계: 
• 보고를 누구에게 어떤 형식으로 할 지, 팀원들과 이야기 해보고, 그 결론을 적는다. 팀원들이 보고를 하므로 팀원들의 합의가 없으면 유명무실해 집니다.
• 마일 스톤: 
• 중간 결과를 언제 어떤 형태로 할지 정해 놓는다. 목표는 잘게 쪼게서 접근하는 것이 최상이다. 그래야 한달마다 전진을 할 수 있다.
• 승인 요건: 
• 프로젝트가 성공하려면 뭣이 만족되어야 하는지 구체적으로 적어야 한다. 'WM에서 잘 돌아야한다' 이런것은 있으나 마나.. 하나 마나
• 승인: 
• 누가 승인하는지, 이름과 사인을 받아야 합니다. 나중에 그 분이 다른 말을 하지 않도록.
• 만약 고객의 요구사항이 변경되거나, 그 분이 일정을 줄이고 싶으시면, 이 승인한 것을 다시 승인해야 하므로, 좀더 현실적으로 방어 할 수 있습니다.
• Sponsor: 
• 이해당사자가 누군지, 그 사람의 확인을 받고 사인을 받아놔야 한다. 사인을 받으면 분명 사본을 달라고 할 것이고, 그러면 그 사람을 그 내용을 검토할 것이고, 요구사항과 승인 요건이 모두 합의되게 됩니다.

큰 회사라면, 당연히 이런 문서가 있거나, ERP, PMS등에 입력 양식이 있을 것이니 그것을 이용하시면 될 것이고, 그것이 없는 중소기업이라면, 내가 기준을 만든다는 생각으로 실제로 잘 쓰이는 문서를 만드시는 것이 좋습니다.

 문서 만드는 것도 일이니, 개발자들이 이 문서를 통해서, 조금이나마 프로젝트하는데, 도움이 될 수 있으면 좋겠네요.

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