👀 KPT로 보는 팀회고

💭 함께 자란 팀은 마지막에 웃는다

🏆 첫 팀프로젝트는 미완성이지만 과정은 성공적이다.

'첫 팀프로젝트 보글'은 결과적으로 미완성으로 끝지만
그 과정은 협업을 이해하는데 있어 나에게 성공적이었다.

• 서비스적으로는 기획했던 기능이 모두 구현되어야 하는것이 맞다 하지만 기술적인 부분 이외에도 중요한것들을 배우게 되었다.

프로젝트 종료 후 개인적으로 느끼고 배운점을 KPT 방식과 5F로 정리하였다.

1. 커뮤니케이션의 중요성
2. 지식 공유에 박한 사람
3. 기능이 작동된다고 아는것은 아니다
4. 프로젝트에서 기한을 지키는 것은 중요하다
5. 모르면 탐구, 해결하고자 하는 집요함
6. 결국에는 사람이다

웃음 가득한 팀원들! :-)

---

프로젝트 KPT (Keep, Problem, Try)

• Keep : 계속 유지되어야할 내용

  • 에러사항 내용과 해결방법 공유
  • 팀내의 역할분담
  • 적극적인 아이디어 회의
  
  

• Problem : 잘되지 않거나 문제가 있었던 내용

  • 소통의 부재
  • 팀내 일정 공유
  • 실제로 구현되지 않은 기능들
  • 적극적인 의견 제시
  • 협업툴 사용 미숙
  • 낮은 참여도
  
  

• Try : P의 해결을 위해 다음번에 시도할 일들

  • 아이스브레이킹 티타임
  • 협업툴 적극 활용
    (깃허브 브랜치, PR, 스케줄러, 트렐로 등)
  • 작업의 우선순위 선정
  • 팀내 현재 상태 공유
  • 프로젝트 사이클 별 회고 진행
  • 지식 공유의 활성화를 위한 프로젝트 기술 블로그 작성
  • 포커스 타임
  • 프로젝트 백엔드 위키 작성
    (에러 해결, 새로 알게된 내용 ...)

---

😃 5F로 보는 개인 회고

• Fact (사실: 무슨 일이 있었나?)
• Feeling (느낌: 무슨 느낌이 들었나?)
• Finding (배운 점: 어떤 인사이트를 얻었나?)
• Future action (향후 행동: 앞으로 무엇을 해야 할까?)
• Feedback (피드백: 앞서 정한 향후 행동을 실천해본 뒤, 이에 대해 어떤 피드백을 받았나?)

---

📕01. 커뮤니케이션의 중요성

개발자에게 있어 협업과 커뮤니케이션은 늘 강조되는 부분인데, 팀프로젝트를 경험하여 그 중요성의 '이유'와 '방법'을 배우게되었다.

• Fact (사실: 무슨 일이 있었나?)

  • 프로젝트시 팀원내의 집중하는 시간이 정해져있지 않았다. 24시간 풀로 올라오는 공지와 요청에 확인하지 못해서 놓치는 부분이 있어서 소통의 부재가 발생하고, 다시 설명해야하는 상황이 발생

• Feeling (느낌: 무슨 느낌이 들었나?)

  • "자주", "쉽게" 대화 할 수 있는 환경
  • 사람은 모두 다르기에 충돌은 당연히 일어날 수 밖에 없다.
  • 함께이기에 해결할 수 있는 일이 더 많다.

• Finding (배운 점: 어떤 인사이트를 얻었나?)

  • 편안한 환경에서 원활한 커뮤니케이션이 오고가는것을 확실히 느낀 순간이었다. 강의실에서 대화하는것보다 코드를 탐구하는 내용, 아이디어 등의 문제점, 해결방법 등의 좋은 아이디어들이 많이 나왔다.
  • 열정이 넘치는것도 좋지만, 충분한 휴식을 통한 리프레시도 필요하다
    9h ~ 6h 혹은 9h ~ 1h 등 팀원모두가 집중해야하는 시간을 정해놓는다면 중요한 사항은 포커스 시간에 공지를 하는 등 적극적으로 그 시간을 활용하고
    이후 시간에 자유롭게 커뮤니케이션을 한다면 소틍의 부재도 줄어들 것 같다는 생각이 들었다.
    

• Future action (향후 행동: 앞으로 무엇을 해야 할까?)

  • 포커스 타임 정하기

📕02. 지식 공유에 박한 사람

팀원은 적이 아니다.

지식을 공유하고, 새로운 혹은 이미 알고있는 지식도 탐구하면서 IT는 발전의 발전을 거듭하고 있다.
또 그것은 앞으로 누군가 혹은 시작하는 기업의 발판이 되어준다 (오픈 소스가 그 예시이다)

• Fact (사실: 무슨 일이 있었나?)

  • 팀내의 오류, 에러 등의 이슈로 진행이 되지 않는 상황에서 혼자 해결 후 개인 프로젝트를 진행하고 있었다.

• Feeling (느낌: 무슨 느낌이 들었나?)

  • 여러명이 모여 하나의 아웃풋을 만들어 낼때에는 혼자 잘한다고 되는것이 아니다. 빠르게 변화하는 이 생태계에서 지식을 '감추는' 지식 공유에 박한 사람이 팀원이라면 동료로 의지하고 도움을 줄 수 있을까 의문점이 들었다. (본인으로 시작해서 점진적으로 올리간다면)
    나의 성장 -> 팀원의 성장 -> 기업의 성장 -> 나의 성장 -> 팀원의 성장 (...)

• Finding (배운 점: 어떤 인사이트를 얻었나?)

  • 어느분야에서는 자신이 알고있는 지식이 곧 경쟁력이 될 수 있기 때문에 '나만 알고있는 정보'로 간직하는 경우를 종종 봤다

단연 팀원이 지식 공유를 하는것을 강요할 수는 없는일이다.(자신이 공부하면 되기 때문에) 하지만 빠른 호흡으로 멀리 나아가기 위해서는 팀이기때문에 공유하면 '좋은' 지식이 분명이 있다.

• Future action (향후 행동: 앞으로 무엇을 해야 할까?)
  • 팀내의 백엔드 위키 등을 작성

📕03. 기능이 작동된다고 아는것은 아니다

• Fact (사실: 무슨 일이 있었나?)

  • 처음에는 프로젝트 기획에 맞춰
    '딱 필요한 정보', '필요한 만큼만',
    "오! 됐다 작동 된다 성공!"으로 만족했다
    하지만 정확하게 머릿속에 넣지않고 딱 필요한 만큼한 보고 사용한 코드는 다음에 보면 누구시죠를 시연하게 된다

• Feeling (느낌: 무슨 느낌이 들었나?)

  • 작동하는것을 지식을 습득했다고 착각하는 순간 성장을 더디게 만든다
  • 집요하게 탐구하고 문제를 해결했을 때 내것이 된다.

• Finding (배운 점: 어떤 인사이트를 얻었나?)

  • 내가 어느부분을 숙지하고 이해했는지 파악한뒤 생각하는것을 구현하는 연습을 해야한다.

• Future action (향후 행동: 앞으로 무엇을 해야 할까?)

  • 새로운 지식 습득시 응용문제 만들어보기
  • 손 코딩 해보고, 눈 코딩은 정식 문법보고 예제 시뮬레이션 돌려보는 연습
  • 팀원에게 설명

📕04. 프로젝트에서 기한을 지키는 것은 중요하다

프로젝트 결과물을 성공적으로 마치는것에 대한 여부중에서 프로젝트 기한은 중요했다.

• Fact (사실: 무슨 일이 있었나?)

  • 이번 팀프로젝트에서 타인의 코드를 확인할 수 있는 순간은 "코드를 합치는 순간"이었다.
    그래서 팀원들은 자신의 코드가 '이 정도면 됐다'고 느낄 때 코드를 공유했던것이 기한을 늦추는 하나의 요인으로 작용했다고 생각한다.
  • 소통의 부재, 깃허브 브랜치 사용하지 않았음

• Feeling (느낌: 무슨 느낌이 들었나?)

  • 개발자가 공유를 하지않고 개별적으로 local환경에서 작업을 할 경우 각 팀원이 현재 어떤 상황인지 알 수 없다.
    정말 기능을 구현하는 시간이 부족해서인지
    학습이 부족하여 오랜시간이 걸리는것인지 작업이 오래걸리는 원인을 당사자 이외에는 알 수 없다

• Finding (배운 점: 어떤 인사이트를 얻었나?)

  • 무엇을 하고 있는지를 알아야 업무 순서와 강도를 조절하여 효율성있는 시간을 보낼 수 있다.
    - 자신이 무엇을 하고 있는지
    - 팀원이 어떤 일을 하고 어떤 관점을 가지고 있는지
    이번 프로젝트로 인해서 왜 깃허브 브랜치를 사용하는지
    PR을 남겨 서로 내용을 공유하고, 의견을 주고받는지 알 수 있었던 경험이었다.

• Future action (향후 행동: 앞으로 무엇을 해야 할까?)

  • 아이스브래이킹 스낵타임, 러프한 작업물부터 공유, 깃허브 브랜치 사용 (PR)

📕05. 모르면 탐구, 해결하고자 하는 집요함

팀 프로젝트를 하면서 깨닳은게 있거나 배운 부분이 무엇이냐고 물으면 이 부분을 말하리라 다짐했던 일이다.

• Fact (사실: 무슨 일이 있었나?)

  • 팀 프로젝트 구성원을 보면 어벤져스 같았다.
    웹디자인 전공자 A, 선수학습이 됐던 프론트엔트 B, 활동적이고 분위기 메이커인 백엔드 C, 기획을 잘하는 D, 리더십 장착 백엔드 E

    개인이 가진 역량은 다르지만
    이걸 프로젝트에 어떻게 얼마나 잘 녹여내는냐는 또다른 문제였다

    1. 모르는 부분이 생기면 혼자 생각하는 시간을 갖지않고 바로 팀원에게 도움요청
     2. 모르면 포기 (코드를 아예 짜지 않는다)
     3. 본인의 코딩 수준을 숨기기

• Feeling (느낌: 무슨 느낌이 들었나?)

  • 개인의 결과물인 경우에는 혼자서 완성이 가능하지만,
    팀 프로젝트의 경우 하나를 작은 단위로 나누어 작업을 하기 때문에 혼자'만' 잘한다고 완성할 수 없다 연관되어있는 페이지의 경우 짝이되어 협업을 진행해야한다.
    문제를 해결하고자 하는 집요함과 탐구하는 시간이 프로젝트 과정과 완성에 어떤 영향을 끼치게 되는지 느끼게 되었다.

• Finding (배운 점: 어떤 인사이트를 얻었나?)

  • 👉 프로젝트를 하면서 기본적으로 개인의 역량도 중요하지만 문제가 생겼을 때, 어떻게 해결하는가? 해결을 했는가?에 대한 내용이 중요하다는것을 느꼈다
    • 얼마나 탐구하려 했으며
    • 문제를 해결하고자 하는 집요함

• Future action (향후 행동: 앞으로 무엇을 해야 할까?)