프로젝트의 성공 & 無야근 두 마리 토끼 잡기 2

우리 프로젝트가 동쪽으로 간 까닭은?

대부분의 프로젝트는 무리한 일정과 부족한 자원을 가지고 시작하게 된다. 프로젝트의 앞 단계를 차지하는 기획과 요구사항 분석과 같은 과정은 퀄리티가 좀 떨어져도 대충 일정에 맞춰서 낼 수 있다. 그러나, 이 대충 만들어진 결과물을 받은 개발자는 완벽한 것을 만들어 내야 한다. 소프트웨어의 세계에는 대충이란 없다. 포인터 하나 잘못 쓰면 작게는 에러메시지에서부터 크게는 블루스크린 또는 사이트 먹통이란 결과를 가져온다. 프로젝트가 안 끝나는 것이다. 필터를 연구한 사람들이나 오디오 쪽에 관심이 많은 분들은 알겠지만, 출력이 입력보다 더 좋을 수는 없기 마련이다. 입력이 옛날 쓰던 VHS테이프라면 아무리 좋은 장비에서 재생한다 해도 DVD화질을 만들 수 없는 것과 도 같다. 구현단계에서의 입력은 기획서나 요구사항명세서이고, 출력은 생성된 실행파일, 설치본, 또는 스크립트 파일 들이다. 여기에 초점을 맞춰서 생각해 보자.

구현단계의 입력 - 기획서 또는 요구사항 명세서 검토

위에서 언급한 것처럼 출력이 입력보다 좋을 순 없다. 그렇다면 최대한 좋은 입력을 얻을 수 있도록 노력해야 한다. 당신이 받은 문서가 업계 최고의 기획자나 조엘 스폴스키-조엘온소프트웨어 운영자, MS Excel 요구사항관리-가 작성한 것이 아닌 이상 충분히 검토되지 않았을 가능성이 높다. 기획서, 특히 요구사항명세서를 제대로 작성하기란 어려운 일이기 때문이다. 요구사항명세서는 요구사항을 수집하고 분석하여 작성되는데, 단순히 문서 포멧에 맞추는 것이 아닌 이상 경험 많은 전문가 만이 제대로 작성할 수 있을 것이다. 조엘이 말하는 명세서의 작성요령이 어려운 것이 아님에도 불구하고, 필자는 조엘이 말하는 수준의 문서를 받아본 적이 없다. 왜일까? 지금까지 대부분의 프로젝트가 충분하게 작성되지 않은 문서에 기초해서 그럭저럭 시작되었기 때문이라고 생각한다. 문서를 받는 개발자가 이슈를 제기하지 않으니 그냥 지나가는 것이다. 물론 그 대가는 끝없는 야근으로 개발자가 지게 된다.

당신은 개발이 본격적으로 시작되기 전에 당신 스스로 하던, 기획자가 하게 하던, PM이 하던, 개발자가 하던 간에 누군가가 책임을 지고 충분히 검토된 요구사항명세서를 작성하게 해야 한다. 그리고, 프로젝트가 끝날 때까지 업데이트 되도록 해야 한다.

요구사항명세 작성에 대해서 감이 없다면 아래 문서를 참고하기 바란다. 조엘의 손쉬운 기능 스펙 작성법 번역본 http://korean.joelonsoftware.com/Articles/PainlessFunctionalSpecifi-2.html

만약, 요구사항명세서란 별도의 문서를 만들 분위기가 아니라면 기획서에 그 내용을 주석 형태로 나마 기록하여야 한다. 이 일을 할 때 가장 중요한 원칙은 명료해야 한다는 것이다. 개발해야 되는 기능의 서술이 조금이라도 애매하면 명료하게 다시 쓰던가 스펙에서 제거한다. 불 분명하게 작성되어 있는 내용은 결국 개발시점에 모두의 혼란을 가져오게 된다. 두 번째는 예외사항의 검토이다. 어떤 기능이 동작함에 있어서 실패할 가능성이나 실패할 수 있는 환경이 있는지에 대해서 검토하고 보완해서 그 내용을 기록한다. 해결할 수 없는 케이스가 발견되면 역시 제거하는 것이 옳다.

사실 명료하지 않은 요구사항 보다 더 큰 문제는 엉뚱하거나 불필요한 요구사항이다. 이 들은 “이산이 아닌가 보다”하고 다시 산을 오르게 하거나 만들어 놓고 보니 쓸모가 없는 것을 만들게 하여 중요한 시간을 빼앗는다. 이 문제는 글이나 그림만으로 최종 결과물을 올바르게 상상할 수 있는 인간은 극소수라는 데서 기인한다. 대부분의 사람들은 글이나 그림만으로는 어떤 기능인지 얼마나 효용성이 있는지 감 잡기 어렵다. 이 문제에 대한 해결방법은 XP와 같은 애자일 방법의 적용이 그 해법이다. 프로젝트 초기부터 사용해 볼 수 있는 기능을 이해관계자에게 전달하여 요구사항의 오류를 수정해 나가는 애자일 방법으로 이 문제를 프로젝트 초기에 잡아 낼 수 있다.

꼭, 거창하게 개발 프로세스를 애자일로 바꿀 필요는 없다. 정확한 수치는 기억나지 않지만, 소프트웨어 사용자의 80%는 전체 기능의 20%도 채 사용하지 않는다고 한다. 여기에 힌트가 있다. 요구사항명세서를 작성할 때 많이 쓰이는 20%를 먼저 개발할 수 있도록 배려하면 된다. 많이 쓰이거나 중요하기 때문에 먼저 개발해야 하는 기능, 나중에 개발해도 되는 기능, 그리고 일정이 부족하면 포기할 기능을 나눌 수 있다. 하나의 기능도 세분화 하여 먼저 필요한 부분과 일정이 부족하면 포기할 부분을 나눌 수 있다. 이렇게 분류하는 과정에서 기획자나 기타 다른 이해관계자와 대립 없이 자연스럽게 스펙을 조절할 수 있게 된다.

사례) 필자가 참여했었던 한 프로젝트는 기획단계에서 일정이 많이 지연되었었는데, 이를 구현단계에서 따라잡아서 프로젝트를 성공시킨 적이 있다. 어떻게 했냐고? 개발에 본격적으로 착수하기 직전 기획팀과의 열띤 논쟁, 설득, 타협에 돌입했다. 그리고, 위에서 언급한 것처럼 전체적인 기획의도를 만족시킬 수 있는 최소한의 것을 제외한 나머지 부분에서 조금이라도 애매한 것이 발견되면 가차없이 스펙에서 제거하였다. 그 결과는 일정준수, 삶의 질 확보, PM, 기획자, 관리자, 개발자 그리고, 소비자 모두의 만족이었다. 일정을 지킬 수 있는 유일한 방법은 개발자의 충원이나 야근이 아니고 스펙 아웃이다. 함께 머리를 모으면 뺄 수 있는 부분을 찾을 수 있다.

- 출처 : 안철수연구소 -

좋은정보가 되셨다면 아래 한번 클릭해주세요^^