#3 스프린트, 기획, 리뷰

2023년 24주 차 회고

이전 회고 ☞ https://brunch.co.kr/@327roy/35 
다음 회고 ☞ https://brunch.co.kr/@327roy/39

노트

---

#1 아 리뷰 좋습니다.

#리뷰

빠르게 프로젝트 인볼브가 되는 입장에서 특정 기능 리뉴얼에 대한 기획을 요청받았고, 화면과 프로세스를 스케치한 것에 대해서 사수분과 리뷰를 가졌다.

일단 본인은 화면을 먼저 설계하는 것을 썩 좋아하지 않는다. 만약 구현하는 항목이 명확해서 화면의 플로우(혹은 인터랙션)과 UXUI만 고민하면 되는 부분이면 모르겠지만, 그렇지 않은 상황에서는 누락되거나 모종의 이유로 추가되는 항목이 발생할 때마다 화면의 수정사항이 생기기 때문이다.

그런 의미에서 이 리뷰가 좋았던 이유는 ‘메인 프로세스에 대해서 고민하고 세부 프로세스를 함께 점검한다는 점’이었다. 즉, 고려해야 할 상황을 먼저 상정하고 화면 작업에 들어가면 된다는 점. 화면 설계를 위해 일을 두 번 할 필요가 없어지기 때문.

결국 시간을 쓰는 행위가 시간을 오히려 시간을 아낄 수 있게 해주는 것. 리뷰를 하는 이유가 아닐까.

---

#2 컨셉 스케치와 개발 리뷰

#컨셉 #화면설계 #리뷰

저번 주 금요일(6/9)부터 제품이 제공하는 서비스 중 ‘리뷰’ 기능에 대한 모듈을 뜯어보기 시작했고, 화요일(6/13) 오전까지 프로세스에 대한 컨셉 화면을 스케치했다. 기존 플로우와 개선하고자 하는 플로우에 대한 형상을 사수 기획자 분과 먼저 공유했고, 큰 틀의 플로우는 사수님이, 그리고 관련되어 있는 화면 하나를 내가 맡아서 담당했다.

가장 집중했던 부분은 1) 화면별로 사용자에게 전달하고자 하는 메시지를 명확히 하는 것 그리고 2) 각 화면(프로세스) 간의 인터랙션을 매끄럽게 추가하는 것이었다. 두 번째는 UXUI에 더 집중했다고 한다면 첫 번째는 보다 상위 단의 기획(화면과 기능의 목적 등)에 가까웠다. 이를 하기 위해서 사용자의 입장에 몰입하고, 간단하게 육하원칙을 따라 화면의 요구사항을 풀어가며 사용자를 이해하려 했다.

아래는 이번에 분석한 자사 제품의 ‘자신이 작성해야 하는 리뷰를 확인하는 화면’에 대해서 육하원칙에 따라 간단하게 정리한 것이다. 본래 기획 공수에 여유가 더 있었다면 사용자 여정을 그리든지, 페르소나를 구체적으로 잡든지 할 텐데 이미 어느 정도 정책이 정의가 되어 있는 제품이기도 해서 굳이 그러진 않았다. 이번 작업이 가지는 의미는 온보딩도 있으니 빠르게 그들이 개선하고자 하는 의도를 파악하고 컨셉을 뽑아내는 것이 우선이기도 했기 때문.

※ 자사 서비스의 리뷰 기능은 자신이 달성한 성과, 자신의 성장에 대해서 본인 스스로 혹은 상급자에게 공유하고 리뷰하는 것을 의미한다.

화면의 요구사항은 아래와 같이 정리했다.

1. Who: 사용자는 누구를 리뷰해야 하는지 알 수 있다.

  • 리뷰대상자

  • 리뷰대상자가 본인인 경우, 아이디가 아니라 '본인' 등 직관적으로 확인 가능하도록 고려

2. When: 사용자는 언제까지 리뷰해야 하는지 알 수 있다.

  • 정기 리뷰의 경우 리뷰 주기가 전체적으로 동일할 터여서, 이 정보는 좌측 상단 1분기 정기리뷰에서 함께 제공을 하면 좋을 듯

3. Where: 사용자는 어디서 리뷰해야 하는지 알 수 있다.

  • 리뷰 화면으로 이동 가능한 직관적인 UIUX

4. What: 사용자는 무엇을 리뷰해야 하는지

  • 리뷰 유형: 성과 리뷰, 성장 리뷰

  • 리뷰 차수: 셀프 리뷰, 1차 리뷰 ..

5. How: 사용자는 어떻게 리뷰해야 하는지

  • 리뷰 화면으로 이동 가능한 직관적인 UIUX

6. Why: 사용자는 왜 리뷰해야 하는지

  • 랜딩(온보딩)과 교육으로 풀어야 할 듯

오전에 컨셉안을 스케치하고 사수분과 컨센서스를 맞춘 후 오후에 공수 추정 등을 위해 개발 담당자 및 개발 셀장 분들과 리뷰를 진행했고, 무사히 칭찬과 격려(?) 속에서 담당한 부분의 발표와 질의응답을 잘 마무리할 수 있었다.

다행히 해당 기능에 대해 플로우와 프로세스를 재정비하는 것에 대해 모두가 공감을 하고 있는 상태여서 설득의 과정이 짧았기에 내가 그린 그림이 그들에게 더 쉽게 침투할 수 있었던 것이라고 생각한다. 아마 사수님이 빌드업을 잘해놓으신 것도 이유가 될 듯하다.

그렇게 오늘의 과제는 종료. 본격적으로 내일부터는 상세 기획에 대한 프로젝트를 하나 간단하게 진행할 예정이다.

---

#3 힘 빼기

#무거운기획서 #가벼운기획서

이직한 곳에서 처음으로 진행한 상세 기획. 완성 후 사수분과 리뷰를 진행했고, 현재 상황에 맞춰서 기획서를 일부 수정한 후 개발셀장님들과 함께 리뷰를 진행하기로 했다. 기획서를 먼저 리뷰할 때 들었던 내용 중 기억에 남는 것은 “생각하는 것보다 협업하는 개발자 분들은 훨씬 능동적이에요. “라는 말.

개발자가 능동적이라는 것은 문서와 함께 현상과 흐름을 이해하고 더 좋은 방법을 찾아 개발하는 등.. 즉 개발서만 보고 개발하는 것이 아닌 보다 주도적인 개발자라고 생각한다. 이 경우에는 개발자들의 상상력과 자율성을 침해하지 않게 너무 디테일한 부분까지는 기획단에서 선을 지켜줘야 할 필요가 있다고 생각한다.

우선 사수분께서 한 말은 되게 적절했다고 생각한다. 그리고 어느 정도 의도가 된 것도 있었다. 이번 기획서에 상당히 힘을 많이 줬기 때문이다. 이번 기획서를 작성할 때 문서 작성의 영역에서 고민했던 것은 디자인 요소부터 개발과 관련된 부분까지 누락 없이 챙긴 ‘무거운 기획서'를 만들 것인지, 혹은 영역과 꼭 들어가야 할 항목, 프로세스 등만 정리하여 UXUI와 개발 방법은 각자 그들에게 맡기는 보다 ‘가벼운 기획서’를 만들 것인지였다.

각각 모두 장단점과 특징이 존재하는데, 자세한 것은 다른 글에서 풀어볼 예정.

---

#4 애자일 스토리

#애자일 #유저스토리

애자일 방법론을 공부하다 보면 ‘유저 스토리’라는 말을 자주 볼 수 있다.

유저 스토리는 요구 사항을 기술하는 방법으로, 제품이나 시스템을 사용하는 사람들의 관점에서 기능이나 요구 사항을 담은 짧은 설명문이다. 유저 스토리의 핵심 포인트는 ‘사용자에게 어떤 비즈니스 가치를 줄 수 있는가’다.

따라서 유저 스토리는 보통 ‘[누가] [비즈니스 가치]를 위해 [어떤 기능]을 한다.’라는 포맷으로 작성되는데, 스토리를 어떻게 작성하는지에 따라서 제품 증분의 개발 공수나 형상이 달라질 수 있다.

가령 ‘[사용자]는 [회원가입을 위해] [고객 이름, ID, 비밀번호를 입력]할 수 있다.’라는 유저 스토리를 작성했다고 가정해 보자. 명료한 유저 스토리다. 개발자는 이 유저 스토리를 보고 자신이 왜, 무엇을, 어떻게 개발해야 하는지를 생각할 수 있을 것이고, 기획자 또한 이를 기반으로 기획서를 만들 수 있을 것이다.

단, 주의해야 할 것은 [고객 이름, ID, 비밀번호]에 해당하는 [어떤 기능] 부분은 논의가 이루어짐에 따라 변경될 수 있다는 점이다. 예를 들어 보안을 위해 기능에 2단계 인증을 넣을 수도 있고, 보다 심리스한 경험을 위해 저 항목들을 입력받지 않고 간편 회원가입으로 대체할 수도 있을 것이다.

따라서 기능에 치우쳐져 유저 스토리와 기획을 풀게 되면 논의가 진행됨에 따라 기획단에서의 공수가 커질 수 있다. 그러므로 유저 스토리를 작성할 때는 ‘비즈니스 가치(Why)’에 주안점을 두고 작성해야 한다. 애자일에서는 고객과 사용자들에게 ‘비즈니스 가치’를 주는 것이 중요한 것임을 잊으면 안 된다.

-

애자일은 공부할수록 재밌다. 애자일에서 사용하는 프레임워크들에 매몰되면 속도가 오히려 디뎌질 수도 있겠지만, 애자일의 본질과 원리에 집중하면 어떻게든 조직 상황에 맞춰 우회하여 사용할 수 있을 듯하다. 이것이 훨씬 기민할 듯하고.

그런 의미에서 다음 주부터 애자일 스터디를 시작한다. 정확히는 애자일을 잘 진행하기 위한 ‘스크럼’이라는 방법론에 대해서 스터디를 할 예정이다. 함께할 책은 ‘에센셜 스크럼’. 따로 애자일 매거진을 만들어야겠다.

---

#5 스프린트 데모와 회고

#스프린트데모 #스프린트회고

스프린트 데모 데이를 가졌다. 이 스프린트 데모를 통해 개발된 산출물을 기획자, 개발자, 디자이너끼리만 공유하는 것이 아니라 제품에 관련되어 있는 다른 팀들에게도 공유하고, 데모 시연하는 것을 보여주며 제품의 이해관계자들에게 피드백, 질의, 격려를 받는다.

순서는 1) 구글미트로 데모 시연까지 하고, 2) 5분 정도 Miro를 통해 피드백, 질의, 격려 내용을 작성하는 시간을 가지는 형태로 진행된다.

내가 생각하는 스프린트 데모의 장점은 아래와 같다.

1. 구성원들에게 내용을 공유하고, 피드백을 받음으로써 개발 산출물과 깊게 관련된 사람들이 스프린트 동안 매몰된 시각에서 어느 정도 벗어날 수 있다.

2. 새로운 시각에서 접근해 오는 인사이트를 확인하며 제품의 방향과 품질을 점검할 수 있다.

처음에는 이런 시간에 차라리 다른 개발을 더 하는 것이 낫지 않을까라는 생각도 했지만, 생각해 보면 스프린트라는 이름 그대로 구성원들은 스프린트 동안 계속 달려왔기 때문에 시작과 종결을 찍어줄 필요가 있을 듯하다. 따라서 스프린트 데모는 일종의 스프린트를 종결하는 의례이자 구성원들이 내용을 공유하고 격려하고 격려받으며 한숨 돌리는 시간이 아닐까.

-

오전에 스프린트 데모가 종료된 후, 오후에는 스프린트 회고를 진행했다. 짤막하게 아이스브레이킹 후 KPT(Keep, Problem, Try)를 기준으로 회고를 진행했다.

좋았던 것, 개선되었으면 하는 것, 시도해 볼 만한 것들이 포스트잇에 적혀 하나둘씩 붙여지고, 그중 다음 스프린트의 액션 아이템으로 선정되는 것을 처음으로 지켜봤는데 기분이 묘했달까. 회고의 의미가 잘 살려지고 있는 듯하다. 부족했던 것을 함께 찾고, 개선해 나가면 앞으로 나아갈 수밖에 없으니까 말이다.

---

#6 기술부채

#기술부채

개발 산출물을 볼 때 ‘기술부채(Technical Debt)’에 대한 얘기를 나누곤 한다. 개발자들에게 기술부채란 소프트웨어 개발 과정에서 발생하는 여러 결정들로 인해 장기적으로 시스템이 복잡해지고 유지보수가 어려워지는 현상을 말한다.

마치 부채와 같이 단기적으로는 편리하거나 비용을 줄일 수 있으나, 장기적으로는 이자를 갚아야 하는 비용이 증가하는 것과 비슷한 맥락으로 사용된다.

보통 급박한 일정으로 개발 시 코드의 품질이 낮아지는 것이 기술부채를 발생시키는 보편적인 원인이다. IT 업계에 제품팀으로 있다 보면 개발팀들이 항상 코드 리팩토링에 대한 얘기를 하는 것을 볼 수 있을 텐데, 이러한 리팩토링(코드 안정화)은 결국 기술부채를 해결하기 위함이라고 생각하면 이해가 쉬울 것이다.

ⓒ 327roy