달력

092017  이전 다음

  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

*Rough한 일정 계획은 Tough한 일정이 된다

  - 계획은 구체적이어야 함

 

*Backward로 일정 계획을 수립하지 말고 Foward한 방식으로 하라

 - 납기일을 역산으로 일정을 세우지 말것. 일정에 현실성이 없음

 

*분석 단계는 쉬는 단계가 아니다

 - 상류단계가 하류 단계보다 중요하다. 분석 단계 기간을 너무 짧게 잡지 말 것

 

*프로젝트 오픈 이후 안정화 기간을 계획 기간에 반영하라

 - 오픈하면 바로 철수하는 일정으로 잡는 사례가 의외로 많다. 사람 일이 어찌 무 자르듯이 딱 끊어지겠는 가

    안정화 기간을 일정에 반영할 것

 

*투입 인력의 경험과 스킬을 고려하라

 - 사람에 따라 생산성에도 차이가 있다. 사람을 고려하여 일정을 수립할 것

 

*누락된 일정이 없어야 한다

 - 예를 들어 테스트 후에 오류를 수정하거나 코드에 대한 리뷰 등이 일정에 누락되는 경우가 많다

    반드시 해야 할 일에 일정이 없다면 일정은 지연될 수 밖에 없다

 

출처 : 대한민국 개발자 희망보고서 (오병곤 저)

신고
Posted by Tornado tornado

 

▶ 사람 관련 실수
1. 동기 저하 :
 프로젝트 전 단계에 걸쳐 주로 프로젝트 관리자가 팀원들의 동기를 저하시키는 행동을 함.  예를 들어 팀원들과 프로젝트의 목적을 공유하지 않거나 야근을 하고 있는데 자신은 휴가를 가는 등의 행동.

2. 저급 인력 : 인력을 고용할 때 일을 완수할 수 있는 사람보다 가장 빨리 투입될 수 있는 사람을 고용.
3. 문제 인물 방치 : 팀이 프로젝트 관리자에게 가지는 가장 흔한 불만 중의 하나는 문제 팀원에 대해 조치를 취하지 않는 태도임.  일을 잘한다 하더라도 분위기를 흐리면 나의 경우는 팀에서 방출시킴.
4. 영웅적 행동 : '할 수 있다'식 태도를 너무 강조하여 모험적이고 극단적인 일정을 수립한다거나 독단적인 행동을 장려함.  사소한 실수를 진짜 재앙으로 이끌 수 있음.
5. 프로젝트 후반에 인력 추가 : 이것은 관리자들이 저지르는 가장 많은 실수.  임산부 2명이 있다고 아기가 5달안에 나올 수 없는 법.  불에 기름을 붓는 행위.
6. 시끄럽고 붐비는 사무실 : 개발자의 약 60%가 더 조용하고 사적인 사무실에서 일하고 싶다는 설문조사 통계가 있음.  본인의 경우도 지하 1층에서 1년간 프로젝트를 수행한 경험이 있는데 난방이 미흡하고 공기가 탁해 집중도 안되고 건강이 안좋아진 경험이 있음.
7. 개발자와 고객 사이의 마찰 : 마찰은 요구사항 변경, 일정 등의 여러 형태로 나타남.  어떤 형태이건 마찰은 의사소통 단절을 일으키고 이로 인해 요구사항 이해 부족, 제품의 질 저하가 발생하고 나아가 프로젝트가 취소를 고려하게 된다. 회복시간도 더디고 이로 인해 실제 업무 집중하기 어렵게 된다.  한번 마찰이 발생할 때마다 일주일은 후유증에 시달렸음.
8. 비현실적인 기대 : 3개월안에 개발할 수 있다고 근거 없는 말을 관리자가 고객에게 약속하는 경우 고객은 비현실적인 기대를 갖게 됨. 개발자는 거의 초죽음 상태.
9. 효과적인 프로젝트 후원 부족 : 프로젝트 팀에 효과적인 지원은 현실적인 계획을 인정해주거나 개발방법론, 품질보증 지원 등의 개발에 도움이 되는 내용이 필요.  간섭과 강요가 아닌 지원이 필요.
10. 관련자 참여 부족 : 프로젝트 관리자, 프로젝트 팀원, 영업, 고객, 최종 사용자, 경영진 후원자, 기타 이해관계자들이 적극적으로 참여해야 친밀한 협력과 조율이 가능.
11. 사용자 참여 부족 : 스탠디쉬 그룹 조사에 의하면 프로젝트가 성공하는 가장 큰 이유는 사용자 참여임.  특히 프로젝트 초기에 사용자 참여가 없으면 요구사항 파악이 제대로 되기 어렵고 이는 반드시 프로젝트 후반부의 변경을 가져와 일정 차질을 야기함.
12. 실속보다 정치 : 한 연구보고에 의하면 '정치가' 즉 상사와의 관계에 전념하는 사람은 초기에는 상사에게 신뢰를 받지만 시간이 지나면 제일 아래로 떨어진다고 함.  이는 정치를 결과보다 우선하는 태도 때문임.
13. 막연한 기대 : '주어진 일정에 맞게 열심히 일하면 문제 없이 끝날 수 있을겁니다.' 이런 식의 막연한 기대는 프로젝트에서 너무 자주 듣는 말임.  낙관주의를 반대하진 않지만 눈을 감고 대책없는 건 아님.

▶ 공정 관련 실수
14. 지나치게 낙관적인 일정 : 예를 들어 6개월 걸릴 프로젝트를 3개월안에 끝낼 수 있다고 비현실적으로 계획 수립 
15. 불충분한 위험 관리 : 무엇보다 적극적인 위험관리가 필요.  프로젝트란 위험을 줄여 나가는 과정으로 볼 수 있음.
16. 하청업체 실패 : 아웃소싱은 원가절감, 인력부족 때문에 하게 되지만 무엇보다 품질의 저하가 우려되고 또 한가지는 자사인력과의 융화 문제임.
17. 불충분한 계획 수립 : 계획 수립은 반드시 필수 사항.
18. 압력에 따른 계획 수립 포기 : 계획을 세웠다가 일정 문제에 부딪히면 팀은 흔히 그 계획을 포기하거나 변경계획을 세우지 않음.  그러면 그 이후의 일정은 주먹구구식으로 진행됨.
19. 애매한 시작으로 낭비한 시간 : 프로젝트를 시작하기 전 프로젝트 실행 품의, 계획서 승인 등에 보낸 낭비 시간이 너무 많음.
20. 건너 뛴 초기 활동 : '기간이 촉박해서 분석, 설계 시간이 없습니다.' 라고 바로 코딩에 들어가서 나중에 바로 잡는 시간과 비용이 도대체 얼마인가?  분석, 설계 상류의 활동의 오류 하나가 구현 단계의 오류와 비교할 때 100배 차이가 난다고 함. 
21. 불충분한 설계 : '건너 뛴 초기활동'의 특별한 경우가 불충분한 설계임.  설계는 품질보다 편의가 강조되는 현실임.
22. 부족한 품질보증 : 검증과 검토, Walkthrough, Inspection을 안하면 일정은 절약되나 나중에 더 큰 대가를 치루게 됨.
23. 불충분한 관리 감독 : 프로젝트를 계획한 후 제대로 일정, 비용, 품질목표를 달성하는 지를 감독, 감사하는 장치가 필요.
24. 너무 이르거나 지나치게 잦은 통합 : 제품을 최종 인도, 출시하기 전에 각 부문의 결과를 통합해야 하는데 소프트웨어의 버그가 해결되기 전에 출시 시기를 앞당기면 나중에 또 통합작업을 해야 하므로 시간 낭비가 발생.
25. 세부업무 누락 : 작은 업무라고 기록 관리되지 않으면 잊어버리고 나중에 추가 요청이 발생할 수 있음.  대략 말로 요구사항을 이야기하고 나중에 왜 구현이 안되었느냐고 하는 경우가 많음.  이런 업무는 대략 20~30%의 추가 비용을 요구.
26. 나중에 따라 잡을 계획 : 프로젝트를 진행하다 어떤 공정이 지연되면 계획을 조정할 때 추후 일정에서 따라 잡을 수 있도록 하는 경우가 있는데 경험상 따라 잡는 경우는 거의 없음.  계획을 재조정할 때 이런 인식이 필요.
27. 미친듯이 구현하는 개발 : 일단 짜보고 고치기(code and fix development) 전략과 무리한 일정이 조합된 재미있는 표현임.  중요한 건 분석과 설계의 상류 과정임을 간과하고 있음. 

▶ 제품 관련 실수
28. 요구사항 치장 : 사용자가 요구한 사항보다 더 복잡한 기능을 추가하는 경우.  사용자는 개발자만큼 복잡한 기능에 관심이 없음.
29. 기능 변형 : 평균적으로 프로젝트의 요구사항은 생명주기 안에 약 25% 정도 변한다고 함.  당연히 일정도 25% 정도 늘어나게 됨.  따라서 변경관리 활동이 필요하고 변경에 따른 일정이 감안되어야 함.
30. 개발자 치장 : 개발자들은 새로운 기술, 언어를 테스트, 구현하고 싶어함.  실제 프로젝트 상황에서 이런 행동이 발생하는 경우 일정은 지연됨.
31. 조삼모사식 협상 : 예를 들어 고객과 일정을 미루거나 오픈을 연기를 협상하는 경우에 대신 어떤 업무를 슬그머니 추가할 것을 요구하는 사례임.  배보다 배꼽이 더 큰 경우임.
32. 연구중심 개발 : 프로젝트 목표가 다분히 기술적인 목적에 치우쳐 있다면 그런 경우는 소프트웨어 개발이 아니라 소프트웨어 연구임.  기술 프로젝트는 일정을 예측하기 어려움.

▶ 기술 관련 실수
33. 특효약 증후군 : 개발 도구나 기술 한가지 만으로 개발 기간을 획기적으로 단축할 수 있다고 믿는 경우임.

34. 새로운 도구나 방법에 대한 과대평가 : 새로운 개발 도구, 언어가 개발 생산성을 획기적으로 향상시키고 일정을 단축시킬 수 있을 것이라는 과도한 믿음을 갖게 되는 경우.  개발 환경에 적용할 수 있는 지 충분한 검증이 필요함.
35. 프로젝트 도중에 도구 변경 : 프로젝트 도중에 버전을 업그레이드 하거다 새로운 도구를 도입하는 경우에 성공하는 경우는 거의 없음.  학습 기간, 안정화, 필연적인 실수 등을 감안하면 도입에 따른 이익이 크지 않음.
36. 자동화된 소스코드 관리 도구 부족 : 소스관리가 안되어 수작업으로 소스를 통합하거나 소스를 덮어쓰는 경우가 발생.  CVS, 소스카페 등의 자동화된 소스코드 관리가 필요함.

신고
Posted by Tornado tornado
 
신고
Posted by Tornado tornado

1.

브레인스토밍 [ brainstorming ]

 
일정한 테마에 관하여 회의형식을 채택하고, 구성원의 자유발언을 통한 아이디어의 제시를 요구하여 발상을 찾아내려는 방법.
 

원리는,
① 한 사람보다 다수인 쪽이 제기되는
아이디어가 많다.
아이디어 수가 많을수록 질적으로 우수한 아이디어가 나올 가능성이 많다.
③ 일반적으로
아이디어비판이 가해지지 않으면 많아진다.
등의 원칙에서 구할 수 있다. 그러므로 브레인스토밍에서는 어떠한 내용의 발언이라도 그에 대한
비판을 해서는 안 되며,
오히려 자유분방하고 엉뚱하기까지 한 의견을 출발점으로 해서
아이디어를 전개시켜 나가도록 하고 있다. 이를테면, 일종의 자유연상법이라고도 할 수 있다.

회의에는 리더를 두고, 구성원수는 10명 내외를 한도로 한다.

1939년에 미국의 광고회사 부사장 A.F.
오즈번이 제창하여 그의 저서 《독창력을 신장하라》(1953)로 널리 소개되었다.

 

출처 : 네이버 백과사전

 

2.

브레인 스토밍에는 다음의 4가지 규칙이 있다.

1. 다른 사람의 발언을 비판하지 않는다.
2. 자유분방한 발언을 환영한다. 몽상도 좋다.
3. 질보다 양을 중요하게 여긴다.
4. 다른 사람의 아이디어에 무임승차한다.

- 가토 마사하루의《내 두뇌에 날개를 달아주는 생각의 도구》중에서 -

 

브레인 스토밍은 완전한 아이디어를 구하는 것이 아닙니다.
파편과 같은 생각들을 하나로 모아가는 작업입니다.
그러므로 번쩍 하는 아이디어를 파바박 말할 수 있어야지,

너무 뜸을 들이거나 이 말을 했다가 창피를 당하지 않을까 걱정하면,

그때는 이미 브레인 스토밍의 자리에서 벗어나게 됩니다.
번쩍, 할 때 자신있게 말하십시오.

 

츨처 : 고도원에서 온 아침편지 中

 

.

.

.

 

브레인 스토밍을 할 때 유의할 점

 
사이트를 어떻게 활성화 시킬 것인가? 같은
 
처음부터 모호한 주제를 던져 놓고 얘기하기 보다는 
 
현재 상황에 대해서 얘기를 풀고
가장 문제가 되는 또는 구체화 된 점을 찾아낸 후
구체적인 목표나 문제를 가지고 브레인 스토밍을 시작하는게 좋습니다.
 
문제가 모호할 경우
아이디어 도출이 막막해지고
문제에 대한 인식이 제각각 틀릴 수 있어
자칫 논쟁이 될 수 있으므로...
 
어느 정도 깊이... 즉, 문제가 어느정도 구체화 되는 수준 까지는
서로 아이디어를 내는 것이 아닌 의식의 공유가 되는 시간을 가진 후
아이디어를 도출시키는 브레인 스토밍을 해야지만이 서로의 아이디어를 비판하기보다는
기존 아이디어에 첨가가 되는 아이디어가 나오는 바람직한 형태의 브레인 스토밍이 되더군요.
 
ps...
브레인 스토밍은 문제를 해결하기 위한 순수 아이디어를 내기 위한 시간이므로
문제점에 대해 개개인의 의견을 묻는 일반적인 회의와는 혼동되어서는 안됩니다.
 
출처 : 명랑기획자의 비밀연구실
신고
Posted by Tornado tornado
지난 주 금요일 있었던 컨퍼런스 중
9FRUITS MEDIA의 김관주 팀장님의 발표 부분 중
리포트로 정리해 회사에 제출할 내용을 발췌했습니다.
 

 

 

 

“현대 마케팅은 Product의 싸움이 아닌 Perception의 싸움이다.”

 

 이 시간에 가장 관심 있게 들었던 부분은 위의 표와 관련된 사항이었습니다. 아무리 본인이 좋은 서비스를 가지고 있다고 하더라도 제대로 표현을 안 한다면 사람들은 보여지는 정도(실체와 표현의 비례관계)만 인식을 한다는 것입니다.

 저희 회사의 경우 일반인들(기회고객)과 내부사용자(회원)들에게 그 동안 PR, 광고, 캠페인 등 보다 적극적이고 전략적인 표현을 안 했기 때문에 실제 가치나 랭킹에 비해 인지의 정도가 낮다는 결론이 나온다고 생각합니다.

 

 

목표는 단일화 해라.

 

 한 AE가 광고주에게 갑자기 ‘이 걸 받아보십시오.’ 하더니 테니스 공 한 바구니를 던졌다고 합니다. 당황한 광고주가 하나도 받지 못하자. ‘그럼 이 걸 받아보십시오.’라고 하더니 공 하나를 차분히 건네줬다고 합니다. 그리고 이렇게 얘기를 했다고 하는군요.

 

“우리는 광고를 통해 고객들이 우리들의 다양한 얘기를 들어주기를 원하지만

 고객은 하나의 메시지를 듣기에도 벅찹니다.”

 

… 그 후 그 AE는 광고주에 의해 짤리지 않았을까 추측해봅니다. ㅡ_ㅡ);

 

 

즉시 결정하는데 따르는 위험  <  결정하지 않아서 초래될 위험

 

 우리는 미래는 급변하니까 비젼이나 명확한 목표를 가지고 갈 필요가 없다고 얘기합니다. 하지만 무언가 목표를 결정하고 가는 것은 결정하지 않았을 때보다 훨씬 더 빠른 대처가 가능합니다. 목표를 가지고 걷는 사람과 목표가 없이 걷는 사람은 행동과 태도에서부터 틀리며 또 다른 목표가 생겼을 때 방향을 수정하기도 훨씬 더 수월합니다.

 

 

<성공적인 프리젠테이션을 위한 7가지 원칙>

 

1. 목표를 뚜렷하게 세워라.

2. 잘 준비하라.

3. 열정과 자신감을 가져라.

4. 커뮤니케이션 스킬을 갈고 닦아라.

5. 비언어적 요소를 적극 활용하라.

6. 비주얼로 감동시켜라.

7. 리허설을 하라.

 

-> 좋은 프리젠테이션은 ‘연습’과 ‘연습’을 통해서만 나온다.

 

 

------

 

김관주 팀장님의 발표는 나비처럼 날아서 벌처럼 쏘는 발표였다고 생각됨. ^^

신고
Posted by Tornado tornado

기획이란?
어떤 목적을 달성하기 위해 진행되어야 할 업무의 이미지를 묘사하고 전체 또는 세부에 걸친 구상을 정리하여 구체화하고 제한하기에 이르는 작업
(기획자는 문제 해결자이다.)

 

 

기획자의 필수 능력
쓰는 능력/ 조사능력/ 분석능력/ 포장능력/ 말하는 능력/ 자신감과 도전의식

 

 

기획서란?
전략과 아이디어를 전달하는 하나의 매개체로, 무형화되어 있는 정보가치와 전략을 설득적이고 효과적인 언어와 이미지, 색채, 기호 등을 이용한 하나의 종합적 커뮤니케이션의 집합체

 

.

.

.

 

지난 4월 29일날 있었던 컨퍼런스에서

플랜업 이정훈 대표님의 발표 부분 중 일부 발췌했습니다.

 

신고
Posted by Tornado tornado