SQL 프로젝트 KPT 팀 회고 & PM의 개인 회고

SQL 팀 프로젝트 KPT 팀 회고(덧붙여, 처음으로 98% 온택트 프로젝트를 진행해본 PM의 개인 회고)

 

데잇걸즈 SQL 과정에서 미니 팀프로젝트로 데이터를 셋팅하는 프로젝트를 진행했다. 현재 데잇걸즈 과정은 한두 번의 오프라인 행사를 빼고는 전 과정이 온라인으로 진행되고 있어, 팀프로젝트도 자연스럽게 온라인으로 진행하게 되었다.(특히 수업과 병행되는 프로젝트이기 때문에 팀원 각자의 시간의 효율성 문제로 데잇걸즈 오프라인 행사가 있었던 날의 만남인 1번을 제외하고 3주라는 기간 동안 모든 회의와 작업을 온라인으로 진행했다.) 

 

그 무엇이라도 일단 진행했다면 되돌아보고 분석해서 다음 번에 더 잘할 수 있는 기회가 된다. 그리고 협업에 중요한 커뮤니케이션과 프로젝트 관리에 대한 소프트스킬은 어느 순간 터득해서 그 후로 어렵지 않게 활용할 수 있는 역량이 아니라, 과거에 터득한 내용을 잊지 않고 이번에도 적용할 수 있도록 계속해서 마음에 담고 있지 않으면 온전히 끌어낼 수 없는 영역이다. 그래서 개인적으로 계속해서 마음에 담고 있을 수 있는 방안을 찾아보려 한다.

 

이제부터는 프로젝트가 끝나면 꾸준히 회고를 해서 어떤 점들을 개선할 수 있고, 체계화해서 가져가야 하는지 살펴보기로 했다. 이런 마음으로 같이 프로젝트를 진행한 팀원들에게 회고를 위한 마무리 wrap-up 미팅을 요청했는데 다들 흔쾌히 받아주셨다.

 

 

---

 

 

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

발표 자료

---

 

회고의 방식은 팀원 분이 가져와 주신 KPT회고의 틀을 가져와서 이번 프로젝트에 맞게 조금 변형해서 적용했다.

 

KPT 회고란?

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

 

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

 

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

 

 

 

---

 

 

KEEP

효율적인 R&R 분배

1. 협업하는 분석 프로젝트를 처음 진행해본 팀원이 과반 이상이었는데도, 헤매지 않고 효율적으로 R&R을 분배해서 진행
2. 팀원 모두가 하나의 프로세스에 다 매달려있지 않고 적절하게 분업(모여라 나눠라가 원활)
   • 전처리 논리만 다같이 미리 정하고, '수집한 데이터를 Python으로 전처리하는 조'과 '수집한 데이터를 바탕으로 필요한 데이터를 추가로 만든 조'으로 나뉘어서 진행
   • 기본 분석 논리 및 지표 정의를 다 같이 논의하고 분석을 위한 분석 테이블 생성 쿼리를 리뷰한 후, '주중 부족 현상을 분석하는 가설 1 조'와 '주말 부족 현상을 분석하는 가설 2 조'로 나뉘어서 진행
   • 각 조의 작업물을 서로 공유하기 위해, 각자의 작업 기록과 논리를 노션에 잘 기록해서 서로 피드백이 원활

 

협업 및 생산성을 위한 적절한 툴 활용

1. 노션에 프로젝트 관리를 위한 효율적인 페이지 구성
   • WBS로 일정관리, 칸반 활용
   • 회의록
   • 중간 작업물, 중간 발표 자료 정리 등 
2. 게더타운, 줌 소회의실, 디스코드를 적극 활용

 

효율적인 일정관리를 통해 목표를 넘어선 달성량

1. 프로젝트 요구 사항은 데이터 셋업까지였지만, EDA - 가설검증 - 간단한 시각화까지 진행
2. 최종 발표 자료를 고려하여 중간 정리를 잘 해둠

 

근거를 바탕으로 한 커뮤니케이션

1. 출퇴근 시간대, 따릉이 대여소 특징 구분(주거지, 상업지구 등), 부족현상 정의법 등 모든 기준 수립에 공인된 자료를 바탕으로 근거를 제시함(사회적 동의를 얻을 수 있는 레퍼런스)
2. 문제점과 분석 주제, 가설을 빠르게 정하고 모든 의사결정을 분석 목적과 가설을 기반으로 함

 

디테일 챙기기

1. 위와 같이 모든 의사결정의 기준에 디테일한 근거를 제시하려고 함
2. 프로젝트 과정과 분석 논리가 잘 전달 될 수 있도록 사소한 부분도 놓치지 않고 시각화를 함
   • e.g. 분석을 위한 분석 테이블 쿼리를 잘 이해할 수 있도록 시각화를 함
3. 데이터 전처리 과정에서 데이터 무결성을 위해 작은 단위까지 데이터를 살핌
   • e.g. 데이터를 살펴보는 과정에서 따릉이 대여소의 번호가 '00356'과 같이 앞에 00이나 0이 붙어서 저장된 경우가 있었는데, 이 때문에 행 수가 맞지 않았음. 이런 데이터의 이상 케이스들을 빠른 시간 안에 잘 찾아냈음

 

칭찬이 넘치는 팀문화

1. 팀원 개개인이 팀에 기여하고 있다는 마음을 느낄 수 있도록, 작은 도움에도 감사함 표현하기. 서로 아낌없이 칭찬하기
2. 적극적인 참여와 각자의 의견 존중하며 합의점 찾아가기
3. 서로 부족한 부분을 메꿔주고, 이런 분위기를 바탕으로 모르거나 이해가 어려운 부분도 주저하지 않고 물어볼 수 있었음

 

PROBLEM

데이터 핸들링과 분석 논리 설정에서의 실수

1. 가설을 2개를 설정해서 하나의 데이터로 주중의 문제점과 주말의 문제점을 다루려고 했는데, 첫 번째 가설인 주중의 문제점을 기준으로 생각하보니 두 번째 가설 주말의 문제점에서 아주 큰 실수인 '가설을 검증할 만한 충분한 데이터'를 살펴보지 못했음
   • 가장 이용률이 높은달의 데이터로 축소해서 보아도 된다는 첫 번째 가설에 대한 강사님의 기술 피드백을 듣고 안일하게 6월의 주말 데이터로 두 번째 가설에 적용
   • 분석을 진행 할 때 가설은 왠만하면 한 번에 1개로 세우고, 만약 부득이하게 2개 이상이라면 각 주제별로 따로따로 데이터 핸들링을 고민할 것
2. 수치형 데이터와 범주형 데이터가 섞여있었는데, 분석 논리 설정에서 통계적으로 이를 구별하고 고려해서 분석하는데 부족했음
3. 데이터 셋업이 목적인 프로젝트이긴 했지만, 액션으로 이어지는 분석 결과를 도출하지 못하고 현상 설명에서 분석이 종료 됨

 

커뮤니케이션에서 아쉬웠던 점

1. 온라인으로 진행되는 과정에서 서로에 대한 파악이 충분하지 못한채 프로젝트가 진행되다 보니, 서로 배려한다고 너무 조심스러워서 초반에 상반되는 주장이 있을 때 각자의 주장을 더 치열하게 밀어붙이지 않고 적당하게만 제시
2. 온라인으로 진행된 프로젝트라 일부 미팅이나 분석 논리를 설정하는 과정에서 시간이 예상보다 오래 걸림

 

 

TRY

더욱 치밀한 레퍼런스 리서치

1. 문제 해결 방법을 적극적으로 찾기
   • 캐글 데이터 레퍼런스 코드, 통계적인 지식 등 필요한 부분들을 더 적극적으로 찾고 적절한 레퍼런스를 찾을 수 있는 사이트를 잘 리스트 업 해두기
   • 다른 사람이 하지 않았던 것을 포착해서 이번 분석에서 새로운 임팩트를 낼 수 있는 법을 고민하기

 

분석 기획 및 분석 논리

1. 셋업된 데이터를 핸들링할 방법을 논의할 시간 더 할당해서 충분히 고민하기
2. 데이터 셋업 이후 분석에 들어가기 전에, 통계적인 측면에서 그리고 서비스나 비즈니스 측면에서 꼭 짚고 넘어가야 할 부분 검토하기

 

온라인 회의에서 생기는 문제 개선

1. 킥오프 미팅, 중간에 효율성이 떨어지고 진척이 느릴 때의 회의는 오프라인으로 진행하기
   • 오프라인 회의는 각 팀원들에게 중간 마감 역할을 함
2. 온라인 회의 환경 세팅을 미리 잘 해두기
   • 각 팀원의 상황에 맞게 게더타운, 디스코드, 줌 등 적절한 온라인 회의 공간 선택
   • 실시간 노션 회의록 공유를 통한 회의 아젠다 관리 
   • 분업해서 일을 진행 할 때나 본인의 주장을 설명하기 위해 전달력이 높은 자료 준비하기
     • 노션을 통한 개인 자료 정리
     • 마크다운이나 주석을 잘 활용한 깔끔한 코드 파일

 

---

 

PM으로써  다음 번에 프로젝트를 이끌 때 개선 할  수 있는 부분들

개인적으로 PM으로써 이번에 부족했던 부분들을 돌아보고 다음 프로젝트 때 개선할 수 있는 부분들을 따로 개인 회고 시간을 가져 정리해봤다.

 

 

---

 

 

킥오프 미팅에 공을 많이 들이기

킥오프 미팅에 더 공을 많이 들여야 한다. 어쩌면 회사에서 일할 때 보다 더.

 

사실 같은 회사 안에서 일하는 사람들은 그래도 어느정도 배경지식과 필요사항에 대해 일치되는 부분이 있는데, 아무래도 분석 프로젝트를 위해 만난 우리들은 정말 서로 공유하는 배경 지식이 매우매우 다르다. 그러므로 서로 Align하는 것에 공을 매우 많이 들여야 하고, 프로젝트 첫 시작인 킥오프 미팅에 공을 많이 들여서 최대한 서로 배경지식과 프로젝트에 대한 생각을 Align하고 시작하는 것이 좋을 것 같다.

 

 

 

프로젝트 규칙을 먼저 만들고 공유하기 

 슬랙 및 노션 확인 규칙(회의 후 회의록 업데이트 알림 슬랙 있으면 무조건 읽고 확인 이모지 날리기)

 

계속해서 우리가 같은 지점에 있고 같은 언어를 쓰고 있다는 걸 확인해야 한다.(특히 데이터 분석 프로젝트에서는 현상을 수치적인 데이터로 변환해서 정의하고, 지표를 정의해야 하기에!)

 

파일명 규칙 만들기, 코드 포맷팅 규칙 만들기(주석, 마크다운 문법 등)

 

서로 코드를 공유해야할 일이 많았는데 팀 전체가 주석을 잘 달지 않고, 코드도 정리하지 않고 이 코드 돌려봤다 저 코드 돌려봤다 하는 일이 잦아서 코드 쉐어와 코드 리뷰에 효율성이 떨어졌다.

 

데이터리안 SQL 캠프를 들었을 때 부터 행갈이에 대한 강조는 자주 들어와서, 개인적으로 쿼리를 짤 때 행갈이는 깔끔하게 하는 습관은 들었지만 나도 주석을 더 자세하게 쓰는 습관을 들여야 한다.

우선 SQL도 쿼리를 짜는 기본적인 논리 흐름을 처음에 주석(/* */)으로 READ ME 파일처럼 잘 적어주고 시작해야겠다고 느꼈다. 또한 서브쿼리마다, with문과 임시테이블 생성문을 쓸 때 마다 시작과 끝을 명확히 볼 수 있게 주석으로 ('~~을 위한' with문 퀴리 끝, 혹은 임시테이블쿼리 끝)과 같이 써주는 것도 좋은 아이디어 인 것 같다.

 

언제나 커뮤니케이션의 기본인 '내가 더 품을 많이 들여야 전체 팀의 리소스가 줄어든다'는 걸 잊지 말기! 이번 프로젝트를 진행했을 땐 어떨 때는 염두에 두고 커뮤니케이션 하다가 어느 순간에는 그 다짐을 흘려버리고 마는데, 프로젝트를 진행할 때는 계속해서 마음에 새기고 있을 것! 팀을 위해 나를 계속 귀찮게 해야한다.

 

SQL 가독성을 높이는 다섯 가지 사소한 습관

참고 할 수 있는 SQL 쿼리 포맷팅 관련 글

 

 

 

팀원 모두가 같은 지점에 있는지 계속해서 확인하기

프로젝트 첫 회의 때 각자의 스킬셋을 나누었는데, PM으로서 내가 이걸 더 숙지하고 중간중간 챙겼으면 더 좋지 않을까 생각한다.

 

단치 처음에 '음 파이썬 잘하는 사람도 꽤 있고, SQL 쿼리 잘짜는 사람도 꽤 있고, 예전에 데이터분석 프로젝트 해봤다는 사람들도 있으니, 프로젝트가 어느정도 잘 굴러갈 수 있겠군' 판단만 하고 그 후로는 머리속에서 지워버린게 아쉽다. 파이썬이 어려운 사람, SQL이 어려운 사람, 통계가 처음인 사람을 계속 팔로업하고 진도를 같이 맞출 수 있도록 더 세심하게 챙겼어야 했다.

그래야 회의에서도 늘어지지 않고 아젠다만 빠르게 논의할 수 있다.

 

'1:팀 전체의 소통'만을 생각하지 말고 자주자주 '1:1 커뮤니케이션'을 챙기자. 계속해서 팀원들에게 뭔가 걸리는건 없는지 혹시 프로젝트를 진행하는데 더 도움이 될 지식들을 개인적으로 물어보면서 전체가 잘 굴러 갈 수 있도록 관리해주어야 한다.

 

 

 

회의시간 관리와 회의 문서 관리 효율적으로 하기

 회의 시간 관리

 

게더타운이나 줌과 같은 온라인 채널에서 회의를 진행하다 보니 회의 아젠다 관리의 중요성을 느꼈다.

회의록 템플릿에 미리 아젠다를 써두고 같이 실시간 회의록을 보면서 팔로업 할 수 있도록 관리하는 것이 중요하다. 아젠다 관리를 소홀하게 하면 1시간 예정인 회의도 금방 2시간이 되곤 했다.

 

회의 진행 미리 시뮬레이션 돌려보기 

 

일정과 할 일에 너무 깔려있지 말고, 회의 시작하기 전 회의 주관자로써 미리 아젠다 공지와 필요한 사항들을 챙긴 후 회의 진행 시뮬레이션도 미리 돌려봐야 한다.

 

우리가 부족 지표 정의를 하기로 했을때, 미리 슬랙에 각자의 코드와 csv 파일을 올려서 서로 코드 체크와 데이터 체크를 하게 했으면, 회의 시간 분배도 잘 되었고, 회의 목표도 더 잘 이뤘을 것이다. 추가로 회의를 진행하면서 생길 수 있는 이슈들을 미리 예상해보고 대비책을 세웠으면 좋지 않았을까 생각한다.

 

회의 시작할 때 브리핑으로 시작하기

 

돌발 회의가 많아서 회의 시작 브리핑을 상황에 따라 유동적으로 했다가 안했다 했는데 매번 각잡고 제대로 했어야 하는게 맞지 않나 하고 후회하고 있다.

 

온라인 회의에 알맞은 진행 방법 도입하기

 

팀원들에게 작은 창으로 회의 아젠다 리스트(실시간 노션 회의록) 띄워서 같이 보면서 참여해 달라고 독려한다던지, 구글 타이머를 활용한다 던지 각자 어느정도 발언을 효율적으로 하게하기 위한 넛지 방법을 더 많이 생각해 보아야 했다.

참고로 커리어리에서 읽은 글에서 '회의 진행 후 남은 회의 아젠다가 30% 정도 일 때, 구글 타이머를 적용하면 효율적인 회의를 할 수 있다'는데 한번 시도해보고 효율성을 체크해보고 싶다.

 

회의록 관리

 

정기 회의 외에 수업 시간에 돌발 회의가 자주자주 열리다보니, (이것도 변명이지만 현업에서와 달리 수업 일정들에 벅차서) 바로바로 회의록 업데이트 및 공유가 미흡했다.

 

언제나 회의록 정리 및 공유는 회의 끝나자마자 정리를 시작해서 당일에 바로 빠르게 공유 할 것! 그래야 다들 회의 직후 기억이 살아있을 때 내용 정리가 되어 혼선이 없다. 이 부분을 소홀히 하면 다음번 회의 때 여지없이 내용 복기와 설득을 다시 해야 한다.

 

 

 

일정관리 세심하게 챙기기

처음에 세웠던 WBS 일정과 아주 다르게 진행 일정이 심하게 밀리다보니, 그리고 과제의 요구사항은 완성한채로 우리의 포부가 섞인 추가적인 분석 작업을 하다보니, 마지막 주에는 PM인데도 일정을 더 세심하게 챙기지 못한 것 같다.

 

변명이지만 계속 일정이 밀리다보니 이 예상 일정도 당연히 밀리겠지 하고 안일하게 생각해 초반과 달리 일정관리를 세심하게 하지 않았다. 또한 프로젝트를 수업과 병행하느라 개인적으로 작업량에 부담스러움을 느끼는 팀원들이 있는 것 같아 팀원들의 현재 리소스를 파악한다고 불필요하게 과하게 눈치를 보느라 손대기 어려웠던것도 있다. 이런 상황에서는 어떻게 더 프로젝트를 효율적으로 운영할 수 있을지 고민해봐야한다.

 

후반부 일정을 얼개만 짜뒀었는데, 남은 5일 일정을 더 타이트하게 짜보자는 한 팀원의 제안을 받고 그제서야 챙겼던게 아쉽다.

 

 

 

 

---

 

데잇걸즈 과정의 마지막 부분인 최종 프로젝트가 다가오고 있다. 최종 프로젝트에서는 지난 SQL 프로젝트에서 느꼈던 아쉬운 부분, 좋았던 부분들을 잘 살려 더 효율적으로 진행해보고 싶다.