Software Requirements

성공적인 팀 단위 업무 수행은 참 어렵다는 것을 언제나 느낀다. 프로젝트 규모가 커질 수록, 프로토타입 등을 통한 요구 사항 확인이 절실해진다. 국내에서는 대부분의 클라이언트 또는 작업 요청자가 기술적인 사항 뿐만 아니라, 한정적인 업무 사항을 내다보고 업무 지시를 하는 경우가 많다. 게다가 요구 사항은 추상적이며 변화 무쌍하기 그지 없다. 퍼지 이론 저리 가라다. 목마른 자가 우물 판다고, 작업 요청자보다, 개발자는 미리 요구 사항을 정확히 파악해 놓지 않으면 낭패를 보는 일이 허다하다. 개발 성과에 대한 책임은 요청자보다 후자에 강조된다. 프로토타입을 만드는 것이 가장 좋은 방법이지만, 적잖은 노력이 뒤따른다. 그렇다. 개발 그 자체보다 요구 사항을 논리적으로 파악하는 것이 프로젝트 성공의 열쇠다. 책은 요구 사항을 어떻게 파악할 것인가, 그리고 어떻게 정리할 것인가에 대해 하나의 방향을 제시하고 있다. 이 책이 마이크로소프트의 교과서가 된 것은 너무나 당연하다. 전문 개발자가 아니라도 관계없다. 상세한 요구 사항을 정하고 기간 단위로 확정을 짓는 것이 고속 개발에 얼마나 도움을 주는지 깨닫게 한다. 책은 개념적인 설명에만 그치지 않고, 자세한 사례 구현으로 실무적인 이해에 많은 도움을 준다. 내가 이 책을 읽고 얻은 결론이란 이렇다. 요구 사항 정립이란 참으로 어려운 문제이다. 더구나 개발팀 모두는 확정되었던 요구 사항이 근본적으로 수정될 수 있음 또한 받아들여야 한다. 그리고, 개발 자체가 목적이 아니라 판매가 목적이란 사실 또한 인정해야한다.(역자의 글에 또한 "만들 수 있는 물건을 팔지 말고 팔 수 있는 물건을 만들어라"라고 처음부터 써있다) 그 모든 점을 이 책에서 배웠다. 이전의 경험에 비추어 실패한 프로젝트의 이유는 당연했다. 개인적인 소감을 제외하더라도... 성공적인 소프트웨어 회사인 마이크로소프트의 교과서라니... 정말 탐나지 않는가? 분명하다. 이 책은 성공적인 프로젝트 개발의 성서로 쓸만한 가치가 있다. "나는 이 프로젝트를 부정적으로 보는 사람은 필요 없습니다. 성공할 수 있는 계획을 세워야 합니다." 23장의 서문에 나오는 글이다. 맞는 말이다. 끊임 없는 요구 사항의 변경은 어찌 보면 당연한 것이다. 고객의 입맛을 맞추기 그리 쉽겠는가. 요구 사항은 쉼없이 변함을 현실로 인정하고, 그를 대비하는 프로젝트 설계를 해보자. 그 길에 이 책이 안내자가 되어 줄 것이다.   http://blog.yes24.com/document/304363     13/04/06 참 별 책을 다 보았군... 참 몰랐고 참 많이 알고 싶었지. 이제는 좀 가닥을 잡은 것 같지만 말야.