!기획리뷰
기획담당자가 작성한 기획서가 전달되면 개발팀에서 리뷰를 하고 여러가지 문제가 없는지 검토를 한다.
기획자는 개발자가 아니기때문에 UX플로우상 누락된 부분이 있을 수 있고, 기획대로 개발을 할 경우 성능상의 문제가 있거나. 지나치게 개발 기간이 늘어날 수도 있고, 구현이 불 가능할 수도 있다.
기획서를 개발팀원이 모두 각자 충분히 리뷰를 한 후에, 회의실에 모여서, 각 페이지별로 넘기면서 팀원 각자가 발견한 이슈들을 취합 정리해서, 유관 부서 담당자가 모두 모인 자리에서 기획 리뷰를 하게 된다. 이때 발견된 문제에 대해서 토론하고 협의해서 스펙의 보완 수정하게 된다.
!스펙정밀검사
처음에는 기획서가 제품의 모든 기능을 설명하기를 기대하였으나 여러 프로젝트를 경험해보니 기획서라는 것은 프로젝트가 진행되는 동안 항상 변경되는 문서라는 것을 알게된다. 즉 스펙은 프로젝트가 끝날 때 까지 항상 변경되는 것으로 애초에 생각하면 되고, 개발은 그에 따라 적절히 대응하고 효율적으로 수정될 수 있는 구조로 개발을 하여야 한다.
충분히 성능적으로 문제가 없는지 고려해야 한다. 배포된 프로그램이 서버/클라이언트 구조를 가지고 있다면, 서버가 감당할 수 있는 동시 요청개수가 얼마나 되는지, 하나의 요청에 대해서 응답시간이 얼마나 걸리는지 등 이런 요소가 성능에 영향을 미치게 된다. 윈도우 프로그램의 경우 어떤 작업의 처리시간이 사용자가 기다려 줄 수 있는 시간인 보통 5초를 넘기는 경우 어떻게 처리를 하는게 좋을 지, 자주 요청되는 데이타에 대해서 캐시를 사용할지, 큰 데이타 덩어를 다른 프로세스에 전달 경우 어떤 방식이 효율적일지, 하나의 자원에 대해서 동시 접근할 수도 있는지, 프로세스의 권한이 다른 경우의 연동에 문제가 없는 지, 중요한 개인정보는 안전하게 관리되고 있는지 등 매우 다양한 성능적인 이슈가 발생할 수 있는데 개발팀은 이런 것까지 감안해서 리뷰를 해야한다. 필요한 경우 별도의 스펙 정밀 검사 문서를 작성할 수 도 있다.
간혹 충분한 대화가 필요할 수도 있다. 기획서의 어떤 스펙이 사실 어떤 의도를 만족시키기 위해서 정의된 것일 수 있는데 개발팀에서 보기에 그 의도를 만족시키는 다른 방법이 있을 수도 있기 때문이다. 보통 그 다른 방법이 더 쉽고 빠른 경우가 많다. 이런 경우 협의를 통해서 얼마든지 스펙이 변경될 여지가 있다.
