<IT에서의 '문제정의'란 말의 정의>

👉 늘 헷갈리는 유저의 '진짜 문제'를 정의하는데에 도움을 주는 글이 있어 공유합니다! 🧮 유저의 진짜 문제는 그게 아닐 수 있다! - 요청자가 원하는 형태가 아무리 구체적이더라도 실제 해결하고 싶은 '니즈'는 다를 수 있음 🧮 문제 정의 역량 1) 사용자의 문제를 세분화해서 프로젝트화 시키고 2) 문제를 여러가지 기술적으로 해결가능한 문제로 치환하는 것 🧮 예시로 보는 문제 정의 과정 1. "배너 하나 넣어주세요!" - 요청 : '여기에 배너 하나 넣어주세요' - 사실 : '이 화면에서 발생한 트래픽을 이용해서 매출을 높이고 싶어요'로 치환 => 헛발 : '여기에 배너를 어떻게 넣느냐'에 집중 => 진짜 문제 : '이 화면의 트래픽을 이용해서 매출을 높일 수 있는 방법' 2. "과거로 돌아가고 싶어요!" - 요청 : '2006년으로 돌아가게 해주세요' - 이유 : "2006년이 가장 행복했던 시간이어서 그 시간으로 돌아가고 싶어요" - 문제에 대한 질문(문제 좁히기) 1) 2006년은 어떤 이유에서 가장 행복했던 시간인지? 2) 그 시간으로 돌아갔을 때, 얻을 수 있는 것은 무엇인지? - 질문에 대한 답변 1) 2006년에 가족들이 모두 함께 했고, 가장 성적이 좋은 시기였음 2) 살아있는 가족, 자기만족감 - 문제에 대한 정의(요청자 관점) > 요구사항의 궁극적인 목적 : 행복 > 행복의 조건 : 가족들의 존재와 자기만족감 - 문제에 대한 정의(IT기술 관점) > 전제조건1 : 시간은 미래로만 이동이 가능하다. > 전제조건2 : 이미 죽은 사람을 되돌릴 수 없다. => 미래에 새로운 가족을 만들고, 자기만족감을 높여서 2006년보다 더 행복한 시간을 만든다. - 문제의 프로젝트화(해결) > 타임머신을 개발하는 것보다 '가족을 구할 수 있는 배우자 매칭 서비스' > 자기만족감을 높여줄 수 있는 '멘탈케어서비스' 혹은 '성적관리 서비스' => 모든 일의 지향점은 '2006년보다 더 행복한 시간을 미래에 만드는 것' 🧮 불편함만을 찾아내는 것은 VOC에 지나지 않는다. - 불편사항들을 리스트업해서 찾아내는 것은 '깨진 유리창'관리에 가까움 > 유리창이 왜 깨졌는지에 대한 문제정의가 필요함 💭Insight 문제정의를 할 때면 VOC를 통해 유저의 불편한 점들을 개선하면 되는건지, 어떤 해결책을 찾아야 하는건지 헷갈립니다. 불편함을 느끼는 궁극적인 목적을 찾고 이를 IT기술로 어떻게 치환할 수 있을지 생각 해 야겠네요. 왜?라는 질문과 프로젝트화 하는 역량이 필요할 것 같네요! 👇 '도그냥'님의 원글 보러가기