동료를 위한 개발하기
아주 작은 바람아, 불어라
애드투페이퍼는
우리는 지난 5년 동안 “대학생의 생활을 풍요롭게!”라는 핵심 목표 아래 대학생 무료 프린팅 서비스 애드투페이퍼, 대학생 마이크로 크레딧 애딧페이, 대학교 교수님 평가 서비스 아이러브프로페서, 토익 공부 방법 모음 토익위키 등의 프로덕트를 “아주 바쁘게" 만들어왔습니다.
꽤 많은 프로덕트들을 만들면서 우리는 “대학생”을 위해 매 순간 최선을 다했다고 자부할 수 있습니다. 대학생이야말로 우리 프로덕트의 사용자이기 때문입니다.
아주 중요한 것을 잊고 있었습니다
지금까지 “아주 바쁘게” 일했기 때문일까요? 우리는 아주 중요한 것을 잊고 있었습니다.
“동료” 또한 우리 프로덕트의 사용자라는 것을 말입니다. “동료”를 위한 개발을 게을리하여, 그들의 업무가 점점 힘겨워지고 있다는 점을 말입니다.
멤버 S양의 사례
광고팀 멤버 S양은 문서 작업, 구글 애널리틱스, 인바운드 마케팅 등 여러 가지 일들을 꼼꼼하고 세심하게 완료할 줄 아는 유능한 멤버입니다.
이러한 다재다능함이 눈에 띄어 자신도 알게 모르게 다른 팀 리소스가 부족할 때 ‘도움을 주는’ 멤버가 되었습니다. 계속해서 도움을 주다 보니, 어느새, 운영팀의 일부 업무를 담당하게 되었습니다. 본인의 기존 광고팀 업무에 운영팀의 업무까지 말입니다.
멤버 S양은 불평불만을 속으로 삭이며 4개월을 보냈습니다. 그러는 동안 멤버 S양은 어떻게 되었을까요? 본인의 업무에 대한 혼란과 회사의 처우에 대한 불만, 펼치지 못한 자신의 능력. 멤버 S양의 속마음은 어땠을까요?
우리는 멤버 S양을 아끼기에, 멤버 S양을 돕기 위해 여러 가지 활동을 시작했습니다.
프로덕트를 바라보는 눈
가장 먼저 진행한 것은 멤버 S양의 CS(Customer Service, 고객 응대) 업무 부하 파악을 위한 간단한 인터뷰였습니다.
Q ) 하루에 얼마나 되는 CS를 처리하나요?
A ) 하루에 150건쯤의 CS를 처리합니다.
Q ) CS 하나를 처리하는데 시간이 얼마나 걸리나요?
A ) 한 건 처리에 2~5분쯤 소요됩니다.
Q ) 왜 해당에 대한 개선을 요청하지 않았나요?
A ) 요청은 몇 번이나 했지만 항상 다른 개발의 우선순위에 밀려서 개선되지 않았기 때문에, 포기하고 있었습니다.
짧게 오고 간 이야기였지만,
저로서는 매우 큰 두 가지 “깨달음"을 얻을 수 있었습니다.
첫째,
분명한 이유 없이 - 바쁘다, 돈이 안된다 - 등의 이유로 제안을 무시하는 행동이 계속된다면 해당 멤버는 더 이상 제안 활동을 하지 않을 것이다라는 점입니다. 그리고 이러한 멤버가 늘어나고, 늘어나게 된다면, 우리는 아이디어 없는 공간 속에서 하루하루 밥벌이나 하게 될고 말 것이라는 점입니다.
둘째,
하나의 프로덕트는 사실 하나로 이루어진 것이 아니다는 점입니다.
하나의 프로덕트는 두 개 이상의 프로덕트로 구성되어 있습니다.
[ 유저 프로덕트 ] : 유저가 실제로 사용하는 앱 등
[ 운영 프로덕트 ] : 유저 프로덕트를 운영하기 위한 시스템 등
[ 그 외 ] : 협력사, 서포터 등의 프로덕트가 있을 수 있다
"하나"의 프로덕트란 <유저>와 <운영> 프로덕트의 밸런스가 유지되고 있을 때의 "상태"를 말하는 것이 아닐까요?
지금까지 멤버 S양이 받고 있던 고통들은 우리가 프로덕트를 [ 유저 프로덕트 ]에 한정 지어 생각하고 있었기 때문에 발생한 문제라는 생각이 들었습니다.
만약 [ 운영 프로덕트 ]에 대한 관심과 개발과 관리를 [ 유저 프로덕트 ]의 30% 정도만으로라도 진행했다면 어땠을까요?
분명 개발팀이나 기획팀, 전략팀에서는 보통 [ 유저 프로덕트 ]만을 생각하는 경향, 혹은 그러할 수밖에 없는 상태에 이르게 됩니다.
그러나 누군가는 반드시 [ 운영 프로덕트 ]를 잊지 않아야만 합니다. 끊임없이 생각하고, 생각을 행동으로 옮겨야만 하는 것입니다.
이러한 작은 노력이 누군가에서, 누구나가 될 때, 우리의 프로덕트는 과연 어떤 모습일까요?
아주 가까이에서
다음으로 진행한 것은 멤버 S양의 CS 처리에 대한 세밀한 행동 관찰이었습니다. 멤버 S의 아주 가까이에서 실제 업무가 어떻게 진행되는지 파악하기로 했습니다.
<운영팀 멤버 S양의 행동 목록>
1. 지메일에 접속합니다.
2. 가장 오래된 CS메일부터 확인합니다.
3. 메일의 내용에서 아이디, 핸드폰 번호, 학교 등등 파악합니다.
4. 관리자 웹페이지에 접속합니다.
5. 관리자 아이디/비밀번호를 입력하고 로그인합니다.
6. 처리를 위한 관련 메뉴로 이동합니다. (비밀번호 변경 관련 CS라면 비밀번호 초기화 메뉴로 이동합니다)
7. 유저 아이디, 핸드폰 번호 등의 개인정보를 복사-붙여넣기 합니다.
8. 실제 처리를 진행합니다 (비밀번호 변경 관련 CS라면 비밀번호 초기화 처리를 합니다)
9. CS 처리 결과의 이메일 전송을 위해 이메일 보내기로 이동합니다.
10. 유저 이메일 주소를 복사-붙여넣기 합니다.
11. CS 처리 결과에 대하여 이메일을 내용을 복사-붙여넣기 합니다 (자세한 작성이 필요하다면 수동 작성합니다)
관찰한 11가지 과정은 다음 세 가지 큰 과정으로 나눌 수 있었고,
각각의 과정에 담긴 문제점과 해결책은 다음과 같았습니다.
1. 메일 읽기
문제점 : CS 메일이 CS 담당자의 입장이 아니라 개발자 입장의 문제 해결을 위해 디자인되었다.
해결책 : CS 메일을 CS 담당자의 활동에 맞춰 리디자인한다. 자주 사용하는 CS 메뉴는 메일 내에 직접 링크를 제공한다.
2. 관리자 메뉴에서 실제 처리하기
문제점 : 입력을 자동화할 수 있는데 복사-붙여넣기로 진행하고 있었다.
해결책 : CS 메일 내에서 링크를 누를 경우, 해당 정보들이 파라미터 값에 의해 자동 입력되도록 수정한다.
3. 처리 결과를 메일로 보내기
문제점 : 메일 자동 전송 기능을 사용하는 다른 부분이 있었나, 해당 부분에는 적용되지 않고 있었다.
해결책 : 메일 자동 전송 기능을 적용한다. 혹은 푸시 노티피케이션을 적용한다
*이 부분에 있어서는, 답변을 직접 입력하는 경우가 많이 있어 해당 글에 언급되지 않은 다른 사항들을 적용하기로 했습니다.
위의 글로는 꽤 오래 걸린 작업인 것처럼 느껴질 수 있습니다만, 문제점 파악과 단순하게 떠오르는 해결책들을 정리하는 데에는 채 10분이 걸리지 않았습니다.
곧바로 1번 사항과 2번 사항에 회사 차원에서의 개선 행동으로 이어지고, 결과물은 아래와 같습니다.
다른 모습으로
<개선 전>
<개선 후>
(겨우?!라고 비웃음을 살 수도 있겠습니다만... 아주 작은 바람에도 시원함은 담겨있습니다.)
이 외에도 운영 효율화를 위해 지메일의 실험실 기능 활용, 크롬 브라우저 익스텐션 활용 등을 제안해 적용하였습니다. 이 부분에 대하여서는 “댓글에 원하시는 분”이 다섯 분 이상이라면 별도의 글을 작성하도록 하겠습니다 (댓글! 제발!)
아주 작은 바람이 분다
[ 운영 프로덕트 ] 를 위한 첫 발걸음은 이렇게 마무리되었습니다.
최초의 인터뷰에서 2~5분 걸린다고 하였던 처리는 개선 후 간단한 CS의 경우 1분 미만으로 처리할 수 있게 되었다는 긍정을 확인할 수 있었습니다.
이 작은 개선 프로젝트의 시작은 <운영>을 위해서였습니다만, 운영 이외에도 좋아진 것들이 여러 가지 있습니다. 그중 가장 만족스러운 점은 아래와 같습니다.
멤버들이 작은 것으로도 큰 일을 할 수 있다 라는 것을 알게 되었다.
다른 팀의 고단함을 서로 이해하게 되자 팀 간의 교류가 많아졌다.
회사가 “개선되고 있다"라는 분위기가 조금씩 생성되고 퍼지고 있다.
바람은 어디에서 불어오는가?
애드투페이퍼는 매주 금요일 오후 1시에 “타운홀 미팅", “애바시 - 애드투페이퍼를 바꾸는 시간, 8분"을 통해 해당 주간의 여러 가지 프로젝트 성과 공유, 업무 효율화를 위한 팁, 자신의 여러 가지 생각들을 공유합니다.
우리는 “아주 작은 개선이 우리를 어떻게 바꾸는지”에 대한 이야기를 나누었습니다.
"지금까지는 바쁘다는 이유로, 우선순위가 아니라는 이유로 당연히 개선되어야 할 사항들이 개선되지 않고 있었습니다.
왜냐하면, 우리가 개선이라는 것을 문제의 근본적인 해결이라고 이해하고 있었기 때문입니다. 그러나 사실 개선이라는 것은 한 번에 완료되는 것도 아니고, 완료될 수 있는 것도 아닙니다. 무엇인가를 만들면 반드시 개선 사항이 생깁니다. 개선 사항을 개선해도 반드시 개선 사항이 생깁니다. 개선이라는 것은 끝에 있는 것이 아니고 과정 속에 있는 것이기 때문입니다.
메일 아래에 단순히 버튼을 달아주는 것만으로도 3분이 걸리던 일을 1분으로 줄일 수 있는 것입니다. 고작 3분에서 1분이라고 생각할 수 있겠지만, 하루 단위, 일주일 단위, 한 달 단위로 생각하면. 이 작은 개선이 얼마나 많은 것을 개선했는지 느낄 수 있을 것입니다.
지금까지 많은 분들이 개선 사항에 대해 제안을 주셨을 것이지만, 대부분 적용되지 않고 있었을 것입니다. 왜냐하면 그때는 내가 팀장이 아니었기 때문에! - 농담입니다 - 왜냐하면 그때는 유저만을 위하는 것이 회사를 위한 길이라고 생각했기 때문입니다! 지금도 그렇게 생각하는 면들이 있습니다만, 이번 ‘작은 개선'을 통해 우리는 더 좋은 회사, 더 좋은 애드 투 페이퍼로 발전할 것입니다.
그래도 역시, 힘든 일입니다. 그렇다고 안 하는 것은 아닙니다. 꼭 해야만 합니다. 여러분들에게 하나 부탁드린다면.
필요한 것 있으면 계속해서 말해주세요! 저도 바쁘고, 모두가 바쁘기 때문에, 잊을 수 있습니다. 하지만 계속해서 말해주시면, 오래 걸리더라도 꼭 잊지 않고 해드리겠습니다!"
* 같이 프로젝트를 진행해 준 멤버 “멤버 S - 신선명, 양희찬, 이현수” 님께 감사드립니다.
* 사실 저는 저렇게 멋있는 말 할 줄 모릅니다.
글쓴이, 문준영
문준영은 아주대학교 불어불문학과를 졸업하고 프로그래밍 책 출판사 면접에 떨어진 뒤 프로그래밍이란 무엇인가가 궁금해서 스타트업 개발자가 된 지 3년이 되었다. 프론트엔드 개발, 안드로이드 개발, 아이폰 개발을 책임지다 “아무래도 개발로 TOP을 찍기는 무리” 라고 판단해 최근에는 Technical Product Manager 라는 거창한 타이틀을 달고 동분서주하고 있다. 조직 개선, 인재 양성, 문과를 위한 프로그래밍 교육 등에 관심이 많으며, 페이스북 페이지 “그날그날 디자인, 그날그날 스타트업, 그날그날 프로그래밍”을 운영중이다.
