마지막에 배포 관련 이슈가 생겨서 팀 회고 시간을 갖지 못하게 되었다.
개인적으로 배포를 하는것보다 팀 회고 시간이 더 중요하다 생각해서 회고 시간을 갖길 원했으나 설득하질 못했다.
모두가 다른 방향을 생각하고 있고, 같은 방향으로 이끄는 일은 참 힘든것 같다.
개인적으로 2주간 팀프로젝트를 진행하면서 있었던 일들을 되돌아보고자 한다.
처음에 아이디어 기획안을 냈을때는 기획대로 구현해보고 싶은 마음이 컸지만, 예기치 못한 상황(lint설정, API문제)들이 처음 했던 기획과는 다른 방향으로 이끌었다.
항상 디테일하게 계획을 짜고 일을 진행하고 싶었지만, 시간이라는 압박에 쫓겨 그냥 그냥 넘어가고 말았던것같다.
프로젝트 진행중에 팀원간 커뮤니케이션도 원활하지 않았는데 이런 극단적인 상황이 있을까 하면서 고뇌했지만, 그 고뇌할 순간에 해결방안을 더 찾아보려 했어야 했다.
엔지니어 분들의 피드백을 받고, 팀원들에게 부탁도 해보고, 화도 내봤지만 사람은 변화를 추구하지않는 사람은 쉽게 변하지 않는다는걸 느꼇다.
만약 다음에 이런 상황이 생긴다면, 커뮤니케이션의 중요성을 인지한 만큼 커뮤니케이션에 관해서는 꼭 짚고 넘어가야겠다.
또한, 기술적으로 어려운 점이 발생한다면 주눅들지않고 내 의견과 생각을 자신있게 말하고 긍정적인 자세를 갖겠다.
개인적으로 어떤 규칙에 얽메이는 것을 싫어해서 사람들과의 관계나 업무에서 자유를 추구하는 편인데, 자유가 주어진 상황에서 책임감을 느끼고 더 노력하는 사람도 있는 반면 그 자유에 안주해서 편함만 좇는 사람들도 있다.
나중에 내가 이끌어 나갈 상황이 있을경우 이 부분은 어떻게 해야 할지 고민이 된다.
(어느정도 규율은 필수적인것 같기도 하다..그 규율로 습관을 만든 다음 자유를 주는게 나을거 같다고 생각한다)
다음 프로젝트에서 신경쓰고 싶은것들
-
처음 기획이 진짜 중요하다(db설계, 로직설계, 기능설정, 아키텍쳐 설계, role 설정)
-
시간 계획 중요
-
프로젝트가 진행되면서 회고 중요
-
커밋메시지 중요
-
커뮤니케이션 안되는 코드는 쓰레기다.
-
목표 설정을 잘하고 어떤걸 원하는지 공유하는게 중요
