Due date와 Quality 중에 뭐가 더 중요한가?

나쁜 질문

내가 인터뷰에 들어가서 빠지지 않고 하는 질문이다. 그런데 이 질문은 좋은 질문이 아니다. 덫을 숨겨놓은 질문이라고 해야 할까? 한번 더 생각해서 답변해주기를 바라는 내 마음이 녹아있는 질문이라고 할 수 있겠다.

대부분의 개발자들은 Due date가 중요하다가 이야기 하고, 기획자나 디자이너들은 대부분 Quality를 이야기한다. (물론 내가 인터뷰했던 사람들의 이야기이다) 내 마음은 '사전에 협의된 Quality가 약속한 Due date에 출시되는 것'이다.

what time is it? by erin m

Due date

Due date 를 맞추지 못하는 원인을 여러 가지 생각해 볼 수 있지만, 다음과 같이 두 가지의 경우가 가장 많다. 사실 이외의 원인으로 일정이 늦어진다면, 그 자체로도 심각한 문제라고 생각할 수 있겠다.

1. 업무 볼륨 산정을 잘 못해서 처음에 잡아놓은 일정에 비해서 업무가 많은 경우

2. 진행중인 업무 중간에 새로운 일이나 돌발적인 이슈가 들어오는 경우

1번의 경우는 실무자에게 1차적인 문제(처리해야 하는 업무가 얼마나 시간이 걸리는지 알 지 못하는 – 이 경우 실무자의 경험부족에서 오는 실수)가 있고 이를 관리하는 팀장이나 리더에게 2차적인 문제(이 경우는 시스템이나 프로세스의 부재 또는 관리자의 태도나 역량에 문제가 있을 수 있다)가 있다.

1번의 경우는 1번의 경우와 어쩌면 똑 같은 문제일 수 있다. 결국 업무의 량과 처리할 수 있는 시간에 대한 계산을 통해서 일정을 정하면 여기에는 항상 여분의 시간을 마련해 놓는 것이 상식이니까 하지만, 이런 저런 준비에도 불구하고 초슈퍼울트라 막무가내 갑을 만나는 경우는 방법이 없을 수 있다. 또한, 우선순위에 대한 협의 및 결정에 대한 역량도 이때 빛을 발휘하기 때문에 개발자들은 커뮤니케이션, 즉 협의와 조정의 어느 정도 이상의 능력을 갖추고 있어야 한다.

Quality

대부분의 프로젝트나 업무에서 Quality가 문제 되는 것은 Due date를 억지로 맞추다가 발생하는 사고인 경우가 대부분이다. 촉박한 일정을 잡아 놓고는(사실 처음에 일정이 촉박한지도 모르는 경우가 대부분이지만) 헐레벌떡 만들다 보면 당연히 쓰레기가 나오는 경우가 대부분이다.

가끔 정말 황당한 것은 개발자 스스로 제대로 테스트도 해보지 않고 컴파일 해서 에러가 없으니까 완료가 되었다고 하는 경우가 있다. (솔직히 '가끔'이라고 이야기하기 어려울 정도로 자주 볼 수 있다) Quality의 기준은 항상 고객 또는 발주자와 협의된 사항임을 망각하는 개발자가 상당 수 있다. 자신의 생각을 개발에 들어가기 전 협의할 때는 제대로 이야기하지 않다가(솔직히 기획 내용이나 요건에 대한 이해가 부족하거나 이해를 못하거나) 막상 개발은 자기 나름대로 해버려서 결과물이 처음 협의된 사항과 완전히 다른 사항을 내놓기도 한다.

결국

Due date나 Quality 모두 정확하게 결과물에 대해서 정의가 되지 못해서 벌어지는 참사일 뿐이다.

어떤 수준의 어떤 기능/내용을 담고 있는 결과물을 언제까지 제공해야 하는지 명확하게 협의가 되고 결정이 되면, 그때까지 전달이 될 수 있으면 되는데,어떤 수준, 어떤 기능/내용인지, 특정 수준과 기능/내용을 담기 위해서 얼마나 리소스가 들어가는지를 정확하게 모르기에 명확한 협의와 소통도 안되고 막연히 잘되겠지 하다가 Due date도 못 맞추거나 말도 안 되는 Quality를 Due date에 제공한다.

아무튼 '사전에 협의된 Quality가 약속한 Due date에 출시되는 것'은 꿈일는지도 모르겠다.

사전에 협의된 Quality가 약속한 Due date에 출시하기 위해서 어떻게 하시나요?

 마루날의 雜學辭典|잡학사전을 RSS리더로 편하게 구독하세요~