| 성공적인 팀 단위 업무 수행은 참 어렵다는 것을 언제나 느낀다. 프로젝트 규모가 커질 수록, 프로토타입 등을 통한 요구 사항 확인이 절실해진다. 국내에서는 대부분의 클라이언트 또는 작업 요청자가 기술적인 사항 뿐만 아니라, 한정적인 업무 사항을 내다보고 업무 지시를 하는 경우가 많다. 게다가 요구 사항은 추상적이며 변화 무쌍하기 그지 없다. 퍼지 이론 저리 가라다. 목마른 자가 우물 판다고, 작업 요청자보다, 개발자는 미리 요구 사항을 정확히 파악해 놓지 않으면 낭패를 보는 일이 허다하다. 개발 성과에 대한 책임은 요청자보다 후자에 강조된다. 프로토타입을 만드는 것이 가장 좋은 방법이지만, 적잖은 노력이 뒤따른다. 그렇다. 개발 그 자체보다 요구 사항을 논리적으로 파악하는 것이 프로젝트 성공의 열쇠다. 책은 요구 사항을 어떻게 파악할 것인가, 그리고 어떻게 정리할 것인가에 대해 하나의 방향을 제시하고 있다. 이 책이 마이크로소프트의 교과서가 된 것은 너무나 당연하다. 전문 개발자가 아니라도 관계없다. 상세한 요구 사항을 정하고 기간 단위로 확정을 짓는 것이 고속 개발에 얼마나 도움을 주는지 깨닫게 한다. 책은 개념적인 설명에만 그치지 않고, 자세한 사례 구현으로 실무적인 이해에 많은 도움을 준다. 내가 이 책을 읽고 얻은 결론이란 이렇다. 요구 사항 정립이란 참으로 어려운 문제이다. 더구나 개발팀 모두는 확정되었던 요구 사항이 근본적으로 수정될 수 있음 또한 받아들여야 한다. 그리고, 개발 자체가 목적이 아니라 판매가 목적이란 사실 또한 인정해야한다.(역자의 글에 또한 "만들 수 있는 물건을 팔지 말고 팔 수 있는 물건을 만들어라"라고 처음부터 써있다) 그 모든 점을 이 책에서 배웠다. 이전의 경험에 비추어 실패한 프로젝트의 이유는 당연했다. 개인적인 소감을 제외하더라도... 성공적인 소프트웨어 회사인 마이크로소프트의 교과서라니... 정말 탐나지 않는가? 분명하다. 이 책은 성공적인 프로젝트 개발의 성서로 쓸만한 가치가 있다. "나는 이 프로젝트를 부정적으로 보는 사람은 필요 없습니다. 성공할 수 있는 계획을 세워야 합니다." 23장의 서문에 나오는 글이다. 맞는 말이다. 끊임 없는 요구 사항의 변경은 어찌 보면 당연한 것이다. 고객의 입맛을 맞추기 그리 쉽겠는가. 요구 사항은 쉼없이 변함을 현실로 인정하고, 그를 대비하는 프로젝트 설계를 해보자. 그 길에 이 책이 안내자가 되어 줄 것이다. |
| 프로젝트 매니저 : 우리는 이런, 이런 프로그램을 개발해야 합니다~ ... 개발자 : 네~ 알겠습니다. 뚝딱~ 뚝딱~ .. ... 개발자 : 완성했습니다. 한 번 보시죠. 프로젝트 매니저 : 아니 이게 아니잖아요. 에잇~ 이렇게 이렇게 다시 하세요. 실무에서 프로그램을 개발하는 개발자라면 열심히 만들었다가 모두 엎고 다시 개발하는 경우가 한번쯤은 있었을 것입니다. 저 역시 그런 경우를 여러번 경험 했었고 그런 대부분의 경우는 정확한 스펙이 정해지지 않은 상태에서 개발했을 경우였습니다. 전체적인 개요만 대충 듣고 개발했을 경우 세부적인 부분에서는 개발자의 추측이 들어가게 되고 그 추측이 빗나갔을 때는 다시 만들어야 하는 경우가 태반이었습니다. 이 책은 이런 경우를 줄일 수 있는 방법을 설명해 놓은 책입니다. 개발 전 필요한 "요구사항" 이 요구사항을 정확하게 얻어내는 방법, 정리하는 방법, 명세하는 방법을 하나 하나 예시를 들어가면서 잘 설명해 놓았습니다. 이 책은 개발자에게도 필요하지만 오히려 프로젝트 매니저나 사용자의 요구사항을 직접 들을 수 있는 영업팀들, 그리고 회사의 매니저들이 보면 더 좋을 책 같습니다. 프로그램 개발에서 정확한 사용자 요구사항이 얼마나 중요한지를 잘 설명해 놓은 책이기 때문입니다. 그냥 전체적인 윤곽만 가지고 개발했다가 다시 고치고, 다시 개발했다가 다시 고치는 식의 개발이 아니라 정확한 요구사항으로 한 번에 끝낼 수 있는 개발에 대해서 그 실제적인 방법을 잘 알려주는 책 입니다. |
| 프로젝트에서 늘 시달리는 것은 현업의 비즈니스적 요구사항과 전산실 직원들의 비기능적 요구사항이다. 현업의 비즈니스 요구사항은 intangible하고 먼가 불명확하고 어설퍼서 도대체 어디서 잘라야 하는지 감도 안잡히고 다 수용해야만 하는지 판단이 안되고 전산실 직원들의 요구사항은 tangible하지만 기능요구사항을 다 수용한다면 도저히 commit할 수 없어 중요도를 어디에 두어야 할 지 막막하다. 이 책을 읽게된 동기도 이러한 맥락에서 도움을 얻고자 하였고 특히 기능과 품질에 대해 달성가능한 기대를 설정하는 방법등이 그러한 고민을 해소해 준거 같다. 이외에는 내가 미쳐 고려하지 못했던 (매번 플젝마다 신경써야지 하면서도 늘 잊어 먹는 부분) scope이나 예산을 늘리게 되는 위험한 요구사항 변경 요청을 관리하는 Tip들이 있어 배울 수 있다.그리고 순수 개발자의 마음에서 기능의 100% Super exelent 기능을 만들려는 것이 얼마나 우매한지를 보여준다 결국 그러한 기능은 다른 resource를 낭비하고 고객은 안쓰게 되는 경우에 대해 경고하고 있다...진짜 여러모로 실제로 일어났던 상황과 비슷해서 이책에서 많은 이슈 해결의 Tip을 도움받을 수 있다. |
| 많은 개발자들이 소프트웨어 개발을 진행하며, 정리되지 않는 요구사항과 추가요구사항들로 인한 난잡한 코드들을 경험해 보셨을 겁니다. 이러한 요구사항들을 관리하는데 초점을 맞춰서 쓰여진 책입니다. 이 책은 쓴 저자의 경험과 지식에 바탕을 두고 요구사항을 수집, 관리를 통한 소프트웨어를 개발하는 방법에 대해 다루고 있습니다. 처음 이 책을 펼쳐 보았을때 소프트웨어 공학쪽 교재같다는 생각이 우선 들더군요. 저자의 실제 경험을 바탕으로 작성한 참고서 같다고 해야할까? 머 그런 느낌이었습니다.^^; 언젠가 실패한 프로젝트를 수습하기 위해 투입된 적이 있었습니다. 근본적인 이유는 요구사항에 대한 잘못된 해석과 설계없는 막코딩이 문제였죠.-_-; 이 책은 이러한 오류를 최소화 시킬수 있도록 트레이닝하는데 도움이 될 수 있을것입니다. 머 복잡하고 어려운 내용은 없기때문에 가벼운 마음으로 읽어볼수 있을 것이고요.^^; 부록에서 마지막으로 책에서 다룬 내용들에 대해 총체적으로 정리를 해놓았는데, 실제 예를 든 요구사항 분석같은것도 좋았고요.^^; 결론적으로 책 자체는 상당히 볼만한 내용을 다루고 있습니다. 그러나 아무래도 번역서이다 보니 용어의 일관성이나 약간의 오탈자등이 문제가 안될수는 없더군요. 그래서 만점을 주진 않았고요, 프로젝트를 진행하시는 분이나 진행하실분들은 한번씩 읽어보시길 추천드립니다.^^ |
| 개인적인 취미생활로 프로그램을 하거나 공부의 목적이 아니라면 대부분의 개발자들은 소프트웨어에 별다른 지식이 없는 일반고객이나 회사의 간부들의 요구(?)에 의해서 개발을 하게된다. 즉, 새로운 신기술, 디자인패턴, 고난이도의 기술등을 썼다고 우쭐대도 고객 또는 업무를 지시하는 상관의 마음에 들지 않으면 개발을 위해 투자한 시간이 헛수고로 돌아가게 되고만다.... 회사에서 간부들에게 위와같은 일로 불평을 했거나. 일반고객에게 '아무것도 모르면서....' 이런 불평을 했던 사람이라면 꼭 한번쯤 읽어봐야 할 책이다. 일반적으로 요구사항 분석을위해 Use Case를 이용하거나. 기타 다른 여러가지 방법을 통해서 해왔다면 이 책에서 설명하는 내용을 활용하여 보다 효율적으로 업무에 적용할 수 있을 것이다. 번역은 막힘없이 읽을 수 있을정도로 잘 되어있고 편집또한 훌륭해서 책장에 전시(?)해도 될만큼 .. ^^ 잘 되어있다. |
| 현업에서 프로젝트 리더의 역활을 하는 한 사람의 소프트웨어 엔지니어로서 얼마전에 이 책이 번역된다는 얘기를 듣고 무척 기대를 했었습니다. 와우북에 이 책의 서평을 쓰겠노라고 메일을 보내고, 이 책을 받아서 읽으면서 왜 칼 위거스의 이 책에 개발자들이 찬사를 보내는지 알수 있었습니다. 제가 일하는 곳은 방산 소프트웨어 및 시뮬레이터 업체로서, 저는 현재 항공기 관련 일부 프로젝트에 참여 하고 있습니다. 고객의 요구사항을 분석하여 SRS를 작성하고, 프로젝트 제안서를 통해 프로젝트 수주를 하는 일에도 여러번 참여하면서 느꼈던 고민들에 대해서 이 책의 저자는 마치 나의 고민을 다 알고 있다는 듯이 명확하게 이야기 하고 있는 점이 놀라웠습니다. 이 책의 내용은 한번이라도 고객의 요구사항을 다뤄본 사람이라면 충분히 공감가는 내용일 것입니다. 만일 프로젝트 경험이 없는 사람이 이 책을 읽는 다면 뜬 구름 잡는 소리라고 할지는 모르겠습니다. 그래도 한번쯤 봐 둔다면 나중에 이러한 일에 닥치면 또 이책을 찾게 되리라 생각합니다. 분명 이책은 프로젝트 경험이 있는 사람이라면, 또 고객의 프로젝트를 실패해본 경험이 있는 사람이라면 어디서 부터 첫 단추가 잘못 끼워졌는지 알 수 있도록 많은 실마리를 제공하고 있습니다. "S/W Requirements" 는 완벽한 소프트웨어를 만드는것에 관한 이야기를 하고 있지 않습니다. 이 책은 우리가 고객이 원하는(요구하는) 제품을 만드는 것에 이야기하고 있는 책입니다. 개발자의 기술의 자랑하는 제품이 아니라,사용자가 사용하고자 하는 용도에 맞는 제품을 어떻게 정의하고 어떻게 하면 그 내용을 서로 공감하는가에 관한 내용들입니다. 현재 프로젝트를 진행하고 있다면, 이 책을 고객과 함께 읽고 프로젝트에 관해서 다시 이야기 해보십시요. 이전에 가졌던 많은 문제들에 대해 다른 관점을 가지리라 생각 합니다. 저도 이책을 현재 프로젝트를 발주한 업체의 담당자에게 소개해주고, 프로젝트에 대해 이전에 서로가 가졌던 관점을 개선하기 위해 노력 있습니다. 무엇보다 저의 현재 프로젝트에 많은 도움이 되고 있지요. 이 책의 내용은 처음 읽기에 조금 지루한감은 있습니다. 그리고 진지하게 보지 않으면 수면용으로 적절하다는 섣부른 판단을 내릴지도 모르겠습니다. 만일 그렇다면 인내를 가지고 책의 1/4만 잘 읽어 보십시요. 아마 그 다음은 이 책이 얼마나 실제적이고 흥미 있는 내용을 이야기 하고 있는지 아실겁니다. 이 책의 저자는 저자의 웹사이트에서 요구사항 문서에 대해 주석이 있는 템플릿을 제공하고 있어서 이 자료들을 활용하여 책의 내용을 프로젝트에 바로 적용 해 볼수 있기도 합니다. 이책의 21장에서는 "Active Focus", "DOORS"등의 요구사항 공학에 적절한 소프트웨어를 소개하고 있는데, 아마 대부분은 그러한 프로그램을 처음 듣거나 아니면 들어는 보았지만 사용해 본적은 없을 것입니다. 서구의 많은 업체들은 실제 이러한 도구를 사용하여 요구사항을 관리하고 있지만 국내에서는 이러한걸 접해보기 힘들다는게 아쉽게 느껴지면서 조금은 부럽기도 합니다. 우리는 워드와 엑셀로서 관리를 해야 할듯 합니다. 뜻있는 없체가 이러한 프로그램을 만들어 준다면 좋겠지요. 소프트웨어를 만들기 위해 사용자와 협의를 하다보면 처음 사용자의 RFP에서 얘기하던 내용이 구제적인 협의에 들어가다보면 점점 요구사항이 변경되는 일은 비일비재 합니다. 이때 요구사항 변경을 프로세스로서 정해 놓지 않으면 나중에 이부분이 프로젝트를 위험에 빠뜨릴 수도 있게됩니다. 이러한 위험성에 대해서 저자는 강조하고 있고 또 그러한 사태를 어떻게 방지 할것인지를 말하고 있습니다. 이 책을보고나서 쓰고싶은 말은 많지만, 한번 먼저 읽어 보라고 권하고 싶습니다. 그리고 프로젝트를 하면서 적용해보라고 말하고 싶습니다. 끝으로 저자가 맺음말에서 이야기한 한 구절을 옮기고 끝을 맺습니다. "여러분이 작업하는 방식을 변경하지 않는다면, 현재의 프로젝트가 지난 프로젝트보다 더 나아질수 있다는 믿음은 근거가 없는 것이다." |