[Project] 중간 회고

LILO Ghim·2022년 1월 18일

communication project

2차 sprint 종료 & 3차 sprint 시작

문제가 아.주. 많았다

프로젝트를 마치고 회고를 쓰려고 했지만, 이틀짜리 sprint도 sprint이므로!!! 1, 2차를 짚고 넘어가야 하겠다

sprint process 관련

scrum
- 제때 작성 되지 않았고, PL로써 관리가 소홀했다.
- 현업이라면) 정해진 rule이 반드시 존재하는데, 이를 제대로 지키지 않은 것은 문제가 큼
- meeting minutes의 경우도 작성하기로 했다면 제대로 수행해야 할 것
Jira
- 업무는 업무대로, Jira task는 업데이트 되고 있지 않음
- 현재 업무와 싱크를 맞추어 제대로 관리 할 것
  
  -> task는 스프린트가 시작되고 난 이후 추가 및 삭제가 어려운데(추가 하지 않는 것이 맞는데), 실제 개발을 하다보면 사전에 기획한 것과 맞지 않은 경우가 많았음.
  
  -> 스프린트 시작 전에 깊게 고민해야 할 부분 인 것 같은데, 개발 시작 전 준비 시간이 항상 촉박했다.
  특히 백은 사전에 세팅해야 할 것이 일정 부분을 차지하고, 프론트는 이미 속도를 내고 있는 상황에서 준비해줘야 할 것들이 많았다.
  
  -> 악순환발생 : 부족한 사전 준비 > 수정사항이 빈번하게 발생 > 사후 공유 미비

개발과 deadline

code
- 현업에서는 깔끔한 코드보다(물론 중요하지만) error가 발생하지 않고, 기능이 구현 되는 것이 우선

deadline
- 진행상황에 대한 수시 공유
  -> 이는 업무 담당자가 갖춰야 할 기본적인 소양인 것도 있지만, PL의 역할이 더 크다고 판단되었다.
  진행상황 및 목표 달성 여부를 팀원 개개인이 반드시 체크하고 공유해서 사전에 문제를 파악하고 해결해야 하지만,
  모두가 개발에 매몰되어 있다 보면 놓칠 수 있는 부분들을 위해서 PL이 존재하고, 이를 체크하고 책임져야 했다고 생각함

소회

2차 프로젝트때와 기업협업 프로젝트에서 같은 상황, 비슷한 문제가 발생한 것 같다

커뮤니케이션 부족 개발에만 매몰 리더십 미달

오히려 프로젝트에 대한 개념이 전무했었던,

미숙한 상태의,

심지어 부족한 인원으로 이루어졌던 1차 프로젝트가

관리적인 측면, 업무 프로세스, 프-백 커뮤니케이션, 결과 도출 등 이 모든게 정말 제대로 이루어졌고, 이에 대한 어떠한 문제도 발생하지 않았었고, 그 이후로 2차 프로젝트, 이번 프로젝트에서 단계별로 일정 수준에 도달하는 프로젝트를 이뤄내지 못했다.(기능구현 외적으로)

Why?

프로젝트 내에서의 역할

1차 프로젝트 : process scrum sprint 관리, api doc, 프론트와의 커뮤니케이션 전담, db 세팅, API, RDS/EC2배포, 발표, keynote
2차 프로젝트 : social login, S3, Docker 배포
기업 협업 프로젝트 : PL, API(공통)

어쩌면 가장 부족한 상태에서 가장 많은 업무를 담당해야 했던 1차 프로젝트가
어째서 더 프로젝트 다운 프로젝트, 제대로 된 협업을 했다고 느껴질까
그리고 상대적으로 그 이후의 프로젝트에서 결함이 생겼을까

다른 팀보다 적은 인원수, 턱없이 부족한 실력을 채워서 프로젝트를 완성하기 위해
처음부터 가질 수 밖에 없었던 리더로써(누구도 시키지 않았지만)의 책임감(내가 정신 똑바로 차리지 않으면 큰일난다는 마음가짐)과
그리고 밤새서 뭔지도 모르고 만들었던,

API document & project briefing

이것이 다른 팀과의 가장 큰 차별점,
다른 팀들에서 발생했던,
그리고 2차, 이번 프로젝트 때 우리에게 발생했던 공통적인 문제가 전혀 발생하지 않고,
프로젝트를 온전히 끝낼 수 있었던 시발점이었다.

무지와 불안에서 오는 책임감

그리고, 2차부터 지금까지 내가 간과 했던 것은
내가 기대하는 것보다,
서로의 업무에 대한 이해도가 여전히 부족하고,
커뮤니케이션 능력이 부족하고,
그리고 이를 위한 노력은 일회성에 그쳐서는 안된다는 것.

2차 프로젝트의 2차 스프린트 미팅 당시, 분명히 내가 언급했었다. 내가 PL이 아니었기도 했지만,

"1차 프로젝트 때 각자 충분히 경험하고 모였을 거라고 생각했고,
API Doc를 내가 굳이 맡아서 작성하지 않고 해보지 못한 팀원이 작성해도,
또 부러 모여 브리핑을 하지 않아도,
각자 본인이 맡은바 제대로 진행이 될 것이라고 생각했고,
프백간에 원할하게 커뮤니케이션 할 것이라고 생각했는데 내 오판이었다 라고.
내가 나섰어야 했다고"

실제로 1차 때 프로세스 & 커뮤니케이션 측면에서 그러한 과정을 거친 팀이 없었다는 걸 뒤늦게 알았고,
2차 때도 API doc을 엑셀이든 포스트맨이든 작성한 팀이 의외로 드물었다.
누군가 나서서 혹은 리더가 제대로 리딩을 하지 않으면 결국 문제가 생긴다.

새로운 tool, 고도화 된 업무처리 방식, 체계 속에서
1차 때의 나처럼 리딩했어야 했으나, 2차 때의 나처럼 기능 구현에만 매몰되어 있었다.

(뭐 그렇다고 잘하는 것도 아니면서, 잘하기라도 하던가)