개발자의 사고력 - 문제 정의

1.문제정의가 뭐야

• 문제 정의가 중요하다 라는 말은 정말 많이 들었다.
• 정작 문제 정의를 잘 하는게 무엇인지 고민을 깊게 해보지는 못했다.
• 단순히 고객 문의에서 oo폼 제출이 안되요. 고처주세요. 라는 문의를 그대로 들고와서 문제라고 말할 수 있을까?
• 고객문의는 하나의 문제 상황이다.
• 문제정의는 생각보다 큰 개념이다.
• 수학문제 출제위원이 되었다고 생각해보자. 예로, 삼각형의 내각의 합은 180도이다. a의 각은?
• 이따위로 문제를 내면 누가 풀겠는가? 필요한 조건들과 a가뭔지 하나도 모르겠다.
• 문제정의는 해결책을 도출하기 위한 그 전의 필요한 모든 정보를 최대한 명시하는 행위이다.

2.잘 된 문제정의와 그렇지 못한 문제정의

우리 웹사이트가 느리다, 서버를 증설하자. 라고 말하면 문제정의가 더 필요하다.

• 웹사이트가 얼마나 느린데? - 측정 필요
• 웹사이트가 얼마나 빨라야 하는데? - 목표설정 필요
• 지금 서버는 한대야? - 현상 파악
• 서버 한대로 트래픽 얼마나 버티고 있는데? - 현상 파악
• 지금 개발자가 몇명인데? - 제약 사항 (리소스)
• 얼마나 급한 업무인데? - 제약 사항 (우선순위)

위 수많은 질문들이 모두 문제정의가 제대로 안되어서 나오는 질문들이다.

• 문제를 해결하기 전에 위와 같은 질문들을 제대로 하지않으면 원하는 결과가 나오지 않는다.
• 결과는 뭐라도 나오지만 실제로 맘속에 원하던 정답과 괴리감이 발생한다.
• 그리고 2번 일을 해야 한다.

3.올바른 문제정의를 위해서는 SMART가 모두 설명되어야 한다.

• Specfic 최대한 구체적으로 정의, 누가+무엇을+왜
• Measurable 해결을 했을때 측정 가능한지 ?
• Achievable 현실성이 있는지
• Relevant 목표와 연관성
• Time bound 언제까지?

4.회고하기

• 문제를 풀고나서 그 문제가 해결되지 않는 경험을 한적이 있다.
• 예) 보안 이슈 티켓
  • 보안이슈 티켓을 처리한 후에 다시 스캔을 걸었다.
  • 여기서의 문제 정의는 내가 보안 문제를 해결하는데 해결책을 찾는게 아니다.
  • 보안이슈 티켓에서 말한 그대로 따라서 구현하는것이 정답이다.
  • 따라서 내가 구현한 방법이 옳더라도, 이슈 스캐너에 잡히면 그것은 틀린 답니다.