첫번째 KPT 회고

작은 미니 프로젝트가 끝나고 처음으로 KPT 회고에 대해서 작성하려 한다.

먼저 KPT 회고에 대해 간단하게 설명하자면 

K = Keep (유지)

P = Problem (문제점)

T = Try (시도)

이 세 단어의 약자로 프로젝트의 진행과정에서 있었던 내용을 정리하고, 회고하는 방법으로

관점을 K, P, T로 나눠 생산적이고 더욱 미래지향적으로 회고를 하기 위한 방법이다.

 

이렇게 모든 팀원의 생각을 공유함으로써, 더욱 발전할 수 있고 Next Step으로 넘어갈 수 있다.. 본격적으로 작성해보자

---

1. 우리는 Team 입니다.

안녕하세요. 내배캠 B-2 봄바람의 팀장 김지환입니다.

저는 언제나 '성장'이라는 단어를 가슴속에 품고있습니다. 그래서 이번에 역시 과연 프로젝트를 통해서 내가 얻을 수 있는게 무엇을까? 라는 생각을 했으며, 성장이라는 키워드를 떠올렸습니다. 프로젝트를 통해 과연 '나'와 '팀원'이 어떻게 하면 성장할 수 있을까? 라는 물음에서 나에겐 배운 지식의 복습효과와 팀원에겐 배운 내용의 학습내용을 점검할 수 있는 부분이 있다는 것을 발견했습니다.

 

그래서 우리 팀만의 약속을 하나 정했습니다.

"모르는 지식에 대해 물어보는 것을 두려워 말고, 서로를 존중하고 배려하는 자세를 통해 더욱 성장하자"

 

이러한 팀의 뼈대를 바탕으로 KPT 회고 진행하겠습니다.

---

2. K (KEEP)

이번 프로젝트에서 좋았던 점을 통해 앞으로 유지(Keep) 할 사항

 

 -  프로젝트에서 발생한 문제나 오류를 팀원이 적극적으로 질문, 진행 상황을 공유하는 것

              + (위 사항을 기반으로 문제 해결 후, 해당 부분을 꼭 복습, 그 지식을 내 것으로 만들기까지 - KDH)

   

저흰 프로젝트를 진행할 때, 저희 팀만의 약속을 정했는데, 바로 1번이 "모르는 지식에 대해 물어보는 것을 두려워 말자"였습니다. 동일한 학습에 대해 기존의 배경지식이 다를 수 있고, 흡수하는 능력이 다르기에 당연히 모르는 부분이 생기기 마련입니다. 보통 모르는 부분이 생기거나 문제점이 발생하면 물어볼 멘토 혹은 더 많은 지식을 알고있는 사람이 필요한데, 그렇지 못한 환경이라면 문제를 해결하는 부분이 어려울 수 있다.

 

이러한 점에서 서로에게 질문하고, 그 질문에 대해 답변을 줄 수 있는 환경을 구성하는 것은 매우 중요하고, Keep 해야할 사항이다.

 

배우는 사람의 입장에선 모르는 부분에 대한 궁금증을 해결하고, 발생한 문제를 해결함으로서 다음 스텝으로 나아갈 수 있는 길이 생긴 것이고, 가르치는 입장에선 궁금증을 해소시키고, 들어온 질문에 대해 답변을 해줌으로써 내 지식이 맞는 것인지 확인할 수 있어 서로에게 이득이 되는 상황이다. 

 

그래서 결론  - 서로에게 모르는 부분이나 발생한 문제, 궁금증에 대해선 적극적으로 어필하고 그 부분을 아는 사람에게 물어보며, 진행 상황을 공유하는 문화는 KEEP

3. P (PROBLEM)

이번 프로젝트에서 아쉬웠던 점을 기반으로, 개선사항에 대한 모든 것, 혹은 일련의 사건

 

- 발생한 문제에 대해 혼자 해결하려 할 때 시간을 많이 지체했다는 점,

튜터분들께 피드백 받은 리팩토링, REST API, 개인페이지 구현에 있어 발전시키지 못한 점,

팀원들과의 소통이 부족하다고 느낀 점

---

 - 문제? 혼자 해결하지 말자! (해당 문제가 많은 시간을 잡아먹는다면)

프로젝트를 진행하다 보면 수 많은 문제를 접하게 될 것이고, 이 문제를 혼자 해결하려는 습관은 좋으나, 많은 시간이 걸릴 수 있다. 또한 배경에 대한 지식이 다르다면 난이도에 대해 몸으로 체감하는 것 역시 다를 것이다. 혼자서 문제를 해결할 수 없다고 느껴지면 빠르게 팀원에게 help call을 요청하는 것이 아무래도 시간을 절약할 수 있지 않나?라는 의견도 있지만, 반대로 팀원에게 의존이 강해지면 결국 나중에 스스로 무언가를 할 때, 힘들어 질 수 있는 단점이 있다.

 

그래서 이 경계를 적절하게 넘나들며 팀원에게 질문을 하는 것이 좋다고 생각한다. 

 

시간이 없다면 결국 하려고 마음먹은 작업또한 딜레이 될 것이고, 결과적으로 프로젝트의 전체에 영향을 주기 때문에, 시간을 타이트하게 쓰려고 한다면, 발생한 문제 혹은 에러사항에 대해 빠르게 짚고 넘어가도록 하고, 그 부분에서 얻은 지식과 내용, 확장적 사고를 따로 정리하는 시간을 가져보면 괜찮지 않을까? 라는 생각을 해본다.

 

-   Try :  문제 해결에 관한 많은 시간이 소요될 경우 빠르게 help call

            발생한 문제에 대해 1차원적인 관점이 아닌 다양한 관점에서 바라보고 문제를 해결할 수 있도록 노력 할 것

---

- 의지 부족?

솔직히 하고자 한다면, 의지만 있다면 더욱 확장해서 할 수 있었지만, 그렇지 못했고, 그렇지 않았다. 나 역시 다른 프로젝트를 진행하면서 구현과 설계 등을 고민하며 자는 시간, 활동 시간 등 시간을 줄여서라도 완성을 해냈던, 어떠한 방법도 가리지 않고 결과를 만들어 냈던 점이 있었다. 

 

이번 프로젝트 또한 마찬가지이지 않을까? 하고자 하는 의지만 있었더라면, 더욱 견고하고 다채로우며, 좋은 기능들을 만드는 것을 시도해볼 수 있었지 않을까? 감히 생각 해본다.

 

  -   Try : 어떻게든 목표를 정해서, 그 목표를 주어진 기간 내 해결하려는 의지를 키우고, 꼭 해낼 수 있도록 수단과 방법을                 가리지 말자

  -   Try : 자신이 맡은 혹은 팀이 맡은 프로젝트에 관한 욕심을 최대치로 끌어 올리자.

---

- 소통의 부재

팀원의 입장에선 소통의 부재를 느끼지 못했을 수 있지만, 적어도 팀장의 입장에선 소통의 부재를 느꼈다. 개인 페이지에 에너지를 많이 쏟다보니 팀 페이지나 url, 협업 방식, 적용 기능, 디자인 등에 대한 의견을 많이 나누지 못했다는 점을 느꼈기 때문이다. 팀장의 위치라면 더욱 리드하자, 끈질기게 붙어서 팀원들을 checking 할 것.

 

  -  Try : 다시 한번 팀장직을 맡게 된다면 더욱 꼼꼼하게 설계하고, Check하는 스탠스를 가질 것. 

             팀장 및 팀원 주도하에 계획과 목표를 더 구체적으로 설계할 것.