오늘 팀 프로젝트를 진행하면서, 내가 제안한 주제가 오히려 팀의 진행을 막고 있는 것 같다는 생각이 들었다. 문제를 “대충 이런 불편이 있대” 수준으로만 잡아두고 시작했더니, 무엇을 해결해야 하는지 기준이 없어서 필요 없는 화면까지 설계하게 되고, 그만큼 시간이 계속 늘어났다.
문제정의가 부족해서 “이것도 필요해 보이고, 저것도 있어야 할 것 같고…”가 반복됐다.
매장/포장, 픽업 가능 시간, 주문 상태 확인 등 정보 전달 이슈가 여러 갈래로 퍼지면서 범위가 커졌다.
결과적으로 팀은 디자인을 진행하고 있는데도 정답에 가까워지고 있다는 느낌이 없어서 막힌 상태가 됐다.
왜 막혔는지(원인)
해결 범위(스코프) 선언이 없었다.
“이번엔 매장/포장 선택만 개선한다” 같은 문장이 초반에 확실히 박혀 있지 않았다.
사용자 불편을 말하긴 했지만,
핵심 불편(1개) → 원인 → 해결 목표로 단단하게 연결되지 않았다.
“좋은 기능”을 계속 떠올리다 보니, 문제 해결이 아니라 기능 추가가 되어버렸다.
문제정의는 문서가 아니라 팀의 ‘디자인 종료 조건’이다.
기준이 없으면 디자인은 계속 커지고, 속도는 느려진다.
“불편 포인트가 여러 개”일수록 더더욱
이번 스프린트에서 딱 하나만 해결하도록 좁혀야 한다.
주제를 제안한 사람이 모든 걸 책임지는 건 아니지만,
최소한 팀이 같은 문제를 보고 있는지 정렬하는 역할은 내가 먼저 해야 한다.
문제정의 1문장 + 스코프 1문장을 먼저 고정한다.
예: “앱 오더에서 매장/포장 선택이 불명확해 사용자가 현재 주문 상태를 직관적으로 이해하지 못한다.”
스코프: “이번 개선은 매장/포장 선택 단계의 명확화에만 집중한다.”
성공 기준 2개만 정한다.
(예) 주문 완료 전 ‘이용 방식’이 한 번은 명확히 노출된다
(예) 주문 완료 후 화면에서 포장/매장 상태를 1초 내 인지 가능
아이디어를 늘리기 전에 필수 화면만 그린다.
매장/포장 선택 → 주문 요약 반영 → 주문 완료 후 상태 표시 (3장으로 끝)
팀에게 “내가 미안해” 대신 정렬된 제안을 가져간다.
감정 사과보다, “범위를 이렇게 줄이자”가 팀에 더 도움 된다.
내가 주제를 제안했는데 진행이 막힌 것 같아서 미안한 마음이 들었다.
하지만 오늘의 막힘은 실패가 아니라, 문제정의의 중요함을 실제로 체감한 순간이었다. 다음 회의에서는 사과로 시작하기보다, 문제정의/스코프를 정리해서 팀의 시간을 줄이는 방식으로 책임지자고 정리했다.