프로젝트의 시작, PM 으로써 무엇을 먼저하는가?

728x90

본 글은 필자의 경험과 교육, 세미나를 통해 얻은 지식을 바탕으로 공유하는 내용입니다.

Project Manager VS Product Manager

SW 관리자를 우리는 보통 PM 이라 부른다. 명확하게 PM 이 지칭하는 역할이 Project Manager 인지 Proudct Manager 인지를 확인해보고 싶다. 두 직무는 명확히 다른 목적을 가진 업무로 헷갈리지 않기를

PM vs PM

SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다.

물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다.

나는 내부 SW 개발 프로젝트를 참여하면서 그 누구도 그것을 하는 사람을 보지 못했다.

다들 운영을 하고 있던 프로젝트라 신경을 쓰지 않았던 부분이 컸을 것이라 생각한다.

"프로젝트 헌장"

이것에 대해 말하고자 한다.

프로젝트 헌장은 어떠한 프로젝트를 진행할 것이며 그에 따른 책임과 권한 등 모든 내용이 수록되어 있고 고객과 스폰서로부터 승인받아야 프로젝트를 시작할 수 있는 거창한 문서이다. (PMBOK 통합관리 부분에 언급되었을 것이다.)

하지만 필자는 이론 기반의 이상적인 프로젝트나 한국형 SI 프로젝트를 말하고 싶지 않다. (<- 정석대로 시키는 대로 하면 됨. 짜증 날 뿐)

회사 내부의 개발 또는 운영 프로젝트에서 필요로 하는 실용적인 프로젝트 헌장에 대한 개인적인 의견이다.

PM(TPM)의 업무 시작, 프로젝트 헌장 만들기

SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다. 물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다. 특히 구축 프로젝트에서 만

PMP

들어가기

PMBOK 에서는 프로젝트 헌장을 개발한다는 표현을 사용한다.

당연하듯 Input 과 Output 이 있고 Develop 라는 단어를 사용한다.

하지만 우리는 신규 구축보다 운영 프로젝트를 더 많이 다루게 될 것이고, 기존에 정의되지 않는 프로젝트의 모습을 구체화하여 문서로 남기는 것이 프로젝트 헌장이 될 것이다.

참고용

PMBOK 의 프로젝트 헌장 개발 프로세스

출처 : https://www.project-management-prepcast.com/pmp-itto

PMBOK 에서 언급하는 좋은 프로젝트 헌장과 필자의 버전을 비교해본다.

(아래 더보기 버튼)

PMBOK Project Charter (프로젝트 헌장)	욘나빠른, 프로젝트 헌장
Project purpose or justification 프로젝트 목적 또는 정당성	N/A - 이미 운영중인 프로젝트 대상으로 생략
Measurable project objectives and related success criteria. 측정 가능한 프로젝트 목표 및 관련 성공 기준	프로젝트 목표 - Product 와 Project 구분하여 작성 프로젝트 평가
High level requirements 상위 수준 요구사항	N/A - 이미 운영중인 프로젝트라 백로그로 관리 됨.
Assumptions and constraints 가정과 제약 사항	리스크 관리
High-level project description and boundaries 상위 수준의 프로젝트 정의 및 한계	프로젝트 목표 버전관리
High-level risks 상위 리스크	리스크 관리
Summary milestone schedule 요약된 마일스톤의 일정	N/A - 프로젝트 계획서에 단계별 명시
Summary budget 요약된 예산	N/A - 프로젝트 계획서에 단계별 명시 - M/M에 의한 예산 고정 할당
Stakeholder list 이해관계자 목록	커뮤니케이션
Project approval requirements 프로젝트 승인 요구사항	N/A - 이미 운영 중인 프로젝트 대상으로 생략
Assigned project manager PM 지정	프로젝트 구성
Project Sponsor 프로젝트 스폰서	N/A - 내부 프로젝트로 지정하지 않음.

* PMBOK Project Charter 참고 : www.projectengineer.net/the-elements-of-a-project-charter/

The Elements of a Project Charter

Before a project even begins, a project charter is a document that incorporates the project and appoints the project manager. Many projects operate without a project charter, even multimillion doll…

www.projectengineer.net

실제 1:1 비교가 되지 않아 그다지 필요 없는 자료인것 같다.

이제부터 개인적으로 프로젝트를 운영하면서 필요한 부분을 명시한 프로젝트 헌장에 대해 살펴본다.

제목 : 프로젝트 헌장

부제목 : OOOO 프로젝트 (or TF)

프로젝트 목표
프로젝트 구성
개발 프로세스
커뮤니케이션
리스크관리
버전 관리
프로젝트 평가
비상 연락 체계
별첨 - 프로젝트 운영 / 장애 대응 / 관련 문서 등등

1. 프로젝트 목표

프로젝트 목표는 현재 진행 중인 또는 진행할 프로젝트의 목표에 대해 명시하여 프로젝트가 산으로 가는 것을 방지하는 목적으로 사용을 한다.

필자는 프로젝트의 목표를 3개의 카테고리로 구분하여 명시하였다.

아래 3개 목표를 정의하여 구성이 모두가 같은 방향을 바라보고 업무에 임할 수 있도록 환경을 조성하는 것이 중요하다고 생각한다.

제품 (Product)

제품의 도메인에 따라 프로젝트 시작 전 목표한 제품의 포지션이 있을 것이다.

해당 포지션에 도달하기 위한 비전과 미션들이 명시될 수 있다.

타이틀로는 슬로건을 1개 정도 정의하여 프로젝트 인원들이 언제 어디서든 인지할 수 있도록 하면 좋을 것이다.

(카피라이팅이 중요함)

ex> 기업 사용자에 최적화

필자는 현재 제품이 개인에게도 유용하지만 기업 사용자를 위한 기능에 집중하기 위해 기업 사용자라는 유저 부분에 강조하여 의사 결정이나 요구사항 수집/분석 시 제품의 방향과 일치하는가를 검토하였다.

프로젝트 (Project)

프로젝트 운영 또는 개발 목표 구현을 위한 지침 등을 명시하여 프로젝트 운영의 일관성을 유지하는 데 사용한다.

보통 정의된 내용은 개발팀 모두가 이미 알고 있지만 지키지 못하는 내용들과 귀찮은 것들이 언급되었다.

그래서 항목이 많다.

ex> 품질 안정성 확보

고객의 요구사항도 중요하지만 품질에 영향을 줄 수 있는 항목은 다시 한번 검토하고 내/외부 상관없이 품질에 대한 이슈가 발견되면 즉각적으로 대응해야 하는 것을 명시했다. 개발 항목 도출과 체크리스트 작성 등을 명시해뒀다.

ex> 투명성 확보

프로젝트가 오랜 시간 유지된 경우 당연시 여기는 항목들이 하나둘씩 생기면서 대수롭지 않게 생각하거나 또는 관련자 몇몇만 공유하고 끝나는 모습들을 목격했다. 그래서 정의되지 않은 항목에 대해서는 무조건 전체 공유할 것을 강조했다.

이슈는 투명하고 공유되고 이력 및 진행 사항이 지속적으로 트래킹이 될 수 있어야 한다.

ex> 공유, 리뷰의 습관화

투명성과 유사하지만 약간 다른 부분이 업무에 대한 언급이다.

모든 업무는 대시보드나 현황판을 통해 지금 무엇을 하고 있는지 서로 알 수 있도록 해야 한다. 스크럼에서 데일리 미팅으로 커버할 수 있다.

또한 개발을 완료한 항목은 리뷰를 통해 요구사항에 부합하는지 체크할 것을 명시하여 누락되거나 잘못 개발되는 부분을 사전에 체크할 수 있도록 명시했다.

ex> 개발 속도 유지

프로젝트 매니저의 중요한 업무 중 하나이지만 누락되는 경우가 많고 속도 측정 및 관리가 쉽지 않다.

그래서 간단하게 개발팀이 무리하지 않고 개발행위를 유지할 수 있도록 항목을 정의했다.

(야근은 지양하고 불가피한 경우 23시 이전까지만 허용, 개발 리소스는 80% 기준으로 일정 수립 등)

구성원 (Members)

프로젝트에 대한 운영 방침이 정해지면 실천을 위해 구성원(멤버)들이 지켜야 할 항목이 따라온다.

ex> 상호 존중과 원칙 준수

구성원 서로는 서로를 전문가로 인정하고 존중해야 업무에 있어 상호 의견을 존중할 수 있다.

자기주장을 강하게 말하기보다는 경청하는 자세를, 타인의 의견에 반대보다는 대안(개선) 책과 이유를 제시해야 한다.

그리고 누구 하나 특별함을 인정하지 않음으로써 평등관계를 유지해야 한다.

ex> 익숙해지지 않기

프로젝트 운영의 최대의 강적이다. 익숙해지는 순간 문제가 발생하기 마련이다.

업무(개발, 기획, 디자인 등) 진행에 앞서 반드시 담당자와 한 번 더 확인 절차를 거쳐야 한다.

회의가 끝나면 반드시 Action Item 에 대한 정의 및 할당이 진행되어야 하고 주체자는 Action Item 에 대한 일정을 관리해야 한다.

이슈의 경중은 내가 판단하는 것이 아니라 우리 모두가 함께 판단해야 한다.

2. 프로젝트 구성

프로젝트를 구성하는 인력에 대한 내용을 정의한다.

개발 분야와 담당 파트, 업무 상세를 이름과 함께 작성을 한다.

프로젝트에 100% 투입되지 않고 지원하는 멤버도 명시하여 프로젝트에 대한 소속감을 줄 수 있도록 해야 한다.

조직에 따라 사일로(Silo), 스쿼드(squad), 스크럼(Scrum) 등 여러 형태로 구성될 수 있기 때문에 그에 맞는 역할과 구성원을 잘 명시하도록 하자. 조직의 특성을 나타내는 역할을 수행하기도 한다.

개발팀 인원은 언제든 퇴사/충원이 발생할 수 있기에 TO 관리도 함께하여 인원이 부족한 파트나 여유로운 파트에 대한 체크가 되어야 한다.

인원 변동이 있을 경우 변경 날짜와 이전 이력도 관리하면 좋다.

변동 이력은 나중에 프로젝트 속도나 비용 분석에 근거 데이터로 사용할 수 있을 것이다.

3. 개발 프로세스

PM이 가장 먼저 정립하고 안착시켜야 할 주요한 업무가 개발 프로세스일 것이다.

회사의 정책과 기존 프로젝트의 방식 등을 고려하여 한 번에 갈아엎는 것이 아니라 점진적 개선을 꾀해야 한다.

필자는 여러 개발 방법론과 프레임워크 중에서도 SCRUM 을 선호한다.

스크럼은 쉽게 받아들일 수 있는 애자일 프레임워크이며 개발팀의 거부감과 귀찮음도 최소화하기 좋은 범용적 프레임워크라 생각한다.

개발 프로세스에서 반드시 명시해야 될 항목은 프로젝트의 시작과 끝이다.

운영 프로젝트라 하여 지속적으로 일만 한다는 느낌을 받게 된다면 성취감이 낮고 피로 누적의 주범이 될 수 있기에 주의했으면 한다.

이를 방지하기 위해 구성원과 이해관계자들에게 시작과 끝을 알리고 성취감을 느낄 수 있도록 하자.

현재 다니는 회사 정책에 의해 모든 프로젝트는 3개월 단위로 단계별 프로젝트 계획을 수립하고 진행하도록 가이드하고 있다.

이를 기반으로 2개월 개발, 1개월 검증이라는 큰 틀을 만들고 2개월 개발 기간 내 2주 스프린트를 운영하는 방안을 만들었다.

2개월 개발

1주 : 준비

프로젝트 진행을 위해 선정된 테마를 구체화하는 작업이 진행되고 개발 가능 여부와 일정들을 피드백받아서 진행할 업무를 Fix 한다.

테마에 대한 백로그가 정의되었다고 해서 무조건 하는 것이 아니라 스프린트 진행 상황에 따라 백로그는 여전히 변경될 가능성이 있다.

변동 가능성은 준비 시점부터 감안하고 프로젝트를 진행해야 한다.

8주 : 개발

보통 4번의 반복(Iteration)되는 스프린트가 운영된다.

스프린트 기간에는 Fix 된 백로그 기반으로 움직이게 되고 변경사항이 발생하지 않도록 내/외부 통제가 진행되어야 한다.

개발팀은 백로그 구현을 위해 주기적인 회의와 리뷰를 진행하고 구체화 작업을 통해 동작 가능한 단위의 개발 산출물을 만들어 내야 한다.

백로그 정제가 잘 되었다면 매 스프린트마다 동작(시연) 가능한 산출물이 나올 것이다.

4주 : 검증

스프린트 기간에 작업된 항목들이 통합되어 Alpha 테스트를 진행하는 기간이다.

3일~5일간의 개발자 통합 테스트를 진행하고 3주간 시스템 테스트를 진행하도록 설계하였다.

시스템 테스트 기간에는 품질팀의 통제에 따라 이슈 처리와 배포가 이루어진다.

Alpha 테스트 진입 시점부터 Grooming 작업이 진행될 수 있도록 관리해야

Beta 테스트 진입 시점부터 새로운 프로젝트의 시작을 준비할 수 있다.

Beta 테스트

Alpha 테스트가 PASS 되면 베타 테스트를 진행한다.

Beta 테스트는 개발 프로세스와 별개로 운영되기 때문에 현시점에 개발팀은 다음 프로젝트를 준비하게 된다.

Beta 테스트의 목적은 사용성과 다양한 환경에서의 안정성을 검증하는 단계로 사용한다.

사내 직원 또는 파트너사 대상으로 진행하고 필요에 따라 일부 고객사에 도움을 청하기도 한다.

Beta 테스트에서 수집된 피드백은 PO와 품질 담당자에게 전달하고 다음(or 이번) 프로젝트에서 반영할지 검토를 진행한다.

Beta 테스트 진입 시점에 업데이트에 대한 고객 공지를 진행한다.

업데이트

Beta 테스트에서 Critical 이슈가 확인되지 않으면 실제 고객에게 배포하는 업데이트 작업을 진행한다.

프로젝트 개발 기간에 진행되기 때문에 내/외부 일정을 반드시 고려해야 하며 서비스 이용에 불편이 발생하지 않도록 해야 한다.

(한 회사에서 여러 개의 프로젝트가 진행될 수 있으니 일정을 미리 확인해야 한다.)

필자는 화요일을 업데이트 날짜로 선정하여 월요일 준비 시간과 이슈 대응을 위한 수~금요일을 확보할 수 있도록 하고 있다.

4. 커뮤니케이션

프로젝트 진행에 있어 구성원과 이해관계자 간의 의사소통은 필수적인 항목이다.

하지만 의사소통 창구가 정의되어 있지 않거나 일원화되어 있지 않을 경우 중구난방으로 의견들이 오가고 정리가 힘들 수 있다.

커뮤니케이션에 대한 방법과 채널을 정의하여 혼선 방지에 신경을 써야 한다.

4.1. 커뮤니케이션 종류

리뷰 (Review)

리뷰는 개발 프로세스에 가장 중요한 커뮤니케이션 방법이다.

백로그에 대한 상세 내용을 리뷰하고 피드백을 받아서 완성도를 높여야 한다.

리뷰는 문서 리뷰와 개발 리뷰 2가지로 분류하여 리뷰 방법에 대해 정의했다.

문서 리뷰

문서는 1일 전 배포하여 담당자들이 Inspection 형태의 개별 리뷰가 진행될 수 있도록 한다.

문서 리뷰 당일 주체자는 주요 항목에 대해 언급을 하고, 참여자들은 개별 리뷰 시 체크한 항목을 확인하는 방식으로 시간을 절약하도록 한다.

(사전 리뷰가 없으면 리뷰 시간은 2~3시간은 훌쩍 넘어가서 시간 낭비가 발생할 수 있다.)

리뷰가 완료되면 품질 담당자는 해당 백로그(유저 스토리)의 완료 조건을 추출하고 개발자는 업무 태스크를 세분화해야 한다.

(Conversation 과 Confirmation 이 작성되는 시점이다.)

개발 리뷰

백로그(유저 스토리)에 대한 개발이 완료되면 Demo 형태의 개발 리뷰가 진행된다.

개발 담당자가 백로그에 대해 간단히 설명하고 동작에 대한 데모를 진행하게 된다.

PO 는 요구사항에 부합하는지 체크를 진행한다.

동료 개발자들은 통합과 관련 부분을 미리 체크해두고 예외 케이스에 대한 피드백을 주고받을 수 있어야 한다.

회의 (Meeting)

회의는 대면/비대면 구분하지 않고 정기 회의와 비정기 회의로 구분할 수 있다.

회의의 목적은 공지 및 주요 내용의 전달과 특정 주제에 대한 의견의 일치성들을 체크하기 좋은 방법이다.

정기 회의

주로 주기적인 일정(진행 사항) 체크와 공지 사항들을 공유하기 적합하다. 따라서 불필요하게 긴 시간을 사용할 필요 없다.

데일리 미팅 : 업무 진행 사항 공유 목적으로 각자 개인당 1분 정도의 시간을 할당한다.

주간 회의 : 스프린트 진척사항 및 회사 내외부 공지 사항을 공유한다.

종료 보고 : 의사결정권자(스폰서)를 참여시켜 진행된 내용을 보고하고 피드백을 받는다.

비 정기 회의

이슈에 의해 진행되는 회의가 많다고 생각한다.

새로운 요구사항 인입에 따른 내부 의견 수집이나 기획/디자인/개발 관련된 이슈에 대한 논의 등 인스턴스한 형태로 진행된다.

이슈가 메인이 될 경우 반드시 Action Item 을 도출하여 마무리가 될 수 있도록 관리해줘야 한다.
비 정기 회의는 모든 구성원이 참여하는 것보다 관련자만 참여시켜 리소스의 낭비를 줄여야 하고 전파하거나 다른 사람에게 알려야 될 내용이 나온다면 주체자나 같은 파트 인원이 정리하여 전달될 수 있도록 가이드해야 한다.

4.2. 커뮤니케이션 도구

일반적으로 이메일과 회의록, 메신저를 이용하여 실시간 커뮤니케이션 및 업무 공유에 용이한 도구를 선택하여 사용한다.

이메일 (Email)

내/외부 관계없이 공식적인 커뮤니케이션 채널로 기록을 남기거나 공지에 적합하게 사용한다.

이를 위해 용도별 그룹메일을 생성하여 사용하는 것을 추천한다.

그룹 메일은 내부용과 외부용을 구분해야 하고 내부용은 가급적 외부로 유출되지 않도록 관리해야 한다.

예를 들어 필자는 아래와 같은 기본 그룹메일을 생성하여 사용한다.

- 개발 파트 단위 그룹 메일 : Frontend, Backend, Mobile, design, HW, Core, 기획

=> front.tf_code@mail.com backend.tf_code@mail.com, android.tf_code@mail.com ...

- 개발 그룹 메일 : 개발 파트 단위 그룹메일 모두 포함.

=> dev.tf_code@mail.com

- 마케팅팀 : 제품 홍보, 마케팅 담당자

=> mkt.tf_code@mail.com

- TF 전체 메일 : 개발 그룹 메일 + 마케팅팀 그룹메일을 포함

=> tf_code@mail.com

- 헬프데스크 : PO, SM(PM), QA, 고객지원

=> help.tf_code@mail.com

- 관리 복구 : PO, SM(PM)

=> mgr.tf_code@mail.com

- 시스템 알림 : 서비스 알림 및 장애 대응 담당자

=> system.tf_code@mail.com

- 공지 메일 : 서비스와 관련된 모든 담당자 또는 그룹메일을 포함.

=> notice.tf_code@mail.com

메신저 (messenger)

실시간 커뮤니케이션에 적합하고 업무나 파트별로 별도 공간을 만들어 메신저 폭탄 스트레스를 줄이는 것이 좋다.

예를 들어 현재 아래와 같이 운영한다.

- 전체 채널 : 공지나 알림 등 전체가 알아야 할 내용들만 선별하여 이용할 수 있어야 한다.

- 긴급 대응 : 모든 알림이 켜져있어야 하며 즉각적인 피드백 상태를 유지해야 한다.

- 업데이트 : 업데이트 시 모든 작업의 순서와 이슈가 공유되어 작업의 오류나 실수가 없도록 상호 감시/보안 용도로 사용한다.

- 각 개발 파트 채널 : 각 파트별로 업무 진행을 위해 자유롭게 그룹 채팅을 진행한다.

- 이슈 채널 : 이슈 대응을 위해 동시 다발적으로 생성이 될 수도 있으며, 완료 후에는 반드시 종료 처리하고 이력을 남기도록 한다.

- 고객 대응 : CS 파트의 기술 문의를 대응하고 이력이 관리되고 중복되지 않도록 유지해야 한다.

- 법인/지사 채널 : 타 부서나 해외 지사의 경우 유입되는 채널을 각각 하나의 메인 채널을 두고 혼선을 없앤다.

또한 메신저는 하나의 툴로 통합하고 플랫폼 종속성이 없는 제품을 선택해야 한다.

요즘은 협업 툴 중에서 워크스페이스 제공과 함께 채팅 기능을 함께 제공하여 프로젝트 운영에 유용한 툴이 많이 있다.

- 구글 채팅 : 구글 미트와 드라이브, 이메일 등 G-suite 에서 제공하는 통합 툴로 매력적이다.

- 슬랙 : 다양한 3rd-party 의 통합이 자유로워 개발 도구와 후킹을 통한 연동도 좋다.

- 기타... 개발 툴과 연동되며 그룹채팅 기능을 제공하는 제품이 너무 많다.

5. 리스크 관리

간혹 리스크와 이슈를 헷갈리는 사람을 본적이 많다. 헷갈리기보다 구별을 못하는 게 맞는 것 같기도 하다.

간단하게 설명하면 리스크는 잠재적 위험 요소로 드러나지 않은 항목이고 이것이 드러나면 이슈가 된다.

리스크는 내/외부 2개로 나누어서 정의하고 지속적으로 모니터링했다.

5.1. 외부 리스크

외부 요인에 의해 운영/개발 중인 프로젝트에 영향을 줄 수 있는 항목을 정의한다.

오픈소스나 플랫폼의 OS 버전, 시스템 사양 등의 항목이 있고

위 항목에 대한 변경이 발생할 때, 호환성 검증에 대한 계획을 수립하는 것이 외부 리스크 관리의 하나이다.

필자는 웹 기반 프로젝트를 진행하다 보니 브라우저의 업데이트가 늘 리스크로 존재하여 Alpha, Beta 출시마다 호환성 검증을 진행하도록 하였다. (실제 품질 담당자가 주도적으로 진행하여 신경 쓸 필요가 없을 정도였다.)

실례로, 크롬 80 베타 버전에서 갑자기 H.264 디코더 기능이 누락되어 이슈로 보고된 적이 있었다.

즉각 적으로 개발 담당자는 구글링을 통해 검색하고, 크로미움 프로젝트에 해당 이슈에 대해 등록하고 푸시하는 업무를 진행했다. 다행히 크롬 80 정식 버전에서 해당 코드가 원복 되었고 이슈는 종료 처리되었다.

또한 크롬뿐 아니라 모바일 OS의 업데이트나 외부 라이브러리의 버전업에 따른 호환성도 반드시 준비해야 한다.

그리고 클라우드 서비스나 IDC 를 이용하게 된다면 사업자들의 장애를 대비한 이중화 및 서비스 전환 계획을 수립하고 예행연습까지 완료시켜놓아야 한다. 도메인 특성에 따라 배상의 책임이 어마어마할 수 있는 부분이니 SLA 문서도 작성을 해두자.

필자 회사의 시스템 담당자들은 AWS 를 메인으로 MS Azure 와 Google IDC, KT Cloud, NHN Toast 등 다양한 서브 서비스 검토하고 테스트하고 있다.

장애 대응 매뉴얼과 비상연락체계가 리스크 관리로 포함된다.

5.2. 내부 리스크

회사(조직) 또는 개발팀 내부 위험요소를 찾아서 관리해야 한다.

리스크 관리도 개발팀 리소스가 포함된다는 것을 잊지 말고 20% 버퍼를 꼭 유지하기 바란다.

가장 먼저 눈에 띄는 것이 개발 인력의 변동이 될 수 있다.

일신상의 이유로 빈자리가 생길 경우 대체할 인력을 빠르게 충원하지 못하면 내부 리소스의 부하, 일정 지연과 연결되는 큰 리스크이다.

회사나 프로젝트에 여유가 있다면 인력의 80%로 운영될 수 있도록 계획을 수립하고 선임 개발자가 부족한 부분을 커버할 수 있도록 50%만 업무 투입하고 선행 기술 개발할 수 있도록 하는 것도 방안이 된다.

선임 개발자들 위주로 개발이 진행되면 개발 속도나 품질면에서 우수할지 몰라도 해당 개발자의 공백을 메우기는 더 힘들어질 수 있다.

두 번째로 빈번한 요구사항 변경에 따른 일정 변경 가능성이다.

고객은 자신이 무엇을 원하는지 모르며, 의사결정권자의 말 한마디는 프로젝트의 방향을 틀어버릴 수 있다. 따라서 개발 프로세스의 통제와 현재 진행 중인 사항을 리뷰하고 주입시키는 역할을 충실히 이행해야 한다. 이것은 리스크가 이슈로 발생할 수 있는 확률을 줄이는 예방이 될 수 있다.

하지만 이미 이슈가 된 상태라면 다음 Sprint의 계획을 변경하고 PO에 의해 백로그 연관성을 빠르게 검토하여 개발 전체의 방향이 틀어지지 않도록 중심을 잡을 수 있어야 한다. 이는 PO가 제품에 대해 얼마나 잘 이해하고 있냐 와 PO(PM)의 경험에 의해 영향도가 결정될 것이다.

따라서 프로젝트 계획을 수립할 때 PO와 함께 변동될 경우에 대한 "Plan B" 를 수립하는 것이 리스크 관리가 될 것이다.

6. 버전 관리

버전은 회사마다 정책이 다를 것이다.

회사 정책을 기준으로 상세 버저닝 규칙을 세워서 개발팀에서 브랜치(branch)나 머지(merge commit)에 혼선을 주지 않도록 해야 한다.

버전 관리(Version Control)의 목적은 형상관리(Configuration Management)가 제일 큰 목표가 아닐까 생각한다.

형상 관리의 주체는 프로젝트 관리자일 수도 있고 품질 담당자일 수도 있다.

상호 원활한 커뮤니케이션을 통해 버전을 통제할 수 있도록 정책을 수립해야 한다.

아래 버전 관리 규칙은 필자가 회사 정책의 4자리 기준에 각 버전 항목에 대한 변경 규칙을 명시하여 프로젝트에 적용하고 있는 관리 방침이다. 또한 서비스 제공을 하다 보면 플랫폼별로 업데이트 일정이나 패치 횟수가 일치하지 않아 버전이 통일되지 않을 수 있다.

이 경우 Minor 버전에 대해서는 모든 플랫폼에서 통일시키고 패치 버전을 통해 업데이트를 진행하는 방법을 선택했다.

- Baseline 을 별도로 명시하지 않고 Major 와 Minor 버전으로 Baseline 을 설정했다.

- iOS, Mac 은 버전이 3자리까지만 등록되어 예외 규칙을 만들 필요가 있다.

Major : 제품, 서비스의 구조 변경이나 리뉴얼을 진행할 경우 변경한다.

- 제품에 대한 모습이 변경되는 것으로 PO에 의해 변경 여부가 결정되는 것이 올바르다고 생각한다.

- 금융권의 차세대 시스템과 동급 수준이라고 생각한다.

Minor : 제품의 메인(주요) 기능이 추가, 변경되었을 경우 변경한다.

- 필자는 Minor 버전이 주요 업데이트 버전이었다. (Baseline 의 기준)

- Minor 버전도 제품에 대한 주요 기능을 다루다 보니 PO 가 선정한 백로그에 따라 버전을 명명 또는 백로그를 분할하여 변경하였다.

- 버전 분할은 PO가 선정한 백로그가 테마 단위일 경우 에픽이나 스토리 단위로 쪼개서 1개 버전씩 상향하는 방법을 취했다.

- 예> 화상회의 참여 인원을 늘리면서 제공되는 레이아웃을 모드로 변경하고 모드 1개당 버전 1씩 상향했다.

- 예> 2.13.1 - 주화자 모드, 2.14.1 - 분할 모드

Patch : 일부 기능의 변경이나 오류 수정이 있을 때 변경한다.

- 오류나 사용성 개선을 위해 패치한 내용이 많았다.

- 이미 제공된 기능에 추가로 옵션이 들어가는 경우도 포함되었다.

- 사용자 서비스와 큰 영향이 없는 관리자 페이지 업데이트도 포함되었다.

- 특정 플랫폼(Android, iOS, Web)만 업데이트하는 경우도 패치 버전을 변경하여 기능의 동일함을 유지하였다.

- 예> 모바일 OS 업데이트에 따른 호환성 패치, 브라우저 호환성 패치 등

QA : 내부에서 검증 기간 배포 시 QA 통제에 의해 변경한다.

- 검증 기간 스테이징 서버에 배포할 경우 버전을 변경하였다.

- 버전은 품질 담당자가 배포를 요청할 경우 처리(반영/추가)된 항목 명세와 함께 버전을 상향한다.

- 내부 개발팀이 필요에 의해 배포가 필요한 경우는 반드시 품질팀의 확인을 받고 진행하여 현상 관리를 할 수 있도록 하였다.

- 검증 기간 잦은 배포는 검증 기간을 늘리게 되고 개발된 항목에 문제가 있음을 인지하고 QA 버전의 수치도 관심을 갖고 확인해야 한다.

참고, 3자리 버전 규칙

XXX . XXX . XXX0XXX (Patch 버전을 Patch + '0' + QA 형태로 사용)

7. 프로젝트 평가

프로젝트 구성원에 대한 동기 부여 방법을 고민해야 한다.

제품의 위대한(?) 비전 제시와 목표 달성 시 보상 등이 PM 이나 관리자에게 권한이 있다면 굳이 생각할 필요가 없을 것 같다.

현실은 프로젝트 관리자에게 가혹하며, 냉정함을 권한다.

프로젝트 관리자에게는 프로젝트 구성원에 대한 평가 권한이 주어지고 구성원들은 평가와 프로젝트 업적을 기반으로 스폰서나 인사팀에서는 처우에 대한 결정을 하게 된다.

그럼 평가를 어떻게 할 것인가? 구성원이 어떻게 신나게 일할 수 있게 만들 수 있는가를 고민해야 한다.

프로젝트 관리자도 직원일 가능성이 높다.

서로 미워하지 않도록 평가 기준을 투명하게 공개하고 프로젝트 중간중간 평가에 대한 코멘트를 할 수 있어야 한다.

(막바지 몰아서 평가하면 중간에 잘하거나 부족한 부분들을 놓쳐서 적절한 피드백을 못할 수 있다고 생각한다.)

필자는 기준 점수를 10점 기준으로 구성원 모두에게 8점을 동일하게 기본 점수로 부여하고 가감을 통하여 절대 평가를 진행한다는 규칙을 공개하였다.

평가 항목은 주관적인 항목이 될 가능성이 높아 평가 항목도 투명하게 공개해야 한다.

그리고 매 프로젝트가 끝나면 구성원들에게 잘한 점과 개선할 점을 피드백하고 관리자로써도 구성원에게 피드백을 받을 수 있도록 자리를 마련하는 것이 좋다. 물론 1:1로...

7.1. 업적 평가

관리자는 개발자가 아니라 역량 평가를 하기에는 능력 밖의 업무일 수 있다.

그래서 프로젝트에서 구성원이 담당한 백로그 기반으로 업적을 평가하게 된다.

백로그에 우선순이나 난이도가 명시되어 있다면 좀 더 수월한 업적평가를 할 수 있을 것이다.

자기 업적 평가 (구성원 스스로)

- 프로젝트 성공을 위해 본인이 진행한 업무나 노력, 성과를 스스로 작성토록 한다.

- 평가 항목과 점수, 코멘트를 작성할 수 있는 시트를 제공한다.

- 업적 평가는 백로그 및 업무 일감, 태스크를 작성하지 않도록 가이드해야 한다. (이것은 연봉으로 합의된 내용이다.)

- 주니어 레벨에게는 노력(기술 검토, 개발 리뷰)과 성과(개인적으로 달성 성과, 제품에 대해 달성 성과 등 근시적 목표 달성 관련된 항목)를 작성토록 했다.

- 시니어 레벨에게는 개선(품질 안정화)과 기술 도입 검토 등 제품의 큰 모습에 대해 고민한 내용들을 적게 했다.

관리자의 업적 평가 (관리자가 구성원을)

- 자기 업적 평가 기준으로 레벨별 편차를 두어 점수 차이가 벌어지지 않도록 조정 작업을 한다.

- 자기 업적 평가는 가점의 대상으로 활용해야 한다.

- 백로그에 대한 분석 능력 (Conversation 작성)에 대하서 가점을 줄 수 있다.

- 검증 기간 내 개발 분야에 대한 이슈 수준과 빈도에 따라 감점을 할 수 있다. (리뷰/설계 미흡으로 인한 이슈 등)

- 일정 준수에 대해서도 사유에 따라 감점을 할 수 있다. (무리한 업무 수용, 나태함 등)

- 스프린트 기간 내 기술적 채무는 인정하되 빈도에 따라 감점할 수 있다.

7.2. 업무 태도

각자 업무만 잘한다고 프로젝트가 성공하지 않는다. 프로젝트가 원활하게 운영되거나 성공할 수 있도록 노력한 부분에 대해서는 반드시 칭찬(격려)을 해야 하고 부족한 부분은 코칭(가이드)이 필요하다.

프로젝트 관리자의 목표는 프로젝트의 성공이며, 개발 속도를 유지해야 하기 때문에 반드시 업무 태도에 대한 평가 및 피드백을 하여 동기 부여가 될 수 있도록 노력해야 한다.

- 업무 태도는 프로젝트 진행 간 구성원들이 태도를 수시로 체크하여 미리 평가해둬야 한다.

- 업무 태도는 프로젝트 진행에 있어 주도적인 업무를 진행하는 적극성과 의견 개진 등 프로젝트를 위한 행동. (가점)

- 부정적 의견 제시나 대안 없는 반대 의견 등은 마이너스 요인으로 피드백을 해야 한다. (감점)

- 불필요한 잔업을 진행하지 않는가를 확인하고 개발 속도를 유지할 수 있도록 피드백해야 한다.

- 협업에 있어 불협화음을 유발하는 행위 및 분위기 저하 행위 (감점)

8. 비상 연락 체계

리스크 관리를 위해 필요한 항목이며, 이미 개인 모바일 기기에 저장되어 있을 것이다.

하지만 문서는 인원이 변경되어도 업무가 유지될 수 있도록 하는 도구이기 때문에 명시해야 될 필요가 있다.

연락 체계는 접수되는 항목과 채널에 따라 전파 단계 및 방향이 달라지기 때문에 도메인이나 회사 특성에 맞게 정의해야 한다.

필자는 유입 통로를 2개 범주로 분류하였다.

- 시스템 알림 : 시스템이나 서비스에서 발생하는 경고 메시지 수신

- 내/외부 유입 : VOC 및 제보 및 장애 신고

큰 차이는 없지만 최초 접수하는 사람이 다르기 때문에 업무 분장을 명확히 해줘야 한다.

시스템 알림 특성

- 다수의 인원이 동시에 알림을 받는다.

- 발생 시스템에 담당자를 지정하여 최초 분석 후, 다음 전파가 될 수 있도록 한다.

내/외부 유입

- 1인이 전파를 받게 되고 상황에 대한 전후 사항을 수집하여 프로젝트 관리자에게 전달해야 한다.

- 프로젝트 관리자는 바로 상황을 전파하고 의심되는 파트의 담당자에게 바로 업무 지시를 내린다.

위 2개 범주로 유입되고 나서는 동일하게 PM 에 의해 업무가 진행되어야 한다.

- 이슈 수준이 높음인 경우 지체 없이 대외 공지를 한다. (1보, 타이틀 공유)

- 이슈 수준이 보통 이하의 경우 원인 파악 후 공지한다. (2보, 원인 및 영향도)

- 원인 파악 및 조치가 완료되면 정식 공지를 내보낸다. (장애 공지 - 조치 완료)

- 조치가 지연될(약 20여분) 경우 추가 지연 공지와 우회 방안 등을 공지한다. (3보, 처리 지연 및 우회)

- 모든 처리가 완료되면 최초 유입부터 처리 완료까지의 타임라인 기반 상황과 재발 방지 계획을 포함한 보고서를 작성하여 유관부서에 공유한다. (장애 공지 - 재발 방지 계획)

9. 별첨 - 프로젝트 운영

프로젝트 운영이 있어 업무를 할당하고 관리하는 생애 주기에 관한 내용 첨부.

마지막 한 마디.

프로젝트 헌장은 문서 형태의 산출물로 나온다.

문서는 버전 관리가 되어야 하고 누구나 언제든지 찾아볼 수 있는 형태로 구성되어 지속적으로 활용되어야 한다.

제발 한 번 만들고 버려지는 형태의 문서, 관리의 소홀이 생기지 않도록 신경 쓰자.

PM의 모든 업무는 관리에서 시작해서 관리에서 끝난다.

PM? No! TPM의 직무 알아보기.

비지니스 파트의 직무인 PO(Product Owner), PM(Product Manager)를 널리 사용하다보니 전통적인 PM(Project Manager)의 직무가 개발영역이 아닌 사업영역에서도 할 수 있는 것처럼 인식이되기 시작했고 실제 혼

Technical PM