서비스 기획 숙련 4. 프로젝트 운영과 협업(킥오프, 공유, 회고)+개인적인 업무 공유/회의록 작성 Tip

이전 챕터에서는 데이터를 분석하고 이를 바탕으로 의사결정을 내리는 과정을 정리했었다.

하지만 좋은 분석과 좋은 의사결정만으로 프로젝트가 성공하는 것은 아니었다...

직장에서든 프리랜서로든 일을 하다 보면 프로젝트 리더가 되기도 하는데(나에게 왜 이런 시련이...)

계속 공지를 해줘도... 각자의 이해정도가 달라서 프로젝트 마감일에 간당간당하게 맞춘 적이 많았다.

마감일은 절대적으로 지켜야 하는 약속이니까... 그것이 프로니까(끄덕)

특히 프리랜서는 마감일 못 지키면 마법처럼 일감이 사라진다.

PM은 프로젝트 참여자들이 같은 목표를 바라보고 있는지, 필요한 정보가 적절히 공유되고 있는지,

프로젝트 종료 후 무엇을 배웠는지까지 관리해야 한다고 한다.

 

이번 챕터에서는 프로젝트 운영 과정에서 PM이 수행하는 킥오프, 공유, 회고에 대해 정리해보려 한다.

[게시글 목차]
1. 킥오프(Kick-off)

   ◾킥오프의 목적
   ◾킥오프에서 공유해야 할 내용
2. 공유(Communication)
   ◾공유의 중요성
   ◾회의록 작성
   ◾업무 공유
3. 회고(Retrospective)
   ◾회고의 목적
   ◾회고 진행 방법
4. KPT 회고
5. 액션 아이템(Action Item)
6. PM이 공유를 잘해야 하는 이유

 

+) 나의 업무 공유와 회의록 작성 Tip

 

---

 

1. 킥오프(Kick-off)

• 킥오프는 프로젝트 시작 전에 참여자들이 모여 프로젝트의 목표와 방향을 공유하는 과정이다.
  (Like. 여행 출발 전 여행 계획 공유)
• 목적지를 모르고 출발하면 각자 다른 방향으로 이동하게 된다.
  프로젝트도 마찬가지다.
• 킥오프를 통해 프로젝트의 목표와 범위를 먼저 정렬해야 한다.
  (정렬 중요하지... 딴 얘긴데, 솔직히 노션 표 중앙 정렬 안 되는 거 너무 거슬림)

◾킥오프의 목적

목적	설명
목표 공유	프로젝트 목표 정렬
범위 정의	어디까지 수행할 것인지 결정
일정 공유	주요 일정 및 마감일 확인
역할 정의	담당자 및 책임 범위 확인
위험 요소 확인	예상 리스크 사전 점검

 

◾킥오프에서 공유해야 할 내용

항목	예시
프로젝트 목표	회원가입 전환율 10% 향상
KPI	회원가입 완료율
일정	6월~7월
담당자	PM, 디자이너, 개발자
예상 리스크	일정 지연 가능성

 

◾사례

LA 프로젝트	1419 타겟 프로젝트
프로젝트 목표 공유 / 주요 일정 공유 / 역할 분담 진행	타겟 사용자 정의 / 프로젝트 방향성 정렬 / KPI 공유
→ 킥오프의 핵심은 일을 시작하는 것이 아니라 같은 목표를 바라보도록 만드는 것이다.

 

 

2. 공유(Communication)

• 공유는 프로젝트 진행 과정에서 필요한 정보를 이해관계자에게 전달하는 활동이다.
• 좋은 프로젝트는 정보가 많아서 성공하는 것이 아니라,
  필요한 정보가 적절한 시점에 공유되어 성공한다.

◾공유의 중요성

공유가 부족한 경우	공유가 잘 되는 경우
PM은 알고 있음 ↓ 개발자는 모름 ↓ 디자이너도 모름 ↓ 서로 다른 방향으로 진행	목표 공유 ↓ 진행 상황 공유 ↓ 이슈 공유 ↓ 의사결정 공유
→ 정보 비대칭을 줄일 수 있다. (이걸 간과하면 나중에 서로 책임을 미루며 충돌하거나 갈등 상황으로 번질 가능성이 높다...)

 

◾회의록 작성

• 회의가 끝났다면 반드시 기록을 남겨야 한다.
• 기억은 왜곡될 수 있지만 기록은 남는다.
  (회의에 모두 집중하면 더할나위 없는데, 보통 그렇지 않은 경우도 있어서 최대한 기록하고 공유를 많이 한다)

아젠다	논의 내용	결정 사항	액션 아이템	담당자	일정
회의 주제	주요 논의 사항	최종 결정 내용	후속 작업	담당 인원	완료 예정일

 

◾업무 공유

• 공유해야 하는 대표적인 내용

구분	진행 현황	일정 변경	이슈 발생	의사결정
예시	개발 진행률 80%	QA 일정 변경	로그인 오류 발견	기능 범위 축소

 

 

3. 회고(Retrospective)

• 회고는 프로젝트 종료 후 프로젝트를 돌아보며 개선점을 찾는 과정이다.
• 목적은 잘못한 사람을 찾는 것이 아니다.
  (일하다 보면 이거 착각하시는 분들 너무 많은데...
  때에 따라 문제 상황 추적이 필요한 경우도 있지만(비즈니스적 타격/성과 관련 등등),
  이미 벌어진 일은 돌이킬 수 없고 앞으로 이런 일을 방지하고자 진행하는 경우가 더 많다)
• 다음 프로젝트를 더 잘하기 위한 학습 과정이다.

◾회고의 목적

학습	개선	공유	성장
경험 정리	문제 원인 파악	팀 경험 축적	반복 실수 방지

 

◾회고 진행 방법

1. 프로젝트 결과 확인
2. 잘한 점 정리
3. 아쉬운 점 정리
4. 개선 방안 도출
5. 액션 아이템 정의

◾회고 시 주의할 점

BAD	GOOD
누구 때문에 실패함 (사실 이건 싸우자는 말로 받아들여질 가능성이 너무 높다...)	어떤 과정에서 문제가 발생했는가? (+앞으로 어떻게 이 문제를 방지할 것인가!)
→ 사람보다 프로세스에 집중하는 것이 중요하다.

 

4. KPT 회고

구분	Keep	Problem	Try
의미	계속 유지할 것	문제점	시도할 것
예시	주간 공유 문화	일정 관리 부족	데일리 스크럼 도입
→ 구조가 단순하고 액션 아이템까지 자연스럽게 연결되기 때문에 많이 사용한다.

 

5. 액션 아이템(Action Item)

• 회고는 개선 행동까지 이어져야 의미가 있다.
• 회고만 하고 끝나면 다음 프로젝트에서도 같은 문제가 반복될 가능성이 높다.
• 핵심 : 회고 → 개선안 → 액션 아이템 → 다음 프로젝트 반영

활용 예시
Problem	일정 지연	요구사항 변경 잦음	QA 부족
Try	중간 점검 회의 추가	변경 프로세스 정의	QA 일정 확보

 

6. PM이 공유를 잘해야 하는 이유

• PM은 프로젝트에서 가장 많은 정보를 연결하는 사람이다.
• 개발자, 디자이너, 데이터 분석가, 이해관계자들이 서로 다른 정보를 가지고 있기 때문에 PM이 이를 연결해야 한다.

이유	설명
목표 정렬	같은 방향으로 진행
정보 비대칭 감소	협업 효율 향상
의사결정 기록	책임 소재 명확화
일정 관리	진행 상황 추적
리스크 관리	문제 조기 발견

 

 

나의 업무 공유와 회의록 작성 Tip

나는 디자인 회사 + 공공기관 + 프리랜서 + 강사(공예/코딩)로 일하며 다양한 프로젝트와 미팅에 참여했었다.

프리랜서만 대략 6~7년 정도(성수기/비수기 업무량 격차가 너무 커서 몇 년이라고 정확히 정의 내리기 어렵다)

대학 때도 실물 굿즈 만들어서 오프라인 행사에 나가서 판매도 하고 그랬다.

 

아무튼, 여러 분야의 사람들과 일을 한 경험이 나이에 비해 많지 않나? 싶다.

처음엔 나도 여느 우당탕 신입들처럼 혼도 많이 나고, 실수한 날이면 자책도 많이 했었다.

(슬퍼도 일정이 많으니 울면서 일하기도 했었다..... 결과적으로는 안구건조 완화에 도움을 줌ㅋㅋㅋ 일시적이지만)

 

연차가 쌓이고 이런저런 일을 많이 겪다 보니 왜 그랬을까? 싶다.

신입이 좀 실수도 하고 그럴 수 있지 왜 그려... 마인드 장착

그래서 후임에게는 같은 실수는 3번 정도 용납하는 삼진아웃룰을 적용한 것이 규칙의 시작점이었다.

(같은 실수 3번 이상은 이제... 고의라고 봐도 무방하니까 / 메모를 하면 '그래도 열심히 하는 친구네'라는 생각이 든다)

 

+) 각설하고, 진짜 Tip 공개

업무 공유는 가능한 모든 방법을 동원해 하는 게 좋은데,

나는 프리랜서로 프로젝트에 투입되면 일단 현재 상황, 기존 업무 진척도, 내가 해야 할 업무, 프로젝트 투입 인원과 역할(당시의 경우에는, 의사결정자와 시공팀 / 출판 업체 등등), 그리고 가장 중요한 마감 일정을 확인한다.

첫 미팅 때는 마감 일정을 기준으로 일자별 체크리스트와 내가 처리할 업무 일정을 러프하게라도 문서화해서 프린트물을 들고 가서 배포한 뒤 시작하는 편이다.

(담당자에게는 별도로 문서화한 걸 이미지로든 PDF로든 공유하고 '팀 내부에 공유 부탁드립니다'라고 한다)

 

먼저, 이들도 일손이 필요해서 나를 고용했다는 사실을 잊지 말아야 한다

구두로만 전달하면 안 그래도 바쁜 사람들이 오로지 나를 위해 집중해서 기억해 줄까? NO...

그리고 일단 문서로 전달하면 '저는 이렇게까지 철저하게 준비해서 보여줬습니다'가 가능해진다.

 

미팅이 시작되면 실시간으로 기록을 한다(회의록 작성자가 있어도 나는 따로 하는 편이다).

가능하면 발언자가 누구인지도 적는데, 너무 빠르게 진행되면 이건 생략하고 내용 중심으로 작성한다.

(하나부터 열까지 놓치지 않고 작성하면 너무 좋은데, 그럴 수 없으니 주로 키워드 중심으로 작성하는 편이다)

 

미팅이 끝나면 회의록을 정제하여 프로젝트 관계자(연락처 닿는 대로 최대한)에게 전달한다.

(대체로 각자에게 유리한 부분을 더 잘 기억하기 때문에 같은 주제로 미팅을 진행해도 방향과 목적이 왜곡될 수 있다)

 

이후에는 좀 더 체계적으로 일정(타임라인별 체크리스트)을 잡는 편인데,

이때 주의해야 할 점은 너무 타이트하게 잡지 않는 것이다(내 업무 처리량만 반영한 경우).

여러 관계자가 얽힌 상황에서 일을 진행하다 보면 어디선가 변수가 발생하고 일정에 차질을 주게 되는 경우가 아주 많다.

일정을 타이트하게 잡으면 그때그때 대응이 너무 어려워지기도 하고 일정이 밀리며 혼란스러워진다.(치솟는 스트레스)

특히 나의 경우에는 출력/시공 일정이 가장 큰 변수 지점이었는데,

최소한의 여유 시간을 포함하여 일정을 짜야 덜 힘들었다...

(사실 여유 시간이 있어도 의사결정자가 늦게 컨펌해 주면 출판/시공 관계자에게 사정사정해야 한다ㅠㅠㅠㅠㅠ

대체 왜 느긋한 건데... 왜 나만 바쁜 것 같은 느낌인 걸까)

 

아무튼, 일정 공유가 끝났다면 바로 타임라인별 체크리스트 내용을 작업하기 시작한다.

★주요 작업★이 끝나면 바로 프로젝트 관계자에게 전달하고,

직접 자리에 찾아가든 전화로든 '~첨부했으니 확인 부탁드립니다'를 프로젝트가 완료될 때까지 무한 반복한다.

(끝없는 리마인드에도 못 봤다는 사람들이 태반인 짠내 나는 현실을 받아들여야 하는데... 쉽지 않다)

 

그러다 보면 시간이 흘러 흘러 정산을 받고 프로젝트를 마무리하게 된다.

(정산을 위한 문서가 오가지만 뭐 그쯤이야... 입금된다고 하면 기꺼이 하게 된다 → 금융 치료 完)

 

나는 프로젝트가 끝나면 개인적으로 아쉬웠던 부분과 개선점을 찾곤 했는데,

주로 당장 개선할 부분과 장기적으로 차근히 개선할 점을 나눠서 생각했었다.

(쉴 때, 주로 철학 / 심리학 관련 책을 보는데 자아성찰과 행동개선이 즉각적으로 일어나는 경우는 잘 없는 것 같다

있다면 그 사람이 대단한 거겠지... 천천히라도 의지를 가지고 개선이 되면 좋은 변화라고 본다)

중요한 것은 발전을 위해 자아성찰이 필요한 것은 맞지만(스트레스의 양만큼 성장하기도 하니까),

너무 지나친 자아성찰은 결국 번아웃으로 이어질 가능성이 크다는 것이다.

(나도 알고 싶지 않았다... 프리랜서 초반에는 프로젝트 끝나면 매번 앓아누웠었다)

타인을 대하듯, 나에게 아쉬웠던 점 또한 적당선에서 타협을 볼 줄도 알아야

느리지만 확실하게 성장할 수 있고 장기적으로 일하기 좋은 환경이 만들어진다.