기획자에게 쉽게 설명해라
기획자도 의외로 신경 쓸 것이 많은 직군이다. 개발자는 개발을 중점적으로 고려하겠지만, 서비스 기획자는 서비스 기능, 고객 의견, 회사의 방향성 등을 광범위하게 고려하고 있다. 게다가 IT 대기업에서는 PM(Project Manager) 역할까지 더해 프로젝트의 일정 관리까지 해야 하는 경우도 있다. 연관된 많은 사람과도 협업해야 해서 개발보다 더 바쁜 직군이지 않을까.
그래서 개발적인 개선사항이나 기술적 한계를 논의할 때 좀 더 고민하면서 해야 한다.
그 스펙은 기술적으로 안돼요. 그 이유는요..
가끔 일어나는 일이지만, 개발적인 이유로 설명 듣고 있다면 기획자는 아마 눈앞이 막막해질 것이다. 이유를 알아들을 수 있게 설명하려면 개발적인 부분을 최소화하는 게 관건이다. 가장 쉬운 접근법은 아무래도 운영 중인 서비스에 스펙이 있는지를 살펴보는 방법이 있다.
그 스펙은 일정상 못 만들어요.
기획적으로 규모가 작아 보여도, 구현하는 입장에서는 다를 수 있다. 그렇다면 스펙을 쪼개서 작은 스펙별로 일정을 산정하고, 당장 해야 할 것과 다음에 할 것을 분리할 수도 있다. 아니면 개발적으로 빠르게 갈 수 있는 스팩을 역제시하는 방법도 있을 것이다.
개발자가 제시할 수 있는 경우의 수를 늘려라
기획자와 개발자는 시야가 다르기 때문에 서로가 만족하는 결과가 만들어지기는 힘들다. 그래서 같은 시아로 볼 수 있는 프로토타이핑을 가지고 협의하는데 아주 효과적이었다.
스팩 개발과 프로토타이핑 개발이 일정이 비슷하지 않겠나?
라고 생각이 들겠지만, 업무가 익숙해진 상태에서는 스펙을 충족하는 Dirty Code 을 만드는 건 큰 시간이 들지 않는다. 오히려 Dirty Code 에서 PR 리뷰를 받을 수 있을 정도의 코드로 리팩토링하고 테스트케이스를 작성하는 시간이 대부분이라 생각한다. 그렇기 때문에 프로토타입으로 먼저 기획자에게 다가서면, 기획자가 보지 못한 부분도 미리 체크할 수도 있고, 더 디테일한 스펙을 만드는 데에 도움을 줄 수 있다.
“저에게 시간과 예산이 조금만 더 있었더라면...”
와 같은 말은 종종 속으로만 생각하지만, 부족한 환경에서 최선의 결과를 만들어야 한다.
