을처기님 찾아주셔서 감사합니다.
전 그걸 기획서라고 부르지 않습니다.
'땡깡서'라고 부르죠.
을처기님께서 일하던 때에 기획자들이 밑에 사람들에게 업무를 가르치니 변할리가 없지요. 모든 기획자들이 그렇지는 않겠지만, 제가 본 몇몇 기획자들은 좀 그랬습니다.
그리고 이번화에서는 자체 개발자들만의 회의였습니다.
음.... 가장 기억에 남는 게 동작 애니메이션 땡깡서였던 것 같습니다.
저같은 경우에는 상황에 맞는 동작을 얻으려고 '테니스 왕자'라는 애니메이션을 밤까지 이틀 넘게 보면서 동영상 연속 캡쳐로 동작들의 이미지를 수집하고 부연 설명을 적어서 보낸 기억이 납니다만, 다른 팀은 그저 한줄의 글로 기획서란 이름의 땡깡서로 넘기더군요.
보통 기능을 구현하는 툴을 만들기 위해서는 기능에 필요한 조건이나 예외처리 데이터 속성, 조건 인자등이 필요합니다.(해보셨다니 아시겠군요.)
가장 빠른 방법은 제일 먼저 프로그래머에게 물어보고 기획서를 써나가는 것이 가장 빨랐습니다. 약간 번거롭기는 해도 시간이 지나면 오히려 더 빠르더군요.
프로그래머의 입맛에 맞는 기획서를 만들어 주는 거니까요.
그래서 서두에 밝힌대로 기획자가 1시간만 더 투자하면 다른 작업자들의 2-3일을 아낄 수 있다고 한 것입니다.^^;
네... 요즘도 그러는군요.
아마 조금더 '진행'이 된다면, 개발자 문제도 대두되겠는데요. DB를 우습게 아는 개발자들이 의외로 많아서요. 반면에 3D의 무슨 효과 같은걸 대단한 '스킬'로 알고 있는 사람이 많거든요.
객체지향 이론에도 나와 있지만, View는 개선할 수 있는 사항이지만 Data는 개선이 불가능하다고 봐야 합니다. 제 느낌에는 기획자들이 저정도면, 프로그래머 그룹에서도 View만 신경쓰고 DB는 뒷전일 수도 있거든요.
이 글에서 언급한 '로비'는 일종의 '뷰'에 해당되기 때문에, 사용자 DB가 제대로 구축되었다면... 로비는 어렵지 않게 구현되어야 합니다. 최초의 3D 온라인 게임인 에버퀘스트는 머그(MUG)의 뷰를 3D로 한것에 불과합니다. 게임의 DB가 제대로 구축되어 있다면, 눈에 보여지는 내용이 2D이건 3D이건 큰 상관이 없다는 것을 보여준 실례입니다.
하여간에... 이 글 읽으면서 정말 옛날 생각이 새록새록 납니다. 게다가 암울하기도 합니다. 다시 기회가 주어진다면 한번 더 그 세계로 가려고 하거든요.
Comment ' 7