밤은 아직까지 시원하네요..^^ 오늘도 짧은 소견 하나 남깁니다. 보통 어떤 프로젝트이던 기획자(혹은 PM 나중에 시간이 되면 PM에 관해서 썰을 풀어보겠습니다.) , 프로그래머, 디자이너 가 기본입니다. 규모가 커질수록 각 파트가 좀더 세분화 되고 TOOL 지원팀등 여러 부가적인 인원이 추가가 됩니다만, 기본적으로 기획자, 프로그래머, 디자이너 이 3가지 범위안에 있습니다. 제목에서 밝혔듯이 거의 대부분 프로젝트(제가 보아본 바에 따르면....^^) 보통 직위는 기획 >= 프로그래머==디자이너 순 입니다. 아무래도 기획자의 입김이 많이 들어가는 편이지요.. 어떤 프로젝트의 기획안이 완성되면 프로젝트와 디자인 팀은 작업에 착수합니다. 이때 기획자의 역활은 배로 비유를 한다면 "조타수와 항해사" 의 역활을 합니다. 프로그래머는 기관사의 역활을 담당한다고 할 수있고 디자이너는 전체적인 외관을 담당한다고 할 수 있지요. 망망대해에서 작은 배 는 어디로 가야될것인가? 이것은 전적으로 기획자에게 달려있습니다. 방향을 아무리 잘 잡았다고 해도, 운전을 잘못하면 가는길은 험난해지고, 또 아무리 운전을 잘 한다고 해도 방향을 헷갈리면 기관사는 죽을맛이고 기껏 잡아놓은 배의 외관도 처참하게 작살나지요.. 그럼 다시 프로젝트로 돌아와서.. 하나의 프로젝트에 기획자가 차지하는 얼마나 될까요? 제 짧은 소견으로는 80%정도를 차지한다고 생각합니다. 이것도 최소로 잡았을때 이야기지요.. 자.. 여태까지 썰을 풀어놓은건 제목이랑 매칭이 안되지요? 이제부터 시작해보겠습니다. 어떤일이던 완벽한것은 없습니다.. 기획서 또한 마찬가지이구요.. 프로그래머는 프로젝트를 진행하다가 기획서를 아무리 봐도 애메한 부분이 나오기 마련입니다. 그럼 기획자와 회의를 가지게 되는데요. 기획자가 보통 직위가 높은경우 가끔 이러한 문제가 발생하는 경우가 있습니다. 예를 들어보지요.. "길동 대리님~~ 이거 아무리 봐도 잘 모르겠는데 어떤식으로 표현하라는겁니까..??" "야. 크라레스! 그것도 모르냐.. 거기 다 써놨잔아.~~ 잘 바바.." "그러니까요.. A가 움직여서 B의 효과를 내는건 알겠는데... 이거 이런식으로 구현하게 되면 전체적으로 어색할거 같은데요..?? " "안 어색해! 그대로 해!!" "......네..일단 해보고 보여드리겠습니다..." .................. 자..위의 예를 보시면 기획자가 직위가 높거나 짠밥이 많은 경우 흔히 발생하는 문제입니다.. 그리고 위와 같은 문제가 발생하는경우 50%는 문제가 생긴다고 볼 수 있습니다..-_-;;; 그럼 이와 반대의 예를 보겠습니다. (기획자가 직위가 낮거나 짠밥이 없는경우..) "야~ 길동아....이거 뭐라고 써놨냐...?" "그대로 써놨는데요.. 크라레스대리님. 그대로 해주시면 되요.." "......야야.. 내생각에 이렇게 하면 조땔꺼 같은데..??? 잘좀 써봐 짜샤..." "그럼 기획이 좀 바껴야 할거 같은데요..." "야..요기서만 쫌 바꾸면 되는데 기획에 뭐 수정될게 있겠냐... 내가 알아서 할께.." ".....네..." ....................... 위와 같은 경우가 발생한경우 역시 문제가 발생할 소지가 다분합니다..-_- 개인이 만드는 프로그램이 아닌 팀 단위 프로젝트에서 한사람의 개인의 생각이 일방적으로 들어가게 되면 상당한 문제를 일으킬 소지가 있기 때문입니다.. 또한 두 경우 모두 서로에게 불만이 쌓일수 있는 경우지요.. 이런 경우를 최대한 없에야 합니다.. 그리고 빼먹을 수 없는 디자이너와의 관계도 있습니다. 디자인 역시 결코 만만한 작업이 아니며 프로그래머와 동등한 노가다를 요구합니다.. (도트나. 매핑 작업 해보신 분은 치를 떨 정도이지요....^^) 기획자나 프로그래머가 의견대립으로 이리저리 컨셉이 바뀌다 보면 디자이너 역시 불만이 쌓이게 됩니다. 밤새 기껏 작업해놓으니.. 쫌 바꼈다고 다시 해오라는 경우가 생기면... 미칠일이죠 단순한 그림 하나만 바뀐다고 생각하는 분들도 계시는데, 디자인이라는것 또한 균형있고 전체적으로 어울리게 만들어야 하기 때문에....예를 들어 색 패턴이 바껴버렸다면.. 그 패턴이 들어가 있는 주변디자인도 바껴야 하기 때문에..패턴 바꿔버린 사람들(기획자이던 프로그래머 이던.) 밤길에 뒤통수 조심해야 하지요.. 위와 같은경우가 아니더라도 기획자와 프로그래머, 디자이너들은 사사건건 대립할 일이 많습니다.. 자칫 잘못하면 3파전 양상으로(?) 가는 경우도 종종 있지요.. 가장 이상적인 모델은 뭐가 있을까요?? 정답은 없습니다..어떤 프로젝트이냐 어떤 스타일의 기획서이냐.. 무엇이 중요한것인지 천차만별이기 때문이지요.. 하지만 이러한 문제를 최소로 줄일려면 정기적인 회의와 서로를 이해하고 배려하는 마음입니다.. 잦은 회의는 의욕상실의 주범입니다.(회의 주체자..주로 대빵들.. 혹은 그 이하 임원들...-_-) 하지만 실제 기획자와 실제 프로그래머, 디자이너들은 정기적인 회의를 갖고 의견조율을 통해 빠른 시간에 결론을 도출해 내야 합니다.. 이것이 차선책이라 감히 말씀드릴수 있겠네요.. 오늘도 밤이 깊었습니다.. ^^ 역시 맥주 한잔 먹고 쓸려니 두서는 어디로 도망갔네요.. 정신없는 글이지만 너그러이 읽어주시고 좋은 하루, 평온한 하루 보내세요~~
밤은 아직까지 시원하네요..^^ 오늘도 짧은 소견 하나 남깁니다. 보통 어떤 프로젝트이던 기획자(혹은 PM 나중에 시간이 되면 PM에 관해서 썰을 풀어보겠습니다.) , 프로그래머, 디자이너 가 기본입니다. 규모가 커질수록 각 파트가 좀더 세분화 되고 TOOL 지원팀등 여러 부가적인 인원이 추가가 됩니다만, 기본적으로 기획자, 프로그래머, 디자이너 이 3가지 범위안에 있습니다. 제목에서 밝혔듯이 거의 대부분 프로젝트(제가 보아본 바에 따르면....^^) 보통 직위는 기획 >= 프로그래머==디자이너 순 입니다. 아무래도 기획자의 입김이 많이 들어가는 편이지요.. 어떤 프로젝트의 기획안이 완성되면 프로젝트와 디자인 팀은 작업에 착수합니다. 이때 기획자의 역활은 배로 비유를 한다면 "조타수와 항해사" 의 역활을 합니다. 프로그래머는 기관사의 역활을 담당한다고 할 수있고 디자이너는 전체적인 외관을 담당한다고 할 수 있지요. 망망대해에서 작은 배 는 어디로 가야될것인가? 이것은 전적으로 기획자에게 달려있습니다. 방향을 아무리 잘 잡았다고 해도, 운전을 잘못하면 가는길은 험난해지고, 또 아무리 운전을 잘 한다고 해도 방향을 헷갈리면 기관사는 죽을맛이고 기껏 잡아놓은 배의 외관도 처참하게 작살나지요.. 그럼 다시 프로젝트로 돌아와서.. 하나의 프로젝트에 기획자가 차지하는 얼마나 될까요? 제 짧은 소견으로는 80%정도를 차지한다고 생각합니다. 이것도 최소로 잡았을때 이야기지요.. 자.. 여태까지 썰을 풀어놓은건 제목이랑 매칭이 안되지요? 이제부터 시작해보겠습니다. 어떤일이던 완벽한것은 없습니다.. 기획서 또한 마찬가지이구요.. 프로그래머는 프로젝트를 진행하다가 기획서를 아무리 봐도 애메한 부분이 나오기 마련입니다. 그럼 기획자와 회의를 가지게 되는데요. 기획자가 보통 직위가 높은경우 가끔 이러한 문제가 발생하는 경우가 있습니다. 예를 들어보지요.. "길동 대리님~~ 이거 아무리 봐도 잘 모르겠는데 어떤식으로 표현하라는겁니까..??" "야. 크라레스! 그것도 모르냐.. 거기 다 써놨잔아.~~ 잘 바바.." "그러니까요.. A가 움직여서 B의 효과를 내는건 알겠는데... 이거 이런식으로 구현하게 되면 전체적으로 어색할거 같은데요..?? " "안 어색해! 그대로 해!!" "......네..일단 해보고 보여드리겠습니다..." .................. 자..위의 예를 보시면 기획자가 직위가 높거나 짠밥이 많은 경우 흔히 발생하는 문제입니다.. 그리고 위와 같은 문제가 발생하는경우 50%는 문제가 생긴다고 볼 수 있습니다..-_-;;; 그럼 이와 반대의 예를 보겠습니다. (기획자가 직위가 낮거나 짠밥이 없는경우..) "야~ 길동아....이거 뭐라고 써놨냐...?" "그대로 써놨는데요.. 크라레스대리님. 그대로 해주시면 되요.." "......야야.. 내생각에 이렇게 하면 조땔꺼 같은데..??? 잘좀 써봐 짜샤..." "그럼 기획이 좀 바껴야 할거 같은데요..." "야..요기서만 쫌 바꾸면 되는데 기획에 뭐 수정될게 있겠냐... 내가 알아서 할께.." ".....네..." ....................... 위와 같은 경우가 발생한경우 역시 문제가 발생할 소지가 다분합니다..-_- 개인이 만드는 프로그램이 아닌 팀 단위 프로젝트에서 한사람의 개인의 생각이 일방적으로 들어가게 되면 상당한 문제를 일으킬 소지가 있기 때문입니다.. 또한 두 경우 모두 서로에게 불만이 쌓일수 있는 경우지요.. 이런 경우를 최대한 없에야 합니다.. 그리고 빼먹을 수 없는 디자이너와의 관계도 있습니다. 디자인 역시 결코 만만한 작업이 아니며 프로그래머와 동등한 노가다를 요구합니다.. (도트나. 매핑 작업 해보신 분은 치를 떨 정도이지요....^^) 기획자나 프로그래머가 의견대립으로 이리저리 컨셉이 바뀌다 보면 디자이너 역시 불만이 쌓이게 됩니다. 밤새 기껏 작업해놓으니.. 쫌 바꼈다고 다시 해오라는 경우가 생기면... 미칠일이죠 단순한 그림 하나만 바뀐다고 생각하는 분들도 계시는데, 디자인이라는것 또한 균형있고 전체적으로 어울리게 만들어야 하기 때문에....예를 들어 색 패턴이 바껴버렸다면.. 그 패턴이 들어가 있는 주변디자인도 바껴야 하기 때문에..패턴 바꿔버린 사람들(기획자이던 프로그래머 이던.) 밤길에 뒤통수 조심해야 하지요.. 위와 같은경우가 아니더라도 기획자와 프로그래머, 디자이너들은 사사건건 대립할 일이 많습니다.. 자칫 잘못하면 3파전 양상으로(?) 가는 경우도 종종 있지요.. 가장 이상적인 모델은 뭐가 있을까요?? 정답은 없습니다..어떤 프로젝트이냐 어떤 스타일의 기획서이냐.. 무엇이 중요한것인지 천차만별이기 때문이지요.. 하지만 이러한 문제를 최소로 줄일려면 정기적인 회의와 서로를 이해하고 배려하는 마음입니다.. 잦은 회의는 의욕상실의 주범입니다.(회의 주체자..주로 대빵들.. 혹은 그 이하 임원들...-_-) 하지만 실제 기획자와 실제 프로그래머, 디자이너들은 정기적인 회의를 갖고 의견조율을 통해 빠른 시간에 결론을 도출해 내야 합니다.. 이것이 차선책이라 감히 말씀드릴수 있겠네요.. 오늘도 밤이 깊었습니다.. ^^ 역시 맥주 한잔 먹고 쓸려니 두서는 어디로 도망갔네요.. 정신없는 글이지만 너그러이 읽어주시고 좋은 하루, 평온한 하루 보내세요~~
네
한줄요약 내가 해줄께 1. 프로그래밍에서 기획이 짱먹는다. 2.기획이 이상한거 시키면 조내 후려패구싶다. 3.결론적으로 봤을 때 프로그래머는 결국 하청업자나 마찬가지다 (ㅅㅂㄹㅁ사장이 돈안줄라고 발악한다)
니가 얘기하는 건 웹에이전시고 여기 들어오는 얘들...플그래머 다 그런지 알고 도망가겠다....찌질스럽게 일하기는...
제대로 된 기획자라면 UML 로 기획안 만들어낼줄은 알아야지.. 걍 대충 파워포인트로 밍기적대고 날로 먹으려하는게 대부분의 기획자들이지..
팀구조; 현실과 이상의 괴리; 항시 발생; 그러나 항시 극복해야죠;