요구사항에 대한 사용자와 개발자의 생각 차이

요구사항과 관련해서 사용자와 개발자의 입장은 항상 이견이 있고, 좁히기 어려운 큰 갭이 있다.

Case 1

사용자A : "이 필드 좀 하나 추가해 주시고요, 이건 이렇게 변경해 주세요."
개발자B : "이건 애초에 없었던 요구사항이쟎아요. 진작에 말씀해 주셨어야지요."
사용자A : "무슨 소리하는 건가요? 그건 당연히 되는 기능으로 알고 있었는데..."
개발자B : "원하시는대로 추가 개발하려면 전체 설계를 다 변경해야 하므로 안됩니다."
             "요구사항을 반영하려면 추가 공수가 필요하고 일정연기가 불가피합니다."
사용자A : "말도 안되는 소리하지 말고. 이 요구사항이 반영되지 않으면 최종 검수는 할 수 없으니까 알아서 하세요."

CASE 2
개발자C : "지금까지 나온 요구사항이외 변경은 없는 거죠? "
              "그렇다면 제가 정리한 요구사항정의서를 확인하시고 합의해주세요"
사용자D : "지금 합의해버리면 나중에 요구사항 변경이나, 추가는 안되는 거 아닌가요?"
               "그렇다면 확정은 좀 더 충분한 검토 후에 해드리겠습니다."
개발자C : "요구사항 합의가 지연되면 다음 과정인 설계/개발도 지연되어 전체 일정에 영향을 줍니다."
            "빨리 확정해주세요"
사용자D : "요구사항은 항상 변할 수 있는 건데 무조건 확정해달라면 곤란한 데..."

 

<나의 경험 >
현업담당자 : "제가 이 프로젝트를 스타트하기 위해 미리 준비를 해왔어요."
                "파워포인트 문서로 100여장의 화면정의를 그린 것이니 프로젝트에서 참고하여 잘 만들어주세요"
PM : "화면정의를 저희 대신에 해주셔서 프로젝트에 많은 도움이 될 것 같습니다. "
         "빨리 개발한 후 보여드리겠습니다."
개발자 : "PM님, 현업이 요구한 파워포인트 대로 개발할 수 없겠는데요. 그 기능은 현재 우리가 적용한 개발언어로는
           구현할 수 없어요."
PM : "그래요? 현업담당자에게 이야기 해보겠습니다."
현업담당자 : "무슨 소리하는거에요? 파워포인트로 되는 기능을 프로그램으로 구현못한다니요. 말도 안돼요.
                 제가 엄청난 시간을 들여 정리한 화면정의서를 하나라도 변경할 순 없어요." 무조건 그대로 만들어 주세요"
PM : "아이구..."

☞ 코딩 마무리나 테스트 단계에서 종종 볼 수 있는 IT프로젝트 사무실의 풍경입니다.

프로젝트의 마무리 단계에서 현업 사용자와 개발자/프로젝트관리자와 요구사항에 대해 목소릴 높여 언쟁하는 경우가 종종 벌어집니다.

개발팀에서는 요구사항이 변경되거나 추가되면 프로젝트 오픈에 지장을 준다고 볼멘 소리 또는 협박을 하며, 사용자는 요구사항에 대해서 변경, 추가사항을 끊임없이 뱉어내고, 딴소리를 하게된다.

결국은 현업이든 프로젝트 개발팀이든 피해는 양측 모두가 입게 되는 건 당연한 이야기 입니다.

요구사항 프로세스 
  1. 요구사항 개발 : 
     요구사항 도출(Elicitation) → 요구사항 분석(Analysis)  → 요구사항 명세(Specification) → 요구사항검증 (Validation)
  2. 요구사항 관리 :
     요구사항 정의/합의/승인 → 요구사항 통제  → 변경 관리 → 변경 영향 분석 → 요구사항 승인     

요구사항 관리가 프로젝트에서 가장 중요한 품질 관리 영역입니다.

▶ 개발자가 생각하는 사용자에 대한 느낌
- 소설을 쓴다. 현실감이 없다.
- 필요한 것이 무엇인지 잘 모른다.
- 자신의 문제가 무엇인지 잘 모른다.
- 요구사항을 정확하게 표현하지 못하는 것 같다.
- 처음에는 요구사항이 없다가 프로토타입을 만들고 나면 요구사항이 늘어난다.
- 현실적으로 불가능한 요구가 많다.
- 일반적인 기능이 아닌 한사람만의 편이성을 위한 기능에 집착한다.
- 모르는게 자랑인듯하고, 악용한다. 기술을 잘 모른다.
- 신기술을 무조건적으로 맹신한다.
- 자신의 기존 시스템에서 해결해야 할 문제를 떠넘기려 한다.
- 이랬다 저랬다 변덕이 심하다.
- 논리적으로 생각하지 않는다. 감정적이다.
- 나이가 좀 어린 개발자를 무시한다.
- 인간관계를 중요시한다.
- 비협조적이다.
- 회사간 자존심 경쟁때문에 당장 필요없는 것을 요구한다.
- 중장기적 안목이 없다.
- 회사 돈이라 그런지 생각 없이 쓰는 것 같다.
- 생각 안하고 깊이 생각하려 하지 않는다.
- 프로젝트가 완료되어 가는 시점에서 관련없는 추가 요구사항을 낸다.
- 요구사항을 못 들어주면 개발자가 실력이 없다고 투덜 댄다.

 

▶ 사용자가 생각하는 개발자에 대한 느낌
- 실력이 없는 건지 무조건 안된다고만 한다.
- 납기를 못 맞춘다.
- 프로젝트가 얼마나 남았는지 잘 모른다.
- 90% 정도 해결하고 10%남았다고 말하지만 실제로는 90% 가 남아있는 경우가 많다.
- 내가 생각하는 프로젝트의 끝과 개발자가 생각하는 끝이 다르다
- 주인의식을 가지고 심각하게 일하지 않는다
- 기술적인 용어만 늘어놓고 사업성을 고려하지 않는다
- 신기술만 고집하는 경향이 있다.
- 개발 프로세스를 잘 이해하지 못하는 것 같다.
- 진척 정도에 대한 정보를 잘 이야기 해주지 않는다.
- 커뮤니케이션에 적극적이지 않다.