수학 문제, 서비스 기획, 개발에도 같은 틀을 적용할 수 있습니다.

문제가 없다면, 시간과 노력을 써도 바뀌는 것이 없을 수 있습니다.

“당연히 보이는 문제가 문제 아닌가?”라고 생각했어요.

개발자인 제가 보는 상황은 이미 좁았습니다.
그래서 문제는 너무 많이 보였고, 오히려 무엇을 특정할지 어려웠습니다.

관심 분야를 작게 만드는 것이 아닙니다.
한 사람의 한 장면까지 내려가, 무엇을 하다가 막히는지 행동을 관찰합니다.

누가

그 어려움을 겪는 사람은 누구인가?

어떤 상황에서

언제, 어떤 조건에서 일어나는가?

무엇을 하려다가

그 사람이 하려던 일은 무엇인가?

어떤 어려움을 겪는가

어느 부분에서 막히는가?

넓게 본 문제 · 기능 전체텍스트 이미지화 기능에서 오류가 계속 발생한다.
특정 글꼴이나 스타일에서 텍스트가 다르게 그려졌습니다.

관찰할 장면: 개발자인 내가 오류를 고치기 위해 코드를 수정할 때

누가

텍스트 이미지화 기능을 개발하는 나

어떤 상황에서

제보받은 오류를 고치기 위해 코드를 수정할 때

무엇을 하려다가

오류를 고치면서 기존 텍스트도 정상적으로 유지하려다가

어떤 어려움을 겪는가

다른 텍스트에서 생긴 문제를 고객 제보 후에 발견한다

좁혀진 문제: 수정이 다른 텍스트에 미친 영향을 확인하기 어려워,
새로운 오류를 고객 제보 후에야 발견한다.

이번 작업이 끝났을 때, 어떤 어려움이 줄어들어야 할까?

개별 오류를 고쳐도 다른 오류를 뒤늦게 발견하고 다시 수정하는 일이 반복됐습니다.
그래서 이번에는 오류를 발견하는 시점을 바꾸기로 했습니다.

개발 사례에서는 놓친 오류를 뒤늦게 고치는 일이 반복됐습니다.
나 자신이 겪는 문제도 선택의 근거가 될 수 있습니다.

같은 일을 하는데도 어려움을 겪지 않는 사람이 있다면, 어떤 차이가 있는지도 살펴봅니다.

가능하다면 실제 작업 과정과 기록도 함께 봅니다.
반복 작업이나 별도 도구는 문제의 영향을 보여주는 단서입니다.

이제 이 어려움을 줄일 해결 방법을 고민할 수 있습니다.

로그인과 결제 같은 기본 기능을 갖춘 웹 서비스 템플릿.
한국 개발자가 사용하기 편하도록 수정했습니다.

이 템플릿을 사용하려는 사람들이 있었고,
어느 부분에서 어려움을 겪는지도 드러나 있었습니다.

기존 기능을 활용하면서, 사람들이 불편해하던 부분을 수정했습니다.