---
# System prepended metadata

title: PMP Review
tags: [PMP, '20220103']

---

PMP Review
===

###### tags: `20220103` `PMP`

### ver 1.0

PMP 1차 미팅 리뷰
---

일자: 2021.12.29 16:00 - 16:50
참석인원: 여승환 이사님, 김예나 팀장님, LEMONADE(김완기, 이강호, 홍석기)

---


**PMP는 우리가 프로젝트를 진행하면서 계속해서 기록해 나아가는 문서의 목차다.**
계속 이거 문서 들고가야한다 끝까지!
- 문서를 이해하려고 쓴 것 같다 // 잘 썼다! 칭찬 받았다!!

**현재 PMP에서 팀 목표와 개인 목표는 어느정도 설명이 가능**

#### 목푠지, Todo인지, 과정인지, 말이 중요하다!!
매일 수행하는 것이 목표가 아니다. // 지금 goal은 **2달 뒤의 나의 상태**이다. Todo가 섞여있다.

#### 문서화 -> 각자 중요하다고 생각하는걸 기록할건지 / 저 문장이 어떤 과정을 거친건지… 
기록의 이유 : 과정을 살펴보기 위해 계획을 세워야 함

기록에 관한 부분 중
- A는 과정을 기록하고, B,C는 결과를 기록하겠다는 것인지, A,B,C 모두 과정과 결과를 모두 기록하겠다는 것인지 명확하지 않을 수 있음
-> 팀 목표 자체가 개인 목표를 담고 있는 하지만, 모호성 제거 필요함.

#### 기록 중 고려 사항
>- 과정에서 적어놓은 것들, **왜 그랬는지에 대해서 기록**해야한다. 아니면 감정의 기록밖에 없겠다. 
>- ex) scrum 20분 -> 30분으로 늘어나는 사례에도 이유가 있을 것. 나중에 봤을때 이해가 되어야한다.
>- plan에 대해서 맥락이 필요하다. 기록의 방법을 바꿔야한다!
>**왜** 이런 plan을 진행했는가?
>- PMP는 우리의 지침서임을 명심
>- 개인적인 문서와 PMP 문서가 모두 통합되어야 한다.
>- 크림을 만들때 어떤 과정에서, 나의 역할과, 어떻게 느꼈는지가 필요하다.


고도화하려는 요소인 개인 추천화에 대한 부분을 검증하는 방법에 대한 방향을 바꾸는 것은 어떨까?

단순 추천이라는 주제를 가지고, **정량적인 판단을 하기에는 결과가 실제 옳다 틀리다에 대한 판단이 어려움.**

- 개인화된 상품 추천 피드 -> 잘되었다고 점검 가능
    - 끝에 우리가 잘했는지 못했는지 판단할 수 있을까?
    - 강호) A/B 테스트? 이사님) 몇 명? 점점 어려워진다.
    - 재밌어보인다고? 그게 아니라, 어떻게 달성할건지, 어떤 목적이 있을건지 그게 필요하다.
    - 추천이 잘됬는지 / 못했는지 판단이 가능하니? -> 추천 알고리즘이 그런게 어렵지 않을까?
    - 조금씩 달성 가능한 목표지점으로 좁혀가던가.. 하는 목적이 있어야한다.
    - 검증이 안된다면 // 설명가능한 개인화 추천… 너가 어떤 이유로 이 상품을 추천 받았다…
 이런 백로그를 남기는 것. 
    - 추천이 아니라, 개인화… 즉 설명가능한 개인화!!


아쉬운 부분😭😭 -> *용.두.사.미.*
>- managemant 와 plan의 인과관계가 없다. 
    // 협업 방식은 plan 이므로.. 뒤에 있었으면 좋겠다.
>- plan은 약간은 노말하게 끝난다.
>- 왜 기록하는 것인가?
    - 내가 다시 살펴보기 위해서다. 과정을!
    - 중구난방 적어놓으면 안된다. 그래서 계획을 세우는거다.
>- 왜 management냐?
    - 강호처럼 아플 수도 있는것이고, 충돌 및 일정, 그리고 물리적인 것들이 제약이 많을 것이다. 그런 것들을 미리 어떻게 진행할건지가 중요하다.
>- Architecture 관련: 지금은 map에 해당. 프론트 개발자들이 구현하고자 하는 바도 아키텍쳐 안에 드러나야함. (Atomic, MVVM) // 각각 아키텍처를 쓰는 이유에 대해서도 명확히 할 것.


ex) A를 **이런 방식으로** 하겠다. (어떤 맥락에 의해)

**goal과 management 사이 맥락 필요.**


목표 보면서 어떤 플젝을 하겠다 가 상상이 가는데 … 목표설정만 보면 어떤걸 만들겠다~ 라는 느낌이 없다. :: 여기도 맥락이 없음.
-> KREAM이라는 서비스를 목표를 위한 소재로 사용해도 좋음. 

### TODO : 2차 리뷰까지 해야할 일: PMP에서 맥락 찾기


<!-- - 석기: expectation 수정하기. -->
<!-- # 석기
PMP meeting

- 잘 썼다! 칭찬 많이 받았다!!
- 계속 이거 문서 들고가야한다 끝까지!
- 문서를 이해하려고 쓴것 같다. 

- 아쉬운 부분 -> 용두사미 느낌이 있다.
    - Management plan 이니까… 조금은 managemant 와 plan 의 인과관계가 없다. / 협업 방식은 plan 이므로.. 뒤에 있었으면 좋겠다.
    - plan은 약간은 노말하게 끝난다.

- 왜 기록?
    - 내가 다시 살펴보기 위해서다. 과정을!
    - 중구난방 적어놓으면 안된다. 그래서 계획을 세우는거다.

- 왜 management냐. -> 강호처럼 아플 수도 있는것이고, 충돌 및 일정, 그리고 물리적인 것들이 제약이 많을 것이다. 그런 것들을 미리 어떻게 진행할건지가 중요하다.
 -->


<!-- - 맥락이 너무 없는것이 아쉽다. //  -->

<!-- - ex) scrum 20분 -> 30분으로 늘어나는 사례에도 큰 이유가 있을것이다. 그런거를 나중에 봤을때 이해가 되어야한다.

- 과정에서 적어놓은 것들, 왜 그랬는지에 대해서 기록해야한다… 아니면 감정의 기록밖에 없겠다. 

- plan에 대해서 맥락이 필요하다. 기록의 방법을 바꿔야한다!

- PMP는 우리의 지침서이다!!

- 개인적인 문서와 PMP문서가 모두 통합되어야 한다.

- 크림을 만들때 어떤 과정에서, 나의 역할과, 어떻게 느꼈는지가 필요하다.

- PMP가 어떤 포지션으로 / 우리에게 어떤 역할을 할건지.. 중요.


- 개인화된 상품 추천 피드? -> 잘되었다고 점검가능?
    - 끝에 우리가 잘했는지 못했는지 판단할 수 있을까?
    - 강호) A/B 테스트? 이사님) 몇명? 점점 어려워진다.
    - 재밌어보인다고? 그게 아니라, 어떻게 달성할건지, 어떤 목적이 있을건지 그게 필요하다.
    - 추천이 잘됬는지 / 못했는지 판단이 가능하니? -> 추천 알고리즘이 그런게 어렵지 않을까?
    - 조금씩 달성 가능한 목표지점으로 좁혀가던가.. 하는 목적이 있어야한다.
    - 검증이 안된다면, // 설명가능한 개인화 추천… 너가 어떤어떤 이유로 이 상품을 추천 받았다… 이런 백로그를 남기는 것. 
    - 추천이 아니라, 개인화… 즉 설명가능한 개인화!!

목푠지, Todo인지, 과정인지, 말이 중요하다!!

매일 수행하는 것이 목표가 아니다. // 지금의 goal은 2달 뒤의 나의 상태이다. Todo가 좀 섞여있다.

문서화? -> 각자 중요하다고 생각하는걸 기록할건지 / 저 문장이 어떤 과정을 거친건지…  -->

<!-- —————

개발자는 management에 익숙하다!

개발 시 계획 잡고 기획할 때 처럼 PMP도 같다.

Design pattern을 확장하면 그게 아키텍처다. -> 유사하다. design pattern에 여러가지 방식이 아키텍처에 모두 있다.


 KREAM을 소개하는 것은 뺄까요? : -> 이걸 담아야겠다, 해서 담는 과정에서 행동한 우리의 생각이 중요한것이다!

————————————

김예나 팀장님 ) 



모든내용에 맥락을 채워라!!

과정 계획 기록 회고…

# 강호 -->

<!-- https://interesting-bramble-6c7.notion.site/PMP-c7b1952bd50f43d6a2938f985d4c6352 -->


<!-- 계획에 방향이 있어야, 과정을 기록한게 의미가 있다.
다시 살펴보기 위해 기록한다.
과정을 살펴보기 위해 기록한다.
Management 
계속 질문을 두려워하지 않아야하고, 답을 두려워하지 않아야 한다. 
그때 그때 어떻게 답을 낼 것인가?
어떤 계획으로 갈 것인지
회고 방법 정하기 뭘 한다가 중요한 것이 아니라 ~~ 한 것을 하기 위한 어떤 작업을 한다. 맥락이 필요해요.
여러분이 하겠다고 하는 것과 목표하고, 시간하고 모든 것들이 결합되서, 맥락이 있을 것.

딱 부족한 것은 맥락임.
목표가 약간은 목표와 TOdo인지 expectation 목표 상태
목표라고 적었던 것들은 수행해 나가는 과정에 가까움.
expectation이 더 좋음. 목표에 가까움
누구는 약간 todo 처럼 적어놓은 사람도 있어
실제 저것도 약간 말을 바꾸면된다.
조금 아쉬울 수 있는데 
다시한 번목표랑 회고에 대해서 생각을 해보고
어찌됐든 API, 아키텍쳐 문서 OK 
맥락이 없음.
맥락을 담았으면 참 좋았을 텐데
맥락이 없어서 아쉽다.
협업을 이렇게 할거다. 
실제로는 목표랑 프로젝트를 진행하면서 어떤 이유때문에 협업에서는 어떤걸 해보겠다. 라는게 있어야 한다.
업데이트를 해나가야 한다.

문제에 답을 내려놓고, 과정에서 의미가 있음
일기장 밖에 안됨
목표 없는 일기장은 감정 밖에 없음

각자의 기록에 의미를 찾아주는게 맥락임 -->