개발자가 좋아하는 기획자
이런 기획자랑 일하는게 좋더라
개발자들은 당연하게도 일하기 좋은 상황을 만들어 주는 기획자를 좋아한다. 앞서 알아본 것처럼 해야 할 일도 많고 공부할 것도 많은 환경에서 높은 집중력을 발휘해야 하는 개발자들은 불필요하다고 생각되는 활동에 쉽게 지친다. 우리가 보기에 “이건 개발자가 해야 하는 거 아닌가?” 하는 일들이 개발자에게는 다르게 보일 수 있다. 이번 장에서는 개발자들이 선호하는 기획자의 모습을 알아본다.
개발자가 업무에 몰입할 수 있는 환경을 조성해주는 기획자를 좋아한다. 앞 단원에서 이야기한 것처럼 개발자의 업무는 상당히 깊은 집중력을 요한다. 스위치를 켜듯이 즉각적으로 높은 단계의 집중에 들어갈 수 있다면 좋겠지만, 대부분의 사람은 깊은 집중을 위해 준비 시간이 필요하다. 집중을 방해하는 요소들이 개입하면 몰입하기가 매우 어렵다. 따라서 업무 시간 동안 개발자가 개발에만 집중할 수 있도록 배려하는 것이 중요하다. 기획자로서 진척 상황이나 개발자가 확인해 주어야 하는 일들이 생기더라도, 이를 즉각적으로 물어보는 대신 가능한 한 질문을 모아 일정한 시간에 한 번에 전달하는 것이 좋다. 집중하고 있는 듯 보이는 상황에서는 굳이 말을 걸지 않는 것이 바람직하다.
많은 사람들이 개발자들은 야근을 많이 한다고 생각한다. 개발자의 하루 일과를 살펴보면 그 이유를 알 수 있다. 출근 후 자리 정리를 하고 데일리 스크럼 회의를 하고 나면 오전에 집중할 시간은 길어야 두세 시간 정도이다. 하지만 오전 시간에는 주로 회의가 잡히기 때문에 개발에 할애할 시간이 줄어든다. 점심 식사 후에도 마찬가지로 집중할 시간이 충분하지 않다. 중간중간 메신저와 전화로 방해받으면, 남은 시간 동안 집중하여 개발에 몰두하기는 쉽지 않다. 결국 집중할 수 있는 시간을 확보하기 위해 야근을 선택하게 되는 경우가 많다. 야근 시간 동안에는 주변에서 별다른 방해가 없어 온전히 개발에 몰입할 수 있고, 낮 시간보다 오히려 더 많은 업무를 진행할 수 있다. 업무 시간 중 소통 시간을 줄여 준다면 개발자들이 야근하는 빈도도 크게 줄어들 수 있을 것이다.
기획 초기 단계에서 개발자와 상의하고 주기적으로 개발 방향을 공유하는 기획자를 개발자들은 선호한다. 누구나 그렇듯, 완성되지 않은 결과물을 다른 사람에게 보여주는 것은 쉽지 않다. 기획자 입장에서 초기 기획을 개발자에게 공유하는 일 역시 꺼려질 수 있지만, 개발자 입장에서는 이 공유가 두 가지 의미를 가진다. 첫째, 구현 불가능한 기획을 사전에 방지할 수 있다. 기획 자체가 문제가 아닌 경우라도, 우리 시스템의 구조적 한계로 인해 불가능한 기능이 있을 수 있다. 기획이 이러한 한계를 넘지 않는지 초기에 확인한다면, 후에 불필요한 수정 작업을 줄일 수 있다.
리스트뷰는 가장 흔한 아이템 목록 표시 방식이다. 화면 기획 단계에서 이 목록을 사용자가 자유롭게 변경할 수 있게 해달라고 미리 상의하면, 개발자는 이를 염두에 두고 설계할 수 있다. 반면, 개발이 어느 정도 진행된 후에 이러한 요청이 들어오면, 상황에 따라 적용이 어렵거나 구조를 새로 잡아야 할 수도 있다. 이렇듯 기획 초기 단계에서 개발자와 상의하는 것이 중요하다.
둘째, 제품의 방향성을 이해하고 이를 미리 반영할 수 있다. 프로젝트가 폭포수 모델로 진행되는 경우 초반에는 기획 및 디자인 리소스가 주로 할당되고, 개발자는 업무가 배정되지 않는 경우가 많다. 이때 기획 초기 단계에 개발자가 참여한다면, 더 나은 구조를 조언하고 필요한 기술을 미리 학습하는 시간을 가질 수 있다. 이러한 두 가지 장점 외에도, 프로젝트의 일원으로 존중받는 느낌을 받게 되므로, 초기 단계에서 방향을 공유하고 주기적으로 소통하는 기획자는 매우 가치가 높다.
기획자는 문서와 메일을 통해 개발자와 주로 소통하게 된다. 구두로 설명하는 것이 편리하다는 것은 이해하지만, 기획자가 주관적 표현을 사용하는 것은 개발자에게 오히려 혼란을 줄 수 있다. 예를 들어, 디자이너들이 종종 언급하는 “샤하게 해주세요”라는 요청은 모호하기 때문에 디자이너와 개발자 모두에게 어려움을 줄 수 있다. 기획서를 작성할 때 최대한 구체적이고 정량적인 표현을 사용하여 개발자가 명확히 이해할 수 있도록 하는 것이 중요하다.
개발자의 업무는 기획서의 내용을 프로그램이 이해할 수 있는 코드로 번역하는 일과 비슷하다. B TO B 이창섭 씨가 진행하는 프로그램 ‘전과자들’의 포항공대 컴퓨터공학과 편에서는 코딩을 명령어로 직접 체험해보며 다양한 예외 상황에 부딪히는 모습을 보여주었다. 기획자가 표현하고자 하는 내용을 명확하게 기록해 두면 개발자가 필요할 때마다 다시 묻는 시간을 줄일 수 있어, 소통과 고민에 들이는 시간도 줄어든다. 개발자가 놓치기 쉬운 부분을 기획자가 강조해 주는 것도 매우 도움이 된다.
우리 시스템의 구조와 데이터베이스(DB) 구조를 이해하는 기획자는 개발자들에게 큰 도움을 줄 수 있다. 특히 화면에 표시할 데이터를 선정할 때 빈 칸을 채우기 위한 임의의 값을 선정하는 것이 아닌, DB의 구조적 한계를 고려해 적절한 데이터를 선택하는 것이 중요하다. 예를 들어, 특정 데이터 값이 필수적으로 필요하다면, 왜 이 값이 꼭 필요한지를 설명해 주고, 개발자가 구조상 무리가 없도록 조정할 수 있게끔 논의하는 것이 좋다.
시스템 동작 방식을 이해하는 것도 도움이 된다. 개발자는 비개발 조직에서 전달받은 리소스들을 프로그램에 적용해야 한다. 시스템에서 사용 가능한 이미지, 동영상의 규격과 형식을 기획자가 미리 파악하고 리소스를 취합할 때 이 기준에 맞추어 전달하면, 개발자는 별도로 리소스를 조정하지 않아도 된다. 이는 품질 저하를 방지하고 시간도 절약할 수 있다.
이 외에도, 적절한 소통 능력을 발휘하는 기획자는 개발자와 협력할 때 큰 장점이 된다. 개발이 적절한 시기에 이루어지기 위해서는 필요한 리소스를 미리 준비해 주는 것이 중요하다. 요리에 비유하자면, 재료를 미리 손질해 두어야 요리가 지연되지 않듯이, 개발에 필요한 리소스를 미리 확보하는 것이 필요하다. 준비되지 않은 리소스가 생길 때마다 소통하고 관리해 주는 기획자는 개발의 흐름을 매끄럽게 유지시킬 수 있다.
기획 내용은 초기 설계서에 해당하기 때문에, 프로젝트가 진행되며 내용이 변경될 수 있고 이는 자연스럽다. 변경 사항에 대해 투명하게 공개하고 개발자의 의견을 묻는 기획자는 좋은 협업 파트너로 평가된다. 변경해야 하는 이유를 납득할 수 있게 설명하고 충분히 양해를 구하면, 제품의 성공이 중요한 개발자 역시 이를 수용할 가능성이 크다.
이렇게 개발자가 좋아하는 기획자의 모습에 대해 알아보았다. 개발자의 역할을 이해하고 필요한 부분을 세심하게 준비하며 양해를 구하는 것만으로도 충분히 협조를 이끌어낼 수 있다. 기획자가 개발자와 원활하게 소통할 수 있다면, 프로젝트는 성공에 더 가까워지고 기획자의 가치는 더욱 상승할 것이다.
