프로젝트 리뷰는 어떻게 해야할까? 시작해야할까?

프로젝트 진행상황은 순조롭지 않고 , 지난번 프로젝트에서도 이번 프로젝트에서도 나쁜 상황들이 반복되고 있어 팀원들과 함께 “프로젝트 리뷰”를 통한 변화가 필요해 보였다.

지난 다른 팀원들과 했던 프로젝트 리뷰들을 돌아보니, 프로젝트 리뷰도 원하는 결과를 도출하기 위해서는 “코드 리뷰” 또는 “코드 컨벤션” 처럼 가이드가 있어야 한다는 생각이 들었다.

1. 프로젝트는 어디까지가 성공이고, 실패일까?
만약 서비스 오픈을 하루정도 연기했다면 성공일까, 실패일까.
QA 리포트가 100개도 넘게 나왔다면 성공일까, 실패일까.
오픈 전날까지 버그 수정이 아닌 신규개발이 있다면 성공일까, 실패일까.
서비스 오픈후 예상하지 못하는 범위내에서 장애가 발생하여 빠른 대응에 실패했다면 성공일까, 실패일까.

계획대로 진행되는 프로젝트는 없다고 가정을 하면,
어느 범위까지를 성공이라고 잘했다고 분류를 나누는건 중요한 포인트가 아니다. 핵심은 프로젝트를 시작할때 계획된것들을 어떻게 적용을 했고, 어떠한 결과가 만들어졌는지가 중요하다. 그래서 프로젝트 리뷰는 성공도 실패도 아닌 단위 성과의 달성 여부로 이야기하는게 필요하다.

2. 프로젝트 리뷰의 준비 가이드
리뷰전에 충분히 돌아볼 수 있는 시간이 있어야 한다.
또한 문서로 기록되어야 팀원들이 같은 실수를 반복하지 않을 수 있다.
담당업무, 총평, 잘한점, 부족한점, 개선사항의 카테고리가 필요하다.

# 담당업무 : 서버 API 개발, 결제 프로세스 개발, AWS 서버 구성
-> “기획” 처럼 포괄적으로 적으면 담당업무가 겹칠 수 있으니 최대한 자세하게 기록한다.

# 총평 : 라이브 되는 node 프로젝트는 처음이라서 부족한점이 많았을텐데,
프로젝트의 서버 개발을 담당하면서 테스트 케이스가 있는 API 구성과, 손쉽게 접근할 수 있는 결제, 장애없는 AWS 서버 구성을 목표로 하였는데, 나름의 성과가 있었다.
-> 프로젝트를 시작할때 계획한것과 종료된 소감을 적는다.
-> 2~3줄을 안넘는걸 추천한다. 5~6명에서 10명정도가 참석하게 되면 총평만 듣다가 리뷰가 종료된다.

# 잘한점
- basecamp를 활용한 to-do 관리
- postman을 사용하여 api 테스트 자동화 및 어플리케이션 개발자와 협업
- aws elastic bean talk를 활용한 무중단 배포시스템 구축, 장애대응
- 기존 mssql sp 코드정리
- api 에러코드 구성

-> 잘한점 역시 짧게 쓰는게 좋다.
-> 잘한건 잘한거다. 잘한건 앞으로도 계속 잘하면 된다.

# 못한점
- elastic search를 활용한 로그 분석을 만들려고 했는데, 시간이 부족해서 만들지 못했다.
- 테스트 케이스가 부족한 경우가 발생되어 api에서 버그가 발생 하였다.
- 추가되는 (출석체크 이벤트, 설치 이벤트)등에 관련되어서 급하게 추가를 하다보니 누더기 코드가 되어 버렸다.

-> 못한점을 적을때 가장 중요한건 “사람을 비난하지 않는다” 이다.
-> 누구 때문에 어떠한 점에서 병목이 생겼다고 이야기를 하면
팀웍크는 물론 프로젝트 리뷰를 하는 의미가 사라진다고 생각한다.
-> 철저하게 업무단위로만 사람이 아닌 task중에 실패한걸 기록해야한다.

# 개선사항
- AWS 서버 비용을 절감할 수 있는 방법을 고민하여야 한다.
- 배포시스템을 자동화 하였으나, 빌드 및 배포시간이 길어서 단축할 수 있는 방법을 찾아야 한다.
- 기획 디자인 파트와 협업할 수 있는 협업툴이 필요한다.
- API 리턴 코드등 코드값을 직관적으로 변경해야한다.
- 공통 함수등을 관리하여야 한다.

-> 개선사항은 상세하게 기록한다.
-> 다음번 프로젝트를 시작할때 지난 개선사항을 보며 프로젝트 목표를 재설정하는데 도움이 될 수 있도록 한다.

이렇게 하는 프로젝트 리뷰는 아마 정말 최소한의 것일텐데, 초기 가이드가 수립되고 여러번 진행하다보면 각 팀들에게 맞는 리뷰 환경을 만들 수 있을꺼 같다.

누가 잘 하고 있으면, 가르쳐주면 좋겠다.