Impact Effort Matrix, 생각보다 간단하지 않네...😭

OWL NOTE·2025년 4월 24일
post-thumbnail

오늘은 다시 한 번 별점 후기를 정리하고, Impact Effort Matrix를 활용해 문제 해결 우선순위를 정하는 작업을 했다. 표면적으로는 "노력 대비 효과"를 기준으로 분류하면 된다고 해서 단순한 작업일 거라고 생각했지만, 막상 시작하고 나니 머릿속이 복잡해졌다ㅠ


😵 혼란 포인트 1 : “Effort”과 “Impact”의 기준이 모호하다

‘개발 난이도가 높다’는 게 과연 어느 정도를 말하는 걸까?
“사용자 영향도”는 빈도 기준으로 봐야 하나, 아니면 유저 이탈 가능성 같은 리스크를 포함해야 하나?
같은 요청이라도 배경과 맥락에 따라 effort와 impact의 평가가 달라질 수 있어서 선뜻 사분면에 넣기가 어려웠다.

그리고 저녁 스크럼을 하면서 들은 이야기인데, "초반에 어떻게 설계했느냐"에 따라서 개발 공수가 상당히 다르다고 한다.
그래서 만약에 컬러 코드?가 하드 코딩되어 있다면 다크 모드 개발이 쉽지 않을 수 있다고...
그런데 이런 것들은 알 수 없는 부분이다보니, Effort가 높다, 낮다를 판단하기가 어렵다.


🤯 혼란 포인트 2 : 숫자(빈도)와 영향력이 항상 비례하지 않는다

예를 들어, 어플 내 오류를 지적하는 후기 숫자는 상대적으로 적었지만, 사용자 경험에 미치는 영향은 매우 크다.
반면 다크모드 요청 빈도는 가장 높지만,어플 내 오류만큼 치명적인 것은 아니다.
그러다 보니 단순히 빈도순으로 우선순위를 매길 수 없다는 점에서 고민이 깊어졌다.


😖 혼란 포인트 3: 영향력이 매우 높고 노력도 높은 기능 vs 영향력은 높고 노력이 중간 정도인 기능

예를 들어,
A 기능은 사용자에게 엄청난 영향을 주지만, 개발 난이도가 높고 (ex. 결제 시스템 오류 수정)

B 기능은 사용자 영향도도 꽤 있고, 개발 난이도는 중간 정도라면 (ex. 다크모드)

이럴 땐 과연 어떤 걸 더 우선 순위로 두어야 할지...
'단순히 Effort-Impact Matrix를 작성한다고 해결되는 문제가 아니구나'를 느꼈고... 이에 대해서 튜터님의 조언이 필요할 것 같다고 느꼈다.

오늘 한 내용들을 보기 좋게 정리하고, 내일 튜터님께 피드백을 받아야겠다.

profile
학습하고 정리합니다

0개의 댓글