회고 / 느낀점
내가 맡은 바 일은 나 스스로 끝낸다.
- Keep : 책임감을 가지고 완성을 하는 태도가 좋다.
프로젝트를 진행하며 팀에서 가장 먼저 느낀 것은 스스로의 문제는 스스로 해결한다 입니다. 목표된 시간 내로 방법을 갈구하여 완성본을 내 놓는 것이 맡은 일에 책임감을 많이 느낄 수 있었으며 팀원 들의 구현 된 기능들을 보며 서로서로 의욕을 높일 수 있는 계기가 된 것 같습니다.
그로 인해 분업하여 프로젝트를 진행하고 있다는 느낌을 확실히 받았으며 아 그냥 제가 할게요가 아닌 API명세서를 이용한 코드 완성등 팀 내에서 작성한 문서를 바탕으로 코드작성을 할 수 있어 굉장히 좋았습니다.
- Problem : 책임감 때문인지 막힌 부분에 소통이 매우 적다
팀 내에서 소통 부분이 조금 부족하지 않았나 란 생각이 들었습니다.
이는 하나의 에러로 튜터님들과 구글의 도움을 받아 스스로 해결하기 위해 고군분투 하는 과정이 나쁘단 건 아니지만 너무 시간적 소요가 길었습니다.
물론 모든 에러가 느리게 해결된 것은 아니었지만 하루나 이틀 동안 잡고 있던 에러도 있었고 30분 안에 해결되는 것도 있었습니다.
하지만 이런 에러가 있을 때 팀원들의 도움과 서로 질의 응답이 많았으면 좀 더 빠르게 다가갈 수 있을 것 같습니다.
- Try : 막힌 부분에선 미안해 하지말고 과감하게 얘기하자.
막힌 부분에 대해 말 없이 끙끙 앓기보단 팀원들과 문제를 공유, 빠르게 해결하는 방안을 생각해 보면 좋을 것 같습니다.
그리고 프로젝트 작업 중간중간 '아 지금 이 에러때문에.. 조금 걸리네요.. 먼저 이것부터 해결하겠습니다' 하고 혼자 가는 것이 아닌 도움을 청하고 팀원들도 프로젝트 전체 진행을 위해서 거리낌 없이 도와줄 수 있으니 미안함을 가지지 않았으면 좋겠다.
문서는 준비되었다.
- Keep : API명세서나 프로젝트 계획서등 깔끔하게 정리된 것이 있어 개발이 순조로웠다.
프로젝트가 중간정도 갈 때까진 모두가 백엔드 개발자를 목표로 작업중이여서 ERD와 API이름, 와이어프레임을 바탕으로 작업 했는데 프론트와 백엔드를 분리하고 프론트 전향자가 생기면서 프론트와 백 개발이 따로 진행되며 둘이 서로 통신할 때 정해야할 규칙들이 필요했습니다.
그래서 API명세서를 만들었고 이로인해 훨씬 원활한 백 프론트 통신이 완성 되었고 코드 구성에 있어서도 문제 없이 진행 되었습니다.
- problem : 중간 프로젝트 진행이 크게 바꼈을 때 갱신 문제점
프로젝트가 진행되며 팀원 한명이 빠지고 프론트로 전환, 분리 되고 기술 스택이 바뀌는 등 진행 사항이 크게 바꼈을 때 정보들이 갱신되지 않는 문제점이 있었습니다.
특히 API명세서는 백엔드에서 코드 변경이 이루어 졌을 때 갱신이 되지 않고 얘기 또한 없던 터라 한동안 프론트 에러인지 검사하느라 시간을 소요 하였습니다.
와이어 프레임도 현재 디자인과는 많이 다르며 구현하지 않기로 하고 삭제된 기능들 또한 정리해야 하는데 하지 못한 아쉬움이 있습니다.
- Try : 매일 1번은 꼭 회의를 통해 갱신과 변경점을 의논하고 다음 회의 전까지 맡은 부분을 최신화 하자.
프로젝트 내에서 굴곡이 많았던 것 또한 제대로 체계적인 회의가 잡히지 않았던 것이라 생각도 있으며 매일 진행사항과 변경점 등을 새롭게 의논하는 게 좋을 것 같습니다.
그리고 변경된 부분이 있다면 회의 참석을 못한 사람이나 나중에 다시 회기 할 때 볼 수 있도록 회의록만 남겨두는 것이 아닌 전체 프로젝트 계획서에서 빠른 갱신을 해주는 것이 프로젝트 진행을 더욱 원활하게 할 것 같습니다.
