 |
|
|
 |
|
|
«
2009/01
»
| 일 |
월 |
화 |
수 |
목 |
금 |
토 |
| |
|
|
|
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 |
31 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Get RSS Page RSS2.0
Powered By
Skin By
|
|
|
|
|
|
|
|
|
얼마전 NC Developer Conference 에서 리니지2팀의 박일이 발표했던 강연을 듣고 스크럼에 대해서 알게 되었다. 그래서 스크럼 번역서(스크럼/Agile Software Development with Scrum/인사이트/박일,김기웅 옮김)를 구입해서 읽어 보고 있다.
그런데 스크럼에서 소개하는 방법과 원칙이 내가 최근 1~2년 새애 느끼던 것과 흡사한 것이 너무 많다. 마치 영웅문의 양과가 구양진경을 읽고 '아니 이럴수가 이렇게 내 생각이 잘 정리되어 있다니!'하고 느낀 기분이랄까.
구체적으로 뭐가 그렇게 흡사하냐면:
1. 소프트웨어 개발은 명확하게 계획하는 것이 불가능하다.
2. 요구사항(혹은 명세서)은 개발이 진행되면서 계속해서 변한다.
3. 릴리즈를 하지 않으면 지지부진하다. 사람들은 릴리즈를 본 후에야 실제로 우리가 무엇을 했는지를 깨닫게 된다.
4. 빠른 피드백으로 제품을 수정해 나가야 한다. 빠르면 빠를 수록 좋다. 그래서 릴리즈 주기는 짧을 수록 좋다.
5. 릴리즈된 제품을 고객이 확인하면, 요구사항 목록이 대거 추가되고, 빠지고, 우선순위 변동이 일어난다.
그 외에도 소소하게 공감되는 게 꽤 된다. 그리고 책에서 소개하는 기법 중에 가장 기본적이고 간단한 것이 일일 회의이다. 이것은 매일 같은 시간에 모든 팀원이 한 자리에 모여 동그랗게 둘러서서 15분 이내로 하는 회의인데, 팀원들은 돌아가면서
1) 어제 무엇을 했는지
2) 오늘은 무엇을 할 것인지
3) 일이 제대로 진행하기 어려웠던 문제점이 무엇이 있었는지
를 말하는 것이다. 관리자를 포함한 모든 팀원이 현재 어떤 상황인지를 파악하기 위한 목적인데, 오늘 프로그램파트만을 대상으로 한 번 해봤는데 효과가 괜찮았다. 서로 이야기 해 주면 금방 끝날 것을 삽질 하던 것들이 발견되었다.
몇 개나 있었는데, 그 중 한가지는: "내가 어제 토템 작업을 하느라 테이블을 고쳤는데, 테이블이 사라졌더라고. 그래서 내가 예전 파일 다시 받아서 고치고 있어."->"아, 그거 내가 어제 파일명 바꿔서 그래. 다른 이름으로 파일이 있을 거야. 테이블도 이쁘게 고쳤어."->"없던데?"->"헉, 퍼포스애 add 안했다."
맨날 커뮤니케이션이 부족하다고 말하기 전에, 실천한번이 중요하다는 생각이 들었다. 스크럼이라는 개발 방법론은 애자일에 있는 선입견과 다르게, 아주 단순한 방법론이다. 위 동영상에서도 설명하는데 8분 걸린다. XP 와 같이 어렵지 않은 것 같다.
그런데 한 가지. 이 방법론 자체는 제작 진행용이다. 일의 성격을 규정하거나, 제품의 품질을 직접적으로 올리기 위해서 XP와 같이 쓰는 팀도 많다고 한다. 또한 중요한 것은 그 무엇보다도, 스크럼 마스터 및 개발팀에서 일하는 팀원들의 열정과 재능이라고 한다. |
|
Track this back : http://whitejames.com/trackback/709
| |
|
 |
|
|
|
Track this back : http://whitejames.com/trackback/697
| |
|
|
|
오. 컬러레이져가 이제 대중화되려나 보다.
라숩 블록에서 보고 나도 체험단에 응모해 봄. |
|
Track this back : http://whitejames.com/trackback/675
| |
|
|
|
마케팅 요약
[마케팅 전략 수립 과정]
1. 소비자 분석
2. 시장 분석
3. 자사 및 경쟁기업 분석
4. 유통 채널 분석
5. 마케팅 믹스 개발
6. 경제성 평가
7. 마케팅 계획의 수정
[소비자 분석]
1. 요구(need)의 범주는 어디까지 인가?
2. 누가 구매하고 누가 사용하는가?
3. 어떤 구매 과정을 거치는가?
4. 고관여 상품인가, 저관여 상품인가?
5. 시장을 어떻게 세분화 할 것인가?
[시장 분석]
1. 관련 시장은 무엇인가?
2. 상품이 상품 수명 주기상 어느 위치에 있는가?
3. 업계 내의 주요 경쟁 요인은 무엇인가?
[자사 및 경쟁기업 분석]
1. 자사의 SWOT과 경쟁기업의 SWOT을 어떻게 비교할 것인가?
2. 주요 기업들의 시장 점유율은 어느 정도인가?
3. 경쟁 상품에 비해 자사 상품은 어떻게 지각되고 있는가?
4. 경쟁 사품들에 맞서는 자사 상품의 위치는 어떠한가?
[유통 채널 분석]
1. 어떤 방법으로 상품을 소비자에게 전달할 것인가?
2. 각 채널에서 유통업자들이 얻는 마진은 어느 정도인가?
3. 각 유통채널의 지배세력은 누구인가?
4. 유통채널로서 인터넷의 역할은 무엇인가?
[마케팅 믹스 개발]
1. 상품(Product)
2. 유통(Place)
3. 판촉(Promotion)
풀 전략과 푸시 전략
광고: 도달률과 노출빈도
4. 가격(Price)
[경제성 평가]
1. 비용은 고정 비용인가, 변동 비용인가?
2. 손익 분기점은 어디인가?
3. 투자액을 회수하는데 소요되는 기간은 얼마나 되는가?
[마케팅 계획의 수정]
1. 어디를 수정할 것인가?
무엇을 수정하더라도 모든 항목을 재검토해야 할 것이다.
|
|
Track this back : http://whitejames.com/trackback/655
| |
|
|
|
펌: http://www.fsforum.net/blog/tag/%EA%B2%8C%EC%9E%84%EA%B8%B0%ED%9A%8D?TSSESSION=555243d33d51c3d85f7802ef2751b5ff
게임 기획에서 발생하는 최악의 7가지 실수
원문: The 7 Worst Game Design Mistakes
실수 #1. 성공한 게임과 비슷하게, 하지만 더 낫게 만든다.
혁신적인 장르를 만들어내는 것은 단지 염원이 될 것이며, 타 게임들과의 경쟁력을 잃게 될 것이다.
실수 #2. 다른 게임을 배낀다.
배끼는 것이 때로는 유용할 수 있을지 모르지만, 그 성공은 오래가지 못할 것이다.
실수 #3. 다른 게임으로부터 배끼지 않는다.
100% 창조적인 게임을 만드는 것보다는 다른 게임의 장점들을 채택하라.
실수 #4. 최대한 변화에 유연한 기획을 한다.
"제 게임에서는 모든 것이 가능합니다"라는 개발자의 노트에는 항상 그 기능에 대해 "거의 개발되었음"이라고 적혀 있을 것이다.
실수 #5. 최대한 변화를 제한 시키는 기획을 하라
다 만들어 놓은 게임에 대해 사람들이 불평 불만을 한다해도 손을 놓고 있을 수 밖에 없을 것이다.
실수 #6. 사소한 것들은 그냥 잊어버려라
그냥 지나칠만한 조그마한 사항들에 대해 새심한 관심을 기울인다면 플레이어들은 게임중에도 몇번이나 감탄사를 내지를 것이다.
실수 #7. 핵심 부분은 잊어버려라
메인 기획은 가장 먼저 완성되어야 한다. 하지만 더욱 중요한 것은 그 기획안이 충분히 재미있어야 한다는 것이다.
종합
핵심적인 사항에 집중하되, 작고 사소한 것들에 대해서도 잊지 않아야 한다. 또한 게임을 배껴서는 안되겠지만, 대신 그것들로부터 배울 점을 얻어내야 한다. 마지막으로 변화하는 것들에 대해 유연하게 대처할 수 있는 투명한 기획이 되어야 한다.
|
|
Track this back : http://whitejames.com/trackback/652
| |
|
|
|
|
|
Track this back : http://whitejames.com/trackback/645
| |
|
|
|
게임 기획이 처음부터 완벽할 수는 없다.
특히 코어 메카닉은 플레이 해 보기 전에는 재미의 정도를 알기가 어렵다.
따라서 먼저 구현하여 플레이 테스트를 한 후,
리테이크 & 피드백의 단계를 반복하게 된다.
여기서 가장 중요한 자원은 '시간'이다.
개발은 일정 시간 이내에 결과물을 만들어 내야만 출시가 가능하기 때문에
이 리테이크를 무한정 반복할 수는 없다.
질문: 일정 시간 이내에 좋은 품질의 결과물을 내기 위해서는 어떻게 해야 할까?
방안:
1. 테스트 => 리테이크 의 시간을 줄인다.
2. 리테이크가 많이 필요하지 않은 훌륭한 기획서를 쓴다.
즉, 소요 시간 = 초안작성시간 + 리테이크 시간 x 리테이크 횟수
여기서 중요한 것은, 리테이크 시간을 줄이는 것은 기본적으로 프로그래머의 구현에 시간이 많이 소요되기 때문에 줄일 수 있는 한계가 있다는 것이다.
이에 비해 기획서를 쓸 때 기획자의 머리 속에서 일어나는 리테이크는 그 시간이 훨씬 빠르기에 (구현보다 느리다면 문제가 있는 거겠지?) 기획서의 퀄리티를 올려서 절약할 수 있는 개발 시간이 훨씬 큰 것 같다.
따라서 리테이크가 적게 필요한 기획서를 쓸 수 있는 능력이
훌륭한 기획자에게 중요한 자질 중 하나일 것 같다.
|
|
Track this back : http://whitejames.com/trackback/633
| |
|
|
|
|
|
Track this back : http://whitejames.com/trackback/623
| |
|
|
|
|
|
Track this back : http://whitejames.com/trackback/604
| |
|
|
|
|
|
Track this back : http://whitejames.com/trackback/598
| |
|
|
|
|
|
|
|
|
|
|
