[서비스 기획 숙련] 킥오프와 회고

포스팅 목표
-실제 킥오프 되는 과정 살펴보기
-실제 회고가 되는 과정 찾아보기. 
-킥오프를 안해서 생겼던 참사 알아보기

---

킥오프란?

킥오프라는 건 무슨 뜻인가요?

❗ 프로젝트의 첫 단계로, 프로젝트가 공식적으로 시작되는 순간입니다.

이 단계에서 PM은 프로젝트의 목표, 범위, 일정, 예산 등 핵심적인 사항들을 팀과 이해관계자들에게 명확히 전달하고, 프로젝트의 성공적인 진행을 위한 기반을 마련합니다.(협업하는 사람들한테 전달하는 과정)

킥오프는 또한 프로젝트에 참여하는 모든 사람들이 같은 목표를 향해 나아가도록 유도하는 중요한 의사소통의 순간입니다.

프로젝트 개요

** LA 프로젝트 Kick-off
💡프로젝트명 : LA 프로젝트(서비스를 LA에 출시하겠다)
목표 : 내일배움캠프 PM코스를 한국 외 국가(특히 LA 중심) 앱스토어에 정식 오픈.(서비스 명만 바꿔둠)

 

1️⃣ 서비스 대상 국가
-한국 외 국가 (1차 타깃: 미국 LA)
2️⃣서비스 언어
-한국어 
3️⃣ 타깃 유저
-현지 한국 교민
4️⃣ 배포 채널
-앱스토어 / 구글플레이 글로벌 오픈

왜 하는가?

1️⃣ 한국 교민 대상 오픈으로 지표 향상 기대.
2️⃣ 교민 수가 생각보다 많음. → 유의미한 트래픽 가능성.
3️⃣ 완전한 글로벌 이전 단계로서 전략적 시험 오픈.
4️⃣  지표 확보 및 마켓 적응력 테스트 목적.

일정 및 마일스톤

✅ 오픈 목표 일정
-빠르면 5월 중
-늦어도 6월 중 

❗일정이 급박하며 빠른 의사결정 및 실행이 필요.

Infra 구성안(인프라)

💡두 가지 구성안 존재
-현재는 구성 2로 먼저 진행.
-구성 1 ↔ 구성 2 간 교체 용이. 
💡도메인 전략
-국가 코드에 따라 클라이언트 호출 도메인 분기. 

** 이전에 미리 정리해두었던 세부 항목들을 기반으로 인프라 구성안을 구체적으로 검토할 필요가 있다는 의견이 나왔어요. 그래서 관련 내용을 더 정리한 뒤, 다음에 다시 회의를 진행하자는 결론이 나온 회의였습니다. **

액션 아이템

[ ] 앱스토어 글로벌 배포 준비.
[ ] LA 지역 커뮤니티 대상 사전 마케팅 고려.

---

10대 타겟 프로젝트

💡10대 타겟 프로젝트

10대(14~19) 타겟을 위한 인앱 중심 브랜딩 캠페인 전개.
목표: 10대의 첫 배달 앱, 학창 시절 필수 앱으로 자리 잡는 것.

캠페인 전략

💡인앱 내 전용 페이지 개설 → 지속적인 앱 방문 유도 → 트래픽 기반의 프로모션 전개.

추진 배경 및 2024년 리뷰
📌배경
신규 유입 확대를 위한 전사 과제.
10대는 2030 대비 신규 풀 넓고, 4050 대비 진입장벽 낮음 → 전략적 공략 필요.
📌2024년 활동 요약
SNS - 프로모션 선순환 구조 형성.
10대 전용 혜택 제공 및 커뮤니케이션 채널 강화. 
 ❗아쉬운 점
앱 이용의 일회성.전략 집중 및 우선순위 재설정 필요. 

 

2025 실행 계획

📆 기간 : 2025년 3월 ~ 12월

 💡목적

• 1419 타겟 브랜딩을 통한 활성 고객 증대. 

💡기대효과

-1419 방문 침투율 증대.
-브랜드 호감도 상승.
-활성회원 증가. 

타깃정보

구분	수치
총 인구수	273만명
총 가입자수	109만명 (40%)
월 방문자수	82만명 (30%)
월 활성회원	55만명 (20%)  *30일 내 주문 이력 기준

 

📌 핵심 타깃

• 만 13 - 18세

📌 퍼포먼스 타깃

• 만 14~19세 (광고/프로모션 타겟 범위) </aside>

 

실행 방향

1️⃣인앱 중심 운영
1419 전용 페이지 개설 (상시 운영)
인앱을 캠페인 허브로 설정 → 지속 방문 유도
2️⃣ 페이지 인입 전략
3️⃣ 기존 유저 대상
📌 인앱 내 상시 노출 강화
푸시 메시지 주 1회인앱
메인 배너 / 메시지 카드 / 바텀 고정
 4️⃣신규 유저 대상
📌외부 도달 확장
홍보 영상 제작대형 유튜버 PPL (미미미누 등)
10대 공간 및 매체 집중 광고 
페이지 구조 및 운영 방식
1️⃣시즌별 주요 이벤트 구조 업데이트 예정.
2️⃣1419 전용 쿠폰 제공.

 

일정

기간 주요 내용

1/1 ~ 3/30	**럭키 드로우 운영 (ver1)
***3개월 운영 후 지속 여부 결정

 

 

KPI 및 목표

💡목표
25년 1월 기준 55만명 (20%) → 12월까지 109만명 (40%)
💡브랜드 호감도
24년 12월 30% → 25년 목표 60% 

예산 계획

항목 기간 예산

항목	기간	예산
신학기 프로모션	2월 4주차 ~ 3월	3억
럭키드로우	4월 ~ 6월	9억
TBD	7월 ~ 9월	4억
TBD	10월 ~ 12월	4억
총합	연간	20억

 

내배캠 사례 공유

👉 내배캠 사례 공유 링크

 

---

회고란?

회고가 중요하다는데, 회고란 무엇일까요?

❗ 회고는 팀의 작업 과정, 의사소통, 도전 과제, 성공적인 점 등을 되돌아보고 어떻게 더 나아갈 수 있을지에 대한 아이디어를 나누는 시간입니다.

회고 사례 1

잘한 점은 + 이모지를 붙여서, 아쉽거나 안 좋았던 점은  - 이모지를 붙여서 간략히 기록합니다.

김배움	아직 기존 히스토리를 잘 모르지만, 오늘 인수인계를 진행할 예정인데 팀내에서 인수인계가 진행되는 것이 아니다보니 혼자 가는게 맞는지 같이 가는게 맞는지에 대한 혼선이 있을 것 같음. 팀간의 R&R을 잘 모르는 상태라서... → 인수인계 미팅을 같이 가기로 하자.
나내일	-위키 공간 분리되어서 좋았음.(그전에 어떤 특수한 상황이 있었는데 위키로 분류해 쓸수있어 좋았다.) -이전 팀에서는 업무 문화, 그라운드룰 정하는 것을 했는데 잘 안되었는데, 이것저것 시도해보는거 좋은 것 같음. 지라나 이런거 써볼려고 하는 것도 좋은 것 같음. -유관부서 작업자나 작업여부가 조직개편으로 인한 여파가 너무 오래가고 있어서 확인이 늦어지는 것이 업무상 어려움이 있음. >> (우리가 어떤 부분을 없애고, 좋았던 점을 어떻게 살릴지 알아서 좋은 일하는 문화를 만들어나가려는 회고 목적)
박캠프	미팅이 너무 많아서 업무 집중도가 낮아지는 것 같음. 생산성을 높이려면 미팅 시간을 조정해 나가야 함
이취업	-스프린트 회고 시간이 오전인데, 리뷰하고 머지(개발자인듯)해야 하는데 그게 좀 애매한 것 같음. 스프린트 시간 오후로 바꾸면 오전에 리뷰해서 정리할 수 있을 것 같음. -코드리뷰 시간 정해놓고 하는 것 좋은것 같음. 하지만, 오전시간에 일하는 것을 진행하기 어려운 점은 있는 것 같지만 꼼꼼하게 보는 것 같음.>>무언가 한거에 대해 꼼꼼하게 볼수있는 상황이 있는건 좋았다.
정성공	내일님 교육 피드백 주신 것 중에, 몇가지 적용해보는 개선을 할 수 있어서 좋았던 것 같아요.

 

---

결정해야 할 것들

 📚Keep / Problem / Try

📌Keep
팀에서 계속하고 싶은 것. 
📌 Problem
문제라고 생각하는 것.
📌 Try
Problem을 해결하기 위해서 시도해 볼 만한 것.

 

Keep Problem Try

Keep	Problem	Try
-	일정 산정시에 미팅 시간이 고려가 제대로 되지 않았음.	회의시간 고려해서 일정 계획을 잡아야 함.
-	스프린트 기간내에 쓸 수 있는 시간을 산정해서 해야할 것 같음. (story point를 계산)	플래닝시에 예상 공수를 좀 더 구체적으로 산정하고 실제 가용시간과 비교해서 계획하자
-	PM스프린트 분리가 필요한가?	PM 스프린트 분리
-	스프린트 싸이클이랑 리뷰 시간이 맞지 않음. 스프린트 회고를 오후시간으로 옮기면 좋겠음.	회고는 수요일 오후 일찍 1시간30분, 플래닝은 회고 미팅에 이어서 (1시간)
-	QA관련 협의가 아직 제대로 안 되어있음. 그 외에도 외부 부서와의 일정을 좀 더 구체화 해야 함	외부 부서와 일정 구체화 및 이슈 정리 BC카드와의 연동개발 일정도 업데이트 해야 함
-	백오피스 오픈스펙 포함 여부 정해야 함.	우선순위 좀 더 구체적으로

 

다음 스프린트 Action Item

스프린트 관련 미팅 시간 조정

PM스프린트 분리

외부 부서와 일정 구체화 통해 잔여 일정 확정 (QA)

인수인계에 참여자 확대 (팀장, PM 모두)

어드민 페이지 중요도 다시 정리 (개발 스케줄 조정 가능성 확인)

---

감사함의 메시지

감사함을 전할 분	감사의 메시지
김배움	바쁘신 업무 가운데도 이 비루한 한 몸 잘 도봐주셔서 감사했어요!
나내일	-기획 내용 공유 때마다 적극적으로 의견을 내주셔서 감사드립니다 그리고 내일님의 아재(?)개그 덕에 팀 내 분위기가 한층 더 밝아지는 것 같습니다 감사합니다 -잦은 기획 변경에도 거리낌 없이 빠르게 대응해주셔서 너무 감사드립니다 -요청드리는 사항에 대해 항상 꼼꼼하게 검토해주셔서 감사드립니다그리고 업무 진행 과정에서 주시는 조언을 통해 많이 배우고 있습니다 감사합니다
박캠프	회식장소 섭외를 기가막히게 해주셔서 맛있게 잘 먹었습니다:) 앞으로도 PG팀 회식장소 담당 잘부탁드립니다!! ㅋㅋㅋ (농담이에여..ㅎㅎ)
이취업	-바쁘신 와중에도 돌보미 역할 잘 해주셔서 감사합니다. -취업님은 항상 열정이 넘치는 태도로 적극적인 의견을 내시고 논의를 이끌어 내셔서 동료들에게 긍정적인 영감을 주십니다. 감사합니다.
정성공	성공님이 옆에 있어서 든든해요. 항상 감사합니다! :)

---

회고 사례 2

 📚그라운드룰

 

 1️⃣ 카메라를 켜주세요.

필터를 장착하신다면, 표정을 확인할 수 있는 필터를 장착해 주세요! 

 

2️⃣ 특정인을 블레임 하지 않습니다.

회고는 설사 그 프로젝트가 엇나간 부분이 있다고 할 지언정 누군가에게 비난하는 자리가 아니기 때문에 특정인 저격 불가하다.

곧 죽어도 꼭 하셔야겠다면, 1비난, 1칭찬 등가교환 가능합니다.

 

3️⃣ 자책하지 않습니다.

 

4️⃣ 누군가를 탓하기 위한 회고가 아닌, 앞으로 일을 더 잘하기 위한 action item 도출에 집중합니다.

 

5️⃣ Do&Don't

-최대한 자세히 써주세요.
-팀원들에게 공유해도 되나? 고민되는 것도 작성하고 공유해 주세요.
-프로젝트 간의 경험을 솔직하게 작성해 주세요.
-좋았어요. 즐거웠어요. 와 같은 단순 단답형은 안돼요. 어떤게 좋고, 즐거웠는지.
  회고는 감정의 교류도 할 수 있겠지만 가장 중요한 것은 경험을 공유하고 더 -나은 방식을 찾아가기 위함입니다.
-성의 없는 답변은 전체 회고 퀄리티를 떨어트려요
-동료가 쓴 내용이 나를 저격하는 것인가? 라는 생각을 하지 않습니다.

---

회고 목적

 ☝픽업 프로젝트를 통해 느낀 점과 얻은 교훈을 바탕으로, 다음에 더 잘 일할 수 있는 방법을 모색합니다.

프로젝트 회고

1️⃣질문별로 1~5점으로 점수를 표시해 주세요. 점수별 이유도 함께 작성해 주세요.

2️⃣질문별 점수에 따라서, 프로젝트 진행 관점에서 답변해 주세요.

3️⃣솔직한 답변이 어렵다면, 문서 기록은 익명으로 하겠습니다.

 

질문

프로젝트 진행 경험은 어땠나요?

프로젝트 어려움이 많았나요?

어려움이 많았다면, 어떤 어려움이 이었나요?

성장을 할 수 있는 프로젝트였나요? (혹은 배운점이 있으신지?)

성장할 수 있는 프로젝트였다면 성장할 수 있었던 이유와 배운점을 공유해주세요

성장할 수 없는 프로젝트였다면 어떤부분이 성장할 수 없었던 부분인지 공유해주세요.

프로젝트 진행은 매끄러웠나요? (병목이 많았는지 이슈가 있을때 즉각해소는 잘되었는지 등)

매끄러웠다면, 어떤점이?

매끄럽지 않았다면, 어떤점이?

 

답변

1. (4.5점) -1. 단 기간에 또 이 만큼 이뤄냈다는 것이 대단하다고 느껴집니다. -2. 목표를 달성한 것은 만점이겠지만, 조금 더 계획적으로 과제 발의가 이뤄지고, 모두가 동시점에서 철저하게 함께 준비했으면 좋았을 것 같습니다. 하지만 우리는 왜 모든 프로젝트를 이렇게 하지 못하고 있을까요? 2. (1점)<--- 낮을수록 좋은 점수, 100등보단 1등이 좋은 느낌 -1. 모든 면에서 잘 해냈다고 생각합니다. 다만, OO와의 커뮤니케이션과 스펙 협의 과정은 아쉬움이 남습니다. -2. 계속적으로 스펙을 체크했음에도 끝까지 스펙이 변경된 것이 있었습니다. -3. 프로젝트 주요 논의에 초대되지 못한 부분이 여럿 있었기에 히스토리를 따라가기 어려웠습니다.(다행히 슬랙에 많은 내용이 남겨져있어서 좋았어요) 3. (3.0점) - 성장 정체에 가까움 -1. 제 개인의 성장에 있어서는 큰 영향이 있었던 프로젝트라 생각하진 않습니다. -2. Core한 기획 및 의사결정은 다른분들이 해주셨고, 외부연동을 위한 스펙 정의/Com 정도라 성장의 척도에선 큰 발전은 없었습니다. -3. 다만, 그럼에도 배운것이 있다면, 체크리스트를 조금더 사전에 꼼꼼히 준비해서 관리하고, 논의에 대한 기록을 어떻게든 남기자는 것입니다. 4. (5.0점) 1. 프로젝트 리드해주시는 분들께서 상시로 주요 내용을 공유해주고, 상황 체크해주셔서 감사해요

1. (4.5점) 1. 일정 지연 없이 배포까지 수월하게 진행된다는 느낌을 받았습니다 1. 서버 테스트 일정, QA 테스트 일정 등이 순차적으로 잘 동작했다는 인상입니다 1. 개발 일정 논의 때 buffer등을 개발자 개개인의 일정을 최대한 고려하여 선정하였는데 주효했던것 같습니다 2. 협의할 때 OO개발팀 분들과 논의가 수월하게 진행되어 편했습니다 3. 전 한게 없어서 사실 구경만 했습니다 2. (2점) 1. 전 한게 없어서 사실 구경만 했습니다2 2. 이번에 인수테스트 형식으로 쪼개어 티켓을 진행했는데, 티켓 단위가 너무 세분화 되어있어 각각의 티켓을 관리하기 어려웠습니다. 기능 한번 배포 할 때 n개의 티켓이 묶었기 때문이었던것 같아요. 하나의 태스크가 하나의 기능 배포를 할 정도의 사이즈였다면 괜찮았을거 같네요 1. 서브태스크 보단 todo를 썼다면... 3. (3점) 1. 많은 도메인에 느슨하게 걸쳐있는 프로젝트 였는데, 개발자 입장에선 할게 별로 없었다는 입장이지만 큰 그림을 만드는 분은 고생하셨을 것 같습니다. 개발 공수와 프로젝트의 어려움간의 연관성에 대해서 생각해볼 수 있는 프로젝트였습니다. 2. 한 게 없어서.. 개발적으로는 성장했다는 느낌은 못 받았습니다. DB 칼럼 하나 추가했고, API 수정했고.. 4. (4.5점) 1. 각 일정별로 설정된 태스크가 이상없이 진행되었고, 이슈도 바로바로 해결되었다는 인상을 받았습니다. 각 자리에서 개발해주신 개발자들의 노고와 일정 수립과 프로젝트 관리를 해주신 분들의 조화가 잘 이루어졌다고 생각합니다.

1. (3.5점) 1. 기존 시스템의 개선이 되지 않았던 시점에서, 서비스가 덧붙여지는 형식이었다 생각합니다. 2. 급한 일정으로 "이건 운영개선에 넣어야 한다"라는 말을 습관적으로 하게 됐던 것 같습니다. 2. (2점) 1. 프로젝트를 진행하며 큰 어려움은 없었지만, 기획 <> 개발 논의시간이 많이 부족했다고 생각합니다. 2. 이번 프로젝트 뿐만아니라, 다른 프로젝트에서도 정책/기획 → 개발 전달 과정에서 단방향 통신이 이뤄지는 경우가 많다고 생각합니다. 1. 이렇게 해주시면 됩니다. 라는 등등 2. 개발팀에서 기획을 모르는 상태에서 기획리뷰를 하는 경우가 허다 했던 것 같습니다. 3. 즉, 지식이 없는 상태에서 "리뷰"를 하게 됐던거 같아서, "리뷰"라는 워딩 보단 기획 "논의" 이후, "리뷰" 시간을 추가로 가지는게 어떨지 생각합니다. 3. (3.5점) 1. OO 기획/개발 팀의 전반적인 플로우에 대해 알게됐던 프로젝트라 생각합니다. 1. 여러 도메인이 업무연관성이 있어, 리뷰 등을 참여하며 이해도가 높아졋던 것 같습니다. 2. 쉽게 이해할 수 있게 준비하셨던 모든 분들에게 감사합니다 4. (3점) 1. 정책/기획이 완료됐음에도, 개발이 진행되며 지속적인 변경이 있었던 것 같은데, 이에따른 문서 업데이트가 기민하게 변경되지 않았던 것 같습니다. 1. 개발이 진행되며 이런부분들이 두드러지게 된다고 느꼈는데, 그러다보니, 초기 기획과 많이 달라지며 히스토리가 계속 쌓인다는 느낌이 있었습니다. 2. 즉, 정책/기획이 변경되는 속도를 기존 문서가 따라오지 못해, "왜 이렇게 한다고 했었지?"라는 느낌을 지속적으로 받았고, 이에 따른 리소스 낭비를 느꼈습니다. 3. 해당 부분에 있어서, 2에서 말한 것과 같이, 초기 "논의" 및 "리뷰"시간이 많이 부족하지 않았나 생각합니다. 1. 논의 시간이 더 많아지면 좋겠습니다. (이해가 완벽히 될 때 까지 필수 시간을 두는건 어떨지 생각합니다.) 2. 전반적인 부분에서 여러분들이 화이팅 해주셔서 즐겁고, 매끈하게 플젝이 진행됐던 것 같습니다

1. 4점 1. 일정을 맞출수 있었고, 비교적 스무스하게 오픈할 수 있었습니다. 2. 이해하기 어려운 데드라인으로 프로젝트 진행 인원이 많이 힘들었던거 같습니다 2. 4점 1. 오픈이 미루어지는데도 변하지않는 일정, 그에따른 추가 개발 스펙 2. 병렬로 성격이 다른 프로젝트 + 운영 배포가 이루어 지다보니 그에따른 코드 충돌 지옥 3. 일정상 나중으로 미뤄뒀던 일이 부메랑이되어 예상못한 프로젝트 필수 피처로 돌아옴. 일반셀러에서도 똑같이 반복될거 같다 3. 3점 1. 주문 -배송의 코드를 더욱 잘 이해할 수 있었습니다 2. 근데 이해한걸 이제 넘기게 되어서 갑자기 1레벨로 돌아간 느낌을 받게 되었습니다 4. 4점 1. 새벽까지 대응하느라 고생하며 기민하게 대응해서 매끄러울 수 있었던거 같습니다 2. 우리모두 고생하고 잘 해낸거 같습니다

1. → 4점 1. 특별한 이슈가 없었습니다. 2. 픽업보다는 다른 업무(커머스주문이관, 탈퇴분리보관)가 더 많아서 아쉬웠습니다. 2. → 4점 3. → 1점 ◦ 개발 이관이 예정되어 있고 일정이 정해져 있어서 구조 개선을 할 수 없어 아쉬웠습니다. ◦ 음 왜 계약 확정(보안 요구사항)이 완료되지 않았는데 개발이 진행이 된걸까요? 4. → 4점

1. (4점) 이미 다른 과제 배포를 계획하고 있는 단계에서, 픽업은 날짜가 박혀있었기 때문에 같이 준비해야 하는 부분이 부담스러웠습니다. 그럼에도 결과적으로는 무사히 배포되어서 뿌듯했습니다. 2. (4점) 정해진 시간 내에 구조 개선까지는 어려웠기 때문에 스펙 축소가 불가피했는데, 이 부분을 사업에 설득하는 게 다소 어려웠습니다. 3. (3점) 상품 도메인 기획 자체로만 보면 큰 정책이 추가되거나 하는 부분이 없었기 때문에 성장했냐? 하면 그렇다고 할 수 없을 것 같습니다. 그럼에도 3점을 준 건, 픽업 이전에 대표이미지 마스킹 여부 관련 배포를 했었는데 이때부터 취급상품 종류로 기획을 했으면 셩님이 두 번 일 안 해도 됐을 것 같은데 하는 개인적인 아쉬움 + 배움이 있었습니다. 픽업 이전에 배포되었어야 하는 과제를 데브에서 QA + 앱 정상 노출 테스트를 위해 일시 베타 점유 ← 이 부분이 매끄럽게 되지 못해 아쉬움 + 배움이 있었습니다. 4. (5점) 유관부서, 담당자가 많은 프로젝트였는데 잘 이끌어주셔서 감사합니다. 칼.있.스.마 이번처럼 담당자가 많을 때는 오버커뮤니케이션이 중요하다고 생각하는데, (거의 데일리로) 이슈 여부 체크해주신 점 감사합니다. 고생 많으셨어요! QA 이슈가 많이 안 나왔습니다.

1. (4점) 프로젝트 진행 경험은 어땠나요? 일단 일정안에 배포 해서 5점 드려요! 오예~ 초반에 요구사항을 청취해서 MVP를 확정하기까지 리드타임이 길었어요 (-0.5점)배민스토어 유관부서들의 고질적인 문제인 것 같기도.... 야근을 1도 안한날이 없었습니다.... (-0.5점) 2. (1점) 프로젝트 어려움이 많았나요? 처음이자 마지막 오프라인 스펙점검, 일정점검이었는데 너무 번갯불에 콩구워먹는 시간이었던 것 같습니다... (+1점) 3. (2점) 성장을 할 수 있는 프로젝트였나요? 도메인에 대해서 얕게 알고 있었는데, 많이 공부했어요. (+1점) 통장 내역이 성장했어요 (+1점) 4. (5점) 프로젝트 진행은 매끄러웠나요? (병목이 많았는지 이슈가 있을때 즉각해소는 잘되었는지등) 프로젝트 대장님이 있어서 든든했어요. 5점 드립니다. 기획, 개발, 웹프론트, 디자인, 전시 기획, 전시개발, QA, 사업, 법무 등등등 모든 유관부서를 지휘해주셔서 감사합니다. 저와 같은 도메인 개발한 분들도 번갯불 워크샵 이후에 픽업에 대해서 빠르게 이해해주시고 많은 의견 주셔서 매끄럽게 진행할 수 있었어요. (+1점) 배포를 며칠 앞둔 시점까지도 스펙변경이 있었어요. (-1점)

1. (3.0) 프로젝트 진행 경험은 어땠나요? 1. 빡셌습니다 2. 기존 기술 부채가 거의 미분양 아파트급으로 쌓이더군요 이거 해결할게 너무 많습니다.. 3. 자잘하게 너무 많은 부분을 건드렸던게 컨텍스트 스위칭이 어렵더군요 2. (4.0) 프로젝트 어려움이 많았나요? ◦ 시간이 없었습니다 하지만 역시 야근은 만능이었습니다. ◦ 각자 맡으신것들이 많아서 컨텍스트 스위칭과 커뮤니케이션이 어려웠습니다 3. (2.0) 성장을 할 수 있는 프로젝트였나요? ◦ 프로덕트의 컨텍스트와 프로세스의 전반적인 부분을 볼 수 있었다 ◦ 다만 이걸 통해서 성장했느냐? 는 잘 모르겠다. 4. (3.0) 프로젝트 진행은 매끄러웠나요? (병목이 많았는지 이슈가 있을때 즉각해소는 잘되었는지등) ◦ 후반에 계속 DM으로 상황을 여쭤봐서 죄송합니다.... ㅠㅠ ◦ (프론트 자체 이슈) 묶어서 MR을 계속 진행하는게 좋지 않을까 싶은 상황이었던것이 ff-merge형태라서 MR을 이슈단위로 잘게 쪼개면 자꾸 뭔가 수정했던 것들이 유실 되는거같은 느낌으로 리오픈이 생겼었다. ◦ 중복으로 겹치는 부분때문에 조금 고생한거 같기는합니다. 서로 수정한 부분 + 리팩토링 같은 부분들에서 불필요한 이슈가 생겼었음 ◦ 어찌되었든 한개의 프로젝트를 여러명이 해서 코드가 파편화 되는거 보다는 한명이 후딱 할 수 있는게 나은거 같다.

 

 

개인별 회고

좋았던 점	개선할 점 / 다음에 시도해볼만 한 것
일정 지켰다! 배포 직후, 테스트과정에서 큰 이슈 없었다! 첫 프로젝트여서 걱정이 많았는데, 팀원들이 많이 도와줘서 큰 어려움 없이 할 수 있었다. 도메인 지식도가 엄청 상승했어요! 처음에 한판을 그릴껄..... 왜 안그렸을까.. 전반적인걸 그렸어야했는데 요구사항을 어떻게 빨리 받고, 어떻게 정리하고 MVP 스펙을 더 유연하게 정리할 수 있을까? 이부분이 아쉬움 베타점유.... 한 세번? 네번을 A님, B님, C님, D님, E님 번갈아가면서 붙잡고 이야기했던점 (첨에 이해좀 잘해볼껄..ㅋㅋㅋ) 사업팀하고 커뮤니케이션할때 너무 장문으로 말했다....... 더 이쁘게 말할수있지않았을까? (그땐 정말 이쁘게 말했다 생각했는데 돌아보니 너무 냉정하게 말한건 아니였을까 반성해봅니다.)	• 문서화를 잘하자=(공유를 잘하자 라는 리뷰) . 구두 논의가 끝난건 슬랙이나 문서화해서 공유하고 이해한 온도가 다 맞는지 체크한다. • 계속 공유하고, 확인하자 (맞을까? 이 방법?) • 한판을 그리고 시작하자. ◦ 메인 PM이 있어야할 것 같다. • 어떻게 하면 더 유연하게 프로젝트를 진행할 수 있을지에 대한 부분에 대한 고민이있고, 이걸 어떻게 하면 더 잘할 수 있을까? 에 대한 고민이있어요 (다른분들의 의견 궁금)
일단 배포! 확인 확인 또 확인한 점 허들 조아용 일정은 정해져있고, 스펙은 나가야하고... 최대한 변경을 적게 하려고 고민해 봄 배포 며칠 앞두고 스펙 변경하게 됨에 따라 V2를 배포한 점 (그래도 V2도 일정 내 무사 배포) 프로젝트랑 스프린트 동시 QA 했던 점 OO 정보 개발자 수기 업데이트 할거야 말거야로 막판에 사업팀과 투닥투닥한 점	• DB 수기 업데이트 절대 안된다고 첨부터 딱잘라 말할걸....
일정지연 없이 무사 배포했다. 기등록 상품 배송방식 일괄 업데이트도 잘 됐다! Phase 2 과제까지 생각하고 기획해라 나 자신아 (성인인증 → 픽업) QA > 배포 테트리스 어렵다. 어떻게 했어야 할ㄲr.........? (도대체 왜 아무런 말도 없는 거야 이젠 할 말도 없는 거야......)	• 향후 과제까지 고려하여 기획을 하자 (대표이미지 마스킹 영역 n일천하...) •데브 QA는 리스크(심리적불인감)가 있다. 앞으로도 큰 프로젝트가 베타 점유를 할 수 있을텐데, 이럴 때는 어떻게 슬기롭게 대처할 수 있을까?
훌륭하게 일정 지연 없이 오픈할 수 있었다. 우리쪽 개빌&기획/OO팀/외부 셀러와의 테스트 & 협조가 순조로웠다. 스펙확인을 처음부터 했지만, 계속 OO쪽 요구사항이 변했다. QA(베타/운영) 일정을 잡기 전에 가능한 상황인지를 꼼꼼하게 먼저 챙길걸	• OO와 스펙 협의가 있을 시, 꼭 문서나 슬랙으로 이력을 남기자 ◦ 이번에도 프리픽스값 변경에 대한 이력이 있었다. ◦ 허들로만 요청받았으면 뒤늦게 이게 무슨일이냐며 난감할 수 있었다. • 일정/오픈에 관한 체크리스트 작성 시, 해당 항목이 진행될 수 있는 필수 조건 등을 기록해보자 ◦ 운영 QA를 하려면, 당연히 운영환경에 서비스가 노출되어야 한다. ◦ 이 부분이 우리에겐 당연한 얘기일 수 있어도, 다른 팀에겐 아닐 수 있다. • 주/격주 단위로라도 한 주간 주요변화&결정사항, 공지사항을 문서로 남겨두면 어떨까? ◦ 난감한 의견 충돌에서 큰 힘이 될 수 있다.
일정 문제가 없었다 각자 알아서 딲딲딲 진행해주시는 프로페샤날 여러분 이 멋있었습니다	• 일정 맞추기위해서 간단한 방향, 최소스펙만 생각했던거 같다 ◦ 꼼수만 늘어나는 왜곡된 성장을 하고 있다 스컬 그레이몬 될듯
일정 산출에 시간을 많이 써서 그런지, 일정을 진행하며 무리가 없었다 요구사항에 관한 부분들을 테스트를 작성하며 개발을 진행했어서 그런지 기능적인 QA이슈가 나오지 않았다. 기획분들이 열심해 해주셔서 기획 이해를 위한 시간이 많이 필요하지 않았다. 프로젝트랑 스프린트 동시 QA 했던 점 → 배포가 너무 힘들었다. 오픈 배포 전 스펙 변경을 급하게 했던점. → 기획 의도와 개발 방향에 대해서 심도있게 고민해야함을 알게됐음.	• 멋진 프로젝트를 만들기위해 개발에서 할 수 있는 일을 많이 고민해봐야할 것 같습니다. ◦ 같이 마스터피스를 만들기 위해 노력할 수 있는 부분들을 많이 시도해보고 싶습니다. ◦ 개발쪽에서도 플젝문서 만들어보는것을 시도해보고 있음
안 밀렸다 수립된 일정들이 태스크 별로 차근차근 진행되었다 정산 엑셀 다운로드 이슈있는것 같던데 OO서비스에서 매를 대신 맞고 있는 거 같다;; 죄송	• 스펙은 빨리 뽑아주는 게 장땡인 듯 하다 먼저 전달해줄 궁리를 잘 하자 • 티켓이 너무 많아지니 관리를 안 하게 되던데 서브 태스크를 todo 단위로 줄이자 • 남 일도 신경쓰자 (진행에 대한 공유가 3줄 요약으로 공유되면 좀더 인지가 잘 될거 같다)
별로 안 밀렸다 나도 한게 없다 (픽업은 아니지만 탈퇴/휴면) 관리 잘 해주신 A님 감사합니다	• 쿠폰 사용 정책을 초기에 (다른분께) 구두로만 전달 받고 어 정책이 맞는데 왜 버그인지 한참 고민했다. ◦ 기획서를 확실히 봐야겠다 • 멀티 브랜치 배포 환경 구성을 잘 하면 여러 분들이 편리해질 것 같다그런데 아래 프로젝트가 완전히 독립적으로 진행된다고 할때 이런 문제는 어떻게 해야 할까
훌륭하게 일정 지연 없이 오픈할 수 있었다. 운영스프린트와 병행 진행되는걸 잘 정리해서 해냈다. 기획서 / 스펙을 잘 정리해주셔서 픽업 셀러도메인 V2도 금방 했다 ( 태정님 지효님 고생 많으셨습니다 ㅠㅠ ) 요구사항과 세부 스펙 변경에 대해서 조금 더 고민하고 기획 리뷰를 드렸어야 했었다 초반에 대기 시간이 좀 길었다 머지 순서오류 때문에 코드 유실 발생, 이슈 리오픈이 많았다.	• 기획 리뷰를 좀 더 생각하면서 들어봅시다. • 좀더 효율적으로 시간을 사용해 봅시다 • 이슈를 천천히 몰아서 묶은다음에 쳐내야할까요? 보이는대로 치다보니 .... ㅠㅠ

 

공통으로 느낀 문제와 해볼 수 있는 것들

문제

💬프로젝트 유관부서를 다 모아서 한번 이야기를 하는 것이 필요할 것 같다.

💬과제 발의하고 이걸 프로덕트에서 어떤 일을 해야 하고, 어떤 것들을 대비해야 하고 이런 것들을 같이 정리하면 좋을 것 같다.

💬하나의 태스크가 하나의 기능 배포를 할 정도의 사이즈가 좋을 것 같다. → todo 기준으로 관리하면 어떨지.

💬정책 ↔ 개발
-단방향 통신이 많았다.
-기획을 모르는 상태에 기획 리뷰를 하는 경우가 많은데, 개발 진행과정에서 이슈가 있을 때 말하기 어려움이 있음. 

 💬베타 점유, 데브 테스트 과정 등에 이슈를 어떻게 잘할 수 있었을까.
-멀티 베타 환경 어떨까요? 

 💬요구사항 청취, 유관부서 협의 MVP 확정까지의 리드타임이 길었다.

💬두괄식으로 내용을 써보는 것도 방법이겠다.

 

문제	액션 아이템 제안
사업팀하고의 요구사항정리 어떻게 할까?	• PM : 안건발의(이프로젝트 해야해!) + 1~2주정도 여기저기 회의 소집을 당해요. + 1주일간 사업팀하고 스펙협의 해요(미팅 1주일동안) + MVP확정아닌 확정이됩니다.
	• 근데 이거 찐찐찐찐 MVP설정을 잘 해주면..... 일정을 줄일수 있지 않을까요...?
• 사업팀 회고에서 이야기 더 해보기
내용 공유 어떻게 하면 좋을까? 어디까지하면좋을까?	• 허들 끝나고 결과를 공유하자(꼭 하자!)
	프로젝트 시작시 그룹멘션 만들어서 모든 내용은 그룹멘션으로 공유하자.
	• 개인이 알잘딱하자 !! 노오력을 합시다.
정책 ↔ 개발 단방향 통신같은 느낌을 어떻게 없앨수있을까?	• 킥오프 - 굵직 (왜하는지)
	기획리뷰 - 상세 기획
	변경리뷰?! - 이 기획이 변경되어야 할 것 같아요! 를 말 할 수 있는 세션을 어떻게 적으면 좋을까... 단어가 생각나지 않아요...
	• 근데 이건 데일리 스크럼 아니에요 사실?
	• 저는 프로젝트 규모는 잘 못봤지만 support에서 요청건을 일찍 발견할 경우 미리 고민해볼 수 있어서 좋았던거 같아요
	• 문서에서 유지하는건 안적어주셔도 무방하지 않을까 싶기는 합니다. 조금이라도 읽어야하는 단어 갯수가 줄어들면 기획서를 읽는데에 도움이 되지 않을까 싶은...