회고
발표자료 제출과 피드백
어제 발표 자료를 기한 내 제출하지 못했고, 이후 상황 보고를 총괄 매니저님께 하지 않아 조치가 미흡했다는 지적을 받았다. 당시에는 정신이 없어 떠올리지 못했지만, 조직에서 이런 절차는 당연한 절차였다. 앞으로는 이런 부분이 자연스럽게 몸에 배도록 신경 써야겠다는 생각이 들었다.
발표자료 내용 부족
발표 자료의 내용이 턱없이 부족했다. 중요한 파트를 진행하기 전에 여러 이슈로 인해 작업 속도가 매우 느렸고, 결국 발표 PPT에 넣을 자료가 충분하지 않았다. 특히 시연 스크립트는 제대로 진행할 수 있게 개발 되지 않은 상태라 공란이었고, 그 대신 우리가 목표로 했던 문서화 작업과 Swagger 문서라도 캡처해 내용을 채워넣었다.
트러블 슈팅의 교훈
발표회가 끝난 후 다른 팀들의 트러블 슈팅 사례를 보면서, 우리가 생각보다 잘 해결했던 문제들을 제대로 정리하지 못했다는 생각이 들었다. 문제를 해결하는 과정 자체가 너무 익숙해지다 보니, 정말로 힘들었던 사례들만 기억에 남았던 것 같다. 하지만 팀과 이외 개발자들에게 공유했을 때 충분히 의미가 있을 수도 있음을 깨달았다. 앞으로는 프로젝트 중간마다 트러블 슈팅 사항을 정리하는 습관을 들여야겠다고 다짐했다.
발표회와 아쉬움
발표회에 불참하지 않겠다는 목표로 막판까지 준비했지만 제출물의 완성도는 턱없이 부족했다. 변명을 하자면 이유는 많지만, 비슷한 환경에서도 누군가는 해냈고, 우리는 그러지 못했다. 조금만 더 빨리 팀의 문제를 캐치하고 방향을 제시했더라면, 적어도 중하위권 정도의 결과물은 만들 수 있었을 것 같다는 생각이 든다. 그래서 더 아쉽고 속이 많이 상했다.
앞으로 개선할 점
정말 많이 속상했던 만큼 이번 경험을 계기로 어떻게 반복되지 않을 수 있나 고민을 해보았다.
-
모호한 요구사항에 대한 빠른 대응
내가 기획에 참여하지 않았으니 모호한 요구사항에 대한 불만과 오판은 당연하다. 이때 빠르게 그런 사항들에 대해 리스트업을 하고 팀의 견해와 함께 담당자(튜터님)을 찾아가야 겠다. -
추가 개발 요소의 우선순위 결정
개발 기간이 매우 짧은 만큼 요구사항 이외에 욕심이 나는 부분은 공용 테이블을 만들어 중요도와 난이도를 설정하고, 이중으로 시간이 소요되는 것처럼 느껴지더라도 필수 기능 개발이 끝나고 리팩토링, 고도화 하는 기간에 진행해야겠다. -
트러블 슈팅 습관화
팀 내에 문제상황 해결에 관한 부분과 특이사항을 최소한 데일리 스크럼 스크립트에 반영할 수 있도록 제안해야겠다. -
일정 관리의 중요성
프로젝트 초기에 일정 관리 체계를 확실히 잡고, 스프링(대처) 기간을 포함한 스프린트 기간을 잘 배분하여 설정하고 코드 프리징 날짜를 명확하게 설정해야겠다. -
팀 프로젝트의 우선순위 명확화
해당 팀 프로젝트에서 제일 중요한 이 무엇인지 기준을 명확히 세워 리마인드하여, 불필요한 고민과 작업으로 낭비되는 시간을 줄여야겠다.