백곰술사의 IT Insight

안녕하세요.

반복적 개발 방법론으로 프로젝트를 수행하며

이 방법론이 현장에서 어떻게하면 잘 활용될 수 있는지 생각해 보았습니다.

저는 금융사에 재직 중이며 금융사 시스템은 결합도가 굉장히 강합니다.

따라서 서브시스템의 결합방식인 증분형은 실질적으로 불가능하기에 프로젝트에서 사용하지 않습니다.

보통은 진화형 반복적 개발 방법론을 사용합니다.

진화형 반복적 개발 방법론은 보통 고객의 요구사항이 불명확할 때 사용하며

운영계에 단계적으로 배포되며 고객의 요구사항을 반복적으로 수용 개발해 진화해 나갑니다.

하지만 우리가 이론적으로는 아래와 같은 개념도로 단순하게 생각할 수 있지만

이 방법론이 현장에서 성공하려면 꽤 많은 한계와 고려사항이 있습니다.

제 경험을 토대로 내용을 공유해 보겠습니다.

1. 핵심요구사항을 개발하는 1차 배포의 품질 기준

 핵심요구사항을 개발하는 1차 최초 배포의 품질 기준은 어느정도 수준일까요?

 반복적 개발 방법론이기에 1차 최초 배포의 품질 기준을 낮게 잡을 수 있을까요?

 배포라는 것은 운영계에 배포되어 실제 사용자가 사용한다는 것을 뜻합니다.

 요구사항이 빈약해 아주 낮은 수준의 품질을 운영계에 배포하는 것은 아래와 같은 문제점을 야기하게 됩니다.

  1) Data Modeling이 틀어질 가능성이 매우 높습니다.

     - 초기 품질이 매우 낮았기에 요구사항이 늘어날수록 기존 테이블들의 변경이 야기됩니다.

  2) 스파게티 코딩이 늘어납니다.

     - 로직이 지속적으로 변경되니 당연한 결과입니다.

 반복적 개발 방법론을 사용하며 효과를 내려면

 요구사항 협의가 완료된 기능(Function)기준으로 배포하거나,

 요구사항이 빈약하더라도 RFP/Reference 기준 100%의 품질을 예상 후, 그 기준에서 90%품질 이상으로 배포되어야 합니다.

 고객이 일단 개발 된 것 부터 빨리 운영계에 배포해달라고 하는 요청이 지속적으로 옵니다.

 하지만 품질확보를 하지 못한 1차 운영계 배포는 첫단추부터 잘못 꿰메는 것이라 두고두고 이후 개발이 고통스러울 것입니다.

 배포 품질 기준은 꼭 고려해야할 가장 최우선 요소입니다.

2. 수행사가 프로젝트의 환경에 익숙한가?

 반복적 개발 방법론은 폭포수 모델처럼 분석-설계-개발-테스트-배포가 순차적으로 진행되어 한번에 끝나지 않습니다.

 일정을 분할해 폭포수 모델이 반복적으로 배포됩니다.

 그런데 수행사가 수행 환경에 익숙하지 않다면?

 실질적으로 설계/개발을 주도하는 분들은 PL/개발자분들입니다.

 현 프로젝트 환경에 익숙하지 않은 분들은 요구사항이 주어지는대로 빠르게 설계/개발 및 배포할 수 없습니다.

 정직원들이 Agile을 이루어 직접 개발하는 곳은 이런 이슈가 없겠지만

 아직 금융사 뿐만 아니라 타 업종 대기업들은 거의 OS를 통해 개발하는 것이 현실입니다.

 적응기간이 필요합니다.

 따라서 반복적 개발 방법론을 사용하려 할 때는

 수행사 구성원들의 수행Reference를 확인하고 구성원을 최적화한 뒤 수행해야 합니다.

3. 일정의 터프함은 구성원들을 지치게 한다.

 반복적 개발 방법론을 활용할 때 PM들이 제일 많이하는 행동입니다.

 "1차 배포에 대한 요구사항은 전체 대비 20%수준입니다.

 따라서 전체 일정 대비 20%의 공수를 가지고 진행하겠습니다."

 이론적으로는 맞는 말입니다.

 하지만 반복적 개발 방법론의 핵심은

 일정관리 측면에서 폭포수 모델 같은 고전적 방법론 보다 더 긴 개발 일정이 필요합니다.

 많은 PM들이 이 부분을 간과하고 반복적 개발 방법론을 채택합니다.

 한 번의 SDLC 수행 간 개발자들이 얼마나 많은 피로도가 쌓이는지는 분명 아실겁니다.

 혹자들은 초기 요구사항이 빈약하지만 일정을 맞추고 고품질의 산출물을 달성하기 위해 사용하는 방법론이 아니냐? 라고 하지만

 반복적 개발 방법론을 사용해보신 분들은 아실겁니다.

 수 번의 SDLC가 반복되는 프로젝트는 개발자가 피로감에 중간에 다 나갑니다.

 결론적으로 Risk가 더 높아지는 것이 현실입니다.

 이런 부분이 이론과 현실의 차이입니다.

 다시 말씀드리면

 반복적 개발 방법론의 일정 산정은 고전적 폭포수 모델보다 더 산정되어야 합니다.

 초기 요구사항이 빈약한 만큼 배포 주기를 조금은 러프하게 가져가야 합니다.

 주어진 일정이 버퍼가 없다면 반복적 개발 방법론은 선택하지 않는 것이 좋습니다.

프로젝트를 수행하며 가장 중요한 관리영역은 범위관리, 일정관리도 아닌 이해관계자 관리일 것 입니다.

"열 길 물속은 알아도 한 길 사람 속은 모른다"

이해관계자 관리만은 다른 관리영역과 다르게 사람의 마음이 주가 되는 영역입니다.

서로 우호적이었던 관계도 급작스럽게 나빠져서 프로젝트가 망가지는 것은 다반사이며 최악은 드랍이 되기도 합니다.

그만큼 PM의 이해관계자 관리 역량은 중요합니다.

제가 경험한 이해관계자 관리 핵심요소는 아래와 같습니다.

(이해관계자 식별, 통제, 관리 등의 일반적인 관리기법이라기 보다는 실제 경험상 중요했던 점입니다.)

1. 서로의 역할에 대해 명확히 해야한다.

 프로젝트를 처음 시작하면 RACI매트릭스를 만들어 각 이해관계자의 역할 및 책임을 명확히 하는 것이 중요합니다.

 특히 이해관계자가 많아지면 각자의 의견이 다른 부분이 많기에 각자의 권한과 역할이 명확하지 않을 시

 프로젝트 중간에 의사결정 및 요구사항이 흔들리게 되며 일정 지연 등의 결과로 귀결될 가능성이 많습니다.

 [참고] RACI Matrix
  정의 : 프로젝트에서 이해관리자들이 담당하는 역할과 책무를 매트릭스 형태로 기술하는 모델

• Responsible: 프로젝트의 "실무자"인 사람 또는 관련자. 이들은 반드시 과업 또는 목표를 완수하거나 의사결정을 내린다. 여러 사람들이 공동으로 책임을 질 수 있다.
• Accountable: 프로젝트의 "소유자"인 사람 또는 관련자. 이 사람은 반드시 과업, 목표, 의사결정이 완료되었을 때 승인이나 승낙을 제공한다. 이 사람은 반드시 모든 관련 활동에 관한 행렬에서 책임이 할당될 수 있도록 해야 한다. 성공을 위해서는 한 사람만이 책무를 담당해야 하며 그 사람이 바로 "책임을 지는 사람"이 되어야 한다.
• Consulted: 프로젝트를 처리하고 승인하기에 앞서 투입요소를 제공해야 하는 사람 또는 관련자. 이런 사람들은 "중심 인물"이며 능동적인 참여자이다.
• Informed: "관련"되어야 하는 사람 또는 관련자. 그들은 진척상황 또는 의사결정에 관한 업데이트를 필요로 하지만 공식적인 컨설팅을 필요로 하거나 과업 또는 의사결정에 직접 기여할 필요는 없다.

2. 이해 관계자의 언어로 소통하자.

 프로젝트에는 다양한 유형의 이해관계자가 존재합니다. 회사관리자, 실무 현업, IT 현업, PM, PL 등

 일례로

 실무현업과 회의 시에는 Flow Chart등을 기반으로 프로세스를 얘기하는 것이 좋습니다.

 테이블과 프로그램 목록 등은 실무현업이 잘 알지 못하고 이해할 필요도 없기에 오히려 소통에 방해가 됩니다.

 IT현업과 회의 시에는 화면설계서, 인터페이스 정의서 등 실질 개발과 관련된 자료가 기반이 되어야 합니다.

 IT현업 입장에서는 데이터 구조 및 개발자원 등이 더 중요하기 때문입니다.

 학에게 평평한 접시로 음식을 대접하면 음식을 제대로 먹지 못하는 이솝우화를 떠올리면 됩니다.

 항상 상대방의 관점에서 효율적인 의사소통 형태로 소통해야 합니다.

3. 이해관계자와 우호적 관계를 유지하자.

 어떻게보면 프로젝트에서는 이해관계자와의 우호관계가 가장 중요합니다.

 관계에 따라 잘 안되는 프로젝트도 성공으로 이끌 수있고, 잘되는 프로젝트도 지연될 수 있습니다.

 이 부분은 어떤 관리기법이 있는 것은 아닙니다.

 이해관계자가 좋아하는 부분을 같이 공감해주고 소통해주면 그것으로 충분합니다.

 이해관계자가 회식을 좋아한다면 회식을.

 이해관계자가 학문을 좋다한다면 관심분야에 대한 얘기를.

 이해관계자가 피로함을 느낀다면 해소할 수 있는 휴식을.

 이해관계자와의 우호관계는 프로젝트 상 부족한 점도 수월하게 넘어갈 수 있는 원동력이자 핵심요소입니다.