brunch

You can make anything
by writing

C.S.Lewis

by X PLEAT Oct 22. 2019

신입으로 애자일한 협업에 도전하기

프로젝트 종료 후 협업 프로세스 돌아보기ㅣ송보령, 최고운, 한승희

엑스플리트는 R&A, UX/UI, GUI 파트 그리고 디렉터가 유닛을 이루어 프로젝트를 수행합니다. 파트 간 유기적으로 협업하며 서로 의견을 적극적으로 공유하고, 프로젝트 완료 후에는 노하우를 공유하고 문제점을 찾아 개선점을 논의하는 'Teach&Share' 문화를 가지고 있습니다. 지난 Teach&Share에서 나온 개선점을 가지고 애자일하게 협업하기 위한 구체적인 개선 방안을 정리하여 공유하려고 합니다.

Unit (Project 팀)

업무계획 작성으로 해야 할 일과 진척상황을 지속적으로 공유하기

엑스플리트를 위한 월간/주간 업무 계획표 재정의

우리는 이미 머릿속에서 자신이 어떤 일을 해야 하는지, 적어도 이번 주까지는 작업을 어디까지 끝내야 할지에 대한 생각을 갖고 있습니다. 다만 잘 지켜지지 못할 뿐이죠. 그게 상황 때문이던, 작업 속도 때문이던 반복적으로 같은 일이 반복된다면 분명 본인에게도 팀에게도 좋지 않은 결과를 가져다줄 것입니다. 그러한 악순환을 막기 위해 각자의 업무 계획과 진행 상황을 가시화해보기로 했습니다.

<AS IS>

매일 퇴근 전 업데이트했던 주간 업무 계획표

주어진 데드라인에 맞추어 공동의 목표를 수행하기 위해서는 명확한 목표를 세우고 계획에 따라 움직이려는 노력이 매우 중요합니다. 그러기 위해서 각 팀원은 개인의 업무계획을 지켜나가는 것뿐만 아니라 나머지 팀원들에게 나의 일정을 '잘' 공유해야 합니다. 현재 저희 팀원들은 주 단위로 간략하게 본인의 업무 내용을 기록하며 프로젝트를 수행해왔습니다. 하지만 규칙이 부족한 상태로 기록을 했기 때문에 각자의 업무 우선순위나 진행도, 이슈 등을 파악하기에는 어려웠죠. 그래서 서로의 업무 내용을 더욱 디테일하고 빠르게 파악할 수 있는 일정 기록 표를 다시 만들어보았습니다.

<TO BE>

ex. 월간 업무 계획표

평균적으로 3달 정도 진행되는 프로젝트의 전체 계획을 월간 계획표를 통해 수립한 후, 세부적인 업무 일정을 주간 계획표에 기록하여 확인할 수 있도록 했습니다. 월간 업무 계획표는 우리에게 중요한 일들이 순서대로 잘 해결되고 있는지 확인할 수 있는 지표이며, 프로젝트의 큰 방향을 방향을 설정하는데도 중요한 역할을 할 수 있습니다.

먼저 주간회의 또는 업무회의 때 공동의 목표를 다 같이 확인하며 이루어져야 하는 작업의 우선순위를 함께 고민하여 작성합니다. 1. 꼭 해야 할 일/ 2. 해두어야 할 일/3. 해두면 좋은 일 순으로 작성하여 모든 일을 시간 내에 끝내기 힘든 상황에서도 가장 중요한 일들은 끝낼 수 있도록 했습니다. '드롭박스 페이퍼' 툴을 활용하여 작성한 업무에 할당할 인원을 태그 하거나 마감기한을 설정하고, 업무 완료 시에는 체크박스를 눌어 완료됨을 표시하도록 했습니다. 그러면 같은 프로젝트를 수행하는 팀원들이 현재 프로젝트 진행 상황을 디테일하게 체크할 수 있겠죠. 그 밖에 따로 요청할 사항을 적거나 주 별 이슈가 있다면 적을 수 있는 란을 만들어 업무 외 일정에 대해서도 한눈에 파악할 수 있도록 했습니다.

ex. 주간 업무 계획표 a.k.a 업무 일기

주간 업무 계획표에서는 개인이 작업 목표를 계획하고 달성하는 과정을 경험할 수 있고 그를 통해 흐트러지는 일정을 바로 잡을 수 있습니다. 하루의 시간을 얼마나 효율적으로 사용하고 있는지 수시로 확인하기 위해 자주 업데이트하는 것이 중요합니다. 본인의 업무를 오전/오후로 나누어 기록하여 할당된 업무 중 중요한 것부터 집중해서 처리할 수 있고 누락된 업무도 빠르게 확인할 수 있습니다. 이러한 기록 방식은 전체 프로젝트의 진척 상황과 협업하고 있는 다른 팀원들의 업무 속도를 파악하기에도 용이합니다. 작업 중 생기는 고민이나 요청사항은 '오늘 있었던 일'에 기록하고 원활히 공유하여 함께 일하는 동료들이 서로의 상황을 계속해서 확인하고 이해할 수 있도록 했습니다.

정신없이 빠르게 프로젝트가 진행되고 나면 각 태스크 별로 어떤 문제가 있었는지 제대로 확인하기가 어렵습니다. 이렇게 업무 계획표를 꾸준히 능동적으로 작성하고 확인해 간다면 프로젝트 종료 후 회고하는 시점에서도 기록을 보며 디테일하게 개선점을 이야기할 수 있을 것입니다.

UI와 GUI는 업무영역을 명확하게 구분 지을 수 없고 서로의 작업물에 많은 영향을 끼치기 때문에 밀접한 협업이 요구되는 관계입니다. 그런 만큼 무엇보다 UI-GUI 간 공동작업 과정에서 많은 어려움을 느꼈고 결국 이 과정상의 비효율을 해결해야 전체 프로젝트의 진행과 결과물의 수준이 좋아질 수 있겠다는 생각이 들었습니다. 따라서 현재 저희의 UX/UI-GUI 협업 과정을 개선하기 위한 방법들을 정리해보았습니다.

UX/UI-GUI 간에는 훨씬 더 효율적인 협업방식이 필요하다.

작업 전 디자이너 간 합의하는 과정 거치기

스케치 라이브러리(UI Kit)을 활용한 통일성 있는 와이어프레임 작업

여러 디자이너가 함께 와이어프레임을 진행하다 보면 크고 작은 이슈들이 발생하기 마련입니다. 프로젝트에서의 구체적인 예를 들면 디자이너 간의 와이어프레임 디테일 수준이 상이하고 작업 스타일이 달라 작업 이후 UI의 일관성을 위해 싱크를 맞춰야 하는 소모적인 과정이 발생했습니다. 이러한 문제들을 해결하기 위해서 작업 이전에 챙기고 가야 할 요소들에 대해 서로 합의할 필요성을 느끼게 되었습니다. 그래서 엑스플리트의 현재 상황과 조건을 고려해 우리의 업무 성격과 방식에 잘 적용될 수 있는 적절한 방법을 생각해 보았습니다.

저희의 경우 하나의 프로덕트를 지속적으로 운영하는 것이 아니라, 정해진 기간 동안 여러 가지 프로젝트를 컨설팅하는 일을 하기 때문에 다양한 프로젝트에 유연하게 적용할 수 있는 스케치 라이브러리를 적극적으로 사용하는 것이 유용하겠다고 생각했습니다.

와이어프레임 협업을 위한 공통 라이브러리

잘 합의하고 정의된 라이브러리를 사용하면 작업 과정 중 혼돈의 여지를 줄일 수 있습니다. 또한 UI의 일관성을 위해 소요되는 시간을 줄일 수 있고 처음부터 같은 용어(네이밍)의 컴포넌트를 사용하게 되기 때문에 더욱 명확한 커뮤니케이션이 가능해집니다. 이어지는 GUI 디자인 단계에서도 화면의 기능 및 콘텐츠 파악이 용이해져 결국 UX/UI와 GUI 간의 협업이 더욱 긴밀해질 수 있습니다. 새로운 사람과 처음 손발을 맞춰 협업해야 하는 경우라면 더더욱 가이드를 활용하여 효율을 낼 수 있습니다.

협업을 위한 화면 명세서 작성법과 기준

라이브러리 이외에도 화면 명세서 작성 기준이나 스케치 플러그인 등에 대해 사전에 합의하면 원활하게 협업할 수 있는 환경을 만들 수 있습니다.

툴을 활용하여 작업물 공유하고 피드백하기

abstract을 활용한 협업 효율 극대화

애자일하고 빠르게 업무가 진행되는 상황에서 무한으로 생성되는 수정 파일 관리와 수정사항 공유, 그리고 그에 한 빠른 피드백은 매우 중요합니다. 그래서 자잘한 공유시간을 가지고 주기적으로 회의하지만 그럼에도 불구하고 작업의 흐름이 매끄럽지 못한 부분이 있었습니다.

엑스플리트는 개발자와의 커뮤니케이션이 많지 않기 때문에 Zeplin과 같은 툴 대신 Sketch를 주로 사용하여 작업합니다. 작업한 파일은 드롭박스에 올려 공유하고 스케치 프로그램을 사용하지 않는 나머지 팀원들을 위해서는 이미지 파일을 추출하여 드롭박스에 업로드합니다. 그리고 이 같은 과정에서 수많은 수정 파일과 폴더들이 생성되고 결국엔 최종 파일을 찾지 못하는 상황이 발생하게 됩니다. 작업 시스템이 완전히 갖춰지지 않은 초기 상태에서 이러한 사소한 문제들은 끊임없이 발생하기 때문에 빠르게 해결할 수 있는 방법을 찾아야겠다고 생각했고 그 결과로 앱스트랙 도입을 고려하게 되었습니다. 앱스트랙을 사용했을 때 어떤 문제를 해결할 수 있고 저희의 작업환경이 어떻게 개선될 수 있을지를 몇 가지 예시로 들어보겠습니다.

1. 무한으로 생성되는 작업파일 버전관리

여러 디자이너가 화면 작업을 나누어하게 되면 어느 시점에서는 서로의 작업물을 공유하고 하나로 통합하게 됩니다. 이 과정에서 제대로 된 파일을 주고받고 커뮤니케이션하는 일은 아주 중요합니다. 그렇지 않으면 서로에게 큰 혼란을 줄 수 있기 때문입니다. 드롭박스에 파일을 업로드하고 다운로드하는 방식으로 파일을 공유하면서 수많은 폴더 중 필요한 파일을 찾는 일은 매우 번거로운 일이었고 그에 따른 혼란을 겪었습니다.

* 마스터파일과 브랜치 파일

회사 계정(xpleat) 내 프로젝트(New Project)를 생성하고 마스터 파일(항공_APP) 불러오기

브랜치의 브랜치의 브랜지..+@

앱스트랙에서는 수정 파일이 지속적으로 생성되어도 원본 파일에는 영향을 끼치지 않고, 체계적으로 수정 기록을 남길 수 있습니다. 여기에서 원본 파일은 마스터 파일, 원본 파일에서 가지를 치듯이 생성되는 수정 파일을 브랜치 파일이라고 합니다. 브랜치 파일을 생성할 때 네이밍을 "날짜_수정한 사람 이름'으로 통일시키면 언제, 누가 수정한 파일인지 확인하고 사용할 수 있습니다. 이렇게 된다면 서로가 서로의 파일을 교차해서 수정해야 할 때나 누군가 이어서 수정해야 할 때 파일을 빠르게 발견하고 수정할 수 있겠죠.

*브랜치 파일의 Merge(통합) 기능

브랜치 파일은 마스터 파일에 머지(통합)하기

따로 저장해놓아야 하는 파일은 Archive하기

앱스트랙에서는 브랜치 파일을 마스터 파일에 Merge(통합) 시킬 수 있습니다. 이 기능으로 수많은 수정 파일들을 자연스럽게 정리할 수 있고 이후 드롭박스에는 깔끔하게 정리된 버전별 파일만 업로드할 수 있습니다. Merge 시켜버린 브랜치 파일들은 자동으로 사라지므로, 보관이 필요한 중간 파일이 있다면 Archive 기능으로 따로 저장해 놓을 수도 있습니다.

2. 모든 팀원과의 작업물 공유

작업물의 변동 사항이 많은 상황에서 한 화면을 다수가 동시에 작업하거나 다수가 동시에 확인해야 하는 상황이 있습니다. 물론 이런 상황에서 작업자끼리 최대한 자주 접촉한다면 이상적인 협업이 이루어질 수 있겠지만 빠듯한 일정 아래에서 저희는 매번 그런 식으로 소통하기에 시간이 부족했고, 그만큼 피드백의 주기도 길어질 수밖에 없었습니다.

* 화면별 수정사항 확인/최대 다수에게 피드백 수렴

이전 파일과 수정한 파일을 함께 높고 비교/대조해보기

수정한 포인트에 대해 구체적인 의견 나누기

앱스트랙에서는 스케치를 실행하지 않고도 바로 화면별 수정사항을 확인할 수 있습니다. 게다가 원본과 수정된 화면을 동시에 보고 전/후를 비교할 수도 있습니다. 수정된 부분에 대한 코멘트를 화면별로 남길 수 있어 자잘한 수정 사항들에 대해 빠르고 구체적으로 피드백을 나눌 수 있고 무엇보다 스케치 프로그램을 사용하지 않는 팀원들도 피드백을 자유롭게 남길 수 있기 때문에 이 기능을 통해 기존에 의견을 얻기 힘들었던 화면 작업을 하지 않는 팀원들에게도 더 풍부하게 피드백을 받을 수 있을 것이 기대됩니다.

* 수정사항 확정 여부에 대한 리뷰 및 승인 요청

특정 팀원에게 승인/리뷰 요청하기 -> 요청받은 팀원이 승인/리뷰해주기

수정 사항을 확정하고 원본 파일에 Merge 하기 위해 최종 확인을 요청할 경우, 특정 인물에게 리뷰 요청을 보낼 수 있습니다. 요청을 받은 사람이 승인 또는 재요청을 할 수 있고 의견을 남길 수 있습니다. 이 기능을 통해서는 수정사항을 확인하고 확정하는 과정을 단축하고 작업 템포를 빠르게 할 수 있을 것으로 보입니다.

업무의 기초이자 기본, 파일 관리

프로세스를 고려한 폴더 정리 구조 재정비

여러 명의 구성원이 함께 사용하고 접근하는 만큼 폴더를 정리하는 데 있어 규칙을 정해야 합니다. 그래야 파일 관리에 소요되는 시간을 줄이고 업무에 더욱 집중할 수 있습니다. 현재 저희는 '드롭박스'를 활용해 구성원들과 프로젝트 파일을 공유하고 있는데, 프로젝트 도중 파일이 무수히 생성될 때 개인의 기준에 의해 분류되다 보니 빠르게 원하는 파일을 찾는 것이 어려웠습니다. 그래서 더 명확한 폴더 계층구조와 파일명 규칙을 개선하는 방법에 대해 고민해보았습니다.

<AS IS>

기존 드롭박스 폴더링

기존의 폴더링 규칙

현재 파일은 대부분 작업 프로세스 순으로 추가된 폴더를 기준으로 정리되고 있었고, 우선적으로 빠르게 확인해야 하는 폴더는 @가 앞에 붙여져 상단에 고정되어있었습니다. 그 외에 중요도가 떨어지고 오래된 파일은 99로 넘버링 해 아래로 가게 하거나 백업용은 OLD로 묶어 분류했습니다. 하지만 프로젝트가 진행될수록 @를 달아 우선적으로 노출시키는 폴더의 수가 많아지고 폴더명이 포괄적이게 되어 어떤 위치에 어떤 파일이 있는지 쉽게 유추할 수 없는 문제가 발생하곤 했습니다. 이러한 문제가 왜 발생했는지 잘 들여다보니 클라이언트와 커뮤니케이션하는 상황이 많아 외부 커뮤니케이션용 파일과 워크샵 등의 진행에 필요한 파일이 따로 필요하고, 내부의 작업기록용 파일들도 동시에 계속 정리되어야 하는 상황임을 알게 되었습니다.

<TO BE>

1. 폴더 구조 규칙 재정의

폴더구조 개선 안

이러한 상황에서 각자가 원하는 파일을 쉽게 찾을 수 있게 하기 위해 2가지 기준으로 폴더 구조를 재정리해보았습니다. 첫째는 누구나 유추하기 쉽게 수행 단계 즉 시간순으로 넘버링한 것이고, 둘째는 수시로 자주 사용하는 파일은 별도로 분리해 빠르게 접근할 수 있도록 한 것입니다.

◦1 Depth → 외부 커뮤니케이션용 / 내부 작업 기록용 파일을 구분합니다.

◦외부용

∙2 Depth → 큰 프로세스 별(Discover/Define/Develop/Deliver)로 자료를 보관합니다.

∙3 Depth → 보고용 자료 (PPT/PDF)

◦내부용

∙2 Depth → 프로젝트 수행단계 별로 자료를 보관합니다. (프로젝트에 따라 수행단계는 변동될 수 있음)

∙3 Depth → 작업 단계가 보이도록 파일을 생성합니다. 모든 2 Depth 파일에는 @최종 산출물 파일이 있습니다.

2. 폴더 및 파일 네이밍 규칙 재정의

파일 네이밍 규칙은 내부의 협업에도 중요하지만 외부로 파일을 주고받는 경우에도 파일명만으로도 목적과 용도를 파악할 수 있어야 하기 때문에 중요합니다. 외부로 공유되는 문서의 경우 파일명에 [회사면_[프로젝트명]을 먼저 붙여 문서를 전달받는 클라이언트가 확인하기에 용이합니다. 그러나 내부 작업물의 경우 프로세스 폴더로 이미 어느 정도 구분이 된 파일이기 때문에 이 파일이 제안서인지, 화면 설계서인지 종류를 확인하는 것이 더 중요합니다. 그래서 내부의 작업 파일에는 작은 단위에서 큰 단위로 네이밍을 하는 것을 기본으로 하여 파일 종류를 쉽게 파악할 수 있도록 해야 합니다. 사소할 수 있는 부분이지만 이렇게 프로젝트 중간중간 폴더와 파일명을 신경 써서 정리해놓으면 시간이 지나도 생각나는 파일을 쉽게 찾아 활용할 수 있고, 결과적으로 앞으로의 업무 효율도 함께 높아질 수 있을 것입니다.

마치며...

프로젝트를 제대로 경험해보기 전에는 팀원의 수가 많지 않기 때문에 협업이 원활할 것이라 생각했습니다. 하지만 생각보다 문제 상황들도 많았고 맞춰가야 할 부분들도 많았습니다. 애자일하게 협업하기 위해서는 파일 정리, 작업물의 버전 관리, 실시간 의견 공유 등 내부적으로 기본적인 작업방식을 합의하는 것이 중요하다는 것을 느꼈습니다. 우리에게 맞는 방법으로 점진적으로 발전해가면 좋겠다고 생각했고 기존 방법을 개선하는 방식으로 해결방법을 만들어보았습니다. 다음 프로젝트에서 적용해 보며 엑스플리트만의 협업 방식이 되도록 지속적으로 개선해나가겠습니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari