[P1/ 박근웅/ 의견] 첫번째 프로젝트 리뷰 및 개선점 제안

[pgw928]

< 좋았던 점 >

오랜만에 하는 프로젝트인데 비대면 프로젝트임에도 불구하고 모두 적극적으로 참여해 주셔서 많은 동기부여를 얻을 수 있었습니다.

< 개선이 필요한 점 & 개선 방안 >

1. 각자가 자유롭게 접근했을 때 다양한 아이디어를 찾고 더 나은 결과를 얻게 되는 것은 사실이나 짧다면 짧은 일주일 안에 6명의 결과들을 하나로 모으기가 쉽지 않았던 것 같습니다. 의논한 내용을 확실히 통일하거나 미니 팀을 결성해서 진행하면 어떨까 싶습니다.

2. 코드의 중요성보다 결과에 대한 논리나 설명이 중요하다고 생각했는데 발표 후에 저희에 대한 평가를 평가할 수 있는 부분이 github와 코드이기 때문에 이 사항들을 잘 정리할 필요성을 느꼈습니다. 또한, 코드 리뷰도 진행하면 좋을 것 같습니다.

3. 회의의 경우도 효율성을 높이기 위해 각자 의논할 내용을 회의 1시간 전에 게시해 취합후 회의를 한다면 놓치는 부분을 줄이고 효율적이지 않을까 싶습니다.

4. 3번의 경우는 여러가지 방안이 있겠지만 대표적으로 (1)이전과 같이 SLACK에 작성, (2)이슈 활용, (3)README에 간단한 달력표를 만들어 한 폴더에 markdown을 작성(달력표와 연동)하는 방법이 있을 것 같습니다. 아무래도 프로젝트에서 보여지는 것이 중요한 만큼 2번이나 3번이 좋다고 생각합니다 각각의 장단점이 있을 것 같은데 의논해 보면 좋을 것 같습니다.

읽어주셔서 감사합니다!

[taeyoung94]

1. 저도 같은 의견입니다. 모두가 다른의견이거나 상반되는 의견을 가지고있을때, 모두가 회의 이전에 미리 생각해보고 같이 결론을 내려서 시간을 더 효율적으로 관리하면 좋을 것 같습니다.
2. 동감합니다. 보여주는것도 잘 해야 저희의 노력이 더 인정받을 수 있을 것 같습니다.
3. 네 회의 시작전에 아젠다쪽에 댓글 달면 좋을 것 같습니다. 한 주 동안 고생 많으셨습니다!! :)

[ilikeinow12]

저희 코드도 잘 짰었는데 마지막에 최종 논의했던 부분만 포함되어 있어서 약간 허전해보였던 것 같아요. 1차 기준 정한 것까지 포함했으면 더 좋았을 뻔했어요. 근웅님 고생 많으셨어요.

[woojuj]

2. 코드리뷰할 때는 최종 코드 결정후에 진행하면 되지 않을까 싶습니다.
3. 회의 전 이슈 활용 좋은 것 같습니다. 해당 일자에 맞는 아젠다 올리고 아래에 댓글로 추가 의견 다는 형식으로요.