내가 정리해 본 분석 과제 발굴 프로세스 및 방법은?!

컨설팅 회사를 다니는 것은 아니라 이런 방법에 대해 누가 가르쳐 준 것은 아니다. 하지만 이와 같은 형태의 작업에 참여하고 추진하다 보니 프로세스를 한 번 정리하는 것도 의미가 있을 듯 같다. 여기에 다른 사람의 의견이나 개선되는 사항을 계속 추가하면 더 멋지지 않을까 싶다.

참고로 ADP나 ADSP에서 다루는 과제 발굴 프로세스를 다루려는 것은 아니다. 거기에서는 크게 상향식, 하향식으로 둘로 나눠서 설명을 하고 있다. 그래서 시험을 목적으로 하는 분들에게 이 포스팅 내용은 적절하지 않다.

 

필자가 생각하는 과제 발굴 프로세스는 '인터뷰 -> 요구사항정의 -> 과제정의' 순이다. 각각의 순서대로 내용을 다뤄보자.

 

 

과제발굴 프로세스

 

 

1. 인터뷰

'무엇을 해주세요'라는 요구사항이 명확하면 상관이 없지만, 보통은 무엇이 문제인지도 잘 정의하지 못하는 경우가 있다. 그래서 무엇이 문제인지에 대해 초점을 맞춰서 진행한다. 물론 애기를 하다보면 몇 가지 해결방안을 논의해 볼 수도 있고, 그에 대해 어떻게 생각하는지 물어볼 수도 있다.

여기서 가지고 있는 문제들이 많이 나와야 뒤에 진행할 내용이 많아진다. 너무 상위단으로 문제가 정의되는 것도 문제고, 너무 하위단으로 문제가 정의되는 것도 문제이다. 하지만 이는 인터뷰 후에 내용을 정리하면서 조정하면 된다.

결론으로 편하게 가지고 있는 문제에 대해서 충분히 듣고 나오는 것이 중요하다 생각한다.

 

 

인터뷰 결과를 정리하는 것은 아래 항목으로 진행해보았다. 더 좋은 안이 있을지도 모르겠다.

 

- 인터뷰 대상, 소속, 일자
- 문제 내용, 문제 발생 이유, 영향대상
- 해결방안 (인터뷰 중에 언급된게 있다면)

 

 

2. 요구사항 정의

IT개발 프로세스에는 요구사항정의라는 Task가 있다. 그래서 요구사항정의서를 작성해달라고 하는 경우가 있는데, 기능상의 요건이나 내용이 많아 이에 딱 맞게 정리되지 않는다.

그보다는 앞의 인터뷰를 통해 그들이 진짜 원하는 Needs를 찾는 것이 필요하다고 생각한다. 동일한 애기를 다르게 애기할 수도 있고, 필요한 것은 동일한데 서로 다른 측면에서의 문제를 말할 수도 있기 때문이다.

요구사항을 주욱 나열하는 것보다는 MECE 등의 기법을 통해 그룹핑하는 것이 추후에 보고할 때 용이하다. 보통 어떤 관점의 문제인지나 누가 혜택을 보게 되는 것인지 등으로 정리하는 것이 유용했던 것 같다.

 

어떤 니즈가 있는지 정리해 본다

 

 

3. 과제 정의

요구사항을 해결하기 위해 어떻게 접근해서 문제를 해결하는 것이 좋은지 고민한다. 여러 요구사항을 동시에 만족하는 해결방안이 있을 수도 있고, 꼭 ML이나 AI알고리즘이 아니더라도 문제를 해결하는 방법이 있을 수 있다. 그래서 어떤 한두가지 방법에 매몰되지 않고, 폭넓게 다양한 방면에서 생각해보는 것이 좋다.

 

 

넓은 시각에서 다양한 방법을 고민해보는 것이 좋다

 

과제 정의가 끝나면 우선순위를 정한다. 보통 성과가 얼마나 기대되는지, 그리고 과제 난이도가 적정한지를 기준으로 많이 정하는 듯 하다. 하지만 우선순위를 정하는 기준은 각각의 케이스에 따라 다르지 않을까 싶다.

 

아래와 같이 정리하는 것이 어떨까 한다.

 

- 과제분류, 과제명, 내용 상세, 기대효과(또는 활용방안)
- 우선순위, 예상기간
- 필요데이터, 이슈사항

오늘은 이렇게 필자가 생각하는 분석 과제 발굴 프로세스 및 방법에 대해서 알아보았다. 필자가 경험한 것을 기준으로 작성했기 때문에 부족한 것이 있을지 모르겠다. 컨설팅 회사 같은 경우 위 프로세스가 굉장히 잘 되어 있지 않을까 예상해본다. 그래도 위 프로세스에 고민하는 사람이 있다면, 도움이 되었기를 바란다.