[우아한테크코스] LV3 - 1차 스프린트 회고

1차 스프린트에서 만난 문제상황과 해결책

소프트 스킬

• 데일리 미팅
  • 개인 일정 정리
    • 문제점 : 근로를 진행하는 크루들이 있어 workout 시간을 온전히 활용하기는 힘들다는 문제가 있었다.
    • 해결책 : 팀 전체적으로 진행하는 회의 및 일정을 중간에 흐름이 끊기지 않게 잘 조절할 수 있었다.

 

서비스 기획

• 회의 진행
  • 문제점 : 회의를 진행하다보면 원래 해결하기로 했던 안건에서 점점 벗어나는 경우가 발생했다.
  • 해결책 : 팀이 해결해야할 안건을 정하고 해당 안건을 얘기하는 회의 시간을 구체적으로 미리 정해두고 회의를 진행한다. 정해진 회의 시간이 지나면 원래 얘기하기로 했던 안건에 대해 잘 논의되었는지 확인한다. 또한 회의 중간에라도 처음 안건과는 주제가 멀어지게 된다면 즉시 브레이크를 걸고 회의를 시작했던 안건을 리마인드 하는 시간을 가지고 재개하는 방식을 채택했다.
• 오늘의 진행자
  • 문제점 : 팀 단위 의사결정이 이뤄져야 하는 상황에서 의견을 나누는 것은 좋으나 이를 통제하는 사람이 없어 회의 분위기가 늘어지는 상황이 발생했다. 또한 팀원 모두가 수평적인 분위기를 유지하다 보니 이제 결론을 내리자고 말을 꺼내는 것이 어려웠다.
  • 해결책 : 데일리 마스터를 정해서 그 날 회의의 전체적인 진행과 의사결정 시기를 결정하도록 권한을 부여했다. 이전처럼 결론을 내려야 하는 시점을 데일리 마스터가 선언하고 넘어갈 수 있도록 했다.
• 의사결정
  • 문제점 : 팀 내에서 다루는 모든 문제들을 해결하는 과정에서 반드시 모든 팀원의 의견이 수렴되어야 결정하는 의사결정 방식을 채택했다. 그 결과 정말 논의가 필요한 부분에 시간을 쏟지 못하고 상대적으로 중요도가 떨어지는 안건에 대해 논의가 너무 길어지는 문제가 발생했다.
  • 해결책 : 반드시 팀 전체의 의견이 하나로 수렴되지 않아도 되는 안건에 대해서는 일부 크루가 결정을 해오면 일단 그것을 따르면서 필요한 부분을 수정해나가는 방식으로 변경했다.

모디가 총대를 매줘서 Github 템플릿을 결정하는 회의에 드는 리소스를 아낄수 있었다. Thank You Modi 🙏

 

• 생각 동기화
  • 문제점 : 같은 안건에 대해 의견을 나누는 과정에서 서로가 하는 말을 이해하지 못하는 경우가 정말 빈번했다. 사용하는 단어의 정의, 서비스의 기능과 방향성, 머릿속에서 그리는 서비스 형태 등이 전부 달라서 발생했던 문제라고 판단되었다.
  • 해결책 : 서로 얘기하는 내용에서 괴리감이 느껴졌다고 판단되었을 때 의견 개진을 멈췄다. 이후 지금까지 나온 내용을 하나의 화면에 반드시 시각화하며 서로의 생각을 동기화하는 과정을 가지도록 했다. 또한 도메인 용어사전을 팀원들과 함께 정의하며 사용하는 용어의 정의를 재정립하는 시간을 가졌다. 해당 과정에서 동일한 기능 명세 문장에 대해서도 너무나 다르게 받아들일 수 있다는 것을 몸소 체험했다. 생각 동기화가 선행되지 않으면 너무나 쉽게 동상이몽이 될 수 있다는 것을 다시 한번 알게되었다.
• 액션 아이템 (하루스터디 Action Item Stack 바로가기)
  • 기획 회의를 진행하며 크고 작은 문제들을 만나고 해결했다. 하지만 기술적인 문제를 해결할 때와는 다르게 정량적인 수치로 해결 과정과 결과를 기록하기 힘들었기 때문에 이후 같은 문제를 효율적으로 해결할 수 있도록 간단한 액션 아이템을 선정하여 계속 쌓아나가는 것을 팀 문화로 선정했다.
  • 칭찬하기 :
    • 문제점 : 회의에서 서로의 의견을 반박하는 순간은 많은데 좋은 의견이 나왔을 때 이를 칭찬하는 순간은 거의 없었다. 이러한 분위기는 팀 내 자유로운 의견 표출에 부정적인 영향을 줬다.
    • 해결책 : 좋은 의견이 나왔을 때 주저하지 않고 칭찬할 수 있는 분위기를 유지할 수 있도록 엄지를 치켜세우는 액션 아이템을 선정. 자유로운 의견 표출을 위한 분위기 형성 뿐만 아니라 회의의 텐션도 업시켜줄 수 있는 기점이 되고 있다.
  • 잡담하기:
    • 문제점 : 서비스 기획 회의를 2주 내내 진행하다보니 아이디어를 생각해내는 데 매몰되어서 효율이 기하급수적으로 떨어지고 분위기도 엄청 다운됐었던 적이 있었다.
    • 해결책 : 개발과 아예 동떨어진 주제에 대해 아무 생각 없이 잡담을 하며 웃고 떠들다 보니 생각보다 분위기 환기 효과가 정말 좋았어서 액션 아이템으로 선정했다.

 

 

서비스 기획 플로우

페르소나 선정 및 유저 시나리오 작성 (정리 문서 바로가기)

 

본격적으로 서비스 기획을 시작하기 전 진행했었던 사용자 스토리 특강을 기반으로 페르소나를 선정하고 이를 기반으로 서비스 사용 유저 시나리오를 작성했다. 우리 팀은 첫날부터 서비스의 핵심 가치를 정하는 회의를 진행했었기에 어느 정도 미리 도출된 요구사항들이 있었다. 그래서 처음 페르소나를 정의할 때 무의식중에 미리 도출되었던 요구사항들을 반영하려다 보니 순수하게 사용자 입장에서 작성하지 못하는 문제가 발생했었다. 이를 인지한 후 기존 도출해냈던 요구사항을 완전히 지우고 순수하게 사용자가 우리 서비스를 사용한다면 어떻게 사용할지에 대해서만 생각하며 페르소나를 정의하도록 했다. 서비스 기획에 단계가 존재하는 것에는 이유가 다 있다는 것을 몸소 깨달을 수 있었던 경험이었다.

 

MVP 기능 명세서 (정리 문서 바로가기)

 

서비스 사용 유저 시나리오를 기반으로 MVP 기능 명세서를 뽑아냈다. 여기에서 MVP라는 용어를 처음 사용해보았다. 우리 팀은 MVP를 서비스 목적을 수행하는 정말 기초적인 플로우를 수행할 수 있도록 하는 기능이라고 생각하고 MVP 기능 명세서를 작성했었다. 하지만 회고를 작성하며 다시 찾아본 MVP의 뜻은 다음과 같았다.(레퍼런스)

 

 

MVP(Minimum Viable Product) : the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. - Eric ries

 

이를 해석하면, MVP는 팀이 최소한의 노력으로 최대한의 검증을 수행할 수 있도록 하는 버전의 새로운 제품을 얘기한다. 여기서 제품은 실제 개발된 프로토타입만을 얘기하는 것은 아니라고 한다. 핵심은 최소한의 노력으로 고객에 대한 가설을 최대한 검증할 수 있도록 하는 것이다. 그래서 극단적으로는 실제 개발된 프로덕트가 아니라 영상이나 PPT를 만드는 것도 MVP에 해당할 수 있다고 한다.

 

기존에 사용되던 MVP의 정의를 조금 다르게 내리고 사용하기는 했지만 정답은 없는 부분인지라 우리가 처음 생각했던 개념의 MVP를 그대로 가져가도 좋겠다는 생각을 했다. 하지만 우리가 도출해낸 MVP가 정말 MVP인지? 그리고 그 MVP가 정말 중요한건지? 왜 중요한건지? 와 같은 질문들에 대해 고민을 많이 했다고 생각했다. 후술하겠지만 데모데이에서 코치님들의 피드백을 듣다보니 정말 최소한의 기능들만을 명세했는지에 대해 다시 고민해봐야겠다는 생각을 하게 되었다. 결과적으로 얘기하면 기존 정의되어 있던 MVP 기능들을 더 쳐내고 축소해서 개발을 진행하게 될 예정이다.

 

 

데모데이 피드백

데모데이는 6개의 프로젝트 그룹이 한데 모여서 발표를 진행하는 형식으로 진행되었다. 이 때 공통적으로 받은 피드백들을 종합하고 다음 스프린트 때 반영하기 위해 정리해보았다.

 

 

“이러한 서비스가 유용할 것이다.” 라는 생각에 대해 실 사용자 데이터를 기반으로 근거 제시가 아직 부족한 듯하다. 어떻게든 구인해서 피드백을 최대한 빨리 구해보는 것이 좋을 것 같다.

 

⇒ 우리 팀의 서비스 핵심 도메인은 스터디이다. 우테코 특성 상 지금까지 스터디를 진행해왔던 크루들이 주변에 정말 많기에 실제 사용자를 구인하는 건 어렵지 않을 것 같다. 하지만 1차 데모데이 기간에서는 실제 사용자를 인터뷰하지 못하고 팀 안에서만 도출된 추측으로 모든 기획을 완성했다. 이 때문에 좀 더 뾰족한 서비스 핵심가치를 1차 데모데이 결과물에서 제시하지 못했던 것 같다. 2차 데모데이에서는 서비스에 필요한 최소한의 공통 기능들을 개발하면서 실제 사용자 데이터를 수집하는데 집중하는 방향으로 나아가게 될 것 같다.

현재 생각하고 있는 방법은 하루스터디 팀이 직접 스터디를 진행해보며 어떤 점들이 진짜 불편한지 찾아보는 것이다. 필요하다면 주변 크루들을 붙잡고 설문조사도 충분히 진행할 수 있을 거라 생각한다. 이를 기반으로 서비스 최소 기능 구현 이후 방향성과 우선순위를 더 구체화시키고자 한다.

 

 

 

기존에 존재하는 커뮤니티나 플랫폼에서 이 문제를 왜 해결하고 있지 못하는지를 파악해보는게 좋을 것 같다.

 

⇒ 기존 스터디 플랫폼을 사용하는 사용자들은 일반적으로 긴 기간에 걸친 스터디 공고가 주로 올라오기 때문에 섣부르게 참여하기 꺼려진다는 문제점을 겪고 있다고 판단했다. 이에 하루스터디에서 제공하고자 하는 핵심 가치는 짧고 빠른 스터디를 통해 효능감을 극대화하는 것이다. 하지만 이는 실제 스터디 플랫폼을 사용하는 사람들을 대상으로 인터뷰해 도출해낸 것은 아니었다. 위에서 언급했던대로 우리가 직접 진행한 스터디 데이터 + 실사용자 설문을 통해 데이터를 수집하고 방향성과 우선순위를 구체화할 것이다.

 

 

서비스 주 타겟이 스터디를 빠르고 짧게 하고 싶은 사람이다.그런데 스터디를 진행한 사람이 이 가치를 얻었다고 생각할 수 있는 수단이 무엇인가? (=어디서 효능감을 얻을 수 있는가?)

 

⇒ 준이 제공해준 스터디 템플릿을 이용해 우리가 직접 스터디를 운영해보는 것으로 결정. 이후 해당 경험을 기반으로 문제점과 서비스 핵심 가치(스터디 효능감을 얻을 수 있는 포인트)를 더 구체화할 예정이다.

 

 

팀 그라운드 룰이 9개인데 각각 구체적으로 정해진 것 같다. 우리가 직접 정한 룰인데 어떻게 앞으로 지켜나갈 것인지 구체적인 고민을 해보면 좋겠다. 개수가 많아서 이를 계속 가져갈 수 있는 방법이 필요할 것 같다.

 

⇒ 기존에 쌓아왔던 액션 아이템 스택을 이용한다. 아직까지는 잘 지켜지고 있는데 이후 실제 효력이 떨어진다고 판단되면 그 때 논의를 해보면 될 것이다.

 

 

현재 MVP 뽑은게 일정 안에 수행하는게 불가능할 것 같다.

 

⇒ 일정 재추산이 반드시 필요하다. 기존에 도출해낸 MVP 기능을 재검토 후 서비스 핵심 가치 제공에 필요한 최소 기능이 아닌 것들을 더 쳐내고 2차 스프린트를 진행하는 것으로 결정했다.

 

 

서비스 핵심가치 및 최소 기능 도출을 위해 다시 고려해봄직한 사항들

• 스터디 모집에 어려움을 겪고 있는게 맞는지, 작은 단위로 스터디하는 방법이나 문화를 모르는게 더 큰 문제가 아닐까
• 스터디를 어떻게 하면 작은 단위 스터디를 똑똑하게 할 수 있을까
• 모집은 너무 할 수 있는 방법이 많은데 문제 인지가 다시 필요할 것 같다.
• 하루만 스터디 했을 때 만족스러운 경험이 언제였는지 생각해봐야 할 것 같다.
• 스터디를 스낵 컨텐츠처럼 쉽고 빠르게 시작하도록 진입장벽을 낮추고 효능감을 빠르게 느낄 수 있도록 하는 방안을 생각해보면 어떨까.
• 이를 예상 소요 시간을 정해서 기능적으로 제한할 것인지, 아니면 스터디의 진행량과 같은 정량적인 수치로 제한할 것인지 등을 고려해줬으면 좋겠다.
• 이 스터디가 끝난 뒤에 예상 상태를 제시하도록 하는 것이 효능감 향상에 긍정적일 것 같다.

 

회고 마무리

2주밖에 안되는 기간이었지만 서비스 기획을 다같이 진행하는 과정에서 정말 많은 문제들을 겪었고 이를 어떻게 효율적으로 해결하기 위해 몰두했던 1차 스프린트 기간이었다. 2차 스프린트 기간에는 개발을 바로 들어가는 것을 팀 모두가 희망했지만 너무 마음만 급했던 것은 아닌지 다시 한 번 되돌아 보게 되었다. 개인적인 관점에서 긍정적으로 생각하는 것은 최소 기능 명세에서 더하는 것보다는 뺄 것이 더 많다고 예상된다는 것이다.

 

이번 1차 데모데이 이후 "우리가 2주동안 해왔던 기획이 많이 흔들리면 어떡하지?"라는 생각 때문에 들었던 불안감이 조급함으로 이어졌던 것 같다. 하지만 모호함에서 벗어나 다시 문제를 정확하게 정의하면 해결될 것이라 믿어 의심치 않는다. 모쪼록 하루스터디 팀원들과 흔들리지 않고 처음의 열정 그대로 프로젝트를 이어나갔으면 하는 바람이다.