우연히 1촌 싸이 보다가... 이런글을 읽었다
개발자의 수동적인 태도에 대한 포스팅이었지만,
가볍게 다루기엔 조금 무거운 주제가 아니었나 생각된다.
짜장면과 개발자
http://searching.egloos.com/2355521
그렇다면 개발자의 입장에서 다시 생각해볼까?
(막상적고 보니... 윗글의 덧글에 더 좋은 예가 많다)
Situation1.
전화가 왔다. "배가 고픈데 면이 좋을꺼 같고, 검은색이면 좋을것 같아요"
"짜장면이면 돼죠?" 하고 배달을 갔다.
"어??? 난 국물이 먹고 싶은데...!"
Situation2.
볶음밥 서비스로. 짬뽕국물을 가져다 줬다.
"국물을 먹어보니 역시 짬뽕이 좋겠어요"
Situation3.
배달을 갔다.
"자장면만 먹으니... 좀 입이 심심한데 탕수육 서비스 안되나요? !!!"
... 생략 ...
사실 어떤서비스를 제공하고, 고객의 need를 파악하는건 개발자의 업무라기 보다는
PM, 기획자의 업무에 더 맞는게 아닐까 싶다.
자장면을 만들고(개발자)
서비스와 메뉴구성(기획자)를 하고
전화를 받고, 배달순서와 오더를 내리고(PM)
하는데 왜 욕은 개발자만 들어야 하는건지 모르겠다..
하지만 국내 실정을 보면 설계, 기획, 개발, 유지보수, 수정, 일정관리 대부분을 개발자가 하는경우도
허다한게 사실이다. 개발자는 슈퍼맨이 아니다.
[고객의 문제?]
갑이라고 볼수 있는...고객
고객은 자기가 원하는것이 무엇인지 정형화 되지 않는경우도 많다.
자기자신은 그것이 당연하다고 생각하지만, 다른 사람들은 그 프로세스를 모른다.
"인도에서는 손으로 카레를 먹는게 상식이지만, 한국에선 숟가락으로 먹는게 상식이다"
동일한 상황이 누가 생각하느냐에 따라서 달라지게 된다.
개발자는 고객보다 개발을 더 잘하지만,
고객은 업무프로세스를 훨씬 잘안다.
필요한 요구사항과, 사용할 업무 프로세스는 고객자신이 가장 잘 알기 때문이다.
그렇다면, 짜장면 이론에서 나왔던것을 반대로 생각하면,
요구를 정확히 했다면 모든것을 받아낼수 있다는것이다.
[PM / 기획자 등등]
고객과 개발자를 묶는 중간단계...
서로의 의견과 요소들을 중재해야 하다는 어려운 일이다.
이들은 고객의 need를 어디까지 구현가능한지 판단하고
일정을 생각하고, 개발자에게 요구해야한다.
하지만, 가끔... 개발자가 알아서 하길 바라는 사람들도 있긴하다... ㄱ-
[개발자의 문제?]
프로젝트에서 가장 중요하게 되는것이
"정확한 시일에 요구한걸 얼마나 정확히 구현하느냐!"이다.
우리나라의 프로젝트상황을 보면... 언제나 일정에 쫓긴다.
중간중간 마다 바뀌는 요구사항이 생기고...
높으신분 한마디에 소스를 뒤업는 경우도 허다하다...
개발자의 문제라고 한다면 그 이유를 정확히 전달해야 한다는 사실이다.
사실 개발자치고 말빨 좋은사람은 드믈다...
하지만, 그 이유를 자근자근 설명하고 설명 한다는건.... 중요하다고 본다.
[마치며]
"개발자 / 기획자,관리자 / 고객" 라는 특성은 서로 다르고 서로 상호 보완되어야 한다.
서로의 특성으로
고객은 이상을 꿈꾸고...
기획자와 관리자는 결론과 편의성을 꿈꾸고...
개발자은 단계단계와 안정성을 꿈꾼다...
이 서로다른꿈은 사실... goal은 한곳이지만 추구하는 바가 다른것 뿐이다.
이것을 얼마나 조율하고 서로 이해하는것이 가장 중요한건 아닐까?
난 그렇게 생각한다.
개발자의 수동적인 태도에 대한 포스팅이었지만,
가볍게 다루기엔 조금 무거운 주제가 아니었나 생각된다.
짜장면과 개발자
http://searching.egloos.com/2355521
그렇다면 개발자의 입장에서 다시 생각해볼까?
(막상적고 보니... 윗글의 덧글에 더 좋은 예가 많다)
Situation1.
전화가 왔다. "배가 고픈데 면이 좋을꺼 같고, 검은색이면 좋을것 같아요"
"짜장면이면 돼죠?" 하고 배달을 갔다.
"어??? 난 국물이 먹고 싶은데...!"
Situation2.
볶음밥 서비스로. 짬뽕국물을 가져다 줬다.
"국물을 먹어보니 역시 짬뽕이 좋겠어요"
Situation3.
배달을 갔다.
"자장면만 먹으니... 좀 입이 심심한데 탕수육 서비스 안되나요? !!!"
... 생략 ...
사실 어떤서비스를 제공하고, 고객의 need를 파악하는건 개발자의 업무라기 보다는
PM, 기획자의 업무에 더 맞는게 아닐까 싶다.
자장면을 만들고(개발자)
서비스와 메뉴구성(기획자)를 하고
전화를 받고, 배달순서와 오더를 내리고(PM)
하는데 왜 욕은 개발자만 들어야 하는건지 모르겠다..
허다한게 사실이다. 개발자는 슈퍼맨이 아니다.
[고객의 문제?]
갑이라고 볼수 있는...고객
고객은 자기가 원하는것이 무엇인지 정형화 되지 않는경우도 많다.
자기자신은 그것이 당연하다고 생각하지만, 다른 사람들은 그 프로세스를 모른다.
"인도에서는 손으로 카레를 먹는게 상식이지만, 한국에선 숟가락으로 먹는게 상식이다"
동일한 상황이 누가 생각하느냐에 따라서 달라지게 된다.
개발자는 고객보다 개발을 더 잘하지만,
고객은 업무프로세스를 훨씬 잘안다.
필요한 요구사항과, 사용할 업무 프로세스는 고객자신이 가장 잘 알기 때문이다.
그렇다면, 짜장면 이론에서 나왔던것을 반대로 생각하면,
요구를 정확히 했다면 모든것을 받아낼수 있다는것이다.
[PM / 기획자 등등]
고객과 개발자를 묶는 중간단계...
서로의 의견과 요소들을 중재해야 하다는 어려운 일이다.
이들은 고객의 need를 어디까지 구현가능한지 판단하고
일정을 생각하고, 개발자에게 요구해야한다.
하지만, 가끔... 개발자가 알아서 하길 바라는 사람들도 있긴하다... ㄱ-
[개발자의 문제?]
프로젝트에서 가장 중요하게 되는것이
"정확한 시일에 요구한걸 얼마나 정확히 구현하느냐!"이다.
우리나라의 프로젝트상황을 보면... 언제나 일정에 쫓긴다.
중간중간 마다 바뀌는 요구사항이 생기고...
높으신분 한마디에 소스를 뒤업는 경우도 허다하다...
개발자의 문제라고 한다면 그 이유를 정확히 전달해야 한다는 사실이다.
사실 개발자치고 말빨 좋은사람은 드믈다...
하지만, 그 이유를 자근자근 설명하고 설명 한다는건.... 중요하다고 본다.
[마치며]
"개발자 / 기획자,관리자 / 고객" 라는 특성은 서로 다르고 서로 상호 보완되어야 한다.
서로의 특성으로
고객은 이상을 꿈꾸고...
기획자와 관리자는 결론과 편의성을 꿈꾸고...
개발자은 단계단계와 안정성을 꿈꾼다...
이 서로다른꿈은 사실... goal은 한곳이지만 추구하는 바가 다른것 뿐이다.
이것을 얼마나 조율하고 서로 이해하는것이 가장 중요한건 아닐까?
난 그렇게 생각한다.