프로젝트

S-HOOK - 그토록 바라던 첫 팀 프로젝트의 시작 [Week1 ~ 2]

Creative_Lee 2023. 7. 13. 14:32

저의 우테코 자소서 내용중 이런 부분이 있습니다.

 

  우테코에서 동료들과 함께 흔들리지 않고 단단하게 성장하고 싶습니다.
제게 동료들과 함께 배울 수 있는 소중한 기회가 주어진다면,
이 글에 미처 담지 못한 열정 괴물 이도현의 성장을 우테코에서 꼭 보여드리겠습니다!

 

 

레벨 1, 2가 흘러 어느덧 레벨3.

드디어 그토록 바라던 팀 프로젝트를 진행하게 되었습니다...!!

 

우테코에서는 2주 단위로 *데모데이를 진행하는데요~!

앞으로 데모데이를 기준으로 프로젝트 주요 이슈와 피드백 사항에 대해 간략하게 정리하고 회고하려 합니다.

  

 

*데모 데이:  각 팀이 추구하는 목표와 방향성 공유하고, 피드백을 주고 받는 날


1. 'S-HOOK' 이 뭔데?

노래의 도입부만 듣고 취향이 아니라고 생각하여 놓친, 알고보면 좋은 노래들이 많습니다.
이런 노래들도 킬링파트만 들어볼 수 있었다면 어땠을까요?

Share의 약자인 'S'와 hook을 합쳐 S-HOOK!

사용자가 투표한 킬링파트(Hook)를 기반으로 노래를 공유하자! 라는 아이디어에서 시작한 프로젝트입니다.

 

고심 끝에 고른 서비스 명 'S-HOOK'


2. 주요 작업 내용

첫 2주 동안 진행한 주요 작업은 다음과 같습니다.

주로 팀원간의 생각 차이를 좁이는데 사용했네요!

 

  1. 사용자 스토리 맵핑
  2. 페르소나 정하기
  3. 컨벤션 및 브랜치 전략 
  4. 데모데이 발표

2-1. 사용자 스토리 맵핑

각자 다른 것을 상상한다.

우리는 보통 요구사항에 대한 부분을 문서화 하여 공유합니다.
빠르게 소통할 수 있지만, 같은 문서를 읽고도 서로 다른 것을 상상한다는 문제점이 있죠.
우리가 같은 것을 생각하지 않았음을 깨닫는 순간은
소프트웨어를 한참 개발하는 도중이거나 소프트웨어를 고객에게 전달한 후 입니다. 
이런 문제를 어떻게 해결할 수 있을까요?

 

사용자 스토리 맵핑 활동을 통해 위와 같은 문제를 해결해 볼 수 있습니다.(더 궁금하신 분들은 여기에서 확인하세요)

 

일전에 근로 워크샵에서 '사용자 스토리 맵핑'을 처음 접했었는데,

구성원 모두의 생각이 일치되는 경험이 너무 좋았어요.

팀원에게 사용자 스토리 맵핑 활동을 제안했고 흔쾌히 승락해 주었습니다.

 

스케치북에 진행한 스토리 맵핑

 

활동은 *작업(Task) 나열하기 👉 *활동(Activity) 구성하기 👉 *스토리(Story) 나열하기 순으로 진행했습니다.

초기 기획이 확실하지 않던 상태에서 진행해서 다소 시간이 걸리긴 했지만,

팀원 모두가 생각이 일치되어 가는 것에 만족했습니다.

 

 

*Task: 사용자가 제품을 사용하는 동안 필요한 모든 작업

*Activity: Task 중 조금 더 큰 단위로 묶을 수 있는 그룹

*Story: Activity를 달성하기 위해 고려해야하는 상황을 정리한 것


2-2. 페르소나 정하기

S-HOOK을 사용할 페르소나를 지정하고 시나리오를 도출해 보기도 했어요.

 

 

사용자 스토리 맵핑 활동과 더불어,

'무엇이 우리 서비스의 핵심 기능인가?' 를 도출하는 데 도움이 됐습니다.


2-3. 컨벤션 및 브랜치 전략

회의를 통해 팀내 PR 코드 리뷰 Rule과 각 파트별 코드 컨벤션 구성했어요.

 

코드리뷰 Rule은 최대한 팀원의 성장을 도모할 수 있는 방향으로 정했습니다.

코드 컨벤션은 과한 제약으로 생산성이 떨어지지 않도록 큰 틀 부터 정해보려고 노력했습니다.

 

또한 브랜치 전략에 대해 학습하고 나름의 이유를 가지고 flow를 정해봤어요.

Git flow 전략에서 release 브랜치를 제외한 흐름으로 가져가보기로 했는데요!

아직 개발 서버가 존재하지 않고 규모가 크지 않기에 제외하게 되었습니다.

추후 서비스의 규모가 커짐에 따라 개발 서버의 필요성을 느끼는 순간에 release 브랜치를 추가하기로 했습니다. 


3. 데모데이 및 피드백

그리고 드디어 1차 데모데이를 진행했습니다...!

좋은 피드백도 많이 받았어요~!

 

주요 피드백 사항을 정리하면 다음과 같습니다.

- 현재 배포한 상황이 없을 텐데, 조금 더 간소한 브랜치 전략을 가져가는 것은 어떨지?
- 주어진 기능에 맞춰서 페르소나를 맞춘 것은 아닌지?
- 아무도 이 파트를 지정하지 않으면 아무도 킬링파트를 들을 수 없는 것이다.
  초창기에는 노가다가 들어가야할 것 같고. 어느정도 정해지면 악의적인 사용자의 어뷰징을 막아야 할것 같다.
- 가능한 저작권 문제 없고, 노래를 들을 수 있으면서 구간을 지정할 수 있는 기능을 완료하는 것이 먼저.

 

현재 위 피드백을 바탕으로 브랜치 전략을 간소화 중에 있고, 페르소나 및 기획을 조정하고 있어요.

기초 공사를 조금 더 단단히 해야할 필요가 있다고 느꼈습니다.


4. Week1 ~ 2  돌아보기

아무래도 기획 관련된 내용으로 회의가 많기도 했고, 컨벤션 외 기타 여러 것들을 논의하느라
전반적으로 정말 바쁜 첫 사이클이었습니다.😅

 

본격적인 개발에 앞서 팀 문화를 비롯한 여러 규칙을 정하고 따르고 있는데,

실제 개발 단계에서도 이런 것들이 정말 잘 지켜지는지,얼마나 도움이 되는지 얼른 다음 사이클을 진행해 보고 싶네요!

 

반성해야 할 부분이 생각나는데요.
팀원과 페르소나 or 아이디어 회의 중에 '보통의 경우, 일반적인 경우'라는 말을 많이 사용한 것 같아요.
개인의 기준으로 전체를 판단한 경우가 생겨 조심해야겠다고 생각했습니다.

 

개발자는 코드를 짜는 직업이 아니라, 문제를 해결하는 직업이라는 것을 몸소 느낄 수 있었어요.

수 많은 기획과 서비스들은 결국 사람들이 겪고 있는 문제를 해결하기 위함이라는 거죠

앞으로의 개발 인생에서도 계속 되뇌이면 좋을 부분이라고 생각합니다.☝

 

 

이제 시작..!

Week 1~2 회고는 여기까지 입니다.

다음 사이클에 다시 만나요!