지석팀 -
- 프로젝트 명 : FTA(Feeling Thinking Answer)
- 프로젝트 소개 : MBTI의 판단기능 중 사고형(Thinking)과 감정형(Feeling)의 선호도 관점에 따른 고민상담 커뮤니티 서비스
- 최종 발표 자료 및 시연 영상 :
최종 평가 피드백
기획
- 다양한 커뮤니티 서비스가 많은데, FTA는 분명하게 특징을 갖고 기획 되었다고 생각합니다.
- 지금 기획을 바탕으로 조금 더 셀링포인트(Selling Point)를 추가한다면 분명 유저를 끌어들일 수 있을 거라고 생각합니다.
- 처음에 의도한 기획에 맞게 마무리를 잘 하셨습니다.
- 지금 프로젝트에 대한 피드백은 아니고 혹시 다음에 또 기획을 하게 될 기회가 생긴다면 아래 내용을 바탕으로 기획을 하면 더 좋은 기획이 될 것입니다.
- 문제 정의: 어떠한 문제가 존재하는지 정의하고, 그 문제를 어떻게 해결해야할지 정리가 되어야합니다.
- 이 과정에서 유저인터뷰, 설문, 리서치 등의 방법으로 정의 및 해결 아이템 선정을 하게 됩니다.
- 유저 정의: 어떤 유저를 상대로 해당 서비스를 제공할지 정의합니다.
- 일반적으로 큰 범주로 보면 B2B 유저와 B2C 유저로 볼 수 있습니다.
- 각각의 유저 카테고리에서도 특징적인 페르소나(Persona)를 설정하고 그 해당 인물이 구체적으로 어떤 문제를 겪고있고, 어떤 해결의 니즈가 있는지를 정의합니다.
- 요구사항 정의: 유저가 겪는 문제를 해결하기 위해 어떤 요구사항이 있는지를 정리합니다.
- 일반적으로 만들고자 하는 서비스의 가장 중요한 포인트입니다.
- 서비스의 특징을 반영하게 되며, 방향성이 됩니다.
- 요구사항을 정리하면서 각각이 어떻게 유저의 니즈를 만족시키고 문제를 해결해주는지 구체적으로 서술합니다.
- 용어 정의: 서비스내에서 사용될 용어를 정리해야합니다.
- 기술적 용어, 기능적 용어, 디자인 용어, UIUX 용어 등등 혼선을 주지 않게 하기 위해 용어를 정리합니다
- 정책 정의: 서비스 전반에 걸쳐 일반적이고 공통적인 정책을 정리합니다.
- 회원 가입 방법, 회원에 대한 정의, 상품 정의, 결제 방법 정의, 플렛폼 정의 등등 다양하게 검토됩니다.
- 기능 정의
- 요구사항을 바탕으로 정말 유저 관점에서 어떻게 동작하는지 정리합니다.
- 데이터의 I/O가 정의되고, 어떻게 표기될지, 어떤 로직이 포함될지도 정리가 됩니다.
- Flowchart 정의
- User Journey 라고생각하면 됩니다.
- 유저는 어떤 행동에 따라 어떻게 서비스를 사용하게 될지 정리합니다.
- Wireframe 정의
- 위의 내용을 바탕으로 눈으로 볼 수 있는 와이어프레임을 작성하여 지금까지 논의한 내용에 서로간에 오해가 없는지 확인합니다.
개발
- 처음에 의도한 방향대로 개발을 다 하진 못했다고 들었습니다. 물론 항상 원하는 방향대로 개발을 하진 못하게 됩니다. 너무 다 못했다고 자책하진 마시길 바라겠습니다.
- 이제 한번의 사이클을 통해서 유의미한 서비스를 개발했기에, 앞으로 3팀에서 기존에 시도하려던 개발을 다시 해보는 것을 목표로 해도 좋습니다. 혹은 개인플젝을 진행하신다면, 시도해보고 싶은 개발을 꼭 진행해보고 적용해보고 비교하길 바라겠습니다.
- 서로 개발적인 이슈가있거나 질문이 있으면 서로 잘 물어보고 도와주며 개발했다고 들었습니다. 개발을 꼭 특출나게 잘하는 것도 좋지만, 정말 남이 잘 읽을 수 있는(가독성 좋은) 코드도 중요합니다. 이번 프르젝트부터 이러한 좋은 습관을 들이면 좋겠다고 생각합니다!
- 그리고 특정 테크스팩을 결정하거나, 특정 라이브러리를 도입할 때 단순히 트렌드를 따라서 하거나 단순히 해보고 싶다고 생각하도 적용을 하기보다는, 왜 이 프로젝트에 이러한 시도를 해봐야하는지를 꼭 생각하고 정리하길 바랍니다. 논리적이고 누가봐도 납득할 수 있는 의사결정과정을 거치는 것도 아주 중요한 개발과정이라고 생각합니다.
- 바빠서 코드리뷰를 서로 완벽하게 하지 못했다고 다들 말씀하신 것으로 알고 있습니다. 물론 바쁘면 코드리뷰를 페어로 한명이 주도하여 설명하고 다른 사람들이 확인해주면서 라이브로 리뷰를 하는 경우도 있습니다. 하지만 이렇게 자주 하기보다는, 꼭 코드리뷰를 하는 시간을 일정에 포함해서 기간산정을 하셔야 한다고 생각합니다.
- 만약 코드리뷰를 계속 미루게 되는 여러분들을 보게 된다면, 무조건 매일매일 업무 시작을 할 때 코드리뷰를 무조건 끝내고서야 본인의 예정된 개발 업무를 하는 습관도 좋습니다. 실제로 많은 회사들이 이렇게 업무시작 자체를 코드리뷰로 시작하는 경우도 많습니다!
- 이렇게 다양한 시도를 해보면서 많은 경험하고 많은 감정을 가져보면 실제 업무를 하면서 유사한 상황을 맞닥드리게 될 때 도움이 될 것입니다.
배포
- 제가 아는 바로는 프로젝트시에 dev 브랜치를 기준으로 피쳐브랜치를 만들고 dev 브랜치에 계속 머지하는 방식으로 개발을 하셨습니다. 이렇게 dev 브랜치에 최종 결과물까지 개발 후 마지막에 main 브랜치에 머지 후 배포를 한번만 하게 되었을 것 같습니다.
- 이러한 방식도 나쁘지 않지만, 많은 경우 프론트앤드 개발은 CICD를 통해 하루에도 수 없이 많은 배포를 하기도 합니다.
- 배포가 필요하지 않은 경우에도 빠른 브랜치 전략을 위해 PR리뷰가 완료되면 기존 서비스에 영향을 끼치지 않는 코드의 경우 main에 언제든 바로 머지하기도 합니다.
- 지금은 여러분이 서로 긴밀하게 협업을 하면서 했기에 큰 이슈가 없었다고 생각하지만, 실제 업무에서는 그렇게까지 긴밀하게 싱크하거나 배려를 하지 않기에 바로바로 main에 머지하는 방식으로 개발을 진행했어도 좋을 것 같습니다.
- 즉, 이번에도 제가 누누이 말씀드렸듯 자주 main에 머지를 해서 vercel에 계속 배포해서 실제 웹에서 확인하고 모바일에서 확인하면서 기능을 개발했으면 좋은 경험이 되었을 수 있을 것 같습니다.
- 팀 3에서는 꼭 이러한 방식으로 시도를 해보시길 바랍니다!
협업
- 모든 분들이 협업에 이슈가 전혀(?) 없었다고 말씀해주셔서 멘토인 저로서도 참 신기하면서 뿌듯했습니다!
- 다행히? 매니저님 의도?에 맞게 다들 성향이 비슷하고 배려심 많은 분들이 프로젝트를 해서 그러지 않을까 싶습니다.
- 이렇게 두달짜리 프로젝트를 지금과 같이 진행했기에 아직까진 문제가 없었지 않을까 싶습니다. 여러분을 뭐라고 하는 건 아니고, 여러분이 이런 생각을 통해 어떠한 문제가 있었을까? 그렇다면 어떻게 해결을 해야했을까?를 생각해보실 수 있게 가정을 해보겠습니다.
- 여러분은 두달간 아무 이슈 없이 잘 협업을 했습니다. 지금과 같이 일을하고 지금과 같이 각자가 특정 역할을 할 것입니다. 이렇게 1년이 지납니다. 그리고 새로운 서비스를 이번에 늘 그렇듯 같은 팀으로 5명이 진행을 하려합니다. 여러분은 과연 이 1년이 지난 상태에서도 또 똑같이 이번 두달동안의 프로젝트와 같이 일을 하실 수 있을 것 같나요??
- 나의 역할이나 성장에 계속 도움이 되는 새로운 프로젝트가 될까요? 제가 하고 싶은 말은 지금은 짧은 호흡이고 모두 배우려는 목적으로 많은 배려를 했다고 생각합니다. 이제 성과를 측정하고 돈을 받고 일하는 프로젝트라고 생각한다면 여러분은 어땠을 것 같나요? 이렇게 한번 생각을 꼭 해보시길 바랍니다.
- 누구를 평가하고, 잘잘못을 지적하라는 느낌보다는, 그러한 상황에서도 지금과 같이 스무스한 팀플을 했다면 어땟을지? 내가 어떻게 행동을 하고 태도를 취하고 발언을 하고 개발을 했을지? 생각해보시면 좋겠습니다.
- 그리고 3팀에서 협업 시, 혹은 백앤드 학생들과 협업 시 지금과 같이 마냥 좋았던 협업이 안될 수 있습니다.
- 그렇다고 해서 왜 2팀은 이렇게 잘했는데 3팀은 왜 이렇게 못하지? 하면서 비교하거나 불평하거나 이슈만 꼬집어 내려하진 마시길 바랍니다.
- 항상 어떠한 경우에도 협업에 이슈는 생깁니다. 그러면 여러분이 해야할 것은, 2팀에서 좋았던 방식으로, 새롭게 겪게 될 협업 이슈를 해결할 방법은 없을지 고민을 하고 시도하고 주도하며 해결하셔야합니다.
- 또 새로운 사람과 협업을 하기 전에, 여러분이 선제적으로 좋았던 방식이나 규칙 아이디어를 먼저 새로운 팀원분들께 제안하면서 공유하고 시도할 수 있게 해보시길 바랍니다! 물론 그 좋았던 방식이 새로운 팀원에게 그대로 잘 적용되지 않을 수 있습니다. 이렇게 다양한 상황에서 다양한 경험을 하면서 이슈를 해결하며 협업을 많이 해보시면 좋을 것 같습니다! 화이팅!!ㅎㅎ
기타
- 꼭!!!!! 개인프로젝트를 해서 빈프로젝트에서부터 배포까지 한 사이클을 다 직접 해보시길 바랍니다.
- 개발을 잘하라는 말이 아니고, 여러분이 하신 FTA코드를 복사해서 가져올지라도 모든 하나하나의 의미있는 단위의 작업을 직접 다 해보고, 팀플에서 할 땐 잘 되었고 남이하는 거 볼 땐 쉬워보였는데? 왜 내가 직접하니 안되지?? 이런 경험을 하면서 이슈도 겪고 방법을 찾아보고 해결하면서 꼭 습득 하시길 바랍니다!
- 그 와중에 운이 좋으면, 아 2팀 팀플할 때 이렇게 했으면 더 좋았을 텐데 이런 느낌이 드는 포인트도 있을 수 있을 것 같습니다.
- 지금 여러분이 배포한 FTA는 얼마나 사용성이 있는지 꼭 알아보시길 바랍니다.
- 1명의 유저가 사용할지라도 정말 유저가 사용하기 좋은 서비스이고, 어려분이 해결하고자하는 문제를 잘 해결해주는 서비스인지도 판단해보시길 바랍니다.
- 만약 지금 서비스에 갑자치 10만명의 유저가 들어와서 글을 쓰고 댓글을 쓴다면 어떨까요? 그 많은 사람들이 입력하는 정보를 다 핸들링할 수 있는 사용성있는 서비스인가요?
- 지금 서비스 개발에서는 일정이 부족해서 못했지만, 사용성을 높이는 측면에서 꼭 다시 개선하고(혹은 추가) 싶은 기능은 무엇일까요? 왜 그런가요? 그게 어떤 의미를 갖죠? 왜 처음부터 고려하지 않았나요? 그 기능이 추가 되면 정말 사용성이 좋은 서비스일까요? 돈을 써서 마케팅을 돌리고, 지인들에게 써보라고 추천할 수 있는 서비스인가요? // 요런 질문들이 제가 자주 묻는 면접 질문들 입니다.
- 여러분 이제 4개월 지났습니다. 그런데 여러분 하나의 의미있는 서비스를 만들어 냈습니다.
- KDT 시작 전에는 본인이 이런 서비스를 만들 수 있을거라고 생각하셨나요?? 지금 공부할 건 많은데 실력향상이 안되고 있다고 느끼시면, 너무 조급해 하지마세요. 여러분은 4개월만에 서비스를 하나 만들어서 배포한 사람입니다. 이제 시작입니다. 이제부터 수 없이 많은 프로젝트를 개발하고 배포하시게 될 것이고 그 과정에서 생각하지 못한 테크닉, 기술, 학습을 하게 될 것 입니다. 앞으로 적어도 20년은 개발을 하게 될텐데, 그 20년 중에 4개월 공부하고 개발한 것입니다. 앞으로 남은 19년 8개월동안 계속해서 공부하고 경험하고 성장하시면 됩니다!! 과유불급입니다. 급하게 해서 체하지 마세요!
총평
- KDT 과정을 통해 본인이 조금이라도 성장을 했다고 느끼면 좋습니다. 만능으로 모든 부분에서 성장을 하는 건 아직 어렵습니다. 어떠한 부분이라도 의미있는 4개월을 보냈고 그 결과가 나의 성장에 도움이 되었다면 그것으로 충분합니다. 앞으로 남은 2개월간 또 새로운 성장을 하시면 됩니다.
- 성장 뿐만 아니라 좋은 동료를 얻고 좋은 정보를 얻고 좋은 대화를 하는 것도 중요합니다.
- 공부를 통한 개발적 성장 외에도 많은 것을 얻도록 노력하시길 바랍니다!