[2차 데모데이] 회고 및 발전 방향에 대한 논의

[Minjoo522]

논의가 필요한 내용

7월 29일(월)에 7월 26일(금) 진행된 2차 데모데이에 대한 회고 및 회의를 진행하고자 합니다.
주요 내용은 다음과 같습니다.

• 2차 데모데이에 대한 회고
• 앞으로 발전 방향에 대한 논의

추가적인 논의가 필요하다고 생각하는 부분이 있으면 자유롭게 알려주세요.
그리고 회의 전까지 앞으로 발전 방향이나 우리 팀이 보완해야 할 사항 그리고 각 분야 TODO에 대해 코멘트를 달아주시면 원활한 회의를 진행할 수 있을 거라고 예상합니다. 😊

[brgndyy]

글이 너무 길어질것 같아서 저의 생각을 간략히만 적어놓습니다.

1. 2차 데모데이에 관한 회고

칭찬을 들은건 아니다보니 아쉬움을 느끼는 것도 당연하다고 생각합니다.

앞으로 발전 방향에 대한 논의

지금 와서 이렇게 말씀드리는 것이 굉장히 조심스러울순 있지만 기획 단계부터 새롭게 시작해보아야하지 않을까 싶습니다.

데모데이때 말씀 들었던 아이템을 꼭 따라가야한다는 아니지만 현 상황에서 꾸준히 나아갔을때 보이는 문제점은 명확해보입니다.

그렇다고 해서 아예 전부 다 갈아 엎고 제로베이스부터 시작해야한다는 건 아닙니다.

현재까지 구현한 부분에서 어느정도는 덜어내고 추가해볼수 있는 부분은 더 추가해보는 방식으로 나아가볼수 있을거 같다고 판단합니다.

[Parkhanyoung]

이번 데모데이 우여곡절이 많았던 것 같은데 다들 너무 고생 많았습니다 🫡
데모데이를 거친 후의 제 개인적 생각을 적어봅니다.

데모데이 회고

코치분들의 조언을 듣고, 첫 주에 이야기했던 우리 팀의 목표와 방향성을 조금 잊고 있었다는 사실을 깨달을 수 있었습니다. 우리는 개발 관련 고민을 우선적으로 하기보다는, 실 사용자를 모으고 가치를 전달하는 일에 대한 고민을 우선시하기로 했었습니다. 그러한 방향이 포트폴리오로서든 몰입 경험으로서든 더 유의미할 것이라고 판단했기 때문입니다. 개발자 커뮤니티(코드 리뷰 플랫폼)를 선정했던 가장 큰 이유도, 그것이 우리가 실 사용자를 유치하고 가치를 만들어낼 수 있는 가능성이 높은 분야라고 판단했기 때문이었습니다. 그런데 실제 개발을 진행하면서 명시적으로 정해진 기획자나 리더가 없으니 알게 모르게 개발 쪽으로 포커스가 많이 옮겨갔던 것 같습니다. 원래의 방향성을 되찾아 유저에 대한 고민을 더 중점적으로 가져가야 하지 않을까 생각했습니다.

앞으로의 방향에 대한 생각

코치분들의 말씀대로 유저에게 우리의 서비스 플로우를 설명하고 그 가치를 설득하는 일의 난이도가 높다고 느꼈습니다. 우아한테크코스를 경험하지 않은 일반적인 개발자 지망생들이 우리 서비스의 코드 리뷰 플로우를 이해하기까지 허들이 높다고 느꼈습니다. 또한 코드 리뷰는 유저에게 심리적, 시간적 부담이 큰 데 반해 코드 리뷰를 통해 얻을 수 있는 가치는 잘 알려져 있지 않기 때문에 허들이 더더욱 높을 수 있겠다고 생각했습니다. 이러한 점을 제품을 개발하기 이전에 캐치하지 못한 점이 아쉽지만, 지금이라도 기획의 방향을 살짝 조정할 필요가 있다고 생각했습니다. 공원이 레퍼런스로 제시해주셨던 Frontend Mentor 서비스의 피처를 적극 차용해도 좋겠다고 생각했습니다. 해당 서비스처럼 코드 리뷰 대신 과제에 대한 솔루션과 관련 의견들을 자유롭게 게시판 형식으로 남기는 방식을 생각해 봤습니다. 이런 형태에서는 사용자들이 서비스를 이해하기 쉬우며(+그만큼 기획적으로 고민할 범위가 좁아지며) 둘러 볼만한 컨텐츠가 풍부해지고, 서비스 내 사용자들 간의 상호작용도 활성화할 수 있을 것이라 생각했습니다. 이 간단한 버전을 출시한 이후에 코드 리뷰 기능을 추가적으로 붙여 보아도 좋겠다고 생각했습니다.

태스크 할당 방식 개선 아이디어

조금 도전적인 변화일 수 있지만 현재 우리 팀의 문제를 해결하는 데 도움이 될 수 있을 것 같아 적어봅니다. 모든 구성원이 문제 해결에 집중하기 위해 태스크 분배 방식에 변화를 줄 수 있겠다고 생각했습니다. 현재는 모든 태스크를 다같이 리스팅하고 그것을 개발 관점에서 할당하여 나눠 갖는 방식이었습니다. 이런 구조이다보니 자연스럽게 실제 문제보다는 개발에만 집중하게 된 것 같기도 합니다. 따라서 단순히 개발 관점에서 업무를 분배하지 않고, 우리가 해결해야 하는 문제를 나열하고 그 문제를 나눠 가져가는 방식으로 변화를 주면 문제에 집중하기 용이할 것이라고 생각했습니다. 예를 들어, 우리가 현재 해결해야 하는 문제가 '사용자 유치', '서비스 플로우 설명' 등이 있다고 했을 때, 프론트 팀원 한명과 백엔드 팀원 한명이 짝을 이루어 '사용자 유치'라는 문제를 할당받는 식입니다. 그 후 둘이 힘을 합쳐 마케팅으로 풀든, 기획으로 풀든, 개발로 풀든 해당 문제를 해결하는 데에만 집중하는 것입니다. 말하자면 데벨업이라는 팀이 하위의 여러 작은 팀으로 쪼개지는 겁니다. 그리고 각 팀이 독립적으로 움직이면서도 중간중간 공유하고 피드백을 받아 반영하는 방식으로 움직인다면 팀 내부 싱크를 유지하면서도 모든 구성원이 문제 해결에 집중할 수 있겠다고 생각했습니다. 추가적으로 3차 스프린트 요구사항에 FE or AN 에서 BE까지 관통하는 업무 중 최소 하나를 FE or AN / BE 개발자가 짝으로 (3인 짝도 가능) 진행이 있는데, 이 요구사항도 자연스럽게 충족할 수 있게 될 것이라 생각합니다! 🙂

---

제 개인적인 의견은 여기까지입니다. 한 편으로는 이번 데모데이에 대한 감상이 개개인 별로 다를 것 같은데, 이 차이로 인해 스트레스 받는 분이 생길까 걱정이 되기도 하네요 🥲 해커톤 때처럼, 정답은 없고 어찌됐든 우리만의 결론만 잘 합의하면 되는 문제이니, 열심히 이야기해서 좋은 결론 같이 내려봐요! 💪🏻

[robinjoon]

데모데이 준비 과정 회고

적어도 데모데이 전날에 완벽히 준비가 되어있어야 한다.

이번에는 정말 운이 좋아서 겨우겨우 시연할 수 있었지만, 앞으로도 이럴 것이라는 보장은 없다.

돌이켜보면 데모데이 전날에 깃허브 로그인 관련 비밀 정보를 어떻게 관리할 것인지 정해지는 것 자체가 너무 늦었던 것 같다. 어떤 의사결정이 팀원 누군가를 제외하고 결정되는 것은 분명 피해야 한다. 하지만, 급하면 그럴 수도 있다.

앞으로의 방향성

코치들의 피드백은 크게 두가지라고 생각한다.

1. 사용자 입장에서 이제 뭘 해야 하는건지 알 수 없다.
2. 사용자에게 가치를 주기까지 넘어야 하는 허들이 너무 높다.

사용자 입장에서 이제 뭘 해야 하는건지 알 수 없으면 친절하고 자세하게 알려주자

사용자의 어떤 행위 이후 다음 행위로 친절하게 유도하는 UI 를 추가하면 그 부분의 지적은 해결할 수 있을 것이라 생각한다.

친절한 유도는 여러 방법이 있을 것 같다.

1. 버튼 클릭 등 여러 행위 이후 적극적으로 안내 모달 출력
2. 서비스 사용법에 영상으로 제공 => 화면 녹화 및 간단한 편집으로 가능!

겸사겸사 매칭 대기 상태에서 사용자가 할만한 컨텐츠를 추가하는 것도 좋을 것 같다.

사용자에게 가치를 주기까지 넘어야 하는 허들이 너무 높으면 설득하는 내용을 배너에 추가하자!

코치는 배너에 넣을 컨텐츠가 없으니까 배너를 제거하라고 했지만, 컨텐츠를 추가하면 된다. 우리 서비스를 통해 가치를 얻는 허들이 높다면, 그것이 가치를 줄 수 있다고 잠재적 사용자를 설득하면 된다. 단 몇몇이라도 설득에 성공하면 되니까.

다음 세가지 사실을 알려주면서 설득할 수 있다고 생각한다.

1. 현업에서 코드 리뷰를 한다는 사실
2. 우리가 우테코를 하면서 코드 리뷰를 통해 성장했다는 사실
3. 현업에선 다른 사람의 코드를 보는 일이 훨씬 더 많다는 사실

1번과 3번은 여타 교육의 홍보자료나 여러 기업의 문화를 설명하는 자료에서 수집하면 되고, 두번째는 크루들 인터뷰해서 컨텐츠로 제공하면 좋을 것 같다.

개발하러 왔는데 이게 맞나??

어느정도 공감하지만, 학습 관점에서 할 수 있는 것 역시 많다고 생각한다. 단적으로 이번 스프린트를 진행하면서 공부한 내용들이 다들 있을 것이라 생각한다. 예를 들어 인프라나 서버 쪽 지식이라던지, CI / CD 라던지... 이런 것들을 글로 정리해서 블로그로 공유한다면 그 과정에서 엄청나게 많은 것을 학습할 수 있을 것이다.

기술은 언제나 가치를 주기 위해 생겨났다. 그렇기에 제공하고자 하는 가치를 떼어놓고 기술만을 추구하는 것은 앞뒤가 맞지 않다. 개인적으로 여러 회사의 면접을 본적이 있고, 합격도 몇번 해본 경험에서는 다양한 기술을 안다고 어필하는 것이 득이 된 경우는 거의 없었다. 오히려 약점만 들어내는 꼴이다. 우리가 아무리 기술을 공부해도, 현업에서 최소 몇년은 구른 선배 개발자들보다 잘 알 수 없다. 차라리, 우리가 어떤 문제를 해결하기 위해 어떤 고민을 어떤 논리로 풀어나갔는지를 어필하는 것이 더 좋을 것이다.

[lilychoibb]

https://suave-bearskin-3ab.notion.site/7-26-2-67833e4c907d4728bdd3ae5040c10e51?pvs=4
데모데이 때 받았던 피드백 정리해두었습니다!

[Minjoo522]

데모데이, 2차 스프린트 회고

우선 데벨업 팀원들 전부 고생 많았습니다.
지금은 어떻게 느끼고 있을지 모르겠지만 다들 많이 성장했을 거라고 믿습니다.
사실 데모데이 피드백에서 좋은 피드백만 받은 것은 아니기에 걱정하는 팀원도 있을 거라고 생각합니다. 하지만 지금 완벽한 것보다 빠르게 부족한 부분을 찾아서 보완하는 게 더 우리를 더 성장할 수 있도록 만든다고 생각합니다.

제가 보기에 많이 지치고 동기 부여가 되지 않고 있는 것 같습니다.
힘들겠지만 다시 한 번 초심을 찾을 수 있도록 해봤으면 합니다.

앞으로 방향에 대한 생각

기획 관련

기획은 변경이 많이 필요하다고 생각합니다.
공원이 말한 프론트엔드 멘토 서비스와 비슷한 방향을 고려해볼 수 있을 것 같습니다.
코딩 테스트처럼 구현 테스트를 연습할 수 있는 서비스를 제공한다고 생각하면 될 것 같습니다.
개인이 자유롭게 풀고 간단한 채점 기능을 제공하며 코드를 올리게 할 수 있을 것 같습니다.
추가적으로 질문 기능도 제공할 수 있겠죠. 😊
코드를 올린 경우 다른 사람의 코드에 별점이나 북마크를 하는 기능을 제공하고 별점이 높은 사람은 랭킹에 올라간다면 약간의 Gamification 효과도 줄 수 있을 것 같습니다.

위 기획 변경으로 얻을 수 있는 효과는 다음과 같습니다.

1. 미션을 수행하지 않아도 볼 수 있는 컨텐츠를 제공할 수 있다.
2. 구현 테스트 연습에 대한 니즈를 충족시킬 수 있다.
   추가적으로 다른 효과도 있을 것으로 예상합니다.

기획 외

기획 변경에 앞서 제일 우려되는 부분은 우리의 회의가 너무 고되고 길어지기만하며 결론이 나지 않는 회의가 많다는 점입니다.
지금과 같은 방법으로 회의가 진행된다면 결국 서로 힘들어지기만하는 길이 아닐까요?
특히 더 논의가 필요한데 회의를 빨리 끝내고 싶어하거나 귀찮아하는게 느껴질 때 열심히 하고자하는 사람의 의욕도 꺾이고 에너지도 소모시키는 것 같습니다.
그러다보니 필요한 기획 회의도 계속 하지 못하고 미루게 된 건 아닐까라는 생각이 들었습니다.

우리가 더 좋은 방향으로 나아가기 전에 기획의 변경 여부와는 상관없이 그라운드 룰 변경이 선행되어야 하지는 않을까요?
저는 아래와 같은 두 가지 변경이 필요하다고 생각합니다.

1. 회의를 귀찮아하지 않기
2. 반복적인 논의가 계속될 때 결정하는 방법을 정하기
   • 예를 들면, 3번 이상 같은 핑퐁이 반복되면 다수결로 정하기와 같은 방법이 있을 것 같습니다.

다른 분들의 생각도 궁금합니다. 😊

[chosim-dvlpr]

먼저 릴리가 공유해 준 피드백 정리본에 덧붙이면 좋을 내용 공유합니다~!

2차 데모데이 피드백 정리

기획/서비스

• 우리 팀의 최종 목표는 커뮤니티 → 활성화 위한 ‘수단’으로써 리뷰 프로세스를 진행하는 것임을 인지하기
• 서비스 기능을 가능한 작게 기획하여 해당 부분의 기술적, 마케팅적 요소를 함께 가져가기
  • 목표를 단계적으로 가져가기
• 개발로써 어떤 문제를 해결할 수 있는가 라는 스토리를 그려보면 좋을 것
  • ex) 수동으로 하던 것을 개발로 자동화 한다든지
• ‘프론트엔드 멘토’ 사이트 - challenges
  • 이 사이트처럼 처음에는 미션만 제시해놓고, → 사용자 많이 모은 뒤 → 페어 매칭 플로우를 추가하는 방법도 있다

CI/CD

• CI/CD 구조도가 있는지? - 백엔드와 프론트엔드 서로가 플로우를 알아야 좋다 (구조도 같이 그려보는 것도 좋다)
  • 플로우를 모두가 알고 있으면 누군가가, 혹은 백/프론트가 없어도 서로 백업 가능하다.
• PATH_CHANGES 등 용어에 대한 설명이 구체적으로 드러나면 좋을 것 같다

디자인

• 메인 배너 - 배너에 넣을 컨텐츠가 생기면 추가하는 것이 좋겠다
  • 블로그 첫 글을 발행한 뒤 배너에 넣어도 좋을 것 같고, 아니면 About 등의 탭에 블로그를 연결하는 것도 좋을 듯

블로그

• 서비스가 성장해가는 과정에 대한 이야기는 사람들이 궁금해하니 현재처럼 우리 프로젝트, 서비스에 대한 소개로 블로그를 시작하는 아이디어 좋다
  • 서비스를 발전시켜가는 과정을 기록해놓자

기타

• 잘하는 개발자는 신기술을 잘 다루는 개발자가 아니라, 문제 상황을 인지하고 어떻게 해결할지를 잘 아는 개발자!

[chosim-dvlpr]

✅ 2차 스프린트 회고

정신없이 2차 스프린트와 데모데이가 지났네요. 다들 고생많으셨습니다~! 2차 스프린트는 개발을 시작하면서 무언가 이루어내고 있다는 느낌을 받을 수 있었어요. 추상적인 것에서 구체화시키는 과정이 즐거웠습니다. 한편으로는 제가 팀에 많은 도움을 주지 못했던 것 같아서 아쉬운 스프린트이기도 했습니다. 디버깅도 돕고 싶고, 빠르게 많은 기능을 쳐내고 싶은데 그러지 못했던 것 같네요 🥲 3차 스프린트 때는 팀에 도움이 될 수 있는 방법을 계속해서 찾아보려고 해요.

✅ 우리 팀에게 더 필요하다고 생각한 것 : 기획에 대한 논의

1. 리뷰 기능 개선

페어 매칭 및 리뷰 기능에서 현재는 전체적인 흐름만 잡혀있다는 생각이 들어요. 리뷰라는 큰 틀은 정해졌으니, 살을 붙이는 방식으로 부족한 점을 채워나가면 좋을 것 같습니다! 코치님이 알려주신 프론트엔드 멘토 사이트를 이용해봤는데요, 이 사이트를 바탕으로 추가하면 좋을 기능은 다음과 같습니다 .

• 미션 진행에 대한 간략한 방법 안내 → 클릭하면 자세한 방법을 알 수 있도록
  • https://www.frontendmentor.io/challenges/social-links-profile-UG32l9m6dQ - Brief Challenge FAQs 참고
• 미션을 진행한 다른 사람들의 PR을 모아볼 수 있는 기능
• 제출 페이지에서 질문 항목 추가
  • 미션을 진행하며 신경 쓴 부분
  • 미션 진행 중 겪은 어려움
  • 아직 해결하지 못한 부분
• 미션에 대한 의견, 코멘트
• 난이도, 권장 실력/레벨
• 리뷰 가이드라인 제공
• 리뷰 품질 평가

2. 신규 기능 추가

개발자 취준생 상호 성장 플랫폼이라는 목표를 유념하면서 신규 기능을 추가하면 좋을 것 같아요. 리뷰 스크랩 기능과 1차 스프린트 때 이야기가 나왔던 로드맵도 좋고, 개발 혹은 학습 중 겪고 있는 에러를 질문할 수 있는 커뮤니티도 있으면 좋을 것 같습니다. 정리하자면,

• 리뷰 스크랩 기능
• 로드맵
• 성장 트래킹: 학습 진행 상황, 프로젝트 완료, 기술 습득 등을 시각화하여 보여주는 기능을 제공
• 실시간 Q&A 게시판 (개발 기술, 커리어, 생활, 코드 토론, 기타)

기획에 대한 자세한 이야기는 회의에서 말씀드릴게요!☺️

[brgndyy]

처음에 제 생각을 최대한 간략히 적어놨었는데요.

회의때 직접 말씀 드리기엔 다들 할말도 많으시고 시간도 길게 쓰일것 같다는 생각이 들어서 제가 생각한 기획안과 태스킹 방식 덧붙여놓습니다.

공원이 추천해주신 프론트엔드 멘토의 핵심 아이템은 기존의 데벨업의 기획과 비교한다면 확실히 호흡을 줄일수 있을것이라 생각합니다.

하지만 절대적으로 판단했을때, 이 또한 호흡이 길지 않나? 라는 생각이 들었어요.

프론트엔드 멘토의 아이템을 차용했을때 걱정되는 부분은 다음과 같습니다.

1. 아무리 호흡을 줄였더라도 아직도 사용자 플로우가 길다.

• 무조건 웹 환경에서 접속했을때만 데벨업의 접속 이유를 찾을 수 있고, 이또한 미션에 몰입하지 않는다면 의미가 없다고 생각합니다. 단순히 미션 제공만 함으로써 기존에 가지고 있던 호흡의 절반으로 줄일 수는 있겠지만 동시에 따라오는 단점이 존재합니다.

2. 해당 미션‘만’ 제공해서 본인이 성장하고 있음을 느낄수 있으려면 정말 질좋은 미션 컨텐츠가 필요하다.

• 현재 프론트엔드 멘토에서 제공해주는 미션을 예로 들더라도, 단순히 자바스크립트, HTML, CSS로만 문제를 풀수 있는데요. 취준생 입장에서 바닐라JS로 계속 무언가 만들려고 하기보다 얼른 리액트로 넘어가고 싶은 욕구가 더 클거라고 생각합니다. 또한 미션‘만’ 제공하는 구조는 그만큼 우리도 많은 미션을 제공해야하므로 리소스 낭비도 있을거 같고요. 뿐만 아니라 미션만 제공한다고 해서 취준생들이 이 컨텐츠를 통해 성장하고 있음을 느낄수 있는가?에 대해서는 미지수라고 판단합니다.

제가 생각한 기획안은 크게 2가지이고 ‘사용자 중심의 컨텐츠’와 ‘우리 데벨업팀 중심의 컨텐츠‘ 총 2가지 입니다.

어떻게하면 사용자가 최소한의 참여를 통해서 성장하고 있음을 느끼게 할수 있을까? 로 잡고 기획안을 생각해보았습니다.

1. 사용자 중심의 개발 토론회장, 개발 아고라

기존에 존재하고 있는 어플인 ‘더 폴’에서 차용해보았는데요.
더 폴 어플에서는 사회적으로 관심도가 높은 이슈들에 대한 간략한 설명을 담은 글을 제공합니다.
그래서 그 게시글에서 사용자들은 본인의 의견을 개진하고, 토론을 진행합니다. 이러한 행위를 통해서 실제로 1원, 2원 등 아주 작은 금액을 제공함으로써 캐시워크의 기능도 제공합니다.
이를 데벨업 컨텐츠에 대입해보자면, 취준생들끼리 토론해볼수 있는 개발적인 주제들을 우리가 제공하고 이를 사용자들끼리 이야기나눌수 있도록 할수 있을거 같습니다.
우리가 레벨 1,2 때 페어프로그래밍을 하면서 페어와 함께 토론했던 주제들에 대한 토론의 장을 마련해준다라고 생각해주시면 될거 같습니다. (ex useQuery vs useSuspenseQuery 중에 어떤걸 언제 써야할까요? or 유효성 검사 로직은 도메인 로직에 있는 것이 맞을까요? 등)

그리고 이러한 주제는 우리 데벨업이 직접 제공을 해줄수도 있지만, 실제로 우리가 제공해준 미션에 참여했던 사람들이 직접 글을 작성하게 해볼수도 있을거 같습니다. (ex 제목 : 이번 흡연구역 미션에서 이야기 다뤄보고 싶은 부분이 있습니다.)

• 더 폴 예시
• 
• 

하지만 위의 개발 아고라 또한 사용자가 직접 의견을 게시해야하는 인풋을 들여야하는 문제점이 있을수 있다고 판단합니다.

그래서 2번째로 생각한 기획안은 데벨업 팀이 제공해주는 컨텐츠입니다.

2. 인터뷰 질문들 제공

이는 우리 팀의 일원인 아톰이 참여하고 있는 인터뷰 스터디의 방식에서 차용해본것인데요.

실제로 아톰이 진행하고 있는 인터뷰 스터디에선 직접 문제를 제출하고 스터디원들이 그 문제에 대한 답을 작성하는 식으로 진행하고 있는 거로 알고 있습니다.

ex ) PUT과 PATCH 메서드의 차이점에 대해서 설명해주세요.

• 스터디원들이 이에 대한 설명을 댓글로 작성함

이에 대한 문제들을 우리가 직접 제공해줌으로써 사용자들이 직접 댓글을 달아보면서 참여할수 있게 하지 않을까? 라는 생각이 들었어요.

직접 댓글을 달지 않더라도 우리가 직접 답까지 제공해주어서, 사용자들이 "데벨업에 접속하면 뭐라도 얻어가는구나." 라고 느끼도록 할수 있겠다 판단했습니다.

---

위의 컨텐츠들을 도입한다면, 사용자 입장에서 버스에서나 지하철에서라도 단 5분이라도 데벨업에 접속해서 조금이나마 성장할수 있음을 느낄수 있도록 할수 있겠다 생각했습니다.

이번에 2차 스프린트 피드백을 듣고 들었던 생각은, 사용자의 인풋은 최대한 적게, 아웃풋은 크게 하는 것이 중요하겠다고 느꼈습니다.

지금 현 상황에서 단순히 미션만 제공한다고 하더라도, 사용자 입장에선

1. 몇 시간이 걸릴수도 있는 미션을 직접 풀어야만 한다.
2. 시간을 들여서 미션을 풀더라도 본인이 성장하고 있음을 직관적으로 느낄수는 없다.

라고 판단합니다.

그렇다고 해서 아예 미션 제공을 빼야만 한다는 의견은 아닙니다. 미션 제공을 하더라도 위의 기능들과 혼합하여 어느정도 사용자가 본인이 성장하고 있다고 느낄수 있는 빠른 피드백을 제공해야한다고 생각합니다.

[brgndyy]

팀 자체의 태스킹 관련

아무래도 스프린트마다 주어진 개발적인 과제도 주어져있고, 지금 현재 팀 프로젝트가 취업과 관련한 포트폴리오가 될 가능성이 크다보니까 자연스럽게 개발에 관하여 치우칠수 밖에 없다고 생각해요.

실제로 저희는 창업하러 우테코에 온게 아니고 개발을 하러 우테코에 온것이니까요.

하지만 이 개발 또한 마케팅과 비슷한 결로 하나의 문제해결 수단일뿐이지, 개발 그 자체로 존재할수 없다고 생각합니다.

그리고 포트폴리오의 관점에서 봤을때도 아무리 기술적인 스택을 덕지덕지 붙여놓아봤자 회사가 바라는 역량에는 못미칠 거라고 생각합니다.

대단하고 유명한 기술스택들을 사용한다고 한들 사용자가 없다면 무슨 의미일까요?

사용자가 없다면 우리가 아무리 대단한 아키텍쳐를 적용한다고 한들 이는 무슨 의미를 가지게 될까요?

이미 레벨3 절반에 다가온 상황에서 신체적으로나 정신적으로 지치는 것이 이해 되고 공감됩니다.

하지만 이런 시점에서 우리는 어찌보면 2배의 효율을 내야만 하는 상황에 맞닥뜨렸다고 생각해요.

기획부터 디자인, 개발까지 다시 시작해야하는 상황에 놓여져있을수도 있고요.

그래서 모두가 다시 한번 갖고 있는 목표를 일체화 할 필요가 있지 않을까 싶어요.

저는 우테코에서 하는 이 협업 경험이 단순히 포트폴리오를 넘어서서 나중에 되돌아봤을때 삶 자체에서 중요한 배움으로 남지 않을까 하는 기대가 있습니다.

그리고 팀원 모두가 다 좋은 사람들이라고 생각하고 개개인이 높은 역량을 가지고 있다고 믿고 있습니다.

이미 레벨3 절반을 지나왔지만, 뛰어난 사람들끼리 모인김에 다시 한번 힘내서 문제 해결에 집중해보았으면 좋겠습니다.

또한 업무 분담 자체를 유연하게 가져가는 것도 더 효율적이지 않을까? 싶은 생각이 들었어요.

본인이 기획보단 개발에 조금 더 재미를 느낀다면 기획하는 과정에서는 최대한 그 팀원의 부담을 줄여주는것이 맞지 않을까 싶습니다.

이건 또 개인적인 바람이지만 신체적으로나 정신적으로 지친 팀원이 계셔서 주어진 태스크에 부담을 느끼신다면 편하게 말씀해주세요.

그 팀원 몫은 다른 팀원, 아니면 제가 도맡아서 해볼수 있을 만큼 최대한 함께 해보겠습니다.

어떻게 해서든지 데벨업 잘되게 해보고 싶어요. 화이팅해봐요!

[Parkhanyoung]

@brgndyy
오래 고민하여 좋은 의견 남겨주셔서 감사합니다 버건디 🙂
버건디가 정성스레 남겨주신 제안에 대한 제 개인적 의견을 남겨봅니다!

Frontend Mentor의 서비스 플로우 역시 길다는 버건디의 의견에 동의합니다. 그리고 제안주신 커뮤니티 기능들 모두 사용자들이 반복적으로 우리 서비스를 찾게 할 수 있는 너무 좋은 아이디어라고 생각합니다. 그런데 한편으로는, 유저가 새로운 서비스를 쓰게 만들기 위해서는 우리 서비스만이 제공하는 핵심 피처가 명확히 존재해야 하지 않을까 하는 생각도 들었습니다. 흔히 신규 서비스는 10X의 경험을 주어야 한다고 말하는 것처럼 말이죠. 개발 아고라, 인터뷰 질문과 같은 기능은 널리 알려진 okky, github, stackoverflow 등의 커뮤니티에서 쉽게 찾아볼 수 있어서 우리 서비스의 핵심 피처로 가져가기에는 아쉬움이 있을 수 있겠다는 생각이 들기도 했습니다. 그래서 Frontend Mentor가 되었든 코드 리뷰가 되었든, 혹은 다른 기능이 되었든, 우선은 다른 서비스에서 쉽게 이용할 수 없는 우리의 핵심 피처를 검증하는 것에 주안점을 두면 어떨까하는 생각이 들었습니다. 그 후 커뮤니티를 활성화하고 개선해 나가는 단계에 말씀해주신 가능들을 붙여나가는 방식이 되면 더 좋을 것 같다고 생각했습니다! 서비스 플로우를 줄이고 기획의 범위를 좁히는 것이 초기 단계에 중요한 것은 맞지만, 또 그것에만 집중하다보면 본질이 모호한 서비스가 될 수 있겠다는 생각이 들어 짧게 글을 적어 보았습니다!

이러한 의견에 대한 버건디의 의견도 궁금합니다~!

미션을 풀더라도 본인이 성장하고 있음을 직관적으로 느낄수는 없다.

이 부분 너무 공감됩니다. 유저들이 직관적으로 본인의 성장을 느낄 수 있게 하는 UX/UI 요소를 같이 고민해서 추가해 보면 좋을 것 같아요!!

---

항상 진심이 담긴 말들로 팀의 사기를 올려주셔서 감사합니다 버건디 🫡 버건디 덕분에 힘이 팍팍 납니다 💪🏻

[brgndyy]

@Parkhanyoung

유저가 새로운 서비스를 쓰게 만들기 위해서는 우리 서비스만이 제공하는 핵심 피처가 명확히 존재해야 하지 않을까 하는 생각도 들었습니다.

너무 맞는 말씀이에요! 사실 미션 제공 기능이 존재하지 않는 상태에서 제가 말씀드린 기능만 존재한다면 작은 단위의 기능 2개만 존재한다고 느낄수도 있을거 같습니다.

그래서 미션 제공 기능이 잘 다듬어진다면 충분히 데벨업의 중심기능으로 내보일수 있다고 생각해요.

그래서 무조건적으로 미션 제공 기능을 빼자는건 아니고, 미션 제공 기능과 덧붙여서 해당 미션을 통해 사용자가 직관적으로 성장하고 있도록 느낄수 있는 기능이 있으면 좋겠다고 생각해서 말씀드린 아이디어였어요! 동시에 미션제공 기능이 없더라도 독립적으로도 존재할수 있는 아이템들이라고 생각했구요.

그리고 위에 말씀 드린 기능들이 기존에 깃허브나 스택오버플로우에 존재하는 기능들이고 작아보일지라도, 이런 기능들을 인스타그램이나 쓰레드처럼 SNS화해서 제공한다면 기존에 존재하던 기능들과는 어느정도 차별점을 둘수 있지 않을까? 싶었습니다.

결국 저희가 목표로 하는건 취준생들을 위한 커뮤니티이다보니, 단순히 미션만 푸는것 이외에도 커뮤니티 특성을 띄고 있는 기능은 있어야한다고 판단했습니다.

Medium도 단순히 블로그글을 다루는 사이트이지만 SNS와 접목시켜서 통해서 현재는 많은 사용자들을 유치한것처럼요!

또 현상황에서 걱정 되는 부분은 미션 제공 기능이 정말 우리의 핵심 피쳐라고 말할수 있는가? 입니다🥲

핵심 피쳐의 역할은 직관적으로도 다른 사이트에는 없어보이는 아이템이어야하고, 해당 기능을 사용했을때 사용자가 느끼고 있던 문제가 해결되는 듯한 느낌을 주어야 한다고 생각해요.

현재 저희만의 자체적인 미션을 만들어놓긴 했지만, 일단 빠른 싸이클을 돌리기 위해서 만들어놓은 미션이다보니 현재 있는 미션들은 사실 핵심 피쳐의 역할을 하기 힘들지 않을까? 싶었어요

사실 현재 데벨업의 컨텐츠를 두고 사용자의 입장에서 이입해보았을때 지금의 미션을 풀고 싶어할까? 라는 생각이 들었습니다.

핵심 기능이 미션 제공이라면, 퀄리티 좋은 미션을 만드는 것 또한 코어라고 생각하는데 이는 개발과는 무관한 분야이다보니 팀원들이 그만큼 중요하다고 생각하지는 않을수 있겠다고 느꼈습니다.

그래서 나름대로의 절충안(?)으로 생각해본 아이디어였습니다!

라이언 말씀대로 사용자가 직관적으로 성장하고있음을 느낄수 있는 기능들을 덧붙여서 보완해볼수도 있겠구요👍

정리하자면 현재의 미션만으로는 미션 제공 기능이 코어가 되기는 힘들다고 판단했고, 퀄리티 좋은 미션이 수반되어야만 미션 제공 기능이 코어가 될수 있다고 생각합니다.

그게 아니라면 추가적인 기능들을 덧붙여서 이러한 단점을 상쇄시켜보는 방향으로 나아가면 어떨까 싶어요!

좋은 피드백 감사해요 라이언! 제가 놓친 부분이나 짚어주실만한 부분 또 댓글로 남겨주신다면 저도 계속 생각해보겠습니다 🙇

[alstn113]

프로젝트 1-2차 스프린트 회고

| 다른 분들이 충분히 개선 방향에 대해서 말씀해주셔서 프로젝트 과정 중 문제에 대해서 적어보겠습니다.

기획 과정과 기능 명세가 불충분했다.

기획 단계에서 구체적으로 결정되지 않았던 것들이 많았습니다. 예를 들어, 리뷰 방식, 알림 방식, 배너, 화면 구성 등이 그렇습니다. 기능 명세와 와이어프레임이 동시에 이루어진 것도 문제였습니다. 더욱 문제였던 것은 기능 명세는 백엔드가 하고, 와이어 프레임은 프론트엔드가 맡아서 한 것입니다. 둘을 합치는 과정에서 기능 명세가 와이어프레임에 맞춰서 결정되다 보니 이해가 되지 않는 부분이 많았던 것 같습니다. 기능 명세 또한 구체적이지 않았고, 그것은 API 명세서를 만들 때까지 결정되지 않았습니다. 이러한 문제로 인해 스프린트 내에서 기능을 구체화하고 추가하는 과정이 많았습니다.
또한 기능을 개발하려고 해도 기능 명세가 불충분해서 개발이 어려웠습니다.
결론은 기획을 아주 구체적으로 정하고, 스프린트 내에서 말했던 것들만 개발하자고 생각합니다.

코드 리뷰나 데일리 스크럼이 형식적으로만 진행되는 것 같다.

백엔드 내에서 코드 리뷰를 하기로 정하고, 어떻게 코드 리뷰를 할 것인지에 대해서 시간을 써서 정했습니다. 하지만 개인적으로 코드 리뷰를 제대로 받지 못했고, 코드 리뷰를 했으나 제대로 반영되지 않았습니다. 구체적으로 인증 PR에 대해서 코드 리뷰를 요청했지만 코멘트 0개로 머지되었습니다. 인가 PR에 대해서 반복하여 요청했지만 코멘트도 없고, 뒤늦게 머지되었습니다. 또한 제가 리뷰한 부분에 대해서는 수정없이 머지된 것을 확인했습니다. 물론 저도 PR에 구체적인 설명이 없었고, 참고였던 RCA를 잘 사용하지 않았습니다. 이러면 코드 리뷰가 의미가 없지 않을까요?

2차 데모데이 전 주에 데일리 스크럼한게 기억이 많이 납니다. 인가 부분에 대해서 프론트엔드가 어떤 예외 상황을 마주칠지 알 수 없으니, 빠르게 작성하고 배포하고 싶었습니다. 매일 아침마다 인가 부분을 구현할 거고, 시크릿 키들이 올라가야하니 준비해달라고 했던게 기억이 납니다. 그런데 그게 충분히 받아들여지지 않은 것 같습니다. 이러면 데일리 스크럼이 의미가 없지 않을까요?

개발 기간을 제한하고 하자.

가끔 백엔드 회의에서 개발 기간을 정하자는 의견이 나왔습니다. 하지만 그것이 제대로 정해지지않았던 것 같습니다. 중간에 멤버 교체가 있었기도 하고 구체적인 사정은 모르겠지만 2명이 CI, CD를 2주간 했던건 길었다고 생각합니다. 슬랙 메세지도 중요한 부분이 아니였고, 구현 후 개선도 좋지만 빠르게 개발하는 부분으로 왔어야 했던 것 같습니다. 백엔드가 5명인데 3명만 개발을 하니 프론트가 개발할게 없건게 아닌가 싶습니다. 앞으로는 개발 기간을 정하고, 그 기간에 맞춰서 개발을 하자고 생각합니다.

마무리

사이 좋게 개발하면 좋겠지만, 서로 듣기 싫은 말들을 많이 했던 것 같습니다.
하지만 저희의 목표는 프로젝트를 망치려는게 아니라 성공적으로 마무리하는 것임을 잊지말아야겠습니다.

[le2sky]

제 의견을 말씀드리자면 팀이 일하는 방법과 무엇을 만들고 있는지 정비하고 싶어요.
우리가 프로덕트를 만들기까지 어떤식으로 일해왔는지 돌아 보고 싶어요.
또한 우리가 만든 소프트웨어가 어떤 규칙으로 작동하는 지, 앞으로 어떻게 동작해야하는지 기록하고 싶습니다.

그리고, 베타 사용자에게 프로덕트를 전달한 이후에 기획 변경을 논의하고 싶어요.
이번 스프린트에 대한 피드백 주인공은 베타 사용자라고 생각했어요.
2주동안 사용자에게 빠르게 한 사이클 경험하는 것을 목표로 정했으면 결과는 봐야한다고 생각해요.
그 이후에 기획 변경을 논해도 좋다는 입장입니다.