by
Jul 30. 2023
#9 기획 시 파악하지 못한 의존성
2023년 30주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/47
다음 회고 ☞ https://brunch.co.kr/@327roy/50
노트
#1 파악하지 못한 의존성
#기획자 #QA #기획검증 #검증
QA 진행 시, 개발 중인 기능과 의존성이 존재하지만 함께 개발되지 못하는 기능이 발견되곤 한다. 예를 들어 1) '데이터 A'와 '데이터 A의 값이 변경될 때 함께 값이 변경되어야 하는 데이터 B, C, D'가 있고, 2) 데이터 A의 처리 방법을 개선하는 기획을 했는데, 3) 데이터 B, C의 처리 방법까지는 고려했지만, 4) 데이터 D의 처리는 고려되지 않았다고 가정해 보자.
이때 개발이 진행될 때는 데이터 D의 처리가 누락되었다는 것이 바로 드러나지 않을 때가 많다. 그러면 언제 발견될까? 보통 앞단에서 누락된 사항은 기능 단위 테스트가 완료되고, 시나리오 검증을 진행할 때 발견된다. 결국 누락된 데이터 D의 처리를 부랴부랴 해야 하는 상황이 닥치고, 다음 백로그를 개발하고 있는 개발자에게 개발을 재요청하는 난감한 상황을 마주친다.
만약 데이터 D가 훨씬 많은 데이터나 기능들과 연결이 되어 있다면? 혹은 데이터 D를 구성하는 정책과 조치해야 하는 방향이 완전히 상반되는 것이라면? 기획을 놓친 것에 대한 부채가 당장 그 상황에 타파하기 힘든 이자를 가져올 수 있다.
최근에 나도 비슷한 상황을 겪은 적이 있다. 이직 후 2주 정도 될 때 급하게 인볼브되어 기획을 진행한 프로젝트에서 위와 같은 경우가 발생했는데, 기획 한 달쯤 뒤 개발이 완료 돼 검증하는 시점에 당시 기획 때는 놓친 데이터 처리 필요 사항이 발견되어 급하게 추가 개발을 요청할 수밖에 없었다. (다행히 치명적인 이슈는 아니었기에 유야무야 잘 넘어갔다.)
하지만 자칫하면 배포와 스프린트 일정이 뒤로 쭉 밀릴 수도 있는 좋지 않은 상황이었다. 따라서 위와 같은 상황이 웬만해서 발생하지 않도록 예방책이 필요하다.
아무리 점진적이고 반복적인 개발을 진행하며 부족한 부분은 후에 개선한다는 마인드셋을 가지고 있어도, 백로그를 분석하는 단계에서는 기존 기능들에 대한 의존성 파악이 더 꼼꼼하게 이루어져야 할 필요가 있다. 그래서 기획자를 위한 의존성 지도(Dependency Map)가 있으면 좋을 것이라는 생각을 한다.
방법을 러프하게 그려본다면 1) 모듈별로 중요한 데이터를 정의하고, 2) 해당 데이터가 포함된 화면을 캡처하여, 3) 이를 직접 매핑하는 방법이 있을 것이다. 가령 '상품 판매가 수정' 기능을 기획하는 것이하면, '상품 판매가 데이터'가 영향을 미치는 화면들이 연결된 의존성 지도를 먼저 확인하고 기획을 진행할 수 있을 듯하다. 결국 기획을 시작하기에 앞서 '의존성 분석'이라는 절차가 한 단계 더 추가되는 것이지만, 리스크 관리 차원에서는 시도해 볼 만한 가치가 있다고 생각한다.
일단 내 업무 영역에 있는 모듈 하나에 대한 전 화면 캡처는 완료해 놓은 상태여서 기회가 된다면 다음 기획 전에 이를 간단하게 매핑시키는 것을 생각하고 있다. 당연히 이는 기능을 계속 써보며 학습하고, 기획 전 분석을 꼼꼼히 할 수 있는 환경을 만드는 것도 병행되어야 할 것이다.
이 외에 어떤 방법이 있을까? 언젠가 논의의 주제로 다뤄볼 수 있으면 좋겠다.
#2 배포 작업 참여
#배포 #B2B #SaaS
금요일 오전 8시, 제품의 마이너 버전 배포와 검증을 무사히 완료했다. 원래는 이번 배포에 내가 기획을 맡았던 기능을 포함하려다 부득이하게 제외하기 되었는데, 이 때문에 해당 기능의 코드를 걷어내 롤백하는 작업을 진행했다.
이후에는 검증 시적! 배포 후에 메인 시나리오에 영향을 미친 사이드 이펙트가 있는지 확인하는데 검증의 주안점을 두었고, 다행히 별다른 문제는 발견되지 않았다. (대신 시나리오 진행 시 정책을 변경한 건이 2건 정도 있었다. 이는 패치/핫픽스로 배포할 예정)
현재 회사는 시맨틱 버저닝(Semantic Versioning) 규칙으로 제품의 버전을 관리하고 있다. (참고 링크)
검증을 보다 무난하게 진행할 수 있었던 이유는 저번 주를 기점으로 제품 표면에 보이는 기능들은 대부분 분석을 완료했기에 가능했다고 생각한다.
이번 배포에서 가장 큰 레슨런은 기획 검증을 QA가 아닌 기획자가 진행해야 하는 상황이라면 여유가 있을 때마다 제품 테스트 환경을 빠르게 세팅할 수 있는 방안을 마련해 둘 필요가 있다는 것이다. 예를 들어 현재 제품의 경우, 제품 내 엑셀 대량 업로드 기능이 존재하기 때문에 미리 파일을 케이스별로 엑셀 양식을 만들어두는 방법을 고려할 수 있을 것이다.
우리 제품의 재밌는 특징 중 하나는 배포 주기다. 제품의 특성상 우리 제품의 고객들도 주말에 쉬기 때문에 금요일 배포를 진행한다. 이전 회사와의 큰 차이점이다.
#3 1on1 meeting
#1on1 #meeting #1:1미팅
금요일 오후에 셀장님과 1:1 미팅을 진행했다. 입사 후 약 2개월이 되었기도 하고, 한 달에 한 번은 정기적으로 리더와 팔로워가 리뷰를 가지는 것이 우리 셀의 룰이기 때문이다.
나는 1:1 미팅의 목적을 좋아한다. 대부분 이런 정기 미팅은 팔로워의 1) 업무 몰입 방해 요소 파악 및 제거와 2) 멘탈 케어라는 목적으로써 일종의 리스크 관리를 의미하는데, 이 때문에 미팅의 분위기가 보통 부드럽게 진행되는 편이기 때문이다.
이번 미팅의 목적은 일종의 면담이었고, 미팅에서 셀장님과 업무, 회사 내/외부의 커리어 패스 등 많은 얘기를 나눴다. 셀장님은 업무를 진행하면서 당신의 명확하지 못한 부분에 대해서 많이 미안해하셨는데, 나를 많이 걱정해 주시는 모습에 되려 죄송하고 감사했다.
미팅에서 인상 깊었던 대화는 '어떤 기획자가 되고 싶은지'였다. 정확히는 1) 도메인 기획 테크닉에 대한 역량과 2) 제품의 방향을 설정하고 관리하는 역량 중 기획자로서 어떤 역량을 더 키우고 싶냐는 질문이었다. 둘 역량 모두 필수적이고 둘 다 뛰어나면 더할 나위 없이 좋지만, 모든 것에 집중한다는 게 현실적으로 힘들기 때문이다.
나는 '제품 관리 측면의 역량'에 비중을 더 많이 두고 싶다고 답변드렸다. 제품의 기능이나 프로세스가 더 뾰족해지고, 그것을 고객에게 더 명확하고 멋있게 전달하는 것도 좋지만, 제품의 가치가 보다 더 많은 사람들에게 도달하고, 행복을 줄 수 있는 방향으로 이해관계자들과 제품을 관리하고 싶기 때문이다. 물론 기획자로서 원인을 찾고, 구현할 방법을 찾는 공통적인 역량도 계속 발전시킬 필요가 있다.
나는 기획자/PM의 커리어 패스를 고민할 때 항상 '라비 메타의 레이더차트'를 참고한다.
미팅에서 '함께 일하고 싶다는 생각이 드는 사람'이라는 말을 들었다. 이런 인정들이 내가 일을 하는지에 이유 중 하나가 아닐까.
#4 정기적인 컨텐츠 발행과 오프라인 행사
#뉴스레터 #컨텐츠 #메일 #오프라인행사 #TRM
나는 배민, 무신사, 토스, 오늘의 집 등 많은 서비스들이 발행하는 블로그형 컨텐츠와 뉴스레터를 좋아한다. 글의 퀄리티가 높고 낮은 것을 떠나서 그들 서비스의 아이덴티티가 글에 잘 녹아져 있기 때문이다. (실제로 대부분 글 퀄리티도 높다.)
그래서 나 또한 '우리 제품 또한 블로그 컨텐츠를 발행하면 어떨까요?'와 같은 의견을 자주 내곤 한다. 다만 이를 꾸준히 리드하고 좋은 글을 쓸 수 있는 사람이 많지 않은 것이 더 적극적인 스탠스를 취하지 않는 이유기도 하다. 그러다 며칠 전 좋아하는 마케터분과 식사자리를 가지며 이와 관련된 얘기를 나눴다.
인상 깊었던 말은 서비스가 블로그와 같은 컨텐츠에 집중하는 것은 제품이 성숙했을 때 시너지가 좋고, 이 행위가 제품의 팬덤을 형성하고 신뢰를 쌓는 데는 좋지만, 매출적인 측면으로 봤을 때도 우리 회사의 제품의 경우 장기적으로도 매출에는 오프라인 행사가 영향을 더 미칠 것 같다는 말이었다.
실제로 자사의 메인 타깃은 B2B, 특히 인사담당자들인데 그들이 직접 데모 버전을 사용하고, 행사 혹은 박람회에서 피부로 체감하는 편이 우리가 이들의 리드를 확보할 때 더 효율적이었다. 아마 그런 이유 때문에 회사도 오프라인 행사를 자주 고려하는 듯하고. (단, 개인적인 생각으로 B2C 서비스는 다를 수 있다고 생각한다. 오프라인과 온라인 중 앱의 청중은 후자가 더 많고, 온라인에 의한 파급력이 더 강하기 때문이다. 예를 들어 무신사나 오늘의 집처럼 컨텐츠를 기반으로 성장한 플랫폼들을 말할 수 있을 듯하다.)
아마 B2B 서비스의 주기적인 컨텐츠 연재의 경우, 오히려 나 같은 사람이나 구인구직까지 생각 중인 사람에게 의미가 더 클 수도 있을 듯하다. 따라서 이런 컨텐츠를 운영하는 시기에는 컨텐츠 연재의 방향을 매출과 팬덤확보뿐 아니라, TRM을 함께 고려해 전략을 구성하는 것도 좋을 듯하다. (TRM: Talent Relationship Management)
#5 북 스터디: 에센셜 스크럼
#스터디 #애자일방법론 #스크럼 #에센셜스크럼
에센셜 스크럼회사에서 [에센셜 스크럼]이라는 책을 가지고 개발자들과 스터디를 진행 중이다. 스터디의 목적은 ‘애자일 방법론과 스크럼 프레임워크에 대해서 학습’하는 것이다.
[에센셜 스크럼] 책은 일종의 ‘애자일과 스크럼’을 실제로 어떻게 적용할 수 있을지에 대한 교보재라고 말할 수 있다. 책 이름처럼 애자일 방법론을 진행하기 위한 프레임워크인 ‘스크럼’에 대해서 상세하게 풀어쓴 책이며, 백로그 준비부터 스프린트의 마무리까지 스크럼 프레임워크의 모든 절차를 다루고 있다.
실제로 책에서는 각각의 프로세스들을 낱낱이 해부하여 내용을 기술하는데, 백로그 그루밍, 인수 조건, 입/출고 조건, 애자일 철학, 대기행렬과 지연비용 등 알아두면 좋은 개념들을 잘 설명한다.
단, 이 책을 읽으면서 조심해야 하는 것이 존재한다. 책에서는 스크럼의 비교 대상으로서 ‘단계별 개발 방식(e.g., 워터폴)’을 자주 언급하는데, 이 때문에 책을 읽고 나서 애자일에 매몰되는 사례가 꽤나 존재하기 때문이다. 예를 들어 "워터폴은 잘못됐어! 애자일은 옳아!"와 같은 케이스를 말할 수 있다.
이 때문에 이 책을 읽고, 스터디를 진행할 때는 항상 ‘정답은 없다.’는 것을 상기시키려고 노력한다.
스터디는 이와 같은 흐름으로 진행한다.
1. 준비
- 범위를 정해, 한 주 동안 개별로 책을 읽고 토론하고 싶은 어젠다 정리
2. 스터디 당일
1) 복기: 이번 회차에서 다룰 내용들을 가볍게 복기한다. 단, 만장일치로 복기를 스킵하고자 하는 경우 이 프로세스를 스킵할 수 있다.
2) 토론: 컨플루언스 문서에 회차별 주제의 내용 중에서 얘기하고 싶은 것을 누구나 편하게 어젠다에 작성한다. 보통 어젠다 1개에 10~15분 정도 얘기를 나누는 편이고, 어젠다와 함께 케이스스터디를 진행한다.
3) 스터디 회고
