*4L + KPT회고방식입니다.
데이터플랫폼을 기획하다 이직 후 커머스로 도메인을 변경했다.
이직 후 1년에 대한 회고이다.
Learned(배운 점)
- 커머스 서비스의 전반적인 프로세스를 이해하게 되었다.
팀 내 서비스기획자가 적었던 점은 나에게 긍정적인 영향도 주었다.
상품+주문+결제+클레임+검색+데이터까지 두루두루 다뤄야하는 환경이기 때문이다.
커머스의 이해가 높지 않았기에 주문이나 결제 등 한 도메인만을 담당했다면 커머스의 전체 프로세스를 그릴 수 없었을거 같다.
입사초에는 검색 위주로 했지만 현재는 주문/결제/클레임의 이슈를 주로 담당하고 있다.
덕분에 복잡한 커머스의 뒷단 Flow와 각 단계별 상태값에 대해서도 알게되었다.
비즈니스 특성 상 멀티 사이트 구조이기에 백단의 시스템이 훨씬 복잡하다.
하나의 상품이라도 유저가 어떤 조건이냐에 따라 노출이 달라지다보니 이런부분이 꼬이지 않게 탐색-주문 단에서 신경을 써야했다.
커머스 유저의 전체 플로우를 다 경험해본 기획자는 많이 않을 듯하다.
나는 대신 경험의 범위가 넓은 대신 1개 도메인만 맡는 분들보다 깊이가 얕을 수 있다는 단점이 있다. 이부분을 극복해야한다. - IT업계의 생태계를 알게 되었다.
기존에는 B2B였고, 내부 프로덕트를 많이 다뤘다보니 대외적인 IT 생태계에 대해서 크게 관심을 두지 않았다. (우물안 개구리..ㅠ)
이직 후 내가 속한 곳은 인하우스였고, 리뉴얼 프로젝트에 참여하면서 대기업 SI와 에이전시, 운영사, 인하우스 등 각각의 역할에 대해 피튀기는 스프린트와 미팅을 통해 이해하게 되었다. 또 인하우스 기획자의 역할과 소통 시 취해야할 태도에 대해서도 알아가고 있다.
초반에는 화면만 그리지 않았지 SI에서 할 영역(엣지케이스 방어안, 로직 작성 등)까지 내가 하고있었다. 그러다보니 책임소지가 애매해진다는 걸 깨달았다. 그리고 나는 요건을 정확하게 주고 비즈니스에 필요한 정책을 잡아주는 방향으로 조금씩 바꿔갔다.
이런식으로 내가 어디에 속하냐에따라 기획자가 할 일이 달라진다는 것 또한 배웠다. - 모든 서비스는 법의 테두리 안에 있어야한다.
법적 리스크에 굉장히x10 예민한 곳이었다. 정보보호의 좁디좁은 통과 범위를 맞추기 위해 관련 법령과 서비스에 반드시 필요한 이유에 대해 확실히 이해하고 있어야했다.
기존에는 내부 플랫폼을 담당했고, b2b 였기에 노출되는 리스크 종류가 많지 않았다.
커머스는... 신경써야하는 리스크가 훨씬 많고, 관련 법령 또한 많았다. 그리고 설명이..너무 애매모호했다.
23년 대응했던 법령은 1. 휴면회원 해지, 2.모바일 접근성 이었다.
1. 정보보호와 법무팀에 우리 서비스에 왜 이런 기능이 필요한지 설득력있는 설명이 필요했고,
2. 비즈니스 요건에 부합하면서 법령에도 저촉되지 않는 기획수정이 필요했으며,
3. 이를 빠르게 보고할 줄 알아야한다. - 목적과 next를 고려한 소통법
내가 잊지말아야할 것 중 하나가 이곳은 it회사가 아니라는 점이다.
MD, CS, 영업, 마케팅 등 여러 사업부의 담당자들과 소통을 하다보니 그들의 눈높이에 맞는 설명이 필요하다는 걸 느꼈다.
내가 사용하는 "서비스"라는 단어와 MD가 사용하는 "서비스"라는 단어의 의미가 다르다는 것,
DB, 배치 등 이런 용어에 대해 그들은 모를 수 있다는 것, 그들 머리속의 플랫폼의 범주와 내 머릿속의 플랫폼 범주의 차이가 크다는 것을... 잊지 말아야한다.
그렇지 않으면 서로 딴이야기를 하다 미팅이 끝나버리던가, 이해를 맞추는데 2주 이상 소요된다... 시간이 생명인 프로젝트에서는...엄청 고통적인 부분이다.
그리고...임원이 디테일을 요구하더라도 실무와 같은 디테일을 보고해선 안된다.
(그렇지 않으면 보고의 늪에 빠지게 되거나, 다신 보고를 못하게 되거나...)
누구와 무엇을 소통하냐에 따라 나의 태도는 달라져야한다. 잊지말자.
Lacked(아쉬운 점, 부족한 점)
- 데이터에서 프로덕트 문제점을 찾고 해결안을 도출하는 것
사이트 리뉴얼 프로젝트가 23년 주요 과제였다. 그렇다보니 구축에 몰두했고 분석에 소홀했다.
이제 새로운 시스템에서의 운영이 본격적으로 시작되고있다.
커머스의 최종 목표인 상품을 많이 판매하기 위해 우리 서비스는 어떤 부분을 개선해야할까?
데이터 설계와 태깅을 담당했지만 데이터 분석에 집중할 기회가 많지 않았다.
이젠 분석을 통해 문제점을 찾고 설득해보자... - 비즈니스 관점에서 서비스를 분석하지 못한 것
b2b2c 형태의 비즈니스라는 점 그리고 이 사업을 둘러싸고 있는 환경들을 살피지 못했다.
지금까지 주된 관점은 사용자가 불편함없이 쇼핑할 수 있을까? 였다면,
이젠 어떻게 하면 구매를 많이 일으킬수 있을까의 관점으로 서비스를 분석해야한다.
오픈마켓보다 당연히 우리 서비스는 불편한 요소가 많을 수 밖에 없다. 그럼에도 우리 서비스에서 구매를 꾸준히하는 헤비유저들이 있다. 헤비유저들이 꾸준히 구매를 이어가는 이유는 뭘까?
타 커머스에서 한다고 우리도 해야하는 게 아니라. 우리 비즈니스 성장에 필요한 것인가?가 중요한 것이다. - 커머스에 대한 이해
정산 방식(배송완료 or 구매확정), 이익률/마진률, 프로모션의 성격(장바구니, 상품 등) 등 커머스 세계는 까면깔수록 배워야할 게 많다.
이건 시스템, 플랫폼에 대한 이해보다는 커머스 전반에 대한 이해이다.
어떤 가격이 사용자에게 노출되어야하는지 기획하려면 판매가/프로모션가/정상가 등 하나의 상품이 가지는 여러 가격에 대해...이해해야한다.
MD분들의 업무, 마케터들의 업무를 멀리서 관찰하고 그들에게 도움을 구해보자... 적어도 나보다는 커머스 경력자들이다. - 연속성 있는 업무를 추진해보기. (프로젝트 성)
리뉴얼 프로젝트가 끝이나고 운영의 비중이 커지면서 연속성을 지닌 업무가 줄고있다. 버그와 이슈들만 찾고 해결해가는 중이다.
내년에 프로젝트까지 아니더라도, 내가 직접 정책과 설계를 하고 그게 어떤 결과로 이어졌는지를 살피는 업무까지 해보고 싶다.
이런 기회가 주어질 가능성은 낮다. 내가 기회를 만들어보자. 만든다면 적어도 자료라도 남기자..!
Keep(유지하고 싶은 것)
- 백엔드에 대한 집착
앞으로 기획자는 화면을 그릴 일이 없어질 거라 예상한다. 그래서 비즈니스 정책과 이를 반영한 백단 설계의 비중이 많아질 듯하다.
그래서 백엔드기획에 많이 집착했었다. 수행사가 정리해논 로직플로우와 erd를 시간이 날때마다 살폈다.
덕분에 현금영수증 등 front보다 백단이 중요한 설계를 혼자 진행할 수 있었고, 개발자를 설득시킬 수 있었다.
하도 살펴본 탓에 개발자보다 더 많이 알게되었다. (직접 개발한 개발자가 아니라서 가능했을 수도..)
그리고 개인적으로 커머스는 백단이 중요하다고 생각한다. 그래서 백단의 구조를 많이 익히고 고쳐보자.
올해는 구매전환에 대한 챌린지가 많을 듯하지만... 그래도 백엔드 기획에 대한 집착을 유지하며 학습하고 활용하자. - 데이터에 대한 집착
데이터분석 툴을 어쩌다보니 팀 내에서 내가 가장 많이 알게 되었다...(마케팅에서 자기네들은 숫자를 안본다나..머라나..-_-)
리뉴얼 당시 데이터 기획을 내가 마두잡고 진행한 탓에...어영부영 운영업무까지 이어지고있다.
태깅이슈도 찾고, 분석 리포트도 만들고, db와 연동도 시키고... (분석은 못하고..ㅠㅠㅠㅠ)
그래도 데이터 분석 툴을 다루는 덕분에 db 접근 권한과 sql을 할 수 있게 되었다.. 얼마나 다행인가..!!!!
sql을 업무에 활용할 수 없어 아쉬웠는데 이렇게 기회를 만들었다. 덕분에 sql을 까먹지않을 정도가 되었다..!!!!
24년에도 데이터에 대한 집착을 유지하자. 그리고 분석에 대한 집착을 키워보자..!! - 설계에 대한 집착
리뉴얼때는 수행사의 기획자들이 기획한 내용을 검토하는 업무가 많앗다.
앞으로는 직접 로직을 설계하는 역할을 많이 해보고 싶다. 최근에 회원쪽 sso 연동을 위해 설계서를 작성하는데
왜그렇게 재밌던지... 현금영수증 flow를 짜는 것도 왜그르케 재미가 있던지...ㅠ
아직 나는 설계를 많이 해봐야하는 단계이다. 그래야 비즈니스 정책도 새롭게 잡아보고 이를 설계에도 녹여본다..!
없다면... 역기획을 해보거나 조금이라도 필요하다면 설계를 만들어랑~!
Try(구체적인 시도 내용)
- 설계서를 만들기
버그나 이슈 개선에도 무조건 설게서를 만들자. 나를 위해서.
현재 하고 있는 상품 노출 제어 조건 개선도... 복잡하게 얽힌게 많다보니 테스트 케이스를 정리하면서 구조를 이해하게 되었다.
손으로 그려보고 자료로 만들어야 이해도가 높아지다보니 조금이라도 복잡하다 싶으면 설계서를 만들어 보자.
상품 노출 제어 조건에 대한 이슈를... 개발자와 유선으로 소통하기 어려웠던 것도 눈에 보이는 자료가 없었기때문..!!
소통을 위해, 나의 이해를 높이기위해 간단하게라도 설계서 작성해보기 - 매주 월요일 데이터 살피기
매주 화요일에 주간 회의가 있으니 월요일에 전주에 대한 데이터를 살펴보기로하자.
구매력을 높이기 위한 서비스 개선 점을 찾기 위해!
그리고 조금씩 정리 해두자. 이게 왜 문제라 보여지는지...!
회고에 대한 회고
일년간의 업무를 회고하려니 양이 많을 거라 생각했다. 그러다보니 회고글에 포함할 내용만 자꾸 생각만 했다.
글을 쓰는 건 미루고 미뤘다.
장기간에 대한 회고는 조금씩 나눠해야겟다. 하루는 learn, 하루는 keep 등 주제별로 나눠 작성 기간을 정해두어야겠다.
내게 필요한 회고를 위해 회고 방식을 결합한 건 잘한거같다.
굳이 정해지 틀안에서 회고를 해야하는 건 아니니까.
반응형