요구사항 스터디를 마치며
2018년 1월, 새해 다짐과 함께 시작한 기획스터디 – 요구사항(Requirement)이 4주의 모임을 끝으로 종료되었다. 나를 포함하여 4명이 모여 매주 한 번씩 2-3시간씩 스터디와 토론을 했고 스터디에 선정하지 못했던 사람들을 위해 4시간의 1day 세미나도 진행했다. 스터디 중간에 세미나를 연 것이라 스터디 후반의 내용도 세미나로 개최할 계획은 가지고 있다. 하지만 언제가 될지는 모르겠다.
애증이라고 할 수 있을까
나의 경력 전체를 놓고 바라보는 요구사항에 대한 관점은 기획의 롤을 수행하는 사람들에게 가장 난이도가 높은 업무 중에 하나다. 개발자들이 기획자의 요구사항을 받을 때 느낌도 이와 비슷할 텐데, 사용자(end-user)와 맞닿아 있는 전방의 기획자들에게는 그 난이도가 좀 더 높은 편이다. 특히 ‘예쁘게’ ‘사용하기 편하게’와 같이 무형문화재 수준의 요구사항을 받을 때마다 이러려고 기획자하나 하는 자괴감도 들 때도 있을 것이다.
요구사항이다 보니 무조건 안 된다 할 수도 없고 무조건 된다고 할 수도 없다. 언제나 요구사항은 불명확하고, 희망사항인지 요구사항인지 우선순위가 없으며, 비즈니스 상황은 시시때때로 변한다. 무엇보다 사람과 커뮤니케이션이 전부기 때문에 본인들조차 알지 못하는 요구사항을 발굴해내는 역할까지도 수행해야 한다.
이런 역할은 비즈니스 애널리스트(BA)라는 전문가의 일이다. 그의 역할은 비즈니스 요구사항들을 분석하고 발굴하여 명확하게 관리하고 그를 개발부서로 잘 전달하는 것이다. 하지만 일반 한국 기획자에겐 그것이 전문영역으로 다뤄지지도 않고, 도제식으로 내려줄 만한 회사 내부 노하우조차 없는 것이 사실이고, 그런데도 데드라인을 맞춰야 하고, 명시적인 요구사항 이상으로 그들이 당연하다고 생각했던 스펙들까지 포함하여 개발해내야 하는 것이 현실이다.
프로답다고 할 수 있을까
지금 내가 일하고 있는 야놀자는 O2O 플랫폼이다. O2O란 오프라인과 온라인 비즈니스가 모이는 곳이지만, 다르게 생각하면 상대방과 부딪히는 수많은 요구사항이 난무하는 곳이기도 하다. 남들은 여름 겨울 휴가시즌이 성수기라고 생각하겠지만, 실제로 이쪽 업계는 매달 빨간 날이 하루라도 껴있으면 여행특수, 휴가특수 준성수기를 보낸다. 남들을 맘 편히 놀게 만들려고 우리는 노는 날을 반납하는 거라는 불편한 농담도 쉬이 오간다.
Anyway. 이런 상황에서 적당히 기억하고, 적당히 기록하는 것만으로는 요구사항들을 수용할 수 있는 임계에 도달해간다. 아무래도 어쩔 수 없다. 쳐내는 속도보다 쌓이는 속도가 더 빠르니까. 당장 버그를 수정해달라는 고객센터 이슈와 하루 건너면 서운한 업주와 영업사이드 불만과 한명의 사용자라도 모셔와야하는 마케팅실 애절함과 그리고 그런 과정에서 생긴 레거시들에 파묻혀있는 개발팀의 원성과. (이렇게 쓰다 보니 별 헤는 밤이 떠오르는 것은 그냥 한글 타자 연습을 열심히 해서겠지.) 그리고도 요구사항이 수십 개씩 쏟아져나오는 회의가 일주일에 20시간 정도는 가뿐히 넘는다.
아니, 하루 5시간씩 회의하는 건 차라리 괜찮다. 소는 누군가가 키우겠지. (방목?) 많은 회의에 빨려 들어가는 스테미너보단 감정노동이 더 힘들다. 안된다하면 왜 다 안된다 얘기하냐 하고, 된다고 하면 왜 그렇게 쉽게 된다고 받아주냐고 말이 나온다. 도대체 누구 장단에 춤을 춰야 하는 거야 하는 생각이 든다. 그러니 중간에서 눈칫밥으로 치고 빠지는 노하우는 엄청 늘어났지만, 내가 일을 덜기 위해서 요구사항을 받아주지 않거나, 어떻게든 해내기 위해 스펙을 교묘하게 틀어내는(결국엔 레거시가 되지만) 일을 해야 할 때마다 짜증이 났다. 그러면서 내가 겨우 회사 일을 하는데 왜 내 짜증을 써야 하는가
에 대한 생각이 들기 시작했다.
에고를 내려놓을 수 있을까
이제까지는 기획자 더러워서 못 해 먹겠네
라는 생각을 종종(종종?) 하는 편이었다면, 이번 스터디를 통해서는 어떻게 하면 더 잘할 수 있을지에 대한 효율성의 관점에서 고민을 하기 시작했다. 특히 다른 회사에 다니는 기획자들과 서로 어떻게 일하고 있는지 어떤 감정을 어떻게 처리하고 있는지에 대한 이야기들을 들으며 이제는 조금 내려놓고 일할 수 있게 되었다.
아마도 요구사항 자체가 내가 해결해야 할 미션이 되기 때문에, 그것을 해결해야만 하는 동기부여가 충분하지 않았을 때 불만이 겉으로 표출 돼 왔을 것이고. 내가 하자고 한 것도 아니지만 개발자들의 불만을 들을 때마다 고래싸움에 새우 등 터지는거 짜증나
도 있었을 것이고. 그리고 이왕 하는거 기깔나게 잘 하고 싶은데 여러 제약조건 때문에 겨우 이 정도밖에 못하나 하는 자괴감도 있었을 것이고.
이런 감정들은 이제는 갖지 않으리라 다짐하고 매번 회의에 참석하고, 제 3자의 관점에서 모두와 이야기하기 시작하고, 어, 나 이 회사에 조금 애정이 떨어졌나?
싶을 만큼 일에서 한 발짝 떨어지고 나니 마음이 편해지기 시작한다.
물론 일을 더 생산적으로 하기 위한 이론도 쌓았다. 아마 지금 진행하는 프로젝트가 끝나고 나면 어떤 것이 나에게 맞고 맞지 않는지 알게 될 테고, 몇 번의 반복훈련을 통해 나에게 맞는 요구사항 개발과 관리 방식에 대해 깨닫게 되는 날이 오겠지 싶다. 책으로 보는 것과 직접 해보는 것의 차이는 엄청난 차이니까.
잘 할 수 있을까
아니. 하지만 믿는다.