에드윈 블로그

#테스트지원

오픈을 앞둔 프로젝트에 테스트 지원을 나왔다. 서비스 기획 팀원분들과 함께 테스트 지원을 나오며 짧은 온보딩 과정을 경험했다. 고객사 비즈니스와 함께 본 프로젝트의 목적에 대해 설명을 들었고 이후 각각 테스트를 담당할 모듈을 배정받아 스터디를 진행하고 있다. 그리고 스터디를 포함한 짧은 온보딩 과정에서 느낀 게 있다.

현상과 목적을 통한 합리적인 설명

이는 모듈을 배정받으며 느낀 점이다. 본인이 희망하는 모듈이 있었으나 모듈은 테스트 지원을 나온 팀원의 의사와 상관없이 이미 배정되어 있었다. 이에 대해 본인은 희망하는 모듈이 있어 리더에게 담당 모듈 교체를 제안했으나 결론은 배정받은 모듈을 유지한다였다. 비록 본인의 요청은 반영되지 않았지만 그럼에도 합리적이라는 생각이 들었다. 이는 리더가 왜 이렇게 배정될 수 밖에 없었는지에 대해 설명해주었기 때문이다. 그렇다면 나는 왜 그 설명이 합리적이라 느꼈을까? 리더는 본인에게 현재의 조직 구조와 더불어 본인의 의도를 설명했다. 조직 구조는 내가 이해한 바와 일치했고 리더가 설명한 본인의 의도 또한 내가 납득할만한 내용이었다. 조금 더 추상화해보자면 현상과 목적을 통해 의사결정을 설명했기에 설명이 합리적이라 느꼈고 그 결정에 수용하게 되었다.

기획자의 역량: 현상에 대한 이해와 전달력

스터디 과정에서 모르는 부분이 생기면 스스로 다른 문서를 찾아보기도 하지만 해당 모듈 담당자에게 묻기도 하고 있다. 이 과정에서 느낀 게 있다면 훌륭한 팀원이 있다는 건 축복이라는 것이다. 훌륭한 팀원 덕분에 배경과 문제 그리고 이를 해결하기 위한 기획적 의도를 한번에 배우고 있다. 한편으로 그러면서 든 생각은 '훌륭한 팀원이란 어떤 팀원일까?'라는 것이었다. 보다 정확히는 '훌륭한 서비스기획자란 어떤 걸까?'라는 것이었다.

설명을 듣다보면 고개를 끄덕이게 만드는 순간이 있다. 이번 프로젝트에서 느끼는 바로 이 끄덕임의 순간은 그 기획자만의 이해를 나 또한 이해했을 때라 할 수 있을 것 같다. 끄덕일 수 밖에 없는 설명을 해주던 기획자는 먼저 상황에 대해 충분히 이해하고 있었다. 단순히 "고객 요청사항"으로 끝나지 않고 고객이 왜 이걸 요청했는지를 이해하고 있었다. 뿐만 아니라 이해한 내용을 나 또한 이해할 수 있도록 설명해주었다. 이게 무슨 의미인가? 나는 프로젝트에 막 투입되어 해당 프로젝트에 대한 이해도가 많이 부족하다. 하지만 이런 나도 이해할 수 있도록 배경과 목적 그리고 기획적 의도를 명확하게 설명해주었다. 이런 훌륭한 팀원들 덕분에 기획자의 역량에 대해 생각해보게 되고 나아가 배움의 시간을 가지며 차츰 업무를 익혀가고 있다.

#세미나

이커머스 세미나에 다녀왔다.

이커머스 솔루션들의 강연을 들었다. 강연을 통해 느낀 건 솔루션은 단순 기능만 제공해선 안된다는 것이다. 타사 사례를 통해 습득한 노하우도 함께 전달하고 이를 통해 또 배우는, "고객사 운영 서포트-학습"의 루프를 만들어가고 있는 것이다. 이를 통해 솔루션만의 혜자를 만들어내는구나 생각이 들었다. 그리고 이렇게 때문에 데이터가 중요하구나라는 생각도 함께 들었다. 

회사 동료분들과 함께 다녀와서 후기를 뉴스레터 형식으로 그룹 전체 공유하기로 했는데 의미있는 인사이트를 전달할 수 있으면 한다.

#사이드프로젝트

구글 폼을 통해 설문을 만들었고 오픈채팅방과 SNS를 통해 설문을 받기 시작했다.

설문을 만들며

설문을 만들면서 느꼈던 건 설문을 하는 목적에 집중해야 설문을 비교적 쉽게 만들 수 있다는 점이다. 우리는 Lean Canvas 항목을 기반으로 제품을 정의했고 이에 대해 검증하기 위해 설문을 돌리기로 결정했다. 그러나 설문을 만들면서 질문에만 집중하게 되고 정작 질문을 던지는 원인은 흐릿해져갔다. 설문이 점차 산으로 가자 나는 좀더 심플하고 설문을 돌리는 목적에 집중하자 제안했다. 이를 통해 우리는 모든 것을 물을 순 없지만 필요한 걸 묻는 설문을 완성했다.

트렐로를 도입하기로 결정했다.

우리의 사이드프로젝트의 1차적 목표는 사람들이 사용하는 프로덕트를 만드는 것이지만 2차적 목표는 포트폴리오에 있다. 결국 커리어에 도움이 되어야 한다는 점인 것이다. 그래서 나는 다양한 제품관리자 공고에서 요구하고 있는 애자일 방식 적용을 검토해봤다.

가장 먼저 스크럼 방식을 검토했으나 현 상황에서 집중해야할 것은 "반복"이 아닌 "전진"에 있다고 판단했다. 제품도 없는 상태이고 아예 와이어프레임도 나온 상태가 아니었기 때문이다. 따라서 완료해야 다음 작업을 진행할 수 있는 칸반을 도입하기로 결정했다. 사실 트렐로라는 협업툴이 있기 떄문에 가능한 것이기도 했다. 트렐로 도입을 위해 간단하게 기능을 학습하고 이를 팀원과 공유하는 시간을 가지며 앞으로 해야할 일들에 대해 얘기를 나눴다.

적용을 검토하며 느낀 것은 프레임워크를 곧이 곧대로 도입하는 것은 이상적이지 않을 수 있다는 것이다. 첫번째 이유는 조직마다 구조가 다르기 때문이다. 두번째 이유는 프레임워크의 모든 세부 규칙까지 학습하는 게 불필요할 수 있기 때문이다. 이러한 이유로 프레임워크에서 우리 팀에 도입하기에 효과적이라는 부분만 도입하기로 결정했다. 바로 칸반보드와 스크럼의 스프린트 방식을 혼합하기로 한 것이다. 우리도 이 방식이 익숙치 않기에 이 프레임워크를 얼마나 잘 쓸 수 있을지 모르겠지만 그 과정 자체도 이번 프로젝트에서 의미가 있을 것이라 기대하고 있다.