by
Aug 05. 2020
프로젝트 용어
같이 쓰는 말인데 서로 다르게 이해하고 있을 때
사용하는 용어와 약어가 기업마다, 업종마다 다르게 사용되어 애를 먹게 되는 경우가 있습니다.
POC만 하더라도 어떤 기업에서는 개념 증명(Proof of Concept)이라는 뜻으로 사용하지만,
몇몇 기업에서는 접점(Point Of Contact)이란 뜻으로 사용하며 자사가 보유한 여러 고객 대면 채널을 지칭합니다.
서로 생각하고 있는 용어가 다른 경우 커뮤니케이션에 혼선이 와서 문제가 발생할 때도 있습니다.
저도 여러 번 겪었던 기억이 납니다. 오늘은 그 이야기를 해보겠습니다.
시나리오, 스토리보드, 화면 정의서
디지털 에이전시에서는 스토리보드와 화면 정의서(또는 화면 설계서)를 혼용해서 쓰는 경우가 많습니다.
뜻을 따져보면 엄연히 다르지만, 문서 내에 화면 흐름과 화면 구성, 인터랙션에 대한 설명을 모두 표현해 놓기 때문에 그렇게 혼용해서 사용하더라도 크게 문제가 되지는 않습니다.
한 번은 모 기업 영업지원시스템을 만들기 위해 초기 설계 단계에 기획 컨설턴트, 개발 PL, 그리고 UI 기획 및 디자인 PM으로서 저까지 세 명이 함께 일을 한 적이 있습니다. 모두 다른 회사 소속이었는데 "스토리보드" 의미가 달라 한참을 진도를 못 나갔던 기억이 납니다.
"스토리보드는 제가 정리해볼게요."
내가 할 줄 알았던 일을 기획 컨설턴트가 하겠다는 이야기에 '디자인 PM 업무만 집중할 수 있겠군'이라고 생각하며 개발 PL과 함께 알겠다고 하고는 완료 날짜를 기다렸습니다. 그러나 정리된 문서는 제가 생각했던 스토리보드(화면 정의서) 형태의 문서가 아니었습니다. 일종의 시나리오가 일부 녹아 있는 스케치에 가까웠습니다.
구체적인 스토리보드(화면 정의서)를 예상했으나 전혀 그렇지 않았던 것입니다.
개발 PL은 화면 정의서가 나오면 바로 개발에 필요한 인터페이스 정의 작업을 들어가려 했는데 진행할 수 없는, 고스란히 1~2주 정도가 날아간 상황이 되어 버렸습니다.
왜 이렇게 꼬인 것인지 셋이 머리를 모아봤습니다. 기획 컨설턴트가 생각한 스토리보드는 말 그대로 '초안'이었습니다.
결국 서로 산출물에 대해 잘못된 시각을 갖고 있었다는 것을 확인하고는 바로잡아 진행했던 기억이 납니다.
화면 목록, IA(Infmation Architecture, 정보구조)
이번엔 문서작성에 사용하는 툴(excel)이 동일하고 모양새가 비슷해서 벌어진 일입니다.
프로젝트 초기 요구사항이 어느 정도 확정되면 필요 기능을 도출하고 화면 목록과 정보구조도(IA, Infmation Architecture)를 작성하게 됩니다.
정보구조도는 조직도 형태로 대 메뉴(1 depth), 중 메뉴(2 depth), 소메뉴(3 depth)까지를 표현하는 게 일반적이지만, 팝업과 탭(tap) 방식의 UI까지 전체적으로 표시하기 위해 어느 단계 이후에는 엑셀 파일로 관리합니다.
이렇게까지 만들다 보면 엑셀의 행이 제작해야 하는 화면의 개수와 일치하게 되는데, 이때부터는 'IA = 화면 목록'이라고 말할 수 있게 됩니다.
"아직까지 IA가 확정 안되었다는 게 말이 되나요? 그러면 개발은 언제 하나요?"
한 프로젝트에서 개발 PL이 기획 PL에게 따지고 물었습니다.
기획 PL은 고객이 아직 확정을 안 해주는데 자신인들 어떻게 하냐고 목소리를 높입니다.
저도 개발 PL과 같은 생각이었습니다. 이미 기획자들이 화면 설계서를 거의 다 만들었고, 상세 화면들이 나왔다는 것은 서비스에 들어갈 메뉴와 기능이 정의되었다는 뜻인데 정보구조가 확정이 안되었다는 것이 이해가 안 갔습니다.
좀 들여다보니, 결국 개발 PL은 개발자들에게 업무 배분과 화면 코드를 따기 위해 화면 목록을 달라고 한다는 것이 IA 달라고 한 것이었고, 기획 PL은 전체적인 정보구조(메뉴 구조)에 대한 확정을 못 받았기 때문에 IA가 아직 초안인 상태라 못주겠다고 하는 상황이었습니다. 이미 완료되어 전달해줘도 되는 화면 목록을 가지고 있음에도 말이죠.
대형 사이트의 경우 IA가 늦게까지 확정되지 않을 때도 있습니다.
특정 중/소 메뉴가 대 메뉴로 올라가야 한다거나, 어떤 메뉴들은 합쳐야 한다거나 하는 등의 결정이 나중에 되거나 오픈 직전 바뀌기도 합니다. 그런다고 해서 개발해야 하는 화면의 개수가 바뀌는 것은 아니기 때문에 정보구조 확정되지 않은 상태로 개발이 진행될 수도 있습니다.
어쨌든 필요한 사항들을 설명하고 대화했다면 금세 해결했을 법안 일이었는데 힘겨루기를 하다 보니 서로 감정은 상하고 일정은 지연되고 있었습니다.
잘잘못 따지고 바로잡기에는 시간이 부족해서 결국 화면 목록은 PM이나 당시 사업관리자로 들어가 있던 제가 취합해서 정리해야 했는데, 그냥 제가 하기로 하고 마무리했습니다.
오래간만에 1,000본이 넘는 화면 목록을 다루었으나, 그만큼의 화면을 정리했던 옛 프로젝트 추억에 잠길 틈은 없었던 기억이 납니다.
이렇듯 당연하다고 생각하는 용어, 특히 문서명 등의 이해에 대한 차이로 벌어지는 이슈가 의외로 많은 것이 프로젝트입니다. 특히 늘 일해오던 사람들이 아닌 '프로젝트' 때문에 모르던 사람들이 모여서 일하는 경우에 이런 일이 더 많이 발생합니다.
아래와 같은 것들이 주로 차이가 있음에도 혼용되며 커뮤니케이션이 잘못될 수 있는 것들입니다.
요구사항 정의서, 요구사항 명세서, 요구사항 추적 표
와이어프레임(Wireframe), 프로토타입(Prototype), 목업(Mockup), 스토리보드, 화면 설계서, 정책서
정보구조도(IA), 화면 목록, 프로그램 목록
테스트 시나리오, 테스트 결과서
