2010/03/15 23:55
나만의세상
난 '개발자'다.
국제표준용어-_-로 개발자와 기획자가 어떤 뜻인지는 모르겠으나, 적어도 한국어를 모국어로 쓰는 사람들 가운데, IT라는 산업에 종사하는 사람들 사이에는, '기획자'는 수요자로 표현되고 '개발자'는 공급자로 표현된다. 진정한 수요자는 유저일텐데 개발 현장에서는 이상하게도 그렇게 표현되곤 한다.
즉, 기획자가 만들어달라고 요구하는 것을 구현해 주는 것이 개발자라고 표현되는 것이다. 맘에 안들지만 받아들이자..
근데 왜인지 이 '기획자'와 '개발자'의 영역 구분은 매우 모호하다.. 그래서 갈등을 유발하기도 한다..
뭐가 모호한가?
소프트웨어 개발 프로젝트는 대략 다음의 과정을 따라 진행된다. (엔지니어링의 결과물이 최종산물이 되는 영역에서는 보통 대동소이하지만 일단 소프트웨어 개발로 국한하자)
문제의 발견 > 요구사항(니즈)의 정립 > 실현방안의 수립 > 소프트웨어 설계 > 구현 > 테스트 > 출시
'니즈의 정립부터 소프트웨어 설계까지'를 보통 '설계'라 부른다. 그리고 개발자들은 이건 자기의 할일이라고 생각한다. 그래서 적극적이다. 이 때 참여하지 않으면 나중에 피똥싸는거 한두번 경험한게 아니니...
근데 보통 '문제의 발견부터 실현방안의 수립까지'를 보통 '기획'이라 부른다. 여기서 모호함이 드러난다. 기획의 상당부분을 개발자들은 설계과정이라 생각한다는 거다. 물론 개발자들도 그 부분을 기획이라고 부르긴 한다. 스스로 프로젝트를 대함에 있어 모호함을 안고 있는거다. 기획자에게 맡겨야 하는 일이면서 자기가 해야 하는 일이기도 하다. 그러다 보니 개발자는 허구헌날 기획자랑 싸운다. 자기가 한 설계가 아니니 신뢰를 못하는 경우도 많다.
개발자와 기획자는 서로 '말귀를 못 알아들는다'고 하며 성질만 부린다.
밥그릇 싸움인듯 하지만 사실은 의사소통의 문제인 것이다.
개발자가 고자세로 나오니 기획자는 저자세로 파고 들수 밖에 없다. 이 과정에서 거의 항상 잊혀지는건 '니즈'다. 소프트웨어의 진짜 수요자인 고객으로 부터 발생하는 유일한 기획요소인 '니즈'가 간과된채 기획이 수정되고 소프트웨어 설계가 이루어진다. 대부분의 소프트웨어 개발 프로젝트가 성공하지 못하는 이유의 큰 부분이 여기에 있다. 사용할 사람들에게 어필하지 못하는 결과물을 만들게 되는거다.
결과가 나온뒤에 되돌아보며 개발자 대부분은 기획을 탓한다. '왜 쓸데없는걸 만들어달래서...' 이런식이다.
참으로 바보같은 생각이다. '니즈'를 잊혀지게 하는 가장 결정적인 역할을 한 사람은 바로 개발자다. '문제발견'단계에서는 보통 아무것도 하지 않은(문제를 감지조차 못한) 개발자인 주제에 이미 발견된 문제로부터 괴발개발이나마 니즈를 적어 들고 나타난 기획자에게, 극렬히 저항하며 실현방안 수립단계를 뒤엎었기 때문에 '니즈'는 뒷전으로 밀려나는 거다. 니즈 정립부터 설계까지의 과정에서 양(positive)의 피드백을 하지 못하고 심지어 부(negative)의 피드백 조차 아닌, 그저 역행만을 만들어 냈기 때문인거다.
반성해야 한다. 어떤 문제로부터 어떤 니즈를 발견해서 가져온 기획안인지 생각은 해 보았는가? 그들(기획자)은 기술적 기반이 취약하다는걸 전제로 개떡같이 말해도 찰떡같이 새겨 들으려 노력하며 들어본 적이 있는가? 모호하게 반복되는 용어나, 과도한 부하를 유발하는 비지니스 로직을 무턱대고 성질부리며 반송하지 않고, 교정해주거나 대안을 제시한 적이 있는가? 설계과정에 '참여'하고 있는가, '딴죽'걸고 있는가... 이 기획이 '쓸데없는 것'이라면 어떤게 '쓸모있는 것'인지 제시해 본적 있는가?
개발자들은 기획자들이 구사하는 '기획어'를 모른다. 생각하고 대들어라.
그럼 뭐... 기획자는 잘했나? 기획은 피해자라고?
웃기지도 않은 소리다. 개발자가 고자세로 나오는 이유도 모른채 기획의 관철만을 위해 일단 저자세로 파고드니 본인조차 '니즈'를 잊는거다. 우리가 가진것이 무엇이며, 기지지 못한 것이 무엇이며, 그래서 지금 만들어 가지려 하는것이 무엇인가를 절대 잊지 말아야 하는 것이 기획자의 업무인 것이다. 개발자가 자꾸 땡깡부려서 프로젝트가 산으로 간다고? 그걸 막지 못했다면 기획자도 업무 태만이고 역량 부족인거다. (난 아니라고 믿고 싶지만) 혹시, 정말로 '니즈'가 결여된 상상의 나래로 만든 기획안은 아니었는가하는 점 역시 돌이켜 반성해야 한다.
개발자가 들이박으면 기획자들은 보통 겁을 먹고 수그리는데, 왜그런가? 기술적 기반이 취약해서다. 개발자가 안된다고 하면 그냥 진짜 안되는게 아니다. 직접 코드를 작성하거나 데이터플로우를 설계할 정도로 기술적 소양을 갖출 필요는 없다. 적어도 SQL정도의 데이터를 보는 방법이라던가, 비지니스 로직이 품게 될 복잡성에 대한 추측 정도는 공부해 두란 말이다. 그정도를 생각할 수 있다면 개발자가 안된다고 하는 기획안을 작성하지 않게 될 것이며, 설령 개발자가 안된다고 뻗대도 소신껏 관철시킬수 있는 근거를 확보하게 될 것이다. 그리고 개발자들이 구사하는 '개발어'를 서서히 이해하게 될 것이다. 기획자들이 공부해야 하는건 ppt 작성 기법이 아니다. 메모장으로 만든 기획안이 ppt보다 훌륭할 수 있다.
결국 의사소통의 문제다.
길거리에서 한국어를 잘 못하는 외국인이 뭔가 물어본다. 보통은 이사람이 하는 말이 뭔지 잘 들어보고 대답을 해준다. 그 외국인이 스와힐리어를 사용하고 있지 않는한은 말이다ㅡ_ㅡ;
제발 외국인을 대하는 마음으로 서로를 대하자. 개발자나 기획자나 한국어를 하고 있다고 착각하기 쉬운데, 소리나 단어나 문법은 한국어와 같지만, 단어의 뜻이나, 단어의 배치에 따라 달라지는 의미등이 거의 외국어나 마찬가지로 다르다.
절대 개발자는 완벽한 기획어를 구사하지 못한다. 반대도 마찬가지다. 자기들이 맡은 업무 영역의 특성상 어쩔수 없다. 기대해선 안된다.
개발자는 기획자의 요청을 개발어로 번역한 후 이해하여 다시 스스로 기획어로 번역해서 본인이 이해한 내용이 맞는가를 확인해야 한다. 기획자 역시 스스로 개발어를 최대한 구사하여 기획안을 작성하고 개발자가 주는 피드백을 기획어로 번역한 후 스스로 개발어로 번역해야 한다.
후...
갑갑하면 한번씩 요딴글을 끄적여 두는구나..
블로그는 내 화장실이었나ㅠㅠ
또 흥분한채 글쓰고 말았네;;; 쩝..
국제표준용어-_-로 개발자와 기획자가 어떤 뜻인지는 모르겠으나, 적어도 한국어를 모국어로 쓰는 사람들 가운데, IT라는 산업에 종사하는 사람들 사이에는, '기획자'는 수요자로 표현되고 '개발자'는 공급자로 표현된다. 진정한 수요자는 유저일텐데 개발 현장에서는 이상하게도 그렇게 표현되곤 한다.
즉, 기획자가 만들어달라고 요구하는 것을 구현해 주는 것이 개발자라고 표현되는 것이다. 맘에 안들지만 받아들이자..
근데 왜인지 이 '기획자'와 '개발자'의 영역 구분은 매우 모호하다.. 그래서 갈등을 유발하기도 한다..
뭐가 모호한가?
소프트웨어 개발 프로젝트는 대략 다음의 과정을 따라 진행된다. (엔지니어링의 결과물이 최종산물이 되는 영역에서는 보통 대동소이하지만 일단 소프트웨어 개발로 국한하자)
문제의 발견 > 요구사항(니즈)의 정립 > 실현방안의 수립 > 소프트웨어 설계 > 구현 > 테스트 > 출시
'니즈의 정립부터 소프트웨어 설계까지'를 보통 '설계'라 부른다. 그리고 개발자들은 이건 자기의 할일이라고 생각한다. 그래서 적극적이다. 이 때 참여하지 않으면 나중에 피똥싸는거 한두번 경험한게 아니니...
근데 보통 '문제의 발견부터 실현방안의 수립까지'를 보통 '기획'이라 부른다. 여기서 모호함이 드러난다. 기획의 상당부분을 개발자들은 설계과정이라 생각한다는 거다. 물론 개발자들도 그 부분을 기획이라고 부르긴 한다. 스스로 프로젝트를 대함에 있어 모호함을 안고 있는거다. 기획자에게 맡겨야 하는 일이면서 자기가 해야 하는 일이기도 하다. 그러다 보니 개발자는 허구헌날 기획자랑 싸운다. 자기가 한 설계가 아니니 신뢰를 못하는 경우도 많다.
개발자와 기획자는 서로 '말귀를 못 알아들는다'고 하며 성질만 부린다.
밥그릇 싸움인듯 하지만 사실은 의사소통의 문제인 것이다.
개발자가 고자세로 나오니 기획자는 저자세로 파고 들수 밖에 없다. 이 과정에서 거의 항상 잊혀지는건 '니즈'다. 소프트웨어의 진짜 수요자인 고객으로 부터 발생하는 유일한 기획요소인 '니즈'가 간과된채 기획이 수정되고 소프트웨어 설계가 이루어진다. 대부분의 소프트웨어 개발 프로젝트가 성공하지 못하는 이유의 큰 부분이 여기에 있다. 사용할 사람들에게 어필하지 못하는 결과물을 만들게 되는거다.
결과가 나온뒤에 되돌아보며 개발자 대부분은 기획을 탓한다. '왜 쓸데없는걸 만들어달래서...' 이런식이다.
참으로 바보같은 생각이다. '니즈'를 잊혀지게 하는 가장 결정적인 역할을 한 사람은 바로 개발자다. '문제발견'단계에서는 보통 아무것도 하지 않은(문제를 감지조차 못한) 개발자인 주제에 이미 발견된 문제로부터 괴발개발이나마 니즈를 적어 들고 나타난 기획자에게, 극렬히 저항하며 실현방안 수립단계를 뒤엎었기 때문에 '니즈'는 뒷전으로 밀려나는 거다. 니즈 정립부터 설계까지의 과정에서 양(positive)의 피드백을 하지 못하고 심지어 부(negative)의 피드백 조차 아닌, 그저 역행만을 만들어 냈기 때문인거다.
반성해야 한다. 어떤 문제로부터 어떤 니즈를 발견해서 가져온 기획안인지 생각은 해 보았는가? 그들(기획자)은 기술적 기반이 취약하다는걸 전제로 개떡같이 말해도 찰떡같이 새겨 들으려 노력하며 들어본 적이 있는가? 모호하게 반복되는 용어나, 과도한 부하를 유발하는 비지니스 로직을 무턱대고 성질부리며 반송하지 않고, 교정해주거나 대안을 제시한 적이 있는가? 설계과정에 '참여'하고 있는가, '딴죽'걸고 있는가... 이 기획이 '쓸데없는 것'이라면 어떤게 '쓸모있는 것'인지 제시해 본적 있는가?
개발자들은 기획자들이 구사하는 '기획어'를 모른다. 생각하고 대들어라.
그럼 뭐... 기획자는 잘했나? 기획은 피해자라고?
웃기지도 않은 소리다. 개발자가 고자세로 나오는 이유도 모른채 기획의 관철만을 위해 일단 저자세로 파고드니 본인조차 '니즈'를 잊는거다. 우리가 가진것이 무엇이며, 기지지 못한 것이 무엇이며, 그래서 지금 만들어 가지려 하는것이 무엇인가를 절대 잊지 말아야 하는 것이 기획자의 업무인 것이다. 개발자가 자꾸 땡깡부려서 프로젝트가 산으로 간다고? 그걸 막지 못했다면 기획자도 업무 태만이고 역량 부족인거다. (난 아니라고 믿고 싶지만) 혹시, 정말로 '니즈'가 결여된 상상의 나래로 만든 기획안은 아니었는가하는 점 역시 돌이켜 반성해야 한다.
개발자가 들이박으면 기획자들은 보통 겁을 먹고 수그리는데, 왜그런가? 기술적 기반이 취약해서다. 개발자가 안된다고 하면 그냥 진짜 안되는게 아니다. 직접 코드를 작성하거나 데이터플로우를 설계할 정도로 기술적 소양을 갖출 필요는 없다. 적어도 SQL정도의 데이터를 보는 방법이라던가, 비지니스 로직이 품게 될 복잡성에 대한 추측 정도는 공부해 두란 말이다. 그정도를 생각할 수 있다면 개발자가 안된다고 하는 기획안을 작성하지 않게 될 것이며, 설령 개발자가 안된다고 뻗대도 소신껏 관철시킬수 있는 근거를 확보하게 될 것이다. 그리고 개발자들이 구사하는 '개발어'를 서서히 이해하게 될 것이다. 기획자들이 공부해야 하는건 ppt 작성 기법이 아니다. 메모장으로 만든 기획안이 ppt보다 훌륭할 수 있다.
결국 의사소통의 문제다.
길거리에서 한국어를 잘 못하는 외국인이 뭔가 물어본다. 보통은 이사람이 하는 말이 뭔지 잘 들어보고 대답을 해준다. 그 외국인이 스와힐리어를 사용하고 있지 않는한은 말이다ㅡ_ㅡ;
제발 외국인을 대하는 마음으로 서로를 대하자. 개발자나 기획자나 한국어를 하고 있다고 착각하기 쉬운데, 소리나 단어나 문법은 한국어와 같지만, 단어의 뜻이나, 단어의 배치에 따라 달라지는 의미등이 거의 외국어나 마찬가지로 다르다.
절대 개발자는 완벽한 기획어를 구사하지 못한다. 반대도 마찬가지다. 자기들이 맡은 업무 영역의 특성상 어쩔수 없다. 기대해선 안된다.
개발자는 기획자의 요청을 개발어로 번역한 후 이해하여 다시 스스로 기획어로 번역해서 본인이 이해한 내용이 맞는가를 확인해야 한다. 기획자 역시 스스로 개발어를 최대한 구사하여 기획안을 작성하고 개발자가 주는 피드백을 기획어로 번역한 후 스스로 개발어로 번역해야 한다.
후...
갑갑하면 한번씩 요딴글을 끄적여 두는구나..
블로그는 내 화장실이었나ㅠㅠ
또 흥분한채 글쓰고 말았네;;; 쩝..
