1. Template 관련

 

1) 다양한PPT 템플렛 다운로드가능 + 슬라이드 노트에 만드는 방법까지 설명된 사이트(ENG)

http://office.microsoft.com/en-us/templates/CT010336615.aspx

 

2) 고퀄 템플렛 다운로드 가능한 곳

http://www.templateswise.com

 


2. 컬러 관련

 

1) PPT빼다, 색깔등등 쓸 때 참고할만한 색 패턴 많은 곳

http://Kuler.adobe.com

 

2) 색깔에 맞춘 사진 컷 찾아주는 곳

http://home.picitup.com/Joomla/

 

3) 역시 PANTONE 참고할만한사이트

http://www.pantone.com/pages/MYP_myPantone/mypantone.aspx

 


3. 아이콘,로고 관련

 

1) PPT용 아이콘(PNG파일) 카테고리별로 searching 가능한 곳

http://www.iconfinder.com

http://office.microsoft.com/en-us/images/?CTT=97

 

2) 각종 로고 eps, ai 등검색&다운로드 가능한 곳

http://www.allfreelogo.com

http://www.seeklogo.com

 

3) 국내 로고들 많은 카페(네이버로고세상)

http://cafe.naver.com/logosesang

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요



처음 제안서를 쓰게 되었을때 어려움을 접하게되는점이 많은것 같다.
많은 제안 작업 중에서 처음 제안서쓰게 되었을때가 가장 기억에 남는데 그때 썼던 제안서를 아직도 보곤 한다. 잊지 않기 위해서인지 아니면 수중한 기억때문인건지...
이거랑 똑같이 쓰면 되니까 걱정 말라던 선임의 말을 믿고 출발했던 제안작업이 수포로 돌아갈때 그렇게 아무렇지 않게 얘기 했던 선임의 호통이 떠오른다.

뭘 잘못 한건지도 모르고 그걸 가르쳐주는사람도 없었으니까.. 나혼자 해결해야만 했었다.
절치부심하고 두번째 제안땐 정말 죽을힘을 다했던거 같다. 시간도 촉박했고 양도 많았다.
이런 저런 컨셉 잡는데만도 하루가 지나갔고 목적있는 제안을 위해서 여러가지 방법의 서브제안들을 만들어갔다.
그리고 하나로 합치고 다시 읽어 보고 다시 수정하고 제안결과는 수주였으나 기술평가(제안서의 평가)에서 조금 못미치는 근소한 점수차이였다.
무엇인가 다른 방법을 써야 하는데.. 항상 이런 생각들이 있었던것 같다.
세번째 부터 제안서 작성은 그렇게 신경쓰지 않았다.
장표 한장에 신경쓰는것보다 큰 틀을 우선 보았다. 제안요청서에 적혀 있는 담당자에게 연락해서 제안을 하게된 배경을 상세하게 물어보고 또 담당자로써의 고충들을 물어보았다. 그땐 그걸 제안요청서에서 못찾았기 때문에 물어본것이였는데 담당자는 좋은 인상을 받았던거 같다.
그리고 제안서를 쓰게 되니 무엇을 찾아서 무엇을 넣어야 하는지 확실하게 알것 같았다.
모르면 물어보면 되는데.. 그 담당자 얘기론 이렇게 물어보는 업체가 한번도 없었다고 한다. 그래서 더 답답했다고 했었다.
내가 원하는것은 이것인데 하나의 문서로(제안요청서) 전달되지 않는다는것이다.
그도 그럴것이 그 많은 제안 요건을 몇십장의 제안요청서로 어떻게 나열하겠는가?
솔찍하게 추가 했으면 하는 제안들도 많이 얘기 해주더라..
담당자와의 연락을 영업팀에 맡겨 제안서의 문서 작성만 하는것이 가장 잘못된 제안작업 인듯 싶다.

오래되지 않았지만 제안서 작업 시 그래도 이정도면 된다 싶은 몇가지의 사항을 정리해보았다.



1. 제안요청서의 담당자에게 물어봐라.
  • 담당자의 인식에 제안업체를 각인시켜야 한다. (이만한 영업이 있을까 싶다.)
  • 제안의 배경과 제안의 목적을 물어봐라.
  • 제안 내용 중 중요도를 체크 해라 (요소별 (기획/디자인/개발...)로 중요도를 물어보면 답은 나온다.)


2. 역지사지
  • 담당자로써의 고충을 본인이 생각해봐라
  • 담당자는 어떤 업체가 들어오는지 중요하지 않다. 어떤사람이 들어오는지가 중요하다. 자신의 생각을 읽는 개발자가 들어온다면 그것이 가장 중요한 제안의 내용이 될것이다. (간혹 정해놓은 업체가 있기도 하다 그것은 그 업체의 개발자들을 알기 때문이다.)


3. 제안의 목적을 가져라
  • 제안 작업 시 가장 중요한것은 제안의 목적이다.
  • 제안의 목적을 다방면으로 리스트업 해라
  • 중요도에 따른 분류로 최종 목적을 잡아라.


4. 추가 제안을 생각해라
  • 제안요청서의 내용만으로 제안서를 작성 한다면 그것은 제안이 아니다. (기본만 하겠다는 업체에게 손을 들어줄 평가위원은 없다.)
  • 추가 제안의 비용산정을 한 후 최종 목록을 뽑아라.
  • 추가 제안에 대한 표시를 해라 (장표에 유치하지만 별표를 한다던지 그냥 넘지지 못하도록 꼭 읽을 수 있도록 표시 해야 한다, 제안서를 평가 하는데 제안서의 디자인을 높이 보는데는 없다. 물론 눈에는 좋겠지만...)


5. 제안서 작업 완료 후 중요도에 따른 표시를 하라
  • 제안서의 모든 장표를 작성한 후 중요도를 체크 하라.
  • 중요도에 따른 표시를 눈에 띄도록 해라

기본적으로 제안서의 작업 보다 제안서 작업 이전의 행동들이 제안을 수주하느냐 못하느냐를 결정 하는것 같다.

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

  1. 2011.04.26 08:13

    역시~! 저번에 지적하신 사항을 잘 정리해주셨네요~^^

  2. 2011.04.27 06:16 신고

    조금더 편하게 읽을 수 있는 글쓰기가 가능했음 좋겠는데.. 그게 안되네요 앞으로 많이 연습해야할듯...ㅋㅋ 도움 되었음 좋겠습니다.


견적의 기본이 되는 S/W기술자 노임단가표 최근버전이다.

전체 증가의 변화도 궁금하여 차트화 하였는데 증가액 만큼의 인력의 대우도 진행되었는지 궁금하다.

대우만큼의 변화는 아니여도 이쪽에 종사하는 분들의 자신의 단가는 알아야 한다.

본인의 위치도 분명하게 알아야 하고 특히 SW기술자 사전 신고제에 대응하는방향도 개인적으로 모색해야할 때이다.

SW 기술자 등급별


2010년도 적용 SW기술자 노임단가 공표

소프트웨어산업진흥법 시행령 제16조(SW기술자의 등급별 노임단가)의 규정에 의한 소프트웨어사업의 대가기준에 적용할 소프트웨어기술자 일 노임단가를 통계법 제23조에 의거 다음과 같이 공표합니다.

【2010년 공표임금: 일 급여 기준】

(단위: 명, 원)

구 분

2010년
조사인원

노임단가

전년대비
증가액

2008년도

2009년도

2010년도

기술사

319

339,988

356,999

358,777

1,778

특급기술자

9,760

300,570

314,773

333,226

18,453

고급기술자

8,071

225,306

228,833

239,085

10,252

중급기술자

9,198

187,566

190,248

188,139

-2,109

초급기술자

11,714

140,198

141,761

146,620

4,859

고급기능사

578

116,845

126,106

140,918

14,812

중급기능사

895

101,158

109,777

110,637

860

초급기능사

990

80,993

86,961

90,599

3,638

자료입력원

1,065

-

67,032

69,680

2,648

* 본 2010년 노임단가는 인원가중평균치임.

* 상기결과는 일급여기준이며, 기본급여+제수당+상여금 등을 모두 포함한 결과임.

* 자료입력원 노임단가의 기본급여는 2009년 48,493원, 2010년 58,795원으로 조사됨.

* 2010년의 월평균 근무일수는 전년도와 동일한 21.6일로 조사됨.

* SW기술자 공인노임단가는 2009년 대비 평균 5.9% 증가함.

<시행일> 2010년 9월 1일부터

2010년 8월 31일

한국소프트웨어산업협회장




참고 :
제경비의 계산방식은 순수 인건비 * 1.1
기술료는 (순수인건비 + 제경비) * 0.2
순수인건비는 노임단가를 참고하시면 되겠구요

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요


http://riemann.tistory.com/102

회원 가입 과정을 정리한 맵으로 전체 프로세스를 한 장으로 요약 정리함 (클릭하면 크게 나옴)


회원 가입은 대부분의 사이트가 기본적으로 진행하는 기초 프로세스이다보니, 이미 정형화된 기본틀을 수용하는 경우가 대부분이다. 그러나 해당 사이트의 특성이나 마케팅적 관점을 고려한다면 전략적 차이를 고려해야 한다.

회원가입에 성공했을 경우, 메인페이지로 이동시키는 것이 좋은지, 회원가입 성공을 알리는 페이지를 한 번 보여주고 메인으로 가게 하는 것이 좋은지를 판단해보자. 만약 회원 가입자에게 쿠폰을 지급하거나 별도의 이벤트를 통해 상품구매를 유발하는 것이 중요한 쇼핑몰이라면 무엇이 좋을까? 혹은 빨리 로그인하여 상품을 구매할 수 있도록 불필요한 과정을 없애고 클릭 수를 줄이는 것이 중요한 전략이라면 프로세스를 어느 지점에서 단축하는 것이 좋을까? 자동 로그인을 해주어서 메인 페이지를 보여주는 것과 메인에서 다시 로그인을 하도록 한 번 더 걸러주는 것은 어떤 차이가 있을까?

각각의 경로마다 이러한 질문들을 던져보는 것이 중요하다.

고객의 입장에서, 사이트의 입장에서, DB 구축의 안정성의 측면에서.. 여러 각도에서 재검토해보면 당연해보이던 회원가입 과정에도 많은 변수가 있음을 알 수 있다.

Posted by 늙은소
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

프로젝트를 망치는 요인 중에 하나가 커뮤니케이션이라고 많이 얘기한다.
커뮤니케이션의 단절은 프로젝트의 심근경색과 같다.
현재는 모르지만 언젠가 크게 터지게 되는 손도 못쓸정도로 위험한 단계까지 가게 된다.





그럴때 우리는 커피 한잔의 여유가 필요하다.
그리고 모든 작업자들과의 대화가 필요하다.
예전에 어떤 기획자에게 이런말을 했다.
관리자가 되려면 먼저 귀를 파라 그리고 입은 신중하게.
열린 귀와 심사숙고한 말로 커뮤니케이션을 하는것 그것이 가장 필요한 사람이 관리자(PM)이기 때문이다.
이런면에서는 나도 어려움을 느낀다.

말을 자르고 내말을 먼저 하는 경우가 더 많았기 때문이다.
언젠가 그런 경우 느끼게 된다.
내가 느꼈던 것처럼 그때의 잘못들을 느끼게 된다.
그럴때 후회하는것보다 지금 준비 하는것이 현명한 방법일것이다.

PM을 위한 커뮤니케이션의 첫번째 방법은 : ' 귀는 열고 입은 신중하게 '

중요한 사항이 발생 할때 회의를 진행 하게 된다.
각 팀별로 주장이 커질때 그 팀들은 선택권을 PM에게 던져준다.
모든 눈들이 PM에게 몰리게 되고 선택을 기다리게 된다.
그럴때 확실한 답변을 해야 한다. PM은 리스크와 프로젝트의 완료를 생각하여 선택을 해야 한다.
그리고 그 선택에 대해서 각 팀/작업자에게 설명을 해야 한다.
왜 이런 결과가 나왔는지를 커뮤니케이션을 해야 한다.

PM을 위한 커뮤니케이션의 두번째 방법은 : ' 이해 할때까지 자세한 설명을 해라 '

커뮤니케이션할때 짧게 얘기 하는것은 상대방에게 호기심을 늦추게 한다.
길게 얘기해서 커뮤니케이션의 장으로 인도를 해야 한다.
어떠한 방법도 좋다 커뮤니케이션의 장으로 인도해라 그가 누가 되었던지 커뮤니케이션을 함으로써 기적을 만나게 될것이다.
그리고 어느정도 인도가 되었을때는 귀를 열어야 한다.

PM을 위한 커뮤니케이션의 세번째 방법은 : ' 커뮤니케이션을 유도 하라 '

관리란 끝이 없다.
어떤일이 발생할지 모르는 상황에서 많은 작업자들과의 커뮤니케이션은 어려운 프로젝트의 활력소가 될것이다.
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

분석단계에서 가장 많은 활동을 하는것이 요구사항의 분석이다.
설문을 통한 방법과 회의를 통한 방법으로 크게 나눌 수 있는데 요즘에는 UT/FGI등을 통해서도 사용자의 요구사항들을 분석하기도 한다.(다양한 방법 중에서도 분석의 효과를 극대화 하고 보고시 근거자료로도 효과가 좋은 FGI 를 많이 사용하는 편이다)
그렇다면 이런 요구사항들의 분석이 끝난 후 산출물은 어떤것들이 있는지 알아보겠다.

▣ 요구사항정의서

ex) 요구사항정의서

요구사항들의 목록화 하여 전체적인 요구사항의 리스트를 확인할 수 있다.
요구사항들의 리스트를 확인하는 문서 자세한 내용은 명세서를 확인함.

→ 구성요소
  • 프로젝트명
  • 작성자
  • 작성일
  • 요구사항분류(업무영역)
    • 기능 요구사항
    • 성능 요구사항
    • 인터페이스 요구사항
    • 운영 요구사항
    • 자원 요구사항
    • 검증 요구사항
    • 테스트 요구사항
    • 문서화(산출물) 요구사항
    • 보안 요구사항
    • 품질 요구사항
    • 유지보수 요구사항
    • 웹접근성/웹표준 요구사항
    • 기타
  • 요구사항ID (요구사항ID는 모든 산출물(문서)에 표시해야 한다. 예를 들어 화면설계서에도 요구사항ID가 있어야 하고 요구사항 추적표에도 있어야 한다.)
▣ 요구사항명세서

ex) 요구사항명세서

요구사항들의 상세 내역들을 확인할 수 있다.


→ 구성요소
  • 업무 영역(요구사항분류 : 요구사항정의서의 요구사항분류 표시)
  • 요구사항ID
  • 요구사항명
  • 개요
  • 상세설명
  • 유형 (요구사항분류)
  • 중요도
  • 난이도(작업의 난이도)
  • 출처 (회의록, FGI/UT, 제안서....)
  • 관련부서(관련 담당자)
프로젝트의 분석단계에서 가장 중요한 산출물 중에 하나인 요구사항정의서와 명세서는 프로젝트의 검수 단계에서도 다시 나타나게 되며 프로젝트가 끝나는 시점까지 요구사항은 늘어날 수 있어 각 문서들의 버전관리(문서 이력)을 관리 해야 한다.
무엇 보다 이런 요구사항들이 모두 적용되었는지 추적표를 작성하여 관리자는 항시 체크를 해야 한다.



Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

  1. 2012.04.10 04:11

    비밀댓글입니다

  2. 2014.01.07 22:39

    비밀댓글입니다


제안서를 처음 접하는 기획자들에게 가장 궁금한것이 제안서의 구성요소일듯 하다.

다양한 방식의 제안서들이 나오고 있지만 기본적인 구성요소는 변하지 않는다.



▣ 그러면 제안서의 구성요소를 알아본다.
  • 제안업체의 일반사항
    • 제안업체명
    • 대표자명
    • 업체의 연혁
    • 인력현황(조직도)
    • 자본규모
    • 사업수행실적(해당 프로젝트와 관련된 수행내역을 표시하여 표시함, 일반과 관련사업수행내역으로 나누어 표시하기도함)
  • 제안목적
  • 사업명
  • 사업기간
  • 사업목적
  • 사업추진체계
  • 개발방법론
  • 일정계획
  • 투입인력계획
  • 상세개발방안
    • 다양한 목적에 대한 개발 방안 나열
    • 추가 개발방안들은 눈에 띄도록 표시함
  • 기술이전계획
  • 품질관리 방안
  • 제안금액(별지)

추가적으로 들어가면 좋은 분장은 다음과 같다.
  • Summary (한페이지에서 목적별 제안 내역을 볼 수 있는 장표)
  • 조견표 (평가항목에 맞게 해당페이지를 한눈에 볼 수 있는 표)
  • 추천사 (관련 프로젝트의 클라이언트의 추천사)
  • 기술지원 확약서 (외부 솔루션이 있는 경우 기술에 대한 지원을 문서화 한다)

무엇보다도 제안서에는 제안서를 보는사람의 마음을 읽어야 한다.
제안서의 내용이 목적 없는 항해라면 그걸 읽는사람은 자신과 맞지 않는 문서를 보게 되는것이다.

목적과 함께 출발하는 제안서의 끝은 마음을 읽는것이다. (가장 힘든부분일듯....)


Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

테스트의 중요성은 완성도에서 나타난다.

가끔 단위테스트에 대한 개발자들의 소월함이 프로젝트의 완성도를 많이 떨이지게 하는 경우가 있다.
이런저런 얘기를 하지만 그건 정말 핑계이다.

관리자(PM)의 측면에서 테스트의 단계에서의 긴장감은 다른때보다 훨씬 높다.
많은 작업자들과의 커뮤니케이션을 해야 하고 그에 대한 판단을 하고 리스크 없는 빠른 조치를 취해야 하기 때문이다.
조금이라도 늦어지면 프로젝트 종료 시점을 지나 지체보상금까지 납부해야 하는 상황이 벌어지기 때문이다.

그렇다면 테스트 단계에서의 완성도를 높일 수 있는 방안은 무엇인지.. 알아본다.

1. 체크리스트를 생활화 하라.
모든 작업에 있어서 체크리스트는 생활화 되어야 한다.
작업의 최소 단위로 나누고 리스트업 하여 작업의 완료 시점을 체크 하고 완료 후 검수까지 진행 되도록 한다.

ex) 체크리스트의 예시

2. 단계별 검수를 진행 한다.
검수는 단계별로 진행해야 한다.
초기 프로젝트의 목표에 대한 이해를 각 작업자들에게 확인 해야 하고 모든 작업자들이 인지되었는지를 확인해야 한다.
그리고 작업자의 검수(단위별 테스트), PL의 검수(단위별 테스트), 테스터의 검수(단위별 테스트/통합테스트), PM의 테스트(전체 주요 요소별 테스트)
각 단위별로 테스트 하게 되면 각 작업의 완성도는 올라가데 된다.

3. 수정사항에 대한 작업자별 이슈카드 작성
작업 진행하게 되면 수정사항이 발생하게 되는데 수정사항을 전체 작업자들에게 공유 하여야한다.
이슈카드 또는 이슈리스트 등을 작성 하여 각 작업자들에게 공유 하고 이에 대한 대응방안을 각 작업자별로 작성 해야 한다.

4. 상세한 시나리오를 작성해라
어떤 테스터가 오더라도 시나리오데로 진행 했을때 무리가 없어야 한다.
시나리오에는 테스트를 할 수 있는 환경(ID/PW, hosts 변경 등)과 테스트의 흐름, 테스트의 결과가 명시 되어야 한다.

ex) 테스트시나리오 예시

5. 테스터는 프로젝트와 별개의 인력을 산정하라.
테스터를 프로젝트를 진행한 인력으로 산정하게 되면 요소별 테스트만 진행 하게 되어 실제 사용자의 테스트가 진행되기 힘들다.
테스터는 프로젝트의 목표만 이해되는 상황에서 실제 사용자의 테스트가 진행되어야 하고 그에 대한 수정사항들을 체크리스트에 작성해야 한다.

이중 가장 중요한 부분은 아무래도 체크리스트를 생활화 하는 부분이겠다.
파일을 공유하는 부분과 문서의 사용법에 대한 부분을 고민했을때 MS-Excel을 사용하여 공유하는것이 가장 좋은듯 하다.

Posted by 김상환

'웹기획 > 테스트' 카테고리의 다른 글

테스트는 완성도에서 가장 중요한 체크포인트  (0) 2011.04.12
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요


사이트 분석(착수 후)

초기 사이트의 분석이 끝나면 제안요청서와 제안서 기술협상에서 발생한 추가사항과 변경사항에대한 분석을 해야 한다.

사이즈 체크뿐 아니라 기능에대한 분석을 해야한다 리스크 발생요인을 체크하고 히스토리관리도 해야한다.

전체 사이트의 분석은 이정도의 수순으로 요구사항 분석 단계로 넘어간다.

이때도 작업 범위에서 벗어 나지 않도록 이해당사자들과의 협의가 중요하다.

상세한 분석과 히스토리관리 리스크 관리가 있어야 협의 시점에서 유리하게 이끌어 갈수 있다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요


예시) 요구사항정의예

보통 프로세스상에서 분석단계에 요구사항정리가 있다. 요즘은 이때 시작한다는 뜻으로 받아드리는것이 좋을듯 싶다.
요구사항은 프로젝트 끝날때까지 변동과 추가가 있기때문이다.
요구사항의 시작은 이해당사자들의 스케줄에 끌려가기 쉽다 분명한것은 우리는 당신을 도와 주는사람이라는 의식을 이들에게 심어줘야 한다는것이다.
믿음이 깨졌을때는 마지막까지 힘들어진다.
...싸워도 이사람과 하면 뭐라도 만들어지겠다는 믿음을 줘야 한다.
그뒤에 스케쥴을 나의것으로 만들어라 그리고 앞에서 리드해라 질문에대한답을 가지고 가라. 이답이 나올때까지 질문을 하라.
 
이해 당사자 마다 다른 질문과 정확한답을 준비해라 그리고 꼼꼼한 회의록을 배포하라.
정해진것은 주간업무보고와 추적표를 공포하라. 그리고 설계단계에 반영하고 요구사항의 ID 를 맞춰 이 기획이 어떤 요구사항의 결과 인것인지를 표시하라.

예시) 요구사항추적표

히스토리 관리도 꼭 필요한 부분이다.
모든 요구사항을 일별, 주별 관리하여 요구사항에대한 보고를 따로 진행해도 좋다.

감리가 있다면 무엇보다도 요구사항추적표를 정리해야 한다.
물론 감리때문이 아니고 검수를 위해서도 요구사항추적표는 필요한부분이다.

검수 시 검수 담당자는 요구사항추적표를 보고 검수를 진행 할테니....


Posted by 김상환

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

이전버튼 1 2 3 이전버튼