2016년 2월 23일 화요일

프로젝트 수행 기법

프로젝트 성공의 가장 큰 조건은 풍부한 경험을 가진 팀원이 프로젝트를 이끌어 나가는 것이지만 모든 프로젝트에 우수한 경험자를 투입하는 것은 어려운 것이 현실이다. 경험이 많은 회사에서는 다른 프로젝트에서도 공유할 수 있도록 축적한 경험을 체계적 기법으로 정리하여 전파하고 관리한다. 기법의 종류와 깊이가 회사의 역량으로 간주될 정도로 기법의 중요도는 시간이 흐를수록 높아졌고, 기법의 자산화는 프로젝트 종료의 필수 프로세스가 되었다. 

기법은 다양한 형태로 정리된다. 프로젝트 산출물을 정리하여 재사용이 가능한 자산으로 활용하기도 하고, 소프트웨어 개발 로직을 체계화하여 프레임워크로 발전시키기도 한다. 액티비티(Activity)나 태스크(Task)의 수행 방법을 정리해 놓은 개발방법론, 가이드, 툴 등도 있다. 효율적인 프로젝트 수행을 위해서는 이러한 기법 활용이 필수적이다. 

SI(System Integration) 중심에서 애자일과 UI/UX를 강조하는 솔루션 형 소프트웨어로 변화하고 있는 요즘에는 새로운 기법들이 주목을 받고 있다. 고객(사용자)의 요구사항을 개발자 관점으로 정리하던 SI와 달리 고객의 관점으로 정리하는 것과 소프트웨어를 시스템 관점이 아닌 비즈니스 관점으로 설계하는 것이 그것이다. 이번 회에서는 고객의 관점으로 요구사항을 정리하는 기법과 소프트웨어를 비즈니스 관점으로 설계하는 기법에 대해 살펴보고자 한다.

고객 관점의 요구사항 정리 기법 

SI와 솔루션에서 개발 방법은 크게 다른 점은 없다. 기획 단계나 완성 후에 릴리이즈 하는 방법이 다르기 때문에 개발방법론 혹은 프로세스에서 다소 차이가 있다고 볼 수 있다. 하지만, 개발자가 고객의 요구사항을 정리하는 방법은 SI와 많은 차이를 보이고 있다. 이번 절에서는 개발자가 고객 관점으로 요구사항을 정리하는 기법에 대해 살펴보도록 한다. 전통적인 소프트웨어 개발 프로젝트는 SI가 많다. 고객의 요구사항에 맞춰 약속된 일정에 개발해야 하기 때문에 요구사항을 어떻게 정리하고 관리할 것인지가 매우 중요한 포인트였다(그림 1 참조). 


<그림 1> 고객 요구사항의 흐름 


<그림 1>를 살펴보자. RFP(Request for Proposal 혹은 Reference for Proposal)는 제안을 받기 위한 고객 요구사항을 명시한 문서다. 제안서는 RFP를 참고해서 작성하는 것이 정석이고, RFP에 포함된 요구사항을 제안서에 모두 반영해야 한다. 고객의 지식으로 RFP를 작성하기 어려울 경우 더 쉽게 기술된 RFI(Request for Information)를 작성한다. 

개발자는 고객의 요구사항을 구두나 문서로 확인하고 제안서를 작성한다. 고객은 개발자에게 “난 잘 모르니까 알아서 잘 만들어 주세요!”라고 하면, 개발자는 경험과 상상에 의존하여 제안서을 제출한다. 바로 여기서 문제가 발생한다. 고객이 원하는 것이 무엇인지 확인하면서 정리해야 하는데 이 과정이 간과되는 것이다. 

사용자스토리 워크샵

최근에는 소프트웨어를 기획하는 단계부터 고객과 함께 고객의 용어로 정리하는 사용자스토리 워크샵이 확산되는 추세다. 고객과 함께 의사소통하며 기획하기 때문에 요구사항에 대한 명확한 정리가 가능하다. 커뮤니케이션을 중요시하는 애자일 기반 프로젝트에서 처음 알려진 사용자스토리 워크샵은 소프트웨어 기획 단계부터 고객을 참여시켜 고객이 원하는 바를 체계적으로 정리하는데 목적이 있다. 

<참조사이트 소개>


사용자스토리 워크샵은 고객의 요구사항을 정확히 이해하고 명확히 소프트웨어에 반영하기 위한 도구라고 할 수 있다. 개발자는 소프트웨어를 개발하기 위해 요소기술만 알아서는 품질이 높고 사용자가 편한 소프트웨어를 개발할 수 없다는 것을 명심해야 한다. 사용자스토리 워크샵을 통해 고객의 요구사항을 잘 정리해도 소프트웨어에 잘 반영하지 못하면 소프트웨어의 품질과 고객의 만족도는 떨어질 것이다. SI에서도 많이 활용되던 요구사항추적표는 정리된 요구사항이 언제, 어떻게 반영되었는지 확인할 수 있게 한다. 

작성자:

댓글 없음 :

댓글 쓰기

피드 구독하기: 댓글 ( Atom )