개발자와 일할 때 이것만은 꼭 알아두자
⑤개발자 이해하기(2)
이전 글을 통해 기획자의 눈에 비치는 개발자들의 일상과 현실, 특징에 대해 이야기하였습니다. 오늘은 이전 글에 이어 개발자와 협업할 때 알아두면 좋은 것들과 개발자들에 대한 이해와 배려에 대해 이야기해 보도록 하겠습니다. 너무나 서로 다른 기획자와 개발자이지만 프로젝트 성공이라는 공통의 목표를 달성하기 위해 상대방에 대한 이해 과정이라고 생각하고 다음을 봐 주시기 바랍니다.
개발자와 협업할 때 알아두면 좋은 것들
첫째, 개발자들의 용어가 이해되지 않으면 묻고, 정확하게 이해한 뒤 대화해야 합니다. 이전 글에서도 이야기한 것처럼 개발자들의 용어를 제대로 이해하지 않으면 대화 내용뿐만 아니라 프로젝트의 방향이 잘못 흘러갈 수 있습니다. 서로의 눈높이를 정확하게 맞추기 위해서라도 개발자들이 쓰는 용어를 정확하게 이해하고, 필요한 경우 공부를 해 두는 것이 필요합니다. 잘 모르는데 아는척하면 일이 엉뚱하게 흘러가거나 개발자들로부터 무시 받을 수도 있으니 주의가 필요한 부분입니다.
둘째, 개발자들의 개발 일정은 고무줄 일정이라고 불릴 정도로 정량적 측정이 힘듭니다. 물론 개발 프로젝트 기간을 산정할 때 사용하는 방법들이 있습니다. 개발 본수라든지 펑션 포인트가 그 예이지만 이는 눈에 보이지 않는 개발의 과정을 정량적으로 산정하기 위한 하나의 방법에 불과합니다. 실제 개발 과정에서는 하나의 기능을 만드는 데 프로젝트 일정을 산정할 때 이야기한 기간대비 1/10로 줄어드는 경우도 있고, 10배 늘어나는 경우도 있습니다. 프로젝트 관리 입장에서도 물론 중요하지만 기획자의 입장에서도 상당한 주의가 필요한 것이 바로 이런 일정입니다. 어렵겠지만 충분한 일정에서 원하는 결과물이 나올 수 있도록 협조하고, 항상 진행상황을 확인해야 하는 역할에 분명 기획자의 기여가 필요한 항목입니다.
셋째, 개발자들이 이야기하는 98% 완성되었다는 진척도는 믿지 마십시오. 개발자들의 이야기를 무시하라는 것이 아닙니다. 실제 98%의 진척률을 보이는 프로젝트가 있다고 하더라도 2%를 수행하는데 지금까지 투입된 전체 시간의 2/100만큼의 시간이 아니라 지금까지 투입된 전체 시간 이상이 걸릴 수도 있습니다. 물론 프로젝트 매니저(PM)가 일정에 대해 책임을 지겠지만 기획자 또한 이런 개발 프로젝트의 속성에 대해서 잘 이해하고 있어야 합니다.
넷째, 개발자들의 ‘쉽다, 어렵다, 하면 된다, 하면 되겠죠’라는 이야기를 표면 그대로 받아들이면 안됩니다. ‘쉽다’라고 이야기한 것이 실제로 개발 난이도가 쉽지 않은 경우도 많습니다. ‘어렵다’는 것은 대부분 현재 주어진 조건으로는 어렵다고 이해하면 됩니다. ‘하면 되겠죠’라는 뜻은 약간의 빈정거림이나 제안을 한 상대방에 대해 무시하는 태도가 포함된 이야기일 수 있으니 그 이면에 가지고 있는 개발자의 생각이나 제약조건 및 환경에 대해서 꼭 확인하는 과정이 필요합니다. ‘하면 된다’는 이야기 또한 제약조건이 붙을 수가 있으니 이 또한 확인해야 하는 항목입니다.
개발자들에 대한 이해와 배려
기획자들이 성공적인 프로젝트를 이끌어내기 위해 같이 협업하는 개발자들을 이해하고, 배려해야 하는 요소들은 여러 가지가 있습니다. 이 중 개발자의 입장에서 기획자가 해 주면 좋겠다는 것들 것 몇 가지 정리해 보았습니다.
첫째, 멀티 태스킹(과한 업무)은 개발자에게 도움이 되지 않고, 창의적인 작업을 할 수 없게 만듭니다. 개발 과정은 정말로 창의력이 필요한 작업입니다. 이런 개발자들을 위해 멀티 태스킹을 요하는 업무나 과한 업무 의뢰는 지양하는 것이 좋습니다. 같은 개발 프로젝트라고 하더라도 오늘은 A라는 기능을 이야기하였다가 이를 끝내기 전에 완전히 다른 B라는 기능에 대해 이야기를 하는 것이 일종의 멀티 태스킹 과정이 될 수도 있습니다. 만일 이런 업무가 필요하다면 시간이라도 분리하여 한 업무에 집중할 수 있는 배려가 필요합니다.
둘째, 비 개발 업무가 많아 개발 흐름이 깨지는 환경을 최대한 만들지 않는 것이 좋습니다. 회사 내에서 개발 프로젝트를 하다 보면 개발 이외에 다양한 업무가 할당되는 경우가 있습니다. 기획자가 이 모든 것을 통제할 수는 없지만 개발의 흐름을 방해하는 외부 요인을 최대한 차단해 주는 것이 프로젝트 품질을 높이는 방향이라는 것을 이해하고 있어야 합니다.
셋째, 노는 것처럼 보이는 것이 노는 것이 아닌 경우가 많습니다. 앞서 이야기한 것처럼 개발 과정 자체는 창의적인 과정입니다. 누구든지 1년 365일 창의력을 발휘하여 업무를 할 수 없는 것처럼 몰입하여 개발하는 데에도 한계가 있습니다. 개발 작업의 속도가 나지 않거나 문제 해결이 되지 않는 경우 많은 개발자들이 자기만의 휴식을 취하는데 기획자의 눈에는 개발자가 노는 것처럼 보일 수 있습니다. 이런 광경을 목격하더라도 오해하지 마시기 바랍니다. 개발자의 휴식은 새로운 업무를 위한 준비과정입니다.
넷째, 집중 또는 몰입할 때에는 그대로 업무를 할 수 있도록 배려하는 것이 좋습니다. 휴식의 시간을 지나면 집중하여 프로그래밍을 하는 개발자들의 모습을 볼 수 있습니다. 어떤 때에는 옆에서 불러도 대답하지 않고 몰입하는 개발자도 볼 수 있습니다. 이런 모습을 본다면 가급적 해당 업무를 계속 할 수 있도록 배려하는 것이 좋습니다. 개발의 흐름을 끊는 행동을 하지 말자는 것입니다. 개발자 본인에게도 좋고, 프로젝트에도 분명 긍정적인 결과를 만들어 낼 것입니다.
다섯째, 눈에 보이지 않는 개발 과정에 대해서는 개발자의 의견을 존중해야 합니다. 앞서 이야기 하였지만 기획자나 고객은 개발된 결과물만 보지만 개발자는 그 과정에 보이지 않는 것들까지 신경을 써서 개발하게 됩니다. 어떤 프레임워크를 사용해서 만들든, 어떤 개발방법론을 도입해서 프로젝트를 진행하든 기획자의 입장에서 최대한 존중해주는 모습이 필요합니다. 설령 그 선택으로 인해 생각지도 못했던 업무가 증가하는 모습을 보이더라도 이런 과정이 개발자 개개인의 역량을 발전시키는데 도움이 되는 것은 사실입니다. 서비스의 품질에 영향을 주지 않는다면 이런 선택에 따라 늘어나는 업무가 있더라도 도움을 주면 좋을 것입니다. 이외에도 개발 본연의 업무 영역에 대해서는 최대한 배려와 존중이 필요하지 않나 생각합니다.
지금까지 기획자가 개발자와 잘 협업하기 위해 알아두어야 할 개발자들의 모습에 대해 살펴보았습니다. 물론 앞서 이야기한 것들이 모든 개발자들을 대변하지도 않고, 일반적인 모습이 아닐 수도 있습니다. 하지만 기획자에 눈에 비치는 개발자의 한 단면인 것은 분명합니다.
좋은 프로젝트를 위해서는 기획자와 개발자가 서로의 입장에서 잘 협력하는 것이 최선의 길입니다. 이런 협력을 위해 상대방을 이해하기에 필요한 기본적인 지식 습득은 물론이고, 때로는 서로 양보하고, 상대방을 인정하며, 긍정적인 방향으로 나아가는 길이 바로 성공적인 프로젝트를 만드는 지름길이라 생각합니다. 기획자와 개발자 사이에는 서로의 입장을 대변할 수 있는 일종의 통역 역할이 필요합니다. 만일 기획자로서 추후 이와 같은 역할을 담당하고 싶다면 무엇보다도 개발자에 대한 관심은 필수라 생각합니다. 다음 번에는 개발자의 입장에서 기획자를 이해하기 위한 여러 모습에 대해 이야기를 해 보겠습니다.
- 본 글은 LG전자 블로그에 기고한 글입니다.
