프로젝트 관리 완벽 가이드 3편: 안녕하세요? 독자 여러분. 오늘은 프로젝트 관리 완벽 가이드 3편, 프로젝트 이해관계자 및 투입인력에 관해 알려드립니다. 프로젝트 목표를 달성하기 위해서는 이해관계자 간 원활한 협업이 필요하고 투입되는 인력들의 명확한 R&R에 따른 업무 수행이 필요헙니다. 어떤 이해관계자가 관여되는지 그리고 프로젝트가 시작되면 어떤 인력들이 투입되는지 자세히 알아보겠습니다.
프로젝트 이해관계자 및 투입인력
프로젝트 이해관계자
프로젝트 관리 완벽 가이드 2편에서 언급한 바와 같이 자체 인력으로 소화하기 어려운 SI 사업의 경우 입찰 공고를 통해 외부업체를 선정하여 사업을 진행하기 때문에 발주사의 의도와는 상관없이 이해 관계가 복잡하여 문제가 발생하기도 합니다. 아래 그림은 사업 공고를 통한 외부업체 계약 시 이해당사자간 관계를 도식화한 그림입니다.
통상적으로 수행사는 프로젝트 관리영역을 담당하고 UI/UX를 포함한 실제 구현은 협력사가 담당합니다. 이해관계자가 많아지면 이해관계가 복잡해져 여러 문제가 발생할 수 있는데요, 특히 개발 대금 지급 문제가 자주 발생하게 됩니다. 고객과 투입인력 간 직계약이 아닌 여러 중간 업체가 계약에 관련되어 있기 때문입니다. 또한 인력 용역 계약이 아닌 업무 단위 개발(턴키 계약)의 경우 고객과 수행사 간 대금지급 방법이 수행사와 하위 계약업체에도 동일하게 적용되는 경우가 일반적이라 선금 이후 중도금 또는 잔금을 받을 때까지 개발 대금을 받을 수가 없어 매달 개발 대금을 지불해야 하는 인력공급업체의 경우 대금 지급에 문제가 생길 수 있습니다.
협력사는 제안서 상에 협력사로 명시되며 통상적으로 주계약자와 턴키 계약(업무계약)을 맺게 되는데 협력사가 인력 용역 계약이 아닌 업무 계약을 맺는 이유는 여러가지 있지만 우선 사업 실적으로 남을 수 있으며 또한 개별적인 인력 용약 계약 대비 프로젝트 비용이 인정되어 계약금액을 좀 더 높게 받을 수 있습니다. 물론 업무 및 투입인력에 대한 책임도 커진다는 사실을 명심해야 합니다.
이해관계자 관계도에 표시되지 않은 이해관계자도 있는데요, 성능/부하테스트, 모의 해킹 전문업체, 웹접근성 점검업체, 감리기관 등이 있습니다. 통상적으로 이들 이해관계자들은 수행사가 별도 계약 체결을 하여 일정에 따라 과업을 진행합니다.
마지막으로 개발자 단가에 관해 잠깐 언급한다면, 개발자 단가는 한국 소프트웨어산업 협회(KOSA)의 노임단가 (초급/중급/고급/특급)에 근거하여 책정되고 주계약자가 투입인력의 등급 및 M/M를 고려하여 총액을 합산하고 합산한 금액에 할인율을 적용하여 최종 계약을 합니다. 물론 이 방식은 앞서 언급한 개발규모 산정 방식 중의 하나인 투입 공수 방식인 경우에 해당됩니다. 최근 KOSA는 등급에 따른 개별 단가를 관리하지 않고 직무별 평균임금만 공지하고 있으니 단가 산정 시 이를 참조하기 바랍니다.
프로젝트 투입인력
프로젝트 조직 및 투입 입력은 프로젝트 규모나 성격에 따라 달라지지만 기본적으로 관리 영역, UI/UX 영역, 개발 영역, 아키텍트/인프라 영역(DB, 인터페이스, TA/AA/SA 등), 전문가 그룹(성능, 보안, 감리 등) 그리고 발주사 TFT로 구성되며 초기에는 필수 인력(주로 PM, PMO, QA, 단위업무 개발 리더)만 투입되고 설계 단계가 끝날 때 실제 구현(디자인/퍼블/개발 등) 인력들이 투입됩니다.
투입되는 인력들은 스킬과 경험에 따라 특급/고급/중급/초급으로 나뉘며 등급이 높을수록 단가도 높고 경험과 스킬이 높은 것은 사실이지만 개발자 등급이 생산성과 직결된다고 보기는 어렵습니다. 왜냐하면 개발자 역량에 따라 중급 개발자가 고급 개발자 이상의 성과를 내는 경우도 많기 때문이죠.
전문가 그룹의 경우 수행사 자체적으로 처리하기 어려운 과업, 예를 들어 성능테스트, 보안, 감리 영역 등은 외부 전문 기관과의 계약을 통해 수행합니다. 프로젝트의 원활한 진행을 위해 발주사 TFT도 대단히 중요하지만 가끔 발주사 TFT의 부실한 프로젝트가 참여가 문제를 일으킬 수 있다는 점에 주의해야 합니다. 프로젝트에 투입되는 인력에 대한 각각의 포지션과 역할은 다음과 같습니다.
프로젝트 관리 그룹(Project Management Group, PMO)
프로젝트 관리 그룹은 프로젝트에 소요되는 모든 자원을 효율적으로 관리하고 단계별 프로젝트 진행 상황을 점검 및 조정하며 발주사 TFT를 포함한 각 자원들 간 원활한 커뮤니케이션을 통하여 주어진 시간 및 비용 범위에서 프로젝트 목표를 달성하는 것에 목표를 둔다. 분석, 설계, 개발(디자인, 퍼블리싱, 소스 코딩) 등의 실질적인 업무를 맡지 않고 시작부터 종료까지 연속적으로 발생하는 관리 차원 업무(진척관리, 위험관리, 변경관리, 품질 관리 등)를 맡게 된다. 프로젝트 관리 그룹에 속한 인력들은 프로젝트 관리자(PM, Project Manager), 사업관리, 품질관리자(QA, Quality Accurance) 등이 있으며 프로젝트 규모가 커질수록 역활과 책임이 커지는데요, 이 인력들의 역활과 책임은 다음과 같습니다.
프로젝트관리자(Project Manager)
- 프로젝트 총괄 책임자(계획 수립, 일정 및 진척관리, 리스크 및 위험관리 등)
- 고객 및 이해관계자와 의사소통을 담당하고 의견을 조율
- 프로젝트 관리자에 대한 더 자세한 정보는 [여기] 참조
사업관리자
- PM을 보조하여 전체 업무가 원활히 돌아갈 수 있도록 지원
- 도입장비 관리(하드웨어, 소프트웨어), 투입인력 관리(근태, 투입 및 철수), 문서 및 회의관리
품질관리자(Quality Assurance)
- 산출물 및 결과물에 대해 발주사거 요구하는 품질 수준을 보증하기 위한 활동 전개
- PM, PL 등과 수시로 의사소통을 하며 품질 수준을 유지
UI/UX 그룹(User Interface / User Experience Group)
최종 사용자가 웹/앱에 접속하여 사용하게 되는 화면을 개발하는 담당자로 구성됩니다. 우리가 흔히 은행 웹사이트에 접속하여 은행 업무를 보거나 휴대폰에서 은행 앱을 실행해서 업무를 볼 때 눈으로 직접 보는 화면을 만드는 것으로 생각하면 이해하기 쉽습니다.
각종 버튼이나 이미지가 아무렇게 배치되고 색상 또한 화려하게 보이지 않을 때도 있지만 여기에는 발주사의 UI/UX 철학이 담겨 있으며 법규 및 제도(웹접근성) 준수를 위한 다소 강제적 요소가 반영되어 있기도 합니다.
사업규모가 클 경우 보통 UI/UX 영역은 전문 에이전시가 주로 담당하는데 수행사가 UI/UX 영역 전문가를 보유하기 힘들기 때문이며 어떤 경우에는 전문 에이전시가 직접 수행사 역할을 하는 경우도 있습니다. 예전에는 그냥 사용자 인터페이스(UI)라고 했으나 요즈음은 사용자 경험(UX)을 중시해서 보통 UI/UX라고 불리며 구성 인력들은 다음과 같습니다.
기획자
- 프로젝트 리더와 함께꼐 발주사의 요구사항 검토
- 발주사와의 지속적인 의사소통(인터뷰 포함)을 통해 서비스 및 정책, 개선 포인트 도출
- 화면 설계(스토리보드)
- 통상적으로 대표 기획자가 UI/UX PL을 담당
디자이너
- 발주사의 UI/UX 가이드에 따라 화면을 디자인(페이지 헤더/풋터, 아이콘, 컬러, 구성요소 배치 등)을 담당
- 화면 설계에 앞서 “와이어프레임” 및 디자인 시안 작성
퍼블리셔
- 디자인 산출물을 이용해 웹 페이지 작성
- 휴대폰 용 앱을 구축할 경우 전체를 네이티브 방식으로 구현 시 웹페이지 퍼블리싱 영역을 불필요
개발 그룹(Developing Group)
분석/설계 단계에서 생성된 화면 및 프로그램 설계서를 바탕으로 프로그래밍 언어를 사용해 해당 업무 로직을 구현하는 인력들로 구성되는데, 업무 특성에 따라 다양한 프로그래밍 언어들이 사용되며 통상적으로 서버단 프로그램과 화면단(클라이언트단) 프로그램으로 구분되어 개발됩니다.
수행사는 개발 분량을 자체적으로 소화할 수 있는 인력을 상시 보유할 수는 없기 때문에 부족한 인력은 인력공급업체로부터 인력을 공급받아 개발에 임하는 것이 일반적입니다. 앞서 언급한 바와 같이 인력공급업체 또한 또 다른 인력공급업체로부터 인력을 공급받아 수행사로 공급하는 경우가 빈번하게 일어나고 있기 때문에 프로젝트 이해관계자는 더욱 복잡해지고 개발자로 인한 문제 발생도 자주 발생합니다. 구성 인력은 다음과 같습니다.
프로젝트 리더(Project Leader, PL)
- 분석/설계 단계부터 개발과 관련하여 발주사와 직접 담당업무 개발 리딩
- 실제 코딩을 담당하는 개발들이 설계 산출물에 근거하여 개발할 수 있도록 가이드 제공
- 테스트 단계에서 결함이 발생하면 결함 처리 담당자를 지정하고 대응 관리
- 개발 범위가 클 경우 단위 업무 별로 PL을 두기도 하며, PL의 역량에 따라 다르긴 하지만 제 경험 상 1명의 PL이 통제할 수 있는 개발자는 10명 이내가 적합
개발자
- 프로그래밍 언어를 사용해 설계 상의 기능을 구현
- 네이티브 구현 시 안드로이드 및 IOS 개발자 필요
아키텍트/인프라 그룹(Architect/Infra Group)
업무 자체가 특정 단위 업무에 국한되는 것이 아니라 시스템 또는 프로젝트 전반에 공통으로 적용되는 것들도 있는데 보통 이런 업무를 담당하는 그룹을 아키텍트/인프라 그룹(또는 시스템 공통 그룹)으로 명명합니다. 여기에 속한 인력들은, 개발(코딩) 자체가 아니라 프레임워크나 DB, 운영체제, 하드웨어/소프트웨어, 네트워크, 솔루션 등 개발을 위한 표준, 구조, 환경, 인터페이스 등에 대한 정의 및 설계를 담당합니다.
발주사 TFT(Task Force Team)
프로젝트의 원활한 진행을 위해 발주사에서 프로젝트와 관련된 업무 담당자를 선별하여 일시적으로 프로젝트에 참여합니다. 발주사 현업 및 ICT 인력으로 구성되며 요구 사항 정의, 테스트, 각종 인프라 지원, 진행 사항 검토 및 평가, 수행사 요청사항 해결 등을 담당합니다. 발주사 TFT 인력도 수행사 인력 못지않게 중요하다는 사실을 명심해야 하는데요, 발주사 TFT 소속으로 프로젝트에 참여하지만 원래 하던 업무가 TFT 참여 기간동안 중단되지 않는 이상 본연의 업무에 더 충실할 수밖에 없기 때문에 분석/설계 시 정확한 요건 반영을 못하고 개발 도중에 요건 변경이나 추가를 하는 경우가 자주 발생하기 때문입니다.
상기 명시된 인력 이외에도 솔루션 도입 시 해당 솔루션 전문가(대개는 제품 공급사의 시스템/소프트웨어 엔지니어), 외부전문기관 인력도 도입 시기에 맞춰 투입됩니다. 계약 기간에 맞춰 투입인력은 프로젝트 장소에서 상주 또는 비상주 근무를 하게 되는데 보통 개발 장소에서 상주 근무가 원칙이나 업무 특성이나 상주 근무가 비효율적인 경우 발주사와 합의하여 비상주로 근무할 수 있습니다. 제안사는 제안서 작성 시 주요 투입인력에 대한 정보(근무 및 개발 경력 포함)를 제공하며 상주/비상주에 대한 내용을 명시해야 합니다. 특히 제안서에 명시된 주요 투입인력은 반드시 투입해야 인력 투입에 대한 문제 발생을 방지할 수 있으며 일반 개발자의 경우 프리랜서인 경우가 많아서 프리랜서 특성 상 제안서에 명시하기 어려운 경우가 많습니다.
맺음말
이상으로 프로젝트 관리, 세 번째 시간으로 프로젝트 이해관계자 및 투입인력에 대해 살펴 보았습니다. 이해관계자가 많을수록 프로젝트의 리스크는 커지므로 효율적인 관리가 필요하며 특히 실제 개발을 담당하는 개발자들에 대한 관심과 지원을 통해 프로젝트가 일정대로 진행될 수 있도록 해야 합니다. 다음 글에는 [프로젝트 단계별 과업]에 대해 알아보기로 하겠습니다.