요구 개발

오늘 생각해 볼 과제는..
요건 정의도, 요구 수렴도 아닌 “요구 개발”이다. 그렇다 요구란 개발되어야 하는 것이다.

“요구”에 관한 절차 정도 어느 SI 구축이나 첫 단계에 들어 있지만, 형/식/적/일뿐.
이 단계에서 “이렇게 해 봐야 소용 없습니다. 더 좋은 방법이 있습니다.”라는 말 누가 할 수 있을까?

아마도 제안 요청과 제안서를 통해 간접적으로 동의가 이루어졌다고 보는 것일까?

그렇지만.

비즈니스의 어디가 가렵고, 그 가려운 곳을 IT가 어떻게 긁어 줄 수 있는지
더 나아가
비즈니스가 어떻게 변화해야 하고, 그 변화를 IT가 어떻게 가능하게 할지

비즈니스는 도대체 무엇을 요구하고 있는지
그걸 알아내는 일이야 말로 가치 있는 일.

물론 POC(Proof Of Concept)도 있고, 파일럿도 있다고 말한다면,
그 개념은 어디서 나왔으며, 무엇을 시험해 봐야하는지 확신은 어디서 올까?

“비즈니스 디벨로핑”이라고 말해야 할까?
순수히 비즈니스가 원하는 것을 개발하기 위한 과정. 최소 1~2개월의 집중적인 요구 “개발 과정”을 인정해야 한다. IT와 비즈니스가 빚어내는 첫번째 작품은 요구인 것이다.

이 개발을 인정해야 비즈니스 모델링이 로지컬해진다.
UML도 도입하고, 방법론을 활용하고…
비로소 경영 전략이 테크놀로지에 수렴된다.

그렇지 않고는.

뜬구름 잡는 컨설팅과 시킨 일만 하는 개발만 남는다.
제안서의 Over-commit과 방만한 RFP만 남는다.

요구 개발의 가치를 인정해줄 때 비로소,
컨설턴트는 허풍 이상의 가치를 발휘하고
프로그래머는 코딩 이상의 창의력을 기여할텐데.

오늘 생각해 본 이 과제…
어제도 오늘도 그리고 아마도 내일도 무의미한 제안서를 쓰도록 강요하고 강요받는 업계만의 특징이기를..

“다 필요 없어요. 차라리 이렇게 하는게 나아요.”라고 말할 수 있는 용기를 위해 건배.

Comments

댓글 남기기