행복한 아빠

요구사항은 왜 그리 자주 변경되는가 본문

하고싶은말

요구사항은 왜 그리 자주 변경되는가

행복한아빠 2009. 12. 11. 21:30

저는 소프트웨어를 개발하는 프로그래머입니다. 제 소명은 우리에게 문제해결을 의뢰한 고객의 기대를 채워주는 것입니다. 그 기대를 보통 요구사항이라고 말하죠. 그런데 이 요구사항이 가만히 있으면 좋겠는데 자꾸 변합니다. 아주 심하게 말이죠. 가장 큰 문제는 의사소통 / 피드백의 부재겠지요. 이 문제는 지겹게 들어왔던거라 제가 또 이야기하고 싶지는 않고 그 밖에 다른 원인이 무엇인지 7가지를 정리해봤습니다.


1. 고객도 자기가 원하는 것을 모른다
사람은 논리적이고 추상화된 생각이나 사상보다 직접 보고 듣는 감각에 더 빠른 동물입니다. 뭔가 보고 만질 수 없는 상황에서는 아무도 자신이 원하는 진짜를 상세하게 설명하기 어렵습니다. 우리의 귀중한 고객에게 그 어려운 걸 요구하다니 너무 심한 일인것 같습니다.

2. 너무 일찍 정의한다
우리는 주로 프로젝트 초반에 요구사항을 정의합니다. 프로젝트를 잘 완수해야 한다는 의무감때문에 초반부터 상세하게 정의하려고 애를 씁니다. 분명 요구사항 정의에 오류가 있을 겁니다. 이 오류는 시간이 지나면서 그 차이가 점점 커지게 되죠. 어떤 요구사항은 몇 달후에 실제 구현을 하기도 하죠. 그 쯤되면 우리가 정의한 요구사항은 엉뚱했거나 심할 경우 필요없을 수도 있습니다. 물론 새로운 것이 튀어나오기도 하죠.
"요구사항 정의와 구현과의 시간차가 클 수록 요구사항 변경은 빈번해진다"라는 말이 있습니다.

3. 상황은 변한다
세상은 점점 더 빠르게 변합니다. 우리가 작성하는 소프트웨어와 관련된 비즈니스도 말할 것 없죠. 6개월 프로젝트라면 지금과 6개월 후 비즈니스 상황은 다를 수도 있습니다. 지금은 필요하지만 6개월 후에는 필요없거나 다른 기능이 필요할 가능성은 항상 존재합니다.

4. 현물을 보면 욕심이 생긴다
머리 속에 빙빙 돌던 소프트웨어의 모습이 실현되어 눈 앞에 펼쳐지면 누구라도 욕심이 생기게 마련입니다. 직접보니 이제부터 생각이 구체화되고 진짜 진짜 추가하고 싶은 기능이 그 때 나오는 경우가 많습니다. 이런 욕심이 나쁜 게 아닙니다. 단지 내가 진짜 진짜 원했던 것을 나오기 전에는 몰랐던 것이죠.

5. 개발자의 두려움
개발자는 자신이 작성한 작품(?)을 완성하기전에 잘 보여주지 않는 경향이 있습니다. 특히 검토 또는 피드백 문화가 잘 갖추어지지 않는 곳에서 더 한 것 같습니다.
이렇게 경직된 분위기에서는, 대체로 개발자는 고객에게 시연하기 바로 전에 결과물을 내놓습니다. 완벽하지 않을 가능성이 대개 크죠. 잔뜩 기대하고 있는 고객 앞에서 에러가 계속 발생하고 분위기 안 좋아집니다. 그리고 점점 개발자는 자기의 작품이 완벽해질 때까지 시간을 끌고 내놓지 않게 됩니다. 피드백이라는 말이 사라집니다.

6. 고객의 두려움
고객도 사업을 성공으로 마쳐야하는 책임이 있습니다. 오히려 우리보다 큰 경우가 많습니다.
뭔가 앞이 보이지 않거나 개발자 집단에서 방어막을 치기 시작하면 사업내에 원하는 결과를 얻을 수 없다는 두려움에 일정 압박과 무리한 요구사항을 내놓기 시작합니다.

7. 대치 상황
개발자의 두려움과 고객의 두려움이 극대화되면 개발자와 고객은 각자의 방어막을 치고 대치하는 나쁜 상황에 빠지게 됩니다. 이런 나쁜 상황까지 가면 양쪽은 극히 민감해지고 고객은 지나칠 수도 있는 것도 개발자를 신뢰할 수 없어 변경을 요구하게 되고, 개발자는 변경에 민감해져 일어날 수 있는 대부분의 것을 변경사항으로 보게 됩니다. 실은 충분히 발생할 수 있는 양의 변경사항인데도 개발자는 그보다 더 변경사항이 많은 것으로 생각하게 됩니다.


결국
해결할 수 있는 원인들도 있지만 몇 개의 원인은 사람의 힘으로 해결할 수 없는 문제도 있네요. 시간을 멈춰서 상황이 변하지 않게 하던지, 독심술이나 레드썬~을 배워서 고객 최면걸어서 고객의 마음 저 깊은 곳의 요구사항을 끌어내는 수 밖에 없는 것 같습니다.

요구사항은 앞으로 오히려 더 심하게 변덕을 부릴 것이라는 말에 당황하지 마십시오. 다행히 "요구사항을 변할 수 밖에 없다"라는 진실을 인정하고, 다른 방법을 찾는 움직임이 활발히 일어나고 있습니다.

바로 애자일이죠~

요구사항이 자주 변하는 또 다른 원인은 무엇이 있을까요?

2 Comments
  • 프로필사진 neod 2010.04.29 02:17 정말 공감 갑니다 : )

    다른 원인을 찾아보려고 했지만 거의 행복한 아빠님이 예를 드신 범주에 포함되는 것 같습니다.



    그래도 굳이 찾아 본다면 현재 겪고 있는 문제가 있긴 합니다.

    과연 이런 상황은 어떤 범주로 볼수 있을까요?

    처음에는 고객이 뭘 원하는지 모르는 상황 이었습니다만 , 차근차근 정의한다는 생각으로 진행 했구요

    고객에게 원하는 요구사항이 "이것" 이 맞는지 확인을 받기 위해 문의를 했습니다.

    그런데 이 문의에 대한 피드백이 상당히 늦어지더군요.

    고객은 피드백이 늦더라도 개발은 챡챡 진행되고 있다고 생각 하구요. 그것에 대해서 이야기 해도

    답변은 계속해서 하루 이틀씩 더 늦어 지게 되더군요.

    결국 기한에 맞춰서 오픈 해야 한다는 과제 때문에 요구사항을 수정해서 고객이 원하는 것을

    보여 줄 수 있는 최소한으로 요구사항을 축소 한 적이 있습니다.


    요구사항의 변경 과 축소가 같은가 하는 부분은 예외로 두더라도

    이런 경우는 어떤 범주에 속할지가 궁금했습니다.

    고객의 두려움? . 흠. 궁금하네요 ^ ^

    좋은 글 잘 읽고 갑니다.
  • 프로필사진 행복한아빠 2010.04.30 11:02 신고 많이 생각하게 만드는 댓글을 주셨네요. ^^
    고객의 피드백을 원활하게 만드는 기술이 굉장히 중요하긴한데 참 어려운 부분입니다. 사람을 움직이는 방법이라.

    상대방(고객)이 움직일만한 방법을 사용하는게 좋지 않을까 모르겠습니다. 제 경험으로는 고객은 문서보다 직접볼 수 있는 UI를 더 좋아하고 장문의 유스케이스보다 짧막한 그림이 들어간 문서를 좋아하더군요. 물론 저도 그런 것을 더 선호하고요.

    이렇게 하려면 우리의 노력이 좀 필요하네요. ㅠㅠ 애자일이나 실용적인 방법을 통해 좀 더 나은 것이 무엇인지 계속 고민중입니다.
댓글쓰기 폼