반응형
기획자와 개발자는 개와 고양이 같다라는 얘기를 많이 해.
기획자는 개 개발자는 고양이.
기획자는 개새끼 개발자는 고양이새끼 ?
둘이 맨날 투닥거리는 이유에 대해서 생각해 볼까해.
일단 기획자얘들은 집단극화가 일상적으로 벌어지는 집단이야. 원래 아이디어는 무궁무진하고 물리적 제한을 받지 않잖아.
거기다가 혼자서 생각할적에는 매우 어렵게 생각되던 기능 도, 여럿이 머리를 맞대면 굉장히 쉬워보이는 효과가 생겨.
왜 그런거 있잖아. 들어갈때는 똥누러 가는 마음이였는데, 서로서로 으쌰으쌰 하다보니까. 어느덧 파티장으로 바뀌는 거. 세상 모든게 내것 같고,
모든걸 다 구현할 수 있을거 같고 다 잘될거 같지. 아싸!! 하면된다...
이걸 집단극화라고 하는데, 이거 땜에 기획자들끼리 기획하면 비합리적인 일정과 기능추가가 이루어지는게 다반사다.
거기에 팀장이 그러한 마인드라면 정말 두손 두발 들게 되지.
이게 기획서라고 떡하니 넘어오면, 개발자는 황당하지.
온갖부정적인 단어의 향연이 벌어진단 말이야. 이건 이래서 안되고 저건 저래서 안되고 그건 그래서 안되고.
마찬가지로 개발자들도 집단극화 현상이 벌어질 수 있다. 이경우 기획자와는 반대 방향의 집단극화가 발생하는 거지.
글고 개발자들은 다른 대안이 있는 것 같아도, 일단 그걸 숨기는 경향이 있지. 왜 ? 개발자는 근본적으로 땜빵스러운걸 싫어 하거든. 땜빵하는거 치고 문제 안생기는 경우가 별로 없기도 하고..
그래서 저것도 안되고 이것도 안되고 그것도 안된다고 한다.
이제 최초 기획서를 누더기로 만들어서 기획팀이랑 얘기를 한다. 당연히 한판 붙게 되어있다. 기획자들 딴에는 졸라 개고생해서 만든 기획서를 누더기로 만든거니 열받고, 개발자는 개발자대로 우리가 슈퍼일개미삼? 이런 엿같은 기분인거고.
이때 팀장의 역할이 중요한데, 일반적으로 팀장은 기획자와 함께 집단극화를 경험한 경우가 많기 때문에 기획자들의 편이 되어서 결정하게 되는 경향이 많다. 뭔가 잘못되었다는 것은 날밤을 세고 드디어 "일정역산"이라는 걸 하게 되면서 슬슬 느끼게 되지만 루비콘강을 건넌 뒤지.
팀장은 이러한 집단 커뮤니케이션의 특성을 이해하고 있어야 한다. 그래서, 집단극화가 되지 않도록 중재하는 역할을 해야 한다. 예컨데 기획팀 회의에 들어 간경우 부정적의견을 내는 역할을 자청해야 한다. 그게 정말 쓸만한 기능이니 ? 좋은 기능이긴 한데 이상적인 기능 아니니 ? 이런거지. 으샤 으쌰 한달안에 다 끝내자 파이팅 하는게 팀장의 역할이 아니란 거야. 반대로 개발팀 회의에 들어가서는 긍정적 시그널을 보내는 역할을 자청해야 한다. 이러이러한 심플한 다른 대안들도 있는데 한번 고려해 보죠.!! 이를테면 다들 예 하는데 아니오 라고 맨트한번 던져주는게 팀장의 역할이라는 거지.
글고 팀을 구성할때, 개발팀을 기획팀보다 2~2.5배 정도 크게 만들어라. 업무가 밑으로 내려가면 그 복잡도가 증가한는 경우가 대부분이다. 기획자 2명이 생각하는 복잡도라는 것은 실제 개발자들이 일을 하게 되면 4배 이상의 복잡도가 된다는 거지.
복잡도가 늘어나면 어떻게 해결해야 하지 ? 상호 커뮤니케이션으로 해결할 수 밖에 없다. 상호 커뮤니케이션이 원할하려면 각 개발자에게 어느정도의 여유시간이 주어져야 한다. 여유시간이 주어질려면 합리적인 일정, 충분한 수의 개발자가 필요한거지.
물론 이러한 상호커뮤니케이션 없이도 제품은 만들어질 수 있다. 하긴 이런 커뮤니케이션을 시간낭비라고 생각하는 얘들도 있긴 하더구나. 이럴 경우 협업을 해야 하는 부분이 빵하고 터지고, 막판에 땜빵 프로젝트가 되기 시작하는 거다. 개발자에게 시간적 여유를 주어야 한다는 것은 생각의 리프레쉬 같은거 외에도 원할한 협업을 위한 것이기도 하다는걸 이해하고 있어야 한다는 얘기다.
기획자는 개 개발자는 고양이.
기획자는 개새끼 개발자는 고양이새끼 ?
둘이 맨날 투닥거리는 이유에 대해서 생각해 볼까해.
일단 기획자얘들은 집단극화가 일상적으로 벌어지는 집단이야. 원래 아이디어는 무궁무진하고 물리적 제한을 받지 않잖아.
거기다가 혼자서 생각할적에는 매우 어렵게 생각되던 기능 도, 여럿이 머리를 맞대면 굉장히 쉬워보이는 효과가 생겨.
왜 그런거 있잖아. 들어갈때는 똥누러 가는 마음이였는데, 서로서로 으쌰으쌰 하다보니까. 어느덧 파티장으로 바뀌는 거. 세상 모든게 내것 같고,
모든걸 다 구현할 수 있을거 같고 다 잘될거 같지. 아싸!! 하면된다...
이걸 집단극화라고 하는데, 이거 땜에 기획자들끼리 기획하면 비합리적인 일정과 기능추가가 이루어지는게 다반사다.
거기에 팀장이 그러한 마인드라면 정말 두손 두발 들게 되지.
이게 기획서라고 떡하니 넘어오면, 개발자는 황당하지.
온갖부정적인 단어의 향연이 벌어진단 말이야. 이건 이래서 안되고 저건 저래서 안되고 그건 그래서 안되고.
마찬가지로 개발자들도 집단극화 현상이 벌어질 수 있다. 이경우 기획자와는 반대 방향의 집단극화가 발생하는 거지.
글고 개발자들은 다른 대안이 있는 것 같아도, 일단 그걸 숨기는 경향이 있지. 왜 ? 개발자는 근본적으로 땜빵스러운걸 싫어 하거든. 땜빵하는거 치고 문제 안생기는 경우가 별로 없기도 하고..
그래서 저것도 안되고 이것도 안되고 그것도 안된다고 한다.
이제 최초 기획서를 누더기로 만들어서 기획팀이랑 얘기를 한다. 당연히 한판 붙게 되어있다. 기획자들 딴에는 졸라 개고생해서 만든 기획서를 누더기로 만든거니 열받고, 개발자는 개발자대로 우리가 슈퍼일개미삼? 이런 엿같은 기분인거고.
이때 팀장의 역할이 중요한데, 일반적으로 팀장은 기획자와 함께 집단극화를 경험한 경우가 많기 때문에 기획자들의 편이 되어서 결정하게 되는 경향이 많다. 뭔가 잘못되었다는 것은 날밤을 세고 드디어 "일정역산"이라는 걸 하게 되면서 슬슬 느끼게 되지만 루비콘강을 건넌 뒤지.
팀장은 이러한 집단 커뮤니케이션의 특성을 이해하고 있어야 한다. 그래서, 집단극화가 되지 않도록 중재하는 역할을 해야 한다. 예컨데 기획팀 회의에 들어 간경우 부정적의견을 내는 역할을 자청해야 한다. 그게 정말 쓸만한 기능이니 ? 좋은 기능이긴 한데 이상적인 기능 아니니 ? 이런거지. 으샤 으쌰 한달안에 다 끝내자 파이팅 하는게 팀장의 역할이 아니란 거야. 반대로 개발팀 회의에 들어가서는 긍정적 시그널을 보내는 역할을 자청해야 한다. 이러이러한 심플한 다른 대안들도 있는데 한번 고려해 보죠.!! 이를테면 다들 예 하는데 아니오 라고 맨트한번 던져주는게 팀장의 역할이라는 거지.
글고 팀을 구성할때, 개발팀을 기획팀보다 2~2.5배 정도 크게 만들어라. 업무가 밑으로 내려가면 그 복잡도가 증가한는 경우가 대부분이다. 기획자 2명이 생각하는 복잡도라는 것은 실제 개발자들이 일을 하게 되면 4배 이상의 복잡도가 된다는 거지.
복잡도가 늘어나면 어떻게 해결해야 하지 ? 상호 커뮤니케이션으로 해결할 수 밖에 없다. 상호 커뮤니케이션이 원할하려면 각 개발자에게 어느정도의 여유시간이 주어져야 한다. 여유시간이 주어질려면 합리적인 일정, 충분한 수의 개발자가 필요한거지.
물론 이러한 상호커뮤니케이션 없이도 제품은 만들어질 수 있다. 하긴 이런 커뮤니케이션을 시간낭비라고 생각하는 얘들도 있긴 하더구나. 이럴 경우 협업을 해야 하는 부분이 빵하고 터지고, 막판에 땜빵 프로젝트가 되기 시작하는 거다. 개발자에게 시간적 여유를 주어야 한다는 것은 생각의 리프레쉬 같은거 외에도 원할한 협업을 위한 것이기도 하다는걸 이해하고 있어야 한다는 얘기다.
'Stigmatized. > Essay' 카테고리의 다른 글
겨울 바탕화면 사이트 (0) | 2009.12.31 |
---|---|
시간은 금이요 (0) | 2009.11.05 |
사람답게 살아보기 (0) | 2009.11.05 |
프로그래머는 세계관이 좁은 경우가 많다. (0) | 2009.11.05 |
음. 드디어.. (0) | 2009.11.03 |