brunch

매거진 보통의 서비스기획 PO 이야기

라이킷 80 댓글 6

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 도그냥 Apr 10. 2022

지랄하는 것이 일 잘하는 줄 아는 사람

서로의 전문성을 인정하고, 협업자의 판단을 믿어주세요.

몇 년 전, 사이트를 신규로 만드는 대형 프로젝트를 위해서 요구사항을 정리하고 있을 때의 이야기다.

지금 말할 때마다 안된다는 이야기만 듣고 있어요.
그래서 이 기능이 왜 필요한지 이야기 하는 거잖아요

누가 봐도 언짢아보이는 그녀는 미간을 잔뜩 찌푸리며 계속해서 자신의 말만 이어나갔다. 언뜻 들어서 다른 말 같지만 사실 내용은 사실 계속해서 같은 말이었다. '필요해' - '개발해줘' - '지금 당장'의 무한 반복. 언뜻 들어보면 그녀의 말은 틀린 말이 하나도 없다. 이러이러한 기능이 다른 회사에는 대부분 있고, 우리도 그걸 쓸 계획이 있으며 몹시 중요하다는 이야기다.

그런데 프로덕트를 만드는 팀인 나의 입장에서는 듣는 내내 복부 어딘가가 간질간질했었다.

"고객들은 이런 UI를 더 편하게 느끼고요. 이런 UX가 있어야 더 효과적이고요"

아직 오픈하지도 않은 서비스에 대해서 이러쿵 저러쿵 말하는 이야기들은 고개를 끄덕이면서도, 마음 한구석 계속해서 의문점이 고개를 들기 시작한다.

'아직 오픈도 안한 서비스에 고객이 어딨어요? 우리 서비스 오픈하면 그렇게 한다는 보장이 있어요?'

목구멍까지 올라오던 그 문장을 목구멍으로 다시 꿀떡 삼켰다. 이 일을 직접 하지 않는 사람들에게 이런 이야기는 그냥 흠집 잡기로 보일 뿐, '하기 싫다'는 말의 다른 문장으로 들릴 뿐이기 때문이다. 하지만 이런 질문을 하며 마음에 돌덩이가 들어앉아도 결국 고개를 저으며 들어라도 주는 이유는 그래도 요청자가 옳을 수도 있다는 일말의 가능성 때문이다. 동의하진 않지만 똑같은 인간이 되고 싶지는 않다.

너도 나도 오픈하지도 않은 서비스의 사용자는 확신할 수 없다.

이 불편함의 끝에는 요청하는 사람의 주장의 근거가 없다는 것에 있다. '타사의 서비스'의 사용자는 우리의 사용자가 아니고, 그러기에 서비스는 실험과 그 결과를 확인하는 끝없는 여정으로 이어진다. 수많은 요구사항들을 다 반영해서 이 세상의 모든 조합이 다 가능한 프로모션 기능을 직접 운영해봤지만, 실제 사용을 한번도 하지 않거나 나중에 현업에서 그 기능이 있는지조차 모르는 조합이나 기능들도 남기 마련이었다. 물론 딱 한번 개발하여 사용하는 경우도 있지만, 그런 개발들이 결국은 사이트의 복잡도를 올려서 나중에 정말 중요한 기능들을 만들지 못하게 하는 '레거시'가 되어 작용하는 경우를 꼭 보았다.

그런데 이제 막 요구사항을 만드는 시점에 '만들어 달라'의 근거가 몹시 부족하고, 그냥 스스로가 고객이라고 생각할 때의 막연한 추정일 때 설득력은 솔직히 높을 수가 없다. 서비스의 복잡도를 높이지 않고 조금이라도 나중에 정말 필요한 것을 집중적으로 개발할 수 있도록 만들려면 서비스는 가벼워야 한다. 그리고 가장 많이 사용할 기능들의 완성도에 더 집중해야한다. 1년에 한번 쓸까말까 하지만 언젠가는 쓸 것 같아서 개발하는 기능은 최소화해야한다. 가장 많은 사용자들이 가장 자주 사용할 기능을 우선해서 더 빠르게 비즈니스를 실행할 수 있도록 하는 것이, 복잡하고 마이너한 기능들을 더 만들기 위해서 애쓰며 복잡도가 개발 기간을 늘리는 것보다 중요하다. 개발과 요구사항을 낸 협업자간의 조율은 바로 그런 지점에 있다.

물론 요청자들의 불안감은 너무나 공감된다.

그래요, 상황은 이래저래 알겠는데,,
지금 개발안하면 앞으로도 다신 안해줄 거잖아요.

기회가 왔을 때에 다 밀어넣어야 한다는 사고방식을 만들어 준 것은 어쩌면 프로덕트팀과의 관계에서 계속해서 학습되어온 결과일 수도 있다. 얼마나 안해주고 얼마나 미뤄지고 얼마나 챙김받지 못했다고 생각하면 이렇게 생각하게 되었을까. 하지만 그럼에도 하고 싶은 말은 '근거'의 미약함이다.

현업에서 생각하는 것보다 기획하는 입장에서 훨씬 더 개발을 거절 당하는 일이 많다. 그건 실제 개발자에게 거절 당할 때도 있고, 스스로 많이 알다보면 스스로 거절하기 시작하기도 한다. 시스템이 안되거나, 개발자 인원이 부족하거나, 해야하는 일의 당위성이 부족하거나 할 때 개발을 진행하기가 어렵다. 회사는 경영이란 한정된 자원을 가장 의미있게 써야 하는 일이고, 결국 중요도를 높이는 것은 중요하다. 그래서 숫자와 근거는 누구를 설득할 때도 가장 효과적이다. 하다못해 해외의 벤치마크 자료라도 명확한 케이스가 있어야 한다. 타인이 만들어놓은 사이트의 그 UI가 효과적이라는 것을 본인의 경험이 아닌 다른 방식으로 증명할 수 있어야 한다.

그렇게 핏대높이고 미간을 찌뿌리고 타인에게 비방하며 중요도를 높이는 것도 하나의 방법일 수도 있다. 그러나 그런 요구사항의 중요도를 높이는 방식에 대한 피해자는 결국 그렇게 했던 사람이 된다. 왜냐하면 IT 프로덕트의 핵심은 지속적인 변화이기 때문에 한번 모든 것을 걸고 인성까지도 걸고 원하는 것을 얻어냈다고 해도 결국 다음에 요청할 일이 또 생길 수밖에 없다. 기획자도 개발자나 디자이너에게 지랄지랄해서 얻어내는 것이 장기적으로 더 악수였다는 것을 깨닫는 일들이 많다. 일은 오래오래 같이 해야한다. 근거없는 '제멋대로' 요청이라는 생각이 뿌리깊게 자리 잡으면 그 사람의 말은 그 어떤 것도 납득하지 않게 된다. 이건 현업관계라고 해도 마찬가지일 것이다.

협업 관계에서 신뢰란 서로의 말에 전문성을 인정하는 것이 아닐까.

협업의 관계에서 신뢰란 상대방이 하는 말에 저의를 고민하지 않는 것이다. 안될만 하니까 안된다고 하는 거고, 시간이 부족하니까 부족하다고 하는 거지 '해주기 싫어서'라는 생각으로 접근하게 되면 '피해의식'이 생겨난다. 그 피해의식은 상대방의 업무적 의도를 유치한 개인적 감정으로 인지하거나, 또는 업무적인 관계에서 스스로가 항상 훌륭하지만 억울하게 도움을 받지못해서 성과를 내지 못한 피해자로 둔갑시킨다. 그러다보면 어느 날부터 진짜로 그 사람이 요청한 일을 모두가 열심히 하기 싫어지거나 반박을 당하는 상황이 오게 된다.

그 때 그 목소리 높이며, 비난과 힐난으로 요청을 하던 그 분은 결국 자기 분에 못이겨서 퇴사를 했다. 나가서도 회사의 모든 사람들을 비난하며 본인은 훌륭했으나 개발이 도움을 주지 않았다는 식으로 이야기를 했다. 하지만 아이디어는 기획이 아니고, 본인의 상식은 실제 고객의 경험이 아니며, 자신의 경험이 전체를 대변할 수 없다. 계속해서 목소리를 높이는 것만으로 상대방을 설득아닌 협박하는 방식으로 협업을 하게 된다면, 결국 그 피해는 그 업무를 하는 모든 사람에게 고스란히 돌아간다. 그 누구도 그 업무를 하는 사람들과 일하고 싶지 않아하게 되니까.

자신이 요청을 할 때, 상대방의 전문성을 충분히 인정하고 스스로가 잘 모를 수 있다는 사실을 인정하는 것이 좋은 협업 관계를 유지하는 가장 좋은 방법이라고 생각한다.

최근 우연히 '지랄을 일 잘하는 것으로 아는 사람'을 보게 되었는데, 미간을 찌뿌리며 회사의 개발팀을 흉보는 그의 모습에서 과거의 그녀가 묘하게 겹쳐보였다. 드라마 '미생'에서 주인공에게 모두와 바둑을 두며 승부를 하려 하지 말라는 말이 있다. 그렇게 모두와 싸우듯이 이겨내는 것이 스스로에게 가장 많은 외로움과 상처를 주고 있는 것을 알고 있을까? 부디 모두와 싸우며 누군가를 무시하고 비난하는 것으로, 자신의 노력까지도 깎아내리는 일이 없으시면 좋겠다. 타인을 무시할 때 잠깐은 스스로가 우쭐해 보일지 몰라도 사실은 더더욱 외롭게 만들 뿐이다.

keyword