[3차 스프린트] 기획 방향에 대한 논의

[Minjoo522]

논의가 필요한 내용

2차 데모데이 때 기획 측면에서 아쉬운 피드백을 많이 받았습니다.
오늘(7월 29일(월)) 회의를 통해서 현재 기획의 코드 리뷰 플로우에 대한 설명이 친절하게 이루어 질 필요가 있다에 대에서는 모두가 공감하고 있다고 생각해요.

코드 리뷰 플로우에 대한 설명이 친절하게 이루어 질 필요가 있다는 문제를 해결하기 위해서 어떻게 해야 한다고 생각하는지 구체적으로 의견을 적어주세요. 😊

코멘트를 잘 달아주셔야 내일 회의에 도움이 될 것 같습니다!

[lilychoibb]

저희가 초기 기획에서 설정한 페르소나에게 가치를 전달하기 위해 어떤 것이 필요할까를 고민해보았습니다.
저희는 '개발자 커뮤니티' 에 앞서 1차적으로, 불안감을 느끼는 개발자 취준생을 위해 양질의 코딩 미션을 제공하고 코드 리뷰를 경험하게 하는 것을 설정했는데요!
코드 리뷰(혹은 피드백)를 경험하게 하는 것에 대해서
페어 매칭 해주는 방식 vs 게시판 형태로 제공하는 방식으로 나누어서 생각해봤어요.
아래 고민해본 것들을 간단하게 정리해봤습니다.

1. 미션 풀이 및 제출 과정 설명 추가
   • 사용자가 미션을 푸는 과정과 제출하는 절차를 명확하게 설명하는 가이드를 제공해야함
   • 게시판을 이용하든, 페어 매칭을 통해 코드 리뷰를 받든 사용자가 프로세스를 이해할 수 있게 해야 함
   • ex) 스크린샷, 동영상 튜토리얼, 단계별 설명 등 직관적으로 이해할 수 있게
2. 페어 매칭 vs 게시판
   • 페어 매칭 (코드 리뷰를 강제시킴)
     • (장점) 코드 리뷰를 무조건 받을 수 있다는 보장을 받을 수 있음
     • (장점) 여러 미션에 찍먹하듯이 피드백 남기는 것보단 두명이서 양질의 피드백을 주고 받을 수 있음
     • (단점) 현재 페어 매칭 방식에서는 매칭된 페어 외에는 다른 사람의 미션을 볼 수 없고, 다른 사람이 자신의 미션을 볼 수도 없음
     • (단점) 다양한 피드백을 받을 기회를 제한시킴
     • (단점) 페어 매칭을 대기하는 동안의 컨텐츠 부족 - 사용자 이탈
     • (단점?) 페어의 코드 리뷰 질이 중요함 (피드백의 질에 따라 사용자별 경험이 천차만별로 달라질 수 있음)
   • 게시판 형태 (코드 리뷰가 강제가 아님)
     • 사용자가 미션을 풀고 제출하면, 해당 게시판에 다른 사용자들이 댓글로 피드백을 남길 수 있도록
     • (장점) 본인 게시글에 피드백이 오지 않아도 다른 사용자의 미션 피드백을 참고할 수 있음 (간접 경험..?)
     • (장점) 여러 개발자와 소통(다양한 피드백)
     • (단점) 페어 매칭 보다는 강제성이 떨어지므로 본인 게시글에 피드백이 오지 않을 수 있음
3. 미션 퀄리티
   • 미션을 통해 사용자가 얻었으면 하는 것 : 미션을 통해 몰입을 경험, 성장하는 느낌, 아키텍처, 클린 코드 경험, 테스트 코드 작성 등등
   • -> 퀄리티 높은 미션을 통해 이루어질 수 있음.
     • 미션의 난이도와 내용, 피드백의 질 중요

[Minjoo522]

저는 이 기획 방향에 대한 논의에서 우리가 할 수 있는가를 생각해봐야 할 때라고 생각합니다.

물론 기술 측면에서 우리 팀원들이 실력적으로 부족한 부분이 없기 때문에 개발에 대한 걱정은 전혀 없습니다.
하지만 우리가 기존 방식을 유지하며 설명을 친절하게 하기 위해서는 기획에 더 많은 힘을 쏟아야 할 것 같습니다. 개발적으로 풀어나갈 수 있는 부분 보다는 UI 디자인으로 풀거나 컨텐츠로 풀어야 하는 부분이 훨씬 많을 것이라고 생각합니다.
혹시 개발적으로 풀 수 있는 부분이 있다고 생각한다면 그 방법을 구체적으로 공유해주면 좋을 것 같습니다. 😊

저는 이런 기획 회의를 현재 우리 팀 상황에서 잘 헤쳐나갈 수 있을지 걱정이 앞섭니다. 거의 며칠간을 기획 회의만으로 하루종일 회의를 해야 결과물이 나올 것 같다고 생각하고 있기 때문입니다. 고될지도 모를 기획 회의를 위한 준비가 모두 되었을까요? 우리 팀원들이 모두 고된 회의를 견뎌낼 자신이 충분히 있다면 저는 기존 방식을 유지하는 것도 좋다고 생각합니다. 해보지도 않고라고 생각할 수 있겠지만 우리가 과연 해보지 않았을까요? 어제 회의는 다들 어땠나요? 또 1차 스프린트 때 기획 회의는 어땠나요?

저는 이런 고된 회의를 억지로 이어가는 것보다 기능을 조금 더 좁혀서 하나를 완성하고 새로운 기능을 덧붙이는 게 낫겠다라고 생각했습니다. 그래서 첫 번째 기능으로 프론트엔드 멘토 서비스를 차용해보자라고 제안 했습니다. 이 기능이 완성되고 나면 이전에 얘기했던 로드맵이나 코드리뷰 스크랩과 같은 추가 기능을 제공할 수 있겠죠?

[brgndyy]

회의때 말씀드렸다시피 현행 유지 vs 프론트엔드멘토 아이템 차용 중에 어떠한 아이템을 채택해도 상관 없다는 입장입니다.

두 가지의 입장이 전부 이해가 가고 공감이 가서 아이템 자체에 대해선 둘다 상관 없다고 생각하지만, 무엇이든 간에

1. 미션 퀄리티는 높혀야한다.
2. 사용자가 빠른 피드백을 받을수 있는 추가피쳐는 필요하다

이 2가지가 충족 되어야 사용자가 유용성을 느낄수 있지 않을까해요!

[chosim-dvlpr]

먼저 저는 어떤 결정에도 동의합니다. 중요한 것은 우리의 목표를 달성하는 것이지 방식은 어떻게든 잘 풀어나갈 수 있다고 생각해요.

1. 현재 페어 매칭 및 코드 리뷰를 빼야 하나?

코치님이 제안하셨던 것이니 엎을 이유도 없다고 생각해요
반대로 이 기획을 가져가야 할 이유도 없어요. 나중에 기능 추가를 하는 방향도 좋을 것 같고, 이미 경험해봤기때문에 구현이나 기획은 쉬울 것이라고 생각해요.

2. 위 방식을 유지한다면?

기획이나 디자인 비중이 많을 것 같아요. 개발적인 고민이 줄어들 수 있을 것 같아요.

3. 개발적인 부분의 니즈 충족은 어떻게?

신규 피처 개발을 하면 어떨지 제안해요. 페어매칭리뷰와 신규피처까지 구현하느라 시간이 부족할 수도 있지만 8명이서 안될건 없다고 생각합니다.

4. 우려되는 사항

1)페어 매칭 리뷰와 2)멘토 사이트처럼 코드 공개 방식 두 기능이 있다면 과연 사람들이 페어매칭리뷰 기능을 사용할까 의문이 있어요. 하지만 해결 방식은 잘 모르겠습니다🥲 좋은 아이디어 있으면 언제나 환영이에요.

5. 결론

저는 어떤 방법이든 받아들일 수 있어요. 아직 우리가 시도해보지 않았기 때문에 어찌될지 모른다고 생각하기 때문이에요. 시간이 부족하면 시간을 내서 하면 되고, 시간이 남는다면 기능을 추가해도 좋아요. 중요한 건 방향이지 방식이 아니라고 생각해요.

[alstn113]

저희 팀의 목표는 '개발자 취준생들이 서로 성장할 수 있는 생태계'라고 했지만 저는 솔직히 '코드 리뷰 사이트'라고 생각했던 것 같아요.
리뷰 플로우가 복잡할 수 있지만 프로그래머스에서 처음 문제를 풀 때 가이드나 전체 과정 중 현재 상태를 나타내는 방식으로 충분히 설명할 수 있다고 생각했습니다. 그게 저희가 우테코에서 배우는 '문제 해결'이라고 생각했습니다. 기획이나 디자인 부분이 많은 것 같지만 개발이 아니라 그것으로 문제를 해결할 수 있다면 하는게 맞다고 생각했습니다.

사일로를 적용한다고 해서 리뷰 매칭을 개선하는 것과 프론트엔드 멘토와 같은 기능을 같이 만들면 될 것 같다고 생각했습니다.
하지만 하나에 집중하는 것이 훨씬 효율적이라고 생각해요. 리뷰 매칭 구현 방식이 깃허브 기록과 머리에서 지워지는 것이 아니니 프론트엔드 멘토 방식을 먼저 개발하고 나중에 해도 될 것 같습니다. 어떤 방식이든간에 기획만 구체적으로 하면 잘 해낼 것 같아요.
하지만 프론트엔드 멘토 기능에만 집중할 경우 팀을 어떻게 나눌지 잘 떠오르지 않네요.