잡 스토리

요구사항을 한 문장으로 적는 양식은 오랫동안 하나였습니다. 사용자로서 나는 무엇을 하고 싶다, 왜냐하면 무엇 때문이다, 하고 적는 유저 스토리입니다. 걸리는 자리는 맨 앞의 누가라는 칸이었습니다. 그 자리에는 대개 페르소나가 들어갑니다. 특정 사용자 집단을 한 사람처럼 구체화해 둔 모델인데, 같은 이름을 읽어도 각자 떠올리는 사람이 달랐습니다.

페이지덱에서도 같은 일이 있었습니다. 지현이 "바쁜 팀 리더로서 나는 문서를 빠르게 찾고 싶다" 라는 문장을 회의에 올리자, 민서는 검색창을 키우는 화면을 그렸고 태오는 최근 연 문서 목록을 떠올렸습니다. 둘 다 문장에 어긋나지 않았습니다. 바쁜 팀 리더가 언제 무엇을 하다가 문서를 찾는지가 적혀 있지 않았으니 각자 아는 장면을 끼워 넣은 겁니다.

잡 스토리는 그 첫 칸을 사람에서 순간으로 바꿉니다. 누가 대신 언제 어떤 상황에서를 적습니다. 회의가 끝난 직후라는 조건이 문장에 박혀 있으면, 문서를 찾는 기능을 어디에 둘지가 함께 정해집니다. 사람은 상황에 따라 다르게 행동하지만 같은 상황에 놓인 사람들은 비슷하게 행동한다는 것이 이 양식이 딛고 선 전제입니다.

한 문장이 세 토막으로 나뉩니다. 순서가 정해져 있고 토막마다 답해야 하는 질문이 다릅니다.

1. 상황 — 언제, 무엇을 하던 중인지 적습니다. "회의가 끝나고 노트북을 덮기 전에" 처럼 시각과 행동이 함께 잡히는 순간이어야 합니다.
2. 동기 — 그 상황에서 하고 싶은 일을 적습니다. "결정 사항만 빠르게 남기고 싶다" 가 여기 들어갑니다. 화면이나 버튼 이름을 쓰지 않고 하려는 일만 씁니다.
3. 기대 결과 — 그 일이 됐을 때 무엇이 달라지길 바라는지 적습니다. "다음 회의에서 같은 논의를 처음부터 다시 하지 않는다" 가 예입니다.

세 토막을 이으면 이렇게 됩니다. 회의가 끝나고 노트북을 덮기 전에, 결정 사항만 빠르게 남기고 싶다, 그래서 다음 회의에서 같은 논의를 처음부터 다시 하지 않는다.

문서의 값은 거의 전부 1번 칸에서 갈립니다. "문서를 정리할 때" 는 상황이 아니라 분류입니다. 하루 중 어느 때라도 해당하니 아무 화면도 정해 주지 못합니다. 반면 회의가 끝난 직후라는 조건은 남은 시간이 2~3분이고 손에 든 것은 방금 적은 메모뿐이라는 제약을 함께 끌고 옵니다. 거기서 빈 문서를 새로 만드는 화면이 아니라 회의록 서식이 먼저 떠 있어야 한다는 결론이 나옵니다.

3번 칸은 만든 뒤에 무엇을 확인할지를 정합니다. 같은 논의를 반복하지 않는 것이 기대 결과라면, 기능을 내고 나서 볼 것은 회의록 작성 건수가 아니라 이전 회의록을 다시 열어 본 비율입니다. 이 칸이 비면 인수 조건, 곧 이 요구가 끝났다고 인정받는 조건을 나중에 따로 지어내게 됩니다.

보통 프로덕트 매니저가 씁니다. 다만 책상에 앉아 지어내는 문장이 아닙니다. 1번 칸에 적을 순간은 관찰에서만 나오기 때문에, 앞서 스위치 인터뷰를 돌립니다. 제품을 바꾼 지 얼마 안 된 사람에게 갈아탄 날 무슨 일이 있었는지 되묻는 인터뷰입니다. 거기서 나온 장면을 그대로 상황 칸에 옮깁니다.

읽는 사람은 셋입니다. 디자이너는 상황 칸을 보고 이 기능을 어느 화면 어느 자리에 둘지 정합니다. 개발자는 동기 칸에서 무엇을 만들지를, 기대 결과 칸에서 어디까지가 완료인지를 읽습니다. 프로덕트 매니저 자신은 나중에 우선순위를 다시 매길 때 이 문장을 씁니다. 같은 상황에서 나온 잡 스토리가 여러 개 쌓이면 그 순간이 제품에서 가장 자주 부딪히는 지점이라는 뜻이 됩니다.

한 문장에는 기능적 잡 하나만 담습니다. 실질적으로 끝내야 하는 과업을 말합니다. 그 과정에서 느끼고 싶은 감정인 감정적 잡은 별도 문장으로 두거나 기대 결과 칸에 붙입니다. 하나에 셋을 다 욱여넣으면 무엇을 만들면 되는지가 도로 흐려집니다.

"이거 잡 스토리로 다시 적어 주실래요? 어떤 상황에서 쓰는 건지가 안 보여요."

무엇을 만들지는 알겠는데 언제 쓰는 기능인지 모르겠으니 화면을 못 정하겠다는 말입니다.

"상황 칸이 '문서를 정리할 때' 로 돼 있으면 너무 넓어요."

그 조건에 해당하지 않는 순간이 없어서 설계에 아무 제약도 주지 못한다는 지적입니다.

"이번에 적은 네 개가 전부 회의 직후라는 같은 상황에서 나왔어요."

흩어져 보이던 요구가 사실 한 순간에 몰려 있으니 그 순간을 통째로 다루자는 제안입니다.

페이지덱의 어느 주 계획 회의 장면입니다. 지현이 스위치 인터뷰 여섯 건을 마치고 잡 스토리 네 개를 들고 들어옵니다. 민서가 먼저 상황 칸만 읽습니다. 넷 중 셋이 회의가 끝난 직후를 가리키고 있으니, 검색을 손보는 대신 회의록 서식을 여는 자리를 앞으로 당기자고 제안합니다. 태오는 기대 결과 칸을 짚으며 이전 회의록을 다시 여는 비율을 미리 재 두자고 말합니다. 지금 값을 모르면 나중에 나아졌는지 알 수 없기 때문입니다.

한 문장이 화면 배치와 측정 항목을 동시에 정한 셈입니다. 세 칸이 각각 다른 사람에게 다른 일을 시키기 때문입니다.

양식을 바꾸면 요구사항의 질이 올라간다고 여기는 경우가 가장 많습니다. 눈에 보이는 변화라서 그렇게 느끼기 쉽습니다. 실제로 달라지는 것은 빈칸의 모양뿐입니다. 상황 칸에 들어갈 순간은 관찰에서만 나오는데, 회의실에서 서로 아는 이야기를 모아 채우면 문장 형태만 갖춘 짐작이 남습니다. 더 나쁜 것은 그 짐작이 근거처럼 보인다는 점입니다. 여섯 달 뒤에 기능이 안 쓰인다는 사실을 발견하고 거슬러 올라가면 처음 상황 칸을 누가 무엇을 보고 적었는지 아무도 기억하지 못합니다.

사람을 안 적으니 사용자를 몰라도 된다고 읽는 경우도 있습니다. 첫 칸에서 페르소나가 빠지는 것을 보고 그렇게 넘겨짚기 쉽습니다. 빠진 것은 사람이 아니라 사람을 집단으로 뭉쳐 부르는 방식입니다. 상황을 적으려면 누가 언제 무엇을 하다가 막혔는지를 먼저 알아야 하니 오히려 더 구체적인 관찰이 필요합니다. 이 오해를 그대로 두면 사용자 조사를 건너뛰고 문장만 양식에 맞춰 적는 팀이 됩니다.