[PM온보딩] 프로젝트 시작 : 도구 세팅
Chapter 3
프로젝트 착수와 세팅 과정
프로젝트가 착수되면, PM은 프로젝트와 팀을 위한 협업 도구를 세팅해야 합니다.
특히 에이전시라면, 여러 개의 프로젝트를 병행하여 관리해야 할 가능성이 높기에 프로젝트마다 도구들을 초기에 잘 세팅해 놓는 것이 중요합니다. 협업 도구들을 설정하고 함께 일하는 팀원들이 어디에서 무엇을 보면 되는지 자연스럽게 알 수 있도록 잡아줘야 합니다. 필요한 정보를 찾기 위해 이리저리 헤매지 않도록 세팅을 잘해놓는다면, 커뮤니케이션의 좋은 기반이 될 것입니다.
세팅하는 툴과 그 역할
1. 노션 (Notion)
노션에는 프로젝트 정보를 등록합니다. 회사에서 진행 중인 모든 프로젝트를 구성원들이 한 곳에서 쉽게 알아볼 수 있도록 프로젝트 상태와 팀 구성을 작성해 놓습니다.
각 프로젝트별로 다음과 같은 정보를 입력합니다.
진행상황: 예정, 진행 중, QA, 하자보수, 종료, 보류 등
구분: 외주/내부 등
프로젝트명 : [회사명] 프로젝트 이름
계약 기간 및 하자보수 기간
타입 : 기획, 디자인, BE개발, FE개발, QA, 유지보수, 하자보수
서비스 유형: Web, App, 반응형, 리뉴얼 등
담당 PM
엔지니어 구성 (디자이너, 개발자)
위와 같이 구성해 두면, PM뿐 아니라 디자이너, 개발자, 운영팀까지도 프로젝트의 맥락을 쉽게 파악할 수 있습니다. 누군가 새로 프로젝트에 투입되었을 때, 노션 하나만 보아도 프로젝트의 정보를 파악할 수 있도록 하는 것이 목적입니다.
2. 슬랙 (Slack)
슬랙은 프로젝트 커뮤니케이션의 중심이 됩니다. 클라이언트와의 소통을 위한 외부 채널, 그리고 팀 내부 논의를 위한 채널을 구분해서 운영합니다.
pj-외부-{프로젝트명}
pj-내부-{프로젝트명}
외부 채널에서는 일정 안내, 주요 공지, 피드백 요청 등이 주로 오가고, 내부 채널에서는 데일리 스크럼, 개발 이슈 공유, 내부 논의가 이뤄집니다. PM은 이 두 채널의 중심이 되어 이끌어 가야 합니다.
단순 슬랙 메시지로만 소통을 끝내기보다, 중요한 결정이나 공유 내용은 컨플루언스에 다시 정리해 두고, 문서화된 형태로 공유하는 것이 좋습니다. 슬랙 안에서는 많은 대화가 오고 가기 때문에 습관적인 기록과 공유가 중요합니다.
3. 지라 (Jira)
지라는 개발 일정과 태스크 관리를 위한 핵심 도구입니다. 프로젝트의 전체 구조를 Epic 단위로 먼저 잡고, 그 안에 Task, Bug 등의 이슈 유형을 세분화하여 관리할 수 있습니다. 기획, 디자인, 개발, QA, 배포까지의 작업 흐름을 에픽별로 설정하고, 지라의 타임라인 기능을 활용해 전체 프로젝트 일정을 시각적으로 확인할 수 있습니다.
“누가, 무엇을, 언제까지 해야 하는지” 팀원들과 함께 확인하고 조율해 나가는 것이 중요합니다.
지라를 잘 세팅해 놓는다면, 팀원 스스로 현재 위치와 해야 할 일을 파악할 수 있도록 도울 수 있습니다.
PM은 지라를 중심으로 데일리 스크럼을 리드하고 우선순위 조율과 전체 로드맵을 함께 그려나가야 합니다.
-> 지라에 대한 내용은 별도 챕터로 더 자세하게 다룰 예정입니다.
4. 컨플루언스 (Confluence)
컨플루언스는 프로젝트의 정보를 기록하고 정리하는 공간입니다. 지라가 일정과 태스크를 다룬다면, 컨플루언스는 기술적/기획적 내용을 문서화하는 데 집중합니다.
컨플루언스를 통해 다음과 같은 정보들을 정리할 수 있습니다.
API 정의 및 백엔드 구조 설명
기능 정의의 배경과 논의 내용
데일리 스크럼 기록
클라이언트 미팅 회의록 및 결과 요약
QA 전략, 테스트 케이스 정리
운영 매뉴얼 및 전달 문서
특히 슬랙이나 회의에서 오간 이야기가 중요할수록, 한 번 더 정리해서 컨플루언스에 남기는 습관이 중요합니다.
PM은 컨플루언스를 통해 내용을 정리하고, 클라이언트에게 공유할 내용이 있다면, 문서화를 합니다.
이렇게 하나의 창구에서 기록 및 공유가 잘 이루어진다면 정보를 찾아 헤매는 시간을 효과적으로 줄일 수 있습니다.
-> 컨플루언스 활용 팁도 지라 챕터에서 함께 다뤄보겠습니다.
5. 구글 시트 (Google Sheets)
구글 시트는 주로 클라이언트와 공유해야 하는 문서들을 정리하는 데 사용합니다.
다음과 같은 문서들을 구글 시트로 정리하여 공유할 수 있습니다.
R & R : 프로젝트에 참여하는 팀원 및 이해관계자들의 담당 역할과 소통 창구를 정리
간트 차트: 프로젝트의 전체 일정과 주요 마일스톤을 시각화, 클라이언트와 일정 조율 시 필요하며, 전체 흐름을 공유하는 데 유용합니다.
계정 정보 : 도메인 주소, 계정 등 프로젝트 진행에 필요한 고객사 계정 정보를 정리, 전달받은 계정 정보가 흩어지지 않도록 한 곳에 정리해 두는 것이 중요합니다.
기능정의서: 화면 단위 또는 기능 단위로 어떤 동작이 구현되어야 하는지를 정리한 문서, 개발자와 디자이너, 클라이언트 모두가 공통 기준으로 참고하게 되는 문서입니다.
요구사항 정의서: 클라이언트의 요청사항을 기준으로 기능 단위로 정리하고 협의 내용을 기록하고 공유하는 문서, 범위나 우선순위 정리가 필요한 시점에서 활용됩니다.
유효성 검사 : 회원가입, 로그인, 입력폼 등 기능 구현 시 적용해야 하는 유효성 검사 항목을 리스트업 한 문서
-> 구글시트를 통해 활용될 각 문서의 템플릿 또한 별도의 챕터로 구분하여 자세하게 다룰 예정입니다.
또한, 프로젝트의 특성이나 규모에 따라 다음과 같은 문서를 작성할 수도 있습니다.
IA (Information Architecture, 메뉴구조도) : 서비스의 전체 메뉴 구조나 화면 흐름을 한눈에 정리한 문서
RFP (Request for Proposal, 정책 정의서) : 서비스에서 지켜야 할 운영 정책, 권한 기준, 예외 처리 기준 등을 명시한 문서
개발 보안 요건 정의서 : 로그인, 결제, 개인정보 입력 등 민감한 기능과 관련된 보안 요구사항을 정리한 문서, 보안성 심사를 대비하거나, 외부 감리 대응이 필요한 프로젝트에서 요구될 수 있습니다.
TC (Test Case, 테스트케이스) : QA 단계에서 각 기능이 예상대로 동작하는지를 검증하기 위한 시나리오 기반 테스트 목록
클라이언트와의 초기 협의에서 어떤 문서를 어디까지 제공할지 사전에 정리해 두는 것이 좋습니다.
하나의 시트를 생성해, 시트 내 탭으로 구분하여 관리 및 공유하는 것을 추천합니다. 클라이언트와 협의가 끝난 문서는 권한을 구분하여 PM만 편집이 가능하도록 버전을 관리하는 것이 혼선을 방지할 수 있습니다.
구글 시트의 가장 큰 장점은 협업과 실시간 공유입니다. 클라이언트가 내용을 바로 확인하고 코멘트를 남기거나 편집 권한 부여를 통해 함께 수정이 가능하고 버전 관리에도 용이합니다. 초안을 보여주고 함께 맞춰가는 방식으로 활용하는 것이 좋습니다.
PM이 반드시 기억해야 할 한 가지
에이전시의 경우, 프로젝트마다 팀이 유동적으로 구성되고 여러 개의 프로젝트를 동시에 병행하는 경우가 많습니다. 그렇기에 PM은 프로젝트마다 정보를 찾기 쉽도록 잘 정리해 두는 것이 중요합니다.
문서는 나만 보기 위한 (나를 위한) 것이 아닌, 내가 자리를 비워도, 누군가 새로 합류해도, 흐름이 끊기지 않도록 기준을 남겨두는 것임을 잊지 말아야 합니다.
