기획자의 소프트스킬 - 킥오프, 정보공유, 회고를 알아보자!

프로젝트를 기획자의 입장에서 3단계로 분리한다면

크게 킥오프 / 정보공유-관리 / 회고 로 나눠질 것이다.

이는 프로젝트 진행 중 팀원들의 목표를 하나로 모아주는

중요한 단계들이다.

 

<나와 타인은 완전히 다르다.>

 

 "나와 저사람은 다르다"

 

기획자가 가장 유념해야 할 상식이다.

나는 개발자와 다르고, 나는 디자이너와 다르고,

나는 마케터와 다르고, 심지어 동료 기획자와도 다르다.

 

나와 다른 사람들을 한데 모아 같은 목표를 향하려면

프로젝트의 시작, 중간, 끝 매순간마다 "서로의 의견교환" 이 동반되어야 할 것이다.

 

---

 1.  🚩 킥오프 

 

< Kick-Off Meeting >

 

킥오프 회의는 프로젝트의 『 시작 』 단계이다. 

 

킥오프 미팅을 통해 프로젝트의 목표와 범위가 명확히 정의되며, 

프로젝트 중 발생할 수 있는 갈등을 예방하고 팀원들이 효율적으로 협력할 수 있는 환경이 조성된다.

킥오프가 제대로 이루어지지 않으면, 프로젝트 중간에 혼란이나 목표 불일치, 일정 지연 등이 발생할 수 있다.

핵심 요소들은 다음과 같다. 

 

1. 프로젝트 목표 , 프로젝트 범위 2. 일정, 팀 구성 ,커뮤니케이션 3. 리스크 / 이슈 대응

 

기획자는 킥오프 미팅을 준비하며 

프로젝트 목표, 범위, 일정, 예산 등 정확한 데이터 등이 빠짐없이 전달되도록 준비해야한다.

기획자는 킥오프 회의의 핵심적인 사항들을 다양한 부서에 미리 전달하고

발표할 자료와 문서 등을 작성한다.

 

킥오프 미팅 이후에는 회의록을 작성하여 기록으로 남긴다.

 

---

1-1.  프로젝트 목표 / 범위

 

먼저 프로젝트 진행 전

무엇을 달성할 것인지, 어디까지 다룰 것인지 명확히 해두어야 한다.

 

< 예시 >

프로젝트 목표  - 신규 서비스 출시로 시장 점유율 7% 증가 - 데이터 관리 프로세스를 자동화하여 연간 600시간 절감 프로젝트 범위 - 포함 : 웹 디자인 및 개발, UX/UI 테스트 - 제외 : 서버 유지보수, 고객지원서비스 제공, 앱 개발

 

---

1-2. 일정, 팀구성, 커뮤니케이션

 

< 예시 >

일정 - 총 프로젝트 기간 : ~ 2026 10/30 - 요구사항 분석 및 설계 : 2026 6/ 9 ~ 6/ 23 - 개발 및 테스트 : 2026 6/ 24 ~ 7/ 3 - 1차 배포 : 2026 7/ 8 팀 구성 PM : Rody 디자이너 : ★ ★ ★ 개발 : ■ ■ ■ QA :  ▲ ▲ ▲ 커뮤니케이션 - 매주 월요일 10:00 AM 정기 회의 - 소통 및 의사결정사항 전달 등은 Slack으로 통일 - 프로젝트 진척사항은 매주 금요일 4:30 PM 사내 메신저로 보고

 

주요 마일스톤과 기한을 설정하고,

프로젝트에 참여하는 각 팀원의 단계별 역할과 책임을 명시한다.

그리고 협업 시 정보 교환 방법을 일륜화시킨다.

 

---

1-3. 리스크 / 이슈 대응

 

일정 상의 문제나 기술적 난제, 자원 부족 등

예상되는 리스크나 문제를 공유하고, 문제가 발생했을 때의 대응 방법도 미리 논의한다.

 

---

 2.  ℹ️ 정보 공유 

 

중요사항을 모두가 알 수 있도록 공유하는 것은 프로젝트 진행에 있어 매우 중요하다.

프로젝트의 진척도를 각 팀원이 전부 인지하고, 발생할 수 있는 문제를 미리 파악할 수 있기 때문이다. 

 

< 청년장사꾼의 정보 공유 및 피드백 문화 >

 

정보 공유는 킥오프 단계에서 지정한 채널을 통해 (ex. 노션 등) 진행되어야 한다.

노션 등의 실시간 업데이트 세션이나, 정기회의를 통해 팀원들이 프로젝트 진행 상황을 이해할 수 있다.

 

하지만 과도한 정보 공유는 오히려 혼선을 야기할 수 있으므로

기획자는 각 부서의 목표에 맞는 정보를 조율하여 제공하는 것이 중요하다.

 

공유는 단순히 정보를 주고받는 것이 아닌

필요한 정보를 필요한 사람에게 정확히 전달하는 과정이다.

프로젝트에 참여하는 각 사람들은 서로 다른 관점에서 일을 하기 때문에

오해가 생기지 않도록 모호한 표현을 지양하여 구체적으로 전달하여야 하며,

전달 이후에는 공유된 정보를 문서화하고, 나중에 필요한 정보를 쉽게 찾을 수 있도록 해야 한다. 

 

---

 3.  💭  회고 

< 활동을 정리하고 인사이트를 정리하는 회고 >

 

회고라는 활동의 필요성은 생각보다 중요하다.

사람은 망각의 동물이기 때문에,

지속적으로 뒤를 돌아보지 않으면 많은 것을 잊어버린다.

 

회고 과정에서는 팀의 작업 과정, 의사소통, 도전 과제, 성공적인 점 등을 되돌아보고

도출된 인사이트를 정리하게 된다. 

또한 프로젝트 진행 중 발생했던 각 부서의 불편사항 등을 개선하기 위해서도 반드시 필요하다.

 

---

3-1 . 왜? (WHY) 의 중요성

 

회고는 무엇이 부족했고, 왜 그랬는지를 근본적으로 분석하여야 한다.

 

< 회고 예시 >

- 좋았던 점 할인율을 높였을 때, 기존 고객의 구매 빈도가 상했다. 프로모션을 SNS와 이메일 마케팅으로 동시에 진행하여, 다양한 채널에서의 노출을 얻었다. - 개선할 점 광고 타겟팅이 너무 넓어서 정확한 타겟층에 도달하지 못했다. 이메일 클릭 비율이 기대 이하였다. - 원인 분석 지나치게 넓은 광고 타켓팅으로 잠재 고객 및 실제 구매 의향이 있는 고객에게 집중되지 않았다. 제목에 할인 혜택 명시가 명확하지 않아, 이메일 마케팅 클릭율이 낮았다. - 해결방안 다음 프로젝트에서는 고객 세분화 전략을 활용해서 더욱 정밀한 광고를 진행하자. 이메일 마케팅에서는 개인화된 제목과 함께 할인 혜택을 더 눈에 띄게 배치해보자.

 

무엇이 잘 되었고, 무엇이 문제였는가?

 

 

잘된 점과 개선할 점을 나눈 후, 

문제나 불편함에 도달했을 때마다 Why? 를 묻는 과정을 통해 발생 원인을 분석한다.

이때 각각 경험한 것을 듣고, 서로의 관점을 이해하는 것이 중요하다.

 

---

3-2 . 회고 내용 정리 후 공유

 

회고 미팅에서 나온 핵심적인 피드백과 개선 사항을 정리하여 팀과 이해관계자들에게 공유해야 한다.

이때, 회고에서 나온 아이디어가 실제 프로젝트에서 어떻게 적용될지 명확히 알 수 있도록 해야 한다.

 

실패 및 개선사항을 공유하여 전사적인 업무 방식의 개선이 이루어지면 가장 좋지만,

여의치 않을 경우 팀 규모의 회고로도 좋다.

< 회고 회의록 예시 >

회의 목적: 이번 프로젝트 진행 후, 디자인팀과 개발팀의 회고를 통해 잘된 점과 개선할 점을 정리하고,  향후 프로젝트에서의 개선 방안을 도출하기 위한 회의. 참석자 : 김배움, 최내일, 박스파르타  회의 일시: 2024년 12월 25일 (목) 잘된 점 : 디자인팀과 개발팀 모두 일정 내에 큰 문제 없이 작업을 완료했으나,  중간에 요구 사항 불명확으로 일부 수정이 발생. 문제점 : 초기 요구 사항 정의와 소통의 부족이 주요 문제로,  이를 개선하기 위해 기획팀과의 협업 강화 및 명확한 우선순위 설정이 필요. 액션 아이템 : 명확한 요구 사항 정의, 정기적인 미팅, 우선순위 설정 등을 통해  향후 프로젝트에서는 효율성과 소통을 개선할 예정. (상세 내용 첨부)