질문은 구체적으로 하자

‘개발 중인 게임에 퀘스트 시스템을 추가하려면 일정이 얼마나 더 필요할까요?’라는 질문이 있다고 생각해 보자. 퀘스트 시스템은 그 양상이 다양하다. 매우 단순한 형태도 있고, 반대로 복잡한 형태도 있다. 그래서, 짧게는 1개월이 걸릴 수도 있고, 길게는 6개월 이상 걸릴 수도 있다. 그런데 질문하는 사람은 더 좁은 범위의 예측을 원한다. ‘2, 3개월’이나, 아니면 ‘4개월’ 같은 답을 원하는 것이다. 아마 범위가 좁아야 예측이 의미 있는 상황일 것이다. 답변자가 답변을 다르게 구성할 수도 있다. ‘이러한 퀘스트 시스템은 3개월 정도 걸리고, 저러한 퀘스트 시스템은 4개월 정도 걸리며, 이렇게 구성하려면 8개월 정도는 필요합니다’라고 말이다. 그런데, 답변자가 일정을 답변하기 위해서는 일정을 예측하는 과정이 필요하다. 그리고 그 과정자체가 시간을 필요로 한다. 그런데 이렇게 복합적인 대답을 하려면 그 대답을 위해 많은 시간을 써야 한다. 심지어 질문자가 상급자라면 잘 정리된 보고서를 만들어야 하기 때문에 더 많은 시간이 소요될 수 있다. 보통 질문자의 머릿속에는 어떤 그림이 있다. 퀘스트 시스템에 관해 질문할 때는 본인이 보았거나 생각하고 있는 퀘스트 시스템이 있다. 따라서, 그 퀘스트 시스템을 더 구체적으로 묘사해 주면 답변자의 시간을 크게 절약할 수 있다. 그리고 질문자가 원하는 것에 가까운 답변을 들을 가능성도 더 높아질 것이다. 프로젝트를 진행하다 보면 모호한 질문이나 모호한 요구사항을 접할 때가 종종 있다. 거꾸로 구체화를 요청해도 구체화는 이루어지지 않고 모호한 질문과 요구사항만 반복될 때가 있다. 이런 상황은 실무자들이 매우 힘들어하는 상황 중 하나다. 질문과 요구사항에 대응하는 것도 힘들지만, 보통 그런 질문과 요구사항은 충분한 고민이 이루어지지 않은 것들이기 때문에 더 힘들다. 기껏 답변을 하고 구현을 해도 나중에 없었던 일이 되기 십상인 것이다. 중요한 질문이나 요구사항일수록 구체화시켜 이야기하자. 충분히 고민을 하고 이야기한다면 구체화시키는 것에 크게 어려움이 없을 것이다. 만약 구체화가 되지 않는다면, 그것은 고민이 충분하지 않았거나, 아니면 애초에 접근하지 않는 것이 좋은 이슈일 것이다. #질문 #프로젝트 #요구사항