개발자가 좋아하는 기획자는?
주의. 지극히 개인적인 생각이기 때문에
공감이 1도 안될 수 있습니다.
개발자는 개발을 잘하면 됩니다. 기획자는 기획을 잘하면 되죠. 근데 그 "잘"이라는 게 무엇일까요? 이것은 굉장히 주관적인 질문일 것입니다.
제 개인적으로 일을 잘한다는 것은 "일을 위한 일을 하지 않는 것"이라고 생각합니다. 좀 더 쉽게 말하면 "할 일만 하는 것" 이죠. 좀 더 쉽게 말하면 "안 해도 될 일은 안 하는 것"입니다. 더 직설적으로 표현하자면 "쓸데없는 일을 벌이지 않는 것"입니다.
방법의 차이
물론 각각 처한 상황에 따라 달라지겠습니다만 제 경험상 기획자들은 문제 해결점을 개발에서 찾는 경향이 있고 개발자들은 문제 해결점을 기획에서부터 찾는 경향이 있었습니다. 예를 한번 들어보겠습니다.
어느 날 기획이와 개발이가 회사를 그만두고 카페를 차렸습니다. 기획이는 카페가 잘 되도록 기획, 경영하는 일을 맡았고 개발이는 현장에서 직접 관리하는 일을 맡았습니다.
이 카페는 점점 장사가 잘 되고 있었죠. 하지만 문제점이 있었습니다. 바로 장사가 잘 됨에 따라 홀에 쓰레기 정리가 잘 되지 않아 더러운 상태로 놓여있는 시간이 많아졌기 때문입니다.
기획이 曰
"우리 매장 청소가 잘 안되네. 일회용 쓰레기도 많고 사람들이 먹다 버린 과자 봉지도 너무 많아. 개발이 네가 아무래도 이것을 빠르게 청소할 수 있는 플로우를 개발해줘."
개발이 曰
"이참에 일회용 잔 이용을 없애고 외부음식 반입을 금지하면 어떨까?"
문제는 둘 다 동일하게 인지하고 있습니다. 다만 그것을 해결할 방법의 방향 자체가 다른 것이죠. 일을 하다 보면 이런 것을 많이 느낍니다.
이 경우 기획이가 운영 정책을 수정하면 쓸데없는 개발 리소스 확보, 개발 착수, 테스트(QA)의 연쇄적 태스크에 들어가는 공수를 아낄 수 있습니다. 이 리소스를 다른 의미 있는 일에 사용할 여지도 남길 수 있고요.
물론 정책을 건드리는 게 항상 정답은 아닙니다. 생각보다 정책을 변경한다는 게 그리 간단한 일은 아니기 때문입니다. 예를 들어 저 카페 홍보 전단지에 "외부 음식 반입 환영"이라는 홍보 카피가 있었다면 정책을 롤백하기 쉽지 않았을 겁니다. 이렇게 정책 수정이 답이 아닌 경우는 개발로 해결하는 게 올바른 방법입니다. 하지만 불필요한 개발 공수는 최대한 안 들이는 게 좋겠죠.
마치며
사실 제가 뭐라도 되는 사람인 거 마냥 "기획자는 저래야 해!"라고 말하는 것은 아닙니다. 하지만 제 개발 경험상 저런 것을 미리 챙길 줄 아는 기획자들과는 더 기분 좋게 일할 수 있었다는 점을 말씀드리고 싶었습니다.
