아주가끔은제정신

"요구사항 관리가 프로젝트 성공 좌우"

고객 요구 정확히 파악해야 품질 높아져···불명확한 요구는 분석 툴 활용이 한 방법

2010년 05월 19일 (수) 21:36:52 안호천기자 hcan@etnews.co.kr

“프로젝트의 성공은 비즈니스의 요구사항을 효율적으로 파악하고 관리하는 것에 달려 있다.” 앨런 데이비스 미국 콜로라도대학 교수는 19일 역삼동 르네상스호텔에서 열린 한국CIO포럼 초청강연에서 이같이 밝히고 “파악된 요구사항을 가용 자원을 활용해 어떻게 해결할 수 있는지를 고민해야 한다”고 강조했다. 앨런 데이비스 교수는 요구관리 분야의 대표적인 석학이다. 데이비스 교수는 효율적인 요구사항 관리를 위해서는 우선 요구사항을 정의하고 해결 방안을 설계한 후 구축에 들어가야 한다고 설명했다. 요구사항이 제대로 정의된 후에야 가용 자원과의 효과적인 조합이 가능하다는 것이다. 제대로 된 요구사항 정의를 위해서는 먼저 고객이 누구인지 면밀히 살펴봐야 한다. 데이비스 교수는 “비즈니스의 요구사항 파악은 엔지니어링이나 마케팅의 관점에서 접근을 시도해야 한다”며 “이런 영역들이 요구사항에 어떠한 영향을 미치는지를 분석해야 그에 따른 기능이나 응대방안의 설계가 가능하다”고 말했다.     19일 역삼동 르네상스호텔에서 열린 한국CIO포럼 월례조찬회에서 앨런 데이비스 미국 콜로라도대학 교수가 요구관리의 중요성에 대해 강연하고 있다. 그는 소프트웨어 엔지니어들이 요구사항들을 파악하고 있다지만 이미 마케팅 부서에서 고객의 요구사항 충족을 위해 노력해왔고 말했다. 따라서 엔지니어링 관점에서 주도적으로 요구사항 파악을 위한 노력이 필요하다고 강조했다. 이어진 강연에서 이승재 한국IBM 래쇼날(Rational) 소프트웨어 사업본부장은 “소프트웨어를 개발한 후 테스트를 통해 문제를 해결하는 것을 잘못된 방식”이라며 “이런 문제를 해결하기 위해서는 처음부터 요구사항 관리에 충실해야 한다”고 주장했다. 일반적으로 비즈니스의 요구사항은 애매모호한 면이 많기 때문에 쉽게 정의하기가 어렵다는 게 그의 설명이다. 따라서 레쇼날 컴포저(Composer)나 도어스(DOORS)와 같은 비즈니스 분석 툴을 활용해 올바른 요구사항을 추출해야 한다고 이 본부장은 말했다. 이 본부장은 “국내 소프트웨어 개발자들은 프로그래밍을 가장 먼저 배우는데 모델링 방법부터 학습을 시작해야 한다”며 “IT조직은 모델링 이전의 요구사항과 모델링을 연계해 개발자들에게 업무를 분배하는 정형화된 프로세스를 확립해야 한다”고 설명했다. 안호천기자 hcan@etnews.co.kr

출처 : http://www.ciobiz.co.kr/news/articleView.html?idxno=2629

========================================================================================================

그래. 좋다. 동의한다. 요구사항관리가 프로젝트의 성패를 좌우한다는 것.
하지만.

1. 요구사항이 명확해야 한다. 프로젝트의 목표도 가치도 비전도 모르는 상태에서 
   Fashion 으로 Passion 같이 시작된 프로젝트에서는 결국 결론은 둘중 하나가 되게 된다.
   책임안지기 위한 회의록들로 점철되고 아웃풋은 매우 미미한 프로젝트가 되거나
   또는 컨설턴트와 개발자들이 프로젝의 마지막의 마지막 그날까지 개고생해서 진화하는 요구사항에 맞춰주거나.
   (후자로 진행되어도 결국 고객의 만족도는 별로다)


2. 요구사항 관리 툴을 이용하면 올바른 요구사항을 추출할 수 있다? 
   오우. 요구사항 관리 툴이 독심술도 하는거냐?
   요구사항 내는 사람 스스로도 뭘 원하는지 모르는데 추출해준다고? 
   그리고. 올바른 요구사항이란건 또 뭐냐? 정확한. 이겠지. 
   정확한 요구사항을 추출해내려면 커뮤니케이션 스킬이 필요한것이고.
   그들의 언어. 어휘와 외부인의 언어. 어휘를 씽크시키던 또는 번역해낼 수 있는 능력이 필요한거다.
   그래서 용어정의라는 것도 하는거고. 뭐. 국어대사전 이런거 까진 편찬하지 않는대도. 응?
   툴같은 소리 하지 마라. 방법론이 필요한거고. 현실적인 방법론이 필요한거다.


3. 개발자는 모델링 방법부터 학습해야 하는게 아니라 비즈니스부터 이해할 수 있어야 한다.
   기술언어만으로 커뮤니케이션을 하면서 고객을 안드로메다로 보내선 안된다.
   나도 개발부터 다 하지만.
   사실. 개발해서 안되는게 어디있나? 논리적인 관계만 존재한다면 다 개발로 가능하고,
   논리적인 비약이 필요한 부분에 대해서는 논리가 안맞기 때문에 그에 대한 예외룰을 적용하면 되는거고
   이렇게 개발하면 시간과 노력. 즉 . 돈이 더 들어갈 뿐인거다. 또는 개발자의 피와 뼈를 갈아넣는것이 필요한거고.
   하지만 고객과 이야기 할 때 이건 기본적인 논리적으로 이런이런 문제가 있고 그래서 안된다. 라고 말해야지
   툴의 한계가 어쩌고 DB가 어쩌고 프로그램이 어쩌고 이런식으로 얘기해봐야 소용없다.
   이해할 수 없는 언어로 설득이란걸 하겠다고 하니 당연히 현업은 절대 굽히지 않는다.
   그리고. 개발자는 개발자대로. 모델러는 모델러 대로 필요한거다.
   얼렁 뚱땅 1인 다역을 요구하지 마라. 전문성만 떨어지고 결국 프로젝트는 날림이 되는거다.
   아니면 다 할 수 있는 고급인력들을 적정한 단가를 주고 일을 시키거나.



어케된게 요즘은 기사들에서 딱 한줄. 그 이상은 의미가 없다.
근데 그 한줄도 몰라서 못하는게 아니라는게 더 문제.
그런걸 가지고 내용없는 기사와 내용없는 세미나들을 하고 있다는 .