살아가는 이야기
부정적인 No 보다는 긍정적인 No 를 하면 어떨까...?
teestory
2009. 3. 16. 17:33
고충 게시판에 올라오는 글들을 보고 문득 생각이 나서 적어 봅니다.
마땅히 올릴만한 데가 없어서, 컬럼이라긴 좀 그렇지만 ^^
몇자 적어 봅니다.
개발자들은 프로젝트를 진행하거나 개발 의뢰를 받을 때,
흔히 무리한 요구를 자주 받습니다.
가장 일반적인 경우가 기간 대비 기능의 요구 사항이 아닐까 합니다만,
일전에 제가 소프트웨어 공학을 인용하면서 짧은 글을 쓴거 처럼,
프로젝트가 성공적으로 수행되기 위해서는
비용 , 시간 , 기능의 3가지 요소가 균형을 이루어야 하고,
이 3가지 요소는 삼각형의 꼭지점과 같아서 어느 한점을 당기면 다른 점이 끌려가야
균형을 이룬다고 말씀드린적이 있습니다.
그런데 흔히 받는 무리한 요구 사항이 이 3가지를 모두 당기려고 하는
요구 사항인 경우가 많습니다.
요컨데, 비용과 시간은 정해져 있는데 기능을 추가하거나...
비용과 기능은 고정되어 있는데 시간을 줄이거나...
이런 무리한 요구사항을 받을때
실질적으로 별다른 권한이 없는 개발자 입장에서는 Yes 를 하기도, No 를 하기도 어려운 상황이 되어버립니다.
물론 이러한 상황에서 Yes 를 해서 월화수목금금금으로 수행을 해서 어느 정도 맞출수 있을지도 모르겠지만
그렇게 수행한 프로젝트의 품질에 대한 보증이나 버그 발생시 마감 기간을 넘기게 되는것은 당연지사입니다.
그렇다면 No 를 하는 경우라면...???
씨알도 안 먹히는 경우도 많습니다만...
굳이 싸우자는 목적이 아니라, 프로젝트가 성공적으로 수행되고
관리자 혹은 클라이언트가 프로젝트의 성공을 통해 실질적인 수익의 창출을 목적으로 한다면,
그들에게 부정적인 No 나 무조건적인 Yes 보다는 긍정적인 No 를 하는 것이 나으리라 생각이 듭니다.
요컨데, No 를 한다고 하면 무조건 안된다고 하기 보다는
실질적인 대안을 제시하는 방법으로서 No 를 하는 것은 어떨런지요....
주어진 요소들만으로는 프로젝트의 수행이 어렵지만,
비용 , 시간 , 기능이 세가지 요소를 어느 부분을 어느 정도 희생하게 되었을때,
가장 최적의 효과가 나오는지에 대한 실질적인 대안을 제시할수 있다면,
프로젝트를 성공적으로 이끌고저 하는 관리자 입장에서도 무조건적으로 No 를 할수는 없으리라 생각이 듭니다.
그렇다면 이러한 최적의 효과를 어떻게 예측을 해야 할까요....
예측이라는 작업 자체는 아시다시피 매우 어려운 작업입니다.
이 부분에 대해서는 소프트웨어 공학에서도 여러가지로 다루어지는 부분이 아닌가 싶어서
깊이는 들어가지 않습니다. 저도 아직 깊은 내용까지는 모릅니다. -.-;
프로젝트에 대한 작업 공수를 추정해서 추정된 공수를 기한 내에 완료하기 위해서
어느 기능을 어떻게 대치하거나 (기능) ,
어느때에 인력을 더 투입해서 공수를 분할 하거나 (비용) ,
오픈 시점을 일괄로 하지 않고 시점을 나눠서 오픈하거나 (시간)
이러한 여러가지 방안들을 적절하게 조합해서
몇가지 조합을 만들어서 대안으로 제시할수 있다면
보다 효과적인 긍정적인 No 가 아닐까 합니다.
별 내용도 없이 길게만 썼습니다만....
오늘도 현장에서 무리한 요구 사항과 무분별한 기능 변경이 난무하는 ( -.-;;; )
최전선에서 고생하고 계시는 개발자 분들께 도움이 될까 해서 적어 봤습니다.
출처 : devpia 한성배님의 글
마땅히 올릴만한 데가 없어서, 컬럼이라긴 좀 그렇지만 ^^
몇자 적어 봅니다.
개발자들은 프로젝트를 진행하거나 개발 의뢰를 받을 때,
흔히 무리한 요구를 자주 받습니다.
가장 일반적인 경우가 기간 대비 기능의 요구 사항이 아닐까 합니다만,
일전에 제가 소프트웨어 공학을 인용하면서 짧은 글을 쓴거 처럼,
프로젝트가 성공적으로 수행되기 위해서는
비용 , 시간 , 기능의 3가지 요소가 균형을 이루어야 하고,
이 3가지 요소는 삼각형의 꼭지점과 같아서 어느 한점을 당기면 다른 점이 끌려가야
균형을 이룬다고 말씀드린적이 있습니다.
그런데 흔히 받는 무리한 요구 사항이 이 3가지를 모두 당기려고 하는
요구 사항인 경우가 많습니다.
요컨데, 비용과 시간은 정해져 있는데 기능을 추가하거나...
비용과 기능은 고정되어 있는데 시간을 줄이거나...
이런 무리한 요구사항을 받을때
실질적으로 별다른 권한이 없는 개발자 입장에서는 Yes 를 하기도, No 를 하기도 어려운 상황이 되어버립니다.
물론 이러한 상황에서 Yes 를 해서 월화수목금금금으로 수행을 해서 어느 정도 맞출수 있을지도 모르겠지만
그렇게 수행한 프로젝트의 품질에 대한 보증이나 버그 발생시 마감 기간을 넘기게 되는것은 당연지사입니다.
그렇다면 No 를 하는 경우라면...???
씨알도 안 먹히는 경우도 많습니다만...
굳이 싸우자는 목적이 아니라, 프로젝트가 성공적으로 수행되고
관리자 혹은 클라이언트가 프로젝트의 성공을 통해 실질적인 수익의 창출을 목적으로 한다면,
그들에게 부정적인 No 나 무조건적인 Yes 보다는 긍정적인 No 를 하는 것이 나으리라 생각이 듭니다.
요컨데, No 를 한다고 하면 무조건 안된다고 하기 보다는
실질적인 대안을 제시하는 방법으로서 No 를 하는 것은 어떨런지요....
주어진 요소들만으로는 프로젝트의 수행이 어렵지만,
비용 , 시간 , 기능이 세가지 요소를 어느 부분을 어느 정도 희생하게 되었을때,
가장 최적의 효과가 나오는지에 대한 실질적인 대안을 제시할수 있다면,
프로젝트를 성공적으로 이끌고저 하는 관리자 입장에서도 무조건적으로 No 를 할수는 없으리라 생각이 듭니다.
그렇다면 이러한 최적의 효과를 어떻게 예측을 해야 할까요....
예측이라는 작업 자체는 아시다시피 매우 어려운 작업입니다.
이 부분에 대해서는 소프트웨어 공학에서도 여러가지로 다루어지는 부분이 아닌가 싶어서
깊이는 들어가지 않습니다. 저도 아직 깊은 내용까지는 모릅니다. -.-;
프로젝트에 대한 작업 공수를 추정해서 추정된 공수를 기한 내에 완료하기 위해서
어느 기능을 어떻게 대치하거나 (기능) ,
어느때에 인력을 더 투입해서 공수를 분할 하거나 (비용) ,
오픈 시점을 일괄로 하지 않고 시점을 나눠서 오픈하거나 (시간)
이러한 여러가지 방안들을 적절하게 조합해서
몇가지 조합을 만들어서 대안으로 제시할수 있다면
보다 효과적인 긍정적인 No 가 아닐까 합니다.
별 내용도 없이 길게만 썼습니다만....
오늘도 현장에서 무리한 요구 사항과 무분별한 기능 변경이 난무하는 ( -.-;;; )
최전선에서 고생하고 계시는 개발자 분들께 도움이 될까 해서 적어 봤습니다.
출처 : devpia 한성배님의 글