기능 명세

무엇을 왜 만들지가 정해져도 만들기는 시작되지 않습니다. 그 사이에 결정이 수십 개 남아 있기 때문입니다. 초대 기능이라면 초대 메일을 며칠 뒤에 만료시킬지, 만료된 링크를 누른 사람에게 무엇을 보여 줄지, 이미 초대한 주소를 다시 넣으면 어떻게 할지가 남아 있습니다. 어느 것도 크지 않지만 저절로 정해지지도 않습니다.

이 결정들이 문서에 없으면 만드는 도중에 하나씩 튀어나옵니다. 태오가 하루에 네 번 묻고, 지현이 그때마다 답하고, 답은 대화창에만 남습니다. 두 주 뒤 검수에서 "만료된 링크를 눌렀는데 빈 화면이 뜬다" 는 말이 나오면 그건 잘못 만든 것이 아니라 정해진 적이 없는 것이고, 다시 정하고 다시 만드는 왕복이 붙습니다.

문서 대신 시안으로 때우는 경우도 같은 자리에서 막힙니다. 시안은 대개 잘 풀렸을 때의 화면 하나만 보여 줘서, 목록이 비었을 때나 서버가 답하지 않을 때의 화면은 거기에 없습니다.

기능 명세는 만들기 직전에 이 결정들을 한곳에 모으려고 쓰는 문서입니다. 조건과 결과를 짝지어 적어 두면 만드는 동안 나올 질문이 문서를 쓰는 동안 앞당겨 나옵니다. 질문의 총량이 주는 것이 아니라 값싼 시점으로 옮겨 가는 것입니다.

문서는 다섯 칸으로 채웁니다. 순서에도 뜻이 있어서 무엇을 다루는지가 먼저 오고, 그 안의 요소와 동작이 뒤따르고, 마지막에 끝났다고 부를 기준이 옵니다.

1. 대상과 범위 — 이 문서가 다루는 화면과 기능이 어디까지인지를 첫 줄에 못 박습니다. 초대 기능을 적으면서 초대받은 사람의 가입 절차까지 포함하는지를 여기서 정하지 않으면 읽는 사람마다 다른 크기의 일을 그립니다.
2. 요소 목록 — 화면에 놓이는 것을 빠짐없이 셉니다. 버튼과 입력칸뿐 아니라 안내 문구, 아무도 초대하지 않았을 때 보이는 화면, 목록을 불러오는 동안 보이는 표시까지 항목으로 세웁니다.
3. 동작과 조건 — 누르면 무엇이 일어나는지를 조건과 짝지어 적습니다. "보내기를 누르면 초대가 발송된다" 는 절반이고, 권한을 고르지 않았을 때·이미 초대된 주소일 때·한도를 넘겼을 때가 붙어야 한 칸이 찹니다.
4. 예외와 오류 — 정상 경로가 아닌 경우를 모읍니다. 네트워크가 끊겼을 때, 같은 버튼을 두 번 눌렀을 때, 권한이 없는 사람이 주소를 직접 열었을 때 무엇을 보여 줄지가 여기 들어갑니다. 실무에서 되묻는 질문의 대부분이 이 칸에서 나옵니다.
5. 인수 조건 — 이 기능이 끝났다고 인정받기 위한 조건입니다. 체크할 수 있는 문장으로 적어야 검수하는 사람이 목록을 그대로 따라갈 수 있습니다.

문장만으로 읽기 어려워지는 부분은 그림을 함께 붙입니다. 거치는 화면이 여럿이고 갈라지는 지점이 많으면 플로우 차트로 순서를 그리고, 하나의 대상이 여러 상태를 오가면 상태 다이어그램으로 상태와 그 사이의 길을 그립니다. 초대 한 건이 발송됨·수락됨·거절됨·만료됨·취소됨을 오간다면 그림 한 장이 문장 열 줄보다 빠릅니다.

규칙이 이 화면을 넘어 제품 전체에 걸리면 그 부분은 제품 정책으로 뺍니다. 초대 권한을 어떤 등급이 가질 수 있는지는 모든 문서와 모든 요금제에 걸리는 규칙이고, 같은 규칙을 두 곳에 적으면 한쪽만 고쳐지는 날이 옵니다.

쓰는 쪽은 대개 그 기능을 맡은 프로덕트 매니저이고, 화면 안의 상태가 많은 기능은 디자이너가 같이 채웁니다. 꾸밈 없이 구조만 그린 와이어프레임을 먼저 놓고 그것을 보며 채우는 순서가 흔합니다.

읽는 쪽은 셋이고 각자 다른 칸을 봅니다.

1. 개발자 — 동작과 조건, 예외와 오류를 보고 얼마나 걸릴지 답합니다. 만들 경우의 수가 곧 일정이라, 이 두 칸이 비면 추정 자체가 성립하지 않습니다.
2. 디자이너 — 요소 목록을 보고 그려야 할 상태가 몇 개인지 셉니다. 요소 여섯 개에 비었을 때와 오류일 때가 붙으면 화면이 열 장을 넘깁니다.
3. 품질 보증 — 인수 조건과 예외 칸을 그대로 검수 목록으로 옮기므로, 적히지 않은 경우는 검수에서도 빠집니다.

쓰는 일은 한 번으로 끝나지 않습니다. 만드는 동안 바뀐 결정이 문서로 돌아오지 않으면 두 주 만에 낡고, 낡은 문서는 없는 것보다 나쁩니다. 없으면 사람들이 묻기라도 하는데, 낡은 문서는 아무도 의심하지 않고 그대로 만듭니다.

"기능 명세 아직 안 나왔죠? 상태가 몇 개인지 몰라서 추정을 못 하겠어요."

경우의 수가 정해지지 않아 일정을 답할 수 없다는 뜻입니다.

"그건 명세에 없던 건데요. 추가하려면 일정 다시 봐야 합니다."

합의된 범위 밖의 요청이라 시간 협의를 다시 열자는 말입니다.

"명세는 고쳤는데 공유를 안 했네요. 지금 버전 다시 보내 드릴게요."

문서와 실제 결정이 어긋난 상태를 바로잡는 말입니다.

페이지덱에서 초대 기능을 다시 만들던 주에 지현이 명세 초안을 돌렸습니다. 민서가 먼저 요소 목록을 보고 빠진 화면 셋을 짚었습니다. 아직 아무도 초대하지 않았을 때, 한도를 다 썼을 때, 목록을 불러오는 중일 때로 셋 다 시안에는 없던 화면입니다.

태오는 예외 칸에서 만료된 초대를 수락하면 어떻게 되는지가 빠진 것을 짚었습니다. 지현이 상태 다이어그램을 그려 보니 만료됨에서 수락됨으로 가는 화살표가 아예 없었고, 없는 길을 막는 화면 한 장이 그 자리에서 추가됐습니다. 문서에 이틀이 들었고 검수까지 안 나왔을 질문 대여섯 개가 그 이틀에 처리됐습니다.

개발 전에 한 번 쓰고 끝내는 문서로 읽는 경우가 가장 많습니다. 만들기 전에 정하려고 쓰는 문서이니 다 쓰면 역할이 끝난 듯 보입니다. 하지만 만드는 동안 결정은 계속 바뀝니다. 한도를 스무 명에서 쉰 명으로 올린 결정이 문서에 없으면 두 달 뒤 검수하는 사람은 스무 명을 기준으로 판정합니다.

시안이 있으면 명세가 필요 없다고 읽는 것도 흔합니다. 화면이 다 그려져 있으니 글로 또 적을 것이 없어 보입니다. 그림이 보여 주는 것은 한 시점의 장면이고, 명세가 적는 것은 장면과 장면 사이의 조건입니다. 한도를 넘겼을 때 초대 버튼이 눌리지 않는다는 규칙은 그림에 담기지 않아서, 시안만 들고 만들면 그 규칙은 만드는 사람이 정하고 검수에서야 드러납니다.