UI.UX / 화면 설계서 이야기.3

PART.4 화면 설계서 구성요소 - Revision History

이 내용 언제 변경되었나요?
왜 변경되었을까요?

독자가 서비스 기획자라면 이와 같은 질문은 한 번씩 들어봤을 것이라 생각한다.

이런 질문을 받게 되었을 경우 필자의 과거를 떠올렸을 때 조금은 삐딱하게 생각했던 기억이 있다. '질문을 한 그대여 변경 내용은 당신이 요청한 거잖아요?' or '당신도 그 자리에서 변경 내용을 같이 들었고, 회의록 또한 공유받았잖아요'라는 생각으로 말이다.

하지만 이런 식의 삐딱한 생각은 자신을 성장시키는 데에 도움이 되는 것은 아무것도 없다. 결국 이 또한 문제라 판단하여 자주 잊어버리는 그대의 상사 또는 클라이언트에게 도움이 될 수 있도록 무언가를 해야 한다는 것이다. 굳이 그런 노력을 해야 한다고 생각하는가? 그런 생각이 든다면 본인은 일을 잘하고 싶은 마음이 없는 사람이라고 생각이 든다. 일을 잘하는 것은 결국 상대방이 원하는 것을 잘해주는 것이다.

[일을 잘하고 싶다는 마음을 전제로]

다시 본론으로 들어가, 그렇다면 웹/앱 및 서비스 기획자는 자신의 상사 또는 클라이언트가 변경 내용의 히스토리를 물어본다면 어떻게 해야 할까?

[머릿속에 저장]

기획자가 굉장히 똑똑하고 기억력이 좋은 사람이라면, 언제 그리고 왜 변경되었는지 기억할 수는 있을 것이다. 하지만 설령 그렇다 한들 상대방도 같은 기억력을 가지고 있지 않기 때문에 기획자 본인의 머릿속에 있는 것은 상대방을 설득하기에는 턱 없이 부족할 수밖에 없다. 이유인즉슨 기억 속에 있는 것 만으로 얘기했을 경우 상대방에서 돌아오는 말들은 대부분 '난 그런 적 없는 것 같은데?' '그렇게 협의하지 않았어요.' '언제 얘기했나요? 제가 그 자리에 있었나요?' 등 수많은 이유를 들면서 기억이 안나는 점을 방어하려고 하기 때문이다. 그럼 어떻게 바뀐 내용을 전달해야 하는 것일까?

[공유하고 알리기]

회의록을 작성하고 공유하는 서비스 기획자

일반적으로 협의 내용을  협의 대상자에게 공유하는 방법은 '회의록'이 대표적이다. 다만 필자는 회의록을 공유하고 나서, 주요 대상자에게 반드시 메신저 또는 개인 연락으로 '공유했습니다'라고 한번 더 알려드리는 편이다. 그것이 곧 공유의 결정적 증거이자 상대방에 대한 배려라고 생각하기 때문이다. (안 해도 문제는 없지만, 하는 편이 훨씬 좋다는 점을 체감으로 느꼈다.) 그럼 공유하는 방법은 회의록만 있는 것일까?

[개정이력 - Revision History]

이것을 언급하기 위해 빌드업이 길었다. 위에서 설명한 '회의록' 자체는 특정 회의 또는 미팅이 이루어진 날의 내용들만을 기록하여 공유하는 수단이었다면, 개정이력이라는 것은 실제 산출물이 될 수 있는 문서에서 변경되는 내용을 관리할 수 있는 포맷이라 볼 수 있다.

개정이력을 적용할 수 있는 문서는 다양하지만 그중에서도 서비스 기획자가 주로 작성하는 [화면 설계서]를 대상으로 어떻게 적용되는 살펴보자.

[개정이력 다시 한번 왜 필요한가]

적용 방법을 살 편 보기 전 다시 한번 화면 설계서에서 개정이력(revision history)이 '왜' 필요한지에 대해서 간략하게만 살펴보자.

화면설계서는 온갖 정책과, 화면에 대한 정의들로 이루어져 있다. 이 내용들은 요구사항 시작인 현업부서 또는 클라이언트부터 시작하여 디자인팀, 마크업팀, 프런트엔드 & 백엔드 개발팀, 네이티브 개발팀, DB, 보안팀 등 수많은 부서들이 확인하게 된다. 어렵게 협의된 내용이, 변경되는 내용 없이 끝까지 흘러가면 좋겠지만, 제품이 만들어지게 되면서 반드시 수정사항은 나오기 때문에, 설계서의 오너인 기획자는 언제 어떠한 사유로 변경이 되었는지 기록 및 관리하여 제품을 개발하는 각 담당자들에게 혼선 없이 내용들을 알려줄 의무가 있다. 개정이력을 제대로 관리하지 않을수록 담당자들은 제 각각 다른 내용의 제품을 개발하고 있는 상황이 벌어지게 될 것이다.

[개정이력 작성방법]

문서를 작성한 시점부터 개정이력을 작성한다.

1) 변경일

문서를 작성 또는 수정한 날짜를 기입한다.

2) 버전

문서의 버전을 작성한다. (마지막 문서의 버전과 개정이력의 마지막 버전은 동일해야 한다.)

3) 변경내용

문서를 확인하는 담당자들이 찾아갈 수 용이하도록 페이지수를 같이 기입한다. 이때 변경된 사유를 함께 기입하게 될 경우 Hisotory 추적과 원인을 훨씬 명확하게 파악할 수 있다.

[ex]

P.5

- UI 변경 (Drop box에서 Radio button으로 변경)

- 사유: 선택항목이 2개이므로 Radio button을  사용하여, 항목 확인과 선택을 쉽게 변경하기 위해 수정 (수정 요청자: 현업부서 홍길동)               

4) 작성자

문서를 작성하거나 수정한 사람의 이름을 기입한다. 작성된 내용이 오류가 있거나 누락이 있을 시 해당 작성자에게 문의 또는 컴플레인?을 할 수 있다.

[끝으로]

프로젝트에서 히스트로리를 추적하는 것은 매우 중요한 부분이다. 우리 인간은 망각의 동물이기 때문에, 어제 먹은 점심도 기억하지 못하는 경우가 태반이다. 하물며 전쟁터 같은 직장에서 오고 가는 결정 사항들이 한두 개가 아닌데 그것을 모두 기억하기란 사실상 불가능에 가깝다. 따라서 변경된 히스토리를 기록하고 관리하여, 의사결정 내용들이 쉽게 엎어지지 않도록 적극적으로 신경을 써야 한다. 여기서 중요한 부분은 단순 기록 관리가 아닌, 왜 변경되었는지까지 꼼꼼하게 기록하고 공유하도록 하자.

내 자신은 누가 지켜주지 않는다.

끝.