데모데이 팀 프로젝트 KPT 팀 회고

** 2022년 11월 22일의 팀 회고를 블로그에 옮김

 

데잇걸즈 데이터분석가 과정의 마지막은 데모데이 팀프로젝트이다. 약 한 달 동안 자유주제로 데이터 분석을 진행하고 이에 대해 발표를 진행한다. 데이터 수집부터 분석 방향 및 분석 방법 설정까지 모두 제한 없이 팀원들과 함께 스스로 정하는 과제이기 때문에, 자유도 높게 해보고 싶은 분석을 진행 할 수 있다는 장점이 있지만 다른 한 편으로는 분석 방향을 잘 못 잡을 경우 적지 않은 시간을 헤메기만 할 수도 있다. 

 

이번 팀프로젝트에서도 자원해서 프로젝트 매니저(PM)을 맡았는데, 저번 SQL 팀 프로젝트 때 팀회고를 진행하고 좋았던 부분과 아쉬웠던 부분을 염두에 두고 프로젝트를 진행해서 그런지 좀 더 발전된 방향으로 프로젝트을 진행하고 팀 커뮤니케이션을 도울 수 있었다. 

 

 

 

---

👇🏻진행한 프로젝트 내용이 궁금하신 분들은 여기로

발표 자료

 

 

KPT 회고란?

• K : Keep
  • 프로젝트 완료 후에도 간직하고 싶은 잘했던 것 / 좋았던 것
  • e.g. "~기술 적용을 했더니 효율적으로 ~를 할 수 있었다."

 

• P : Problem
  • 프로젝트 중 겪었던 어려움(기술, 소통, 협업, 에러 등 프로젝트 진행 관련된 그 어느것이든) / 프로젝트 완료 후에도 아쉬움으로 남는 것
  • e.g. "~기능 적용 중 ~이슈가 발생하였다."

 

• T : Try
  • Problem 중 해결된 사항에 대한 해결 방법 / 해결되지 않은 사항에 대한 피드백
  • e.g. "~기능 적용 중 발생한 ~이슈 해결을 위해 ~를 하였다."
  • 이번 회고에서는 '놓쳤던 점이나 아쉬웠던 점을 보완해서' 다음에 적용해 볼 수 있는 방법을 나눴다.

 

 

---

 

Keep

팀 커뮤니케이션 및 팀 문화

• 첫 회의 때 '프로젝트 진행 그라운드 룰'을 정했기 때문에, 팀원 누구 한 명도 빠지지 않고 모두 소통에 참여하고 빠르게 피드백을 주고 받았음

 

• 누군가 개인사정으로 회의에 빠졌어도 기록을 읽으면 진행 내용을 알기 쉽게 내용이 투명하게 잘 공유됨

 

• 모든 과정마다 팀원 모두가 이해하고 수용 가능할 때 진행 시킴
  • "모르는 걸 물어보면 타박하지 않고 잘 알려줌"

 

• 팀에 기여하려는 적극성
  • 다들 각자 맡은 일을 하다가 시간이 남으면 적극적으로 나서서 다른 팀원 일이 끝날 수 있게 도왔음
  • "분업화가 매우 잘 되었고 각자 할 일이 끝나면 다른 사람 일을 돕는 분위기가 좋았음"

 

• "이가 없으면 잇몸으로 정신"

 

 

처음에 프로젝트에 대해 생각하는 바를 문서화 했던 것(각자 프로젝트 기획안 작성 및 공유)

• 팀원들의 프로젝트에 대한 관점 및 목표 하나로 얼라인하기

 

• 팀의 일 나의 일로 만들기(팀원들이 프로젝트에 대해 스스로 고민을 많이 투자 할 수록 자신의 일로 인식한다!)

 

팀원들이 프로젝트에 대해 스스로 고민을 많이 투자 할 수록 자신의 일로 인식한다! 함께하는 고민으로 만드는 과정의 중요성!

• • 아이디어를 문서화하면서 논리적으로 될 프로젝트인지 아닌지를 알 수 있었던 것

 

 

문서화를 바탕으로 공식 기술피드백 일정보다 빠르게 강사님들께 여쭤봤던것

• 다양한 관점 수집 가능, 특히 파일럿테스트에 관한 아이디어를 재명 강사님께 많이 얻었음

 

 

프로젝트 관리

• 빠르게 서비스를 제작하고 파일럿테스트와 그 결과 해석까지 했음
  • 적정수준의 기술을 활용하려 했던 게 가장 큰 요인, 또한 프로젝트 초기에 우리가 다룰 수 있는 데이터를 선택한 게 큰 요인(한번도 주제가 크게 바뀐 적이 없었음)

 

• 일의 우선순위를 잘 잡음(중요도는 떨어지지만 빠른 시간안에 해결 가능해서 효율이 높을 일들)
  • 현실적으로 불가능한 부분은 적절히 제외하고 대체할 방법을 찾은 게 좋았음
  • 여러 가지 분석 모델을 시도해보고 모델을 결정한 근거가 있었던 점

 

• 사전에 프로세스 바를 만들어 진행률을 매 주 확인한 것

 

• 칸반보드 작성이 잘 되어있었고 회의 때마다 아젠다와 해야할 일이 명시되어있어 진행이 수월했음(회의록 관리를 잘했음)

 

• 중간점검을 통해 프로젝트의 진척도를 확인하고 진행 중 변경된 프로젝트 방향을 재점검 하고 파악한 것

 

• 온라인 회의인데도 다양한 툴 사용으로 효율적으로 회의 진행 (게더타운 화이트보드, 잼보드, 아이패드 노트 창 공유 등등)

 

Problem

분석 방법에 대한 아쉬움

• 시간부족 + 지식부족으로 분석 과정에서 더 많은 방법을 고민해보지 못한 게 아쉬웠음
  • 리뷰 데이터 텍스트 분석에 키워드 감성분석을 더했더라면 키워드 별 맛집 선정을 좀 더 구체적으로 할 수 있지 않았을까에 대한 아쉬움
  • ‘더 알아보기’ 홈페이지를 노션이 아닌 다른 플랫폼을 활용 혹은 웹페이지를 만들어볼 수 있지 않았을까에 대한 아쉬움

 

• 텍스트분석 딕셔너리 만들기를 수작업을 많이 했던것
  • 파이썬을 잘 했다면 코드로 해결할 수 있지 않았을까 하는 생각이 듦…
  • 딕셔너리를 만들고 지쳐서 kmeans만 하고 kmodes는 못 돌려 본것

 

• 제작한 서비스 파일럿 테스트 질문지를 좀 더 바이아스 없게 만들어야 했음
  • 질문은 5점 척도의 3점에 맞게 질문
  • 액션이 나올 수 있게 질문하기(이 질문으로 무엇을 물어서 서비스를 개선할 수 있을지, 너무 모호하게 물어보면 안됨)

 

 

프로젝트 관리에 대한 아쉬움

• 분업화는 잘 되었지만 분업한 결과물에 대해 피드백 프로세스가 확실하게 정착되어 있지 않았음
• 구글 드라이브 파일명 통일이 안되어있어서 찾을 때 시간이 소요됐던 점

 

• 개인적으로 PM으로서 스스로에게 아쉬웠던 점은 그냥 바로 브레인 스토밍을 하거나 논의하면 되는데, '이런 사안에 대해 시간을 가지고 생각해보고 모일까요?'라고 제시한 적이 많았다…사람마다 일하는 방식이 다르고..개인적으로 맡겨두면 안할 가능성이 크다는 것을 생각할 것
  • 그냥 같이 바로 아이디어를 낼 수 있는 협업 방법을 생각해보기

 

Try

• 분업한 결과물에 대해 각자 보고하고 피드백 받는 프로세스를 확실히 정착 시켰으면 더 좋은 결과가 있었을 것 같음

 

• git을 활용하여 공용으로 사용할 코드를 함께 편집하고 살펴봤다면 팀원의 기여도도 명확해지고 파이썬에 대한 경험이 늘지 않았을까 생각됨
  • 사용한 최종 코드는 깔끔하게 정리 필요(git 활용 - 최종 코드에 대한 기록)

 

• 파일명에 대한 양식을 작성. 새로운 형식의 자료가 생길 때마다 사람들과 합의를 맞추고 파일명 양식을 지속적으로 추가

•