2주프로젝트(WebPaper_day10 : 프로젝트를 끝내면서)

개인적인 회고

 

마지막에 배포 관련 이슈가 생겨서 팀 회고 시간을 갖지 못하게 되었다. 

개인적으로 배포를 하는것보다 팀 회고 시간이 더 중요하다 생각해서 회고 시간을 갖길 원했으나 설득하질 못했다. 

모두다 다른 방향을 생각하고 있고, 같은 방향으로 이끄는 일은 참 힘든것 같다.

 

그래서 개인적으로나마 2주간 팀프로젝트를 진행하면서 있었던 일들을 되돌아보고자 한다.

처음에 아이디어 기획안을 냈을때는 기획대로 구현해보고 싶은 마음이 컸지만, 현실적인 시간과 상황이 처음 했던 기획과는 다른 방향으로 이끌었다. 항상 디테일하게 계획을 짜고 일을 진행하고 싶었지만, 시간이라는 압박에 쫓겨 그냥 그냥 넘어가고 말았던것같다.

글을 쓰면서 느끼는 점은 시간이라는 압박에 제대로 대처를 못한것같다. 시간을 더 확보하려는 노력도 안했고, 더 효율적으로 쓰려고 그나마 노력했으나 그 결과는 좋지 못했다.

 

그러다보니 기획했던것에 비해 프로젝트의 규모는 점점 줄어들 수 밖에 없었고, 흥미도 점점 잃어갔다.

팀원들도 이 프로젝트를 원해서 지원하지 않았기에 그다지 흥미를 느끼는것 같지 않았다.

이 때 팀장인 내가 동기부여를 하려고 노력했었어야 한다고 생각한다.
(프로젝트의 내용이 마음에 안들면 개인적인 기술 및 협업능력을 키우는 목적으로라도 동기부여를 했어야 한다고 지금와서야 생각이 든다.)

 

프로젝트 진행중에 커뮤니케이션도 원활하지 않았는데 이 부분에 대해 포기해버린것도 후회가 된다.

이런 극단적인 상황이 있을까 하면서 고뇌했지만, 그 고뇌할 순간에 해결방안을 더 찾아보려 했어야 했다.

만약 다음에 이런 상황이 생긴다면, 커뮤니케이션의 중요성을 인지한 만큼 커뮤니케이션에 관해서는 꼭 짚고 넘어가야겠다.

나 또한, 기술적으로 어려운 점이 발생한다면 주눅들지않고 내 의견과 생각을 자신있게 말하고 긍정적인 자세를 갖겠다

 

개인적으로 어떤 규칙에 얽메이는 것을 싫어해서 사람들과의 관계나 업무에서 자유를 추구하는 편인데, 

자유가 주어진 상황에서 책임감을 느끼고 더 노력하는 사람도 있는 반면 그 자유에 안주해서 편함만 좇는 사람들도 있다. 나중에 내가 이끌어 나갈 상황이 있을경우 이 부분은 어떻게 해야 할지 고민이 된다.

(어느정도 규율은 필수적인것 같기도 하다..그 규율로 습관을 만든 다음 자유를 주는게 나을거 같다는 생각)

 

 

팀프로젝트 회고

처음 기획이 진짜 중요하다(db설계, 로직설계, 기능설정, 아키텍쳐 설계, role 설정)

시간계획 중요

프로젝트가 진행되면서 회고 중요

커밋메시지 중요

리액트 사용시 컴포넌트 관의 관계 정리

커뮤니케이션 안되는 코드는 쓰레기다.

목표 설정을 잘하고 어떤걸 원하는지 공유하는게 중요

 

 

처음 기획시 참고