핸드오프 검토를 넘어 커뮤니케이션 프로세스 재정의
2024.01.24
이번 글에서는 디자인 핸드오프 방식을 수정하려다가 커뮤니케이션 프로세스를 재정의하게 된 과정이 담겨 있습니다. 처음에는 단순한 커뮤니케이션 누락이라고 생각했지만, 반복되는 문제 속에서 이는 명확한 프로세스가 구축되지 않아 발생하는 문제임을 인식하게 되었습니다.
특히 저희 조직은 이주일 단위로 새로운 스프린트가 시작되고, 그에 따라 스쿼드가 새롭게 구성되는 구조였기 때문에, 작업자가 바뀔 때마다 이전 작업자와 정했던 프로세스를 다시 설명해야만 했습니다.
결국 멤버들 간의 암묵적 룰에 의존하는 방식으로는 한계가 분명했습니다. 그래서 팀 내에서 문제를 제기했고, 이를 공식적으로 다루기 위한 회의를 제안했습니다. 회의는 일회성으로 끝나지 않았고, 실험과 회고를 거쳐 팀 내 협업 방식을 바꾸는 작지만 중요한 전환점이 되었습니다.
펼쳐놓고 파악하기
먼저 기존 조직 내 프로덕트 개발 프로세스를 되짚어 보기로 했습니다.
[1] 전사 아이데이션 회의
- 회의 시작 전 Agenda를 설정, 데이터 브리핑을 통해 자유롭게 의견 공유
- 아이데이션 문서를 기반으로 우선순위를 고려하여 이번 스프린트에 작업할 것들을 결정
[2] 기획 구체화 회의
- 스쿼드 내 모든 구성원이 기획 구체화 회의에 참여
[3] Sprint 회의
- 기획 문서를 기반으로 일감 분배 및 Story point 산정 (Jira)
[4] Flow 회의
- 각 Feature의 담당자들이 모여 Flow 회의 진행
[5] flow chart 중간 공유
- Slack or Figma 코멘트로 핑퐁
[6] flow 확정되면 본격적으로 디자인 작업 시작
[7] 디자인 중간 공유
- Slack으로 디자인 의도, 고민되는 지점, Figma 링크 공유
- Slack or Figma 코멘트로 핑퐁
[8] 디자인 확정되면, 마스터 파일에 업로드
- 이후 라이팅 요청 (전체 플로우 맥락 기반으로 워딩 받기 위함)
[9] 라이팅 픽스 전, 마스터 파일을 개발자에게 공유 (병합 중 휴먼에러 검토 목적)
[10] 인터렉션 작업 완료, Protopie 파일을 개발자에게 공유
[11] UX 라이팅 픽스, 개발자에게 최종 공유 (변경 지점은 Figma 코멘트로 공유)
[12] QA 진행
- FE 팀에서 올린 QA list를 참고하여, 기능, 디자인 QA 진행
[13] 배포 후, 스프린트 회고 진행
과정을 나열하다 보니, 5, 8, 9번 진행 시 프로세스가 충분히 구체화되지 않아 혼선이 발생하고 있음을 알게 되었습니다.
1. 커뮤니케이션 부족으로 인한 정보 누락
문제 : flow 중간 공유를 하더라도 개발 작업 시 누락되는 화면이 발생하는 문제
원인 : 공유한 작업물을 PM만 확인하는 경우가 많아, 수정 사항이 발생하더라도 개발자가 이를 인지하지 못하는 상황이 발생하기 때문이다.
2. 피그마 마스터 파일의 복잡도 높아 변경 사항 파악이 어려움
문제 : 마스터 파일에서 무엇이 변경됐는지 개발자가 빠르게 캐치하지 못하는 문제
원인 : 마스터 파일에 모든 기능에 대한 화면이 있기 때문에 복잡하다.
3. 형상관리 불충분으로 인한 변경 사항 파악의 어려움
문제 : 변경 이력에 대한 명확한 추적이 어려워, 이후 작업자가 변경 사항을 인지하지 못하거나 누락되는 문제
원인 : 언제, 누가, 무엇을, 왜 변경했는지를 기록하고 확인할 수 있는 체계가 없기 때문이다. 결국 메이커 외에는 변경 이력을 파악하기 어렵다.
4. 겹치는 화면에 대한 스쿼드 간 명확한 역할 분담의 부재로 인한 작업 누락
문제 : 기능이 겹쳐 동일한 화면을 다루는 경우, 각 스쿼드의 디자이너 간 작업 범위에 대한 협의가 없어 작업이 누락되는 문제
원인 : 선행 작업자가 해당 화면을 이미 작업했을 것이라 간주해 중복을 피하려다, 오히려 작업 항목에서 제외해 버렸기 때문이다.
시도해 볼 수 있는 방안
문제와 원인을 파악하고 나니, 구체적으로 어떤 시도들을 해 볼 수 있을지도 명확해졌습니다.
1. 디자이너 주도의 flow 리뷰 회의 도입
리뷰는 스쿼드 내 모든 구성원들이 모여 유즈 케이스(상황별 케이스), 엣지 케이스를 더블 체크한다.
2. 최종 디자인 핸드오프 시, 디자이너 개별 작업 파일 공유
마스터 파일의 복잡함으로 인해 개발자가 디자인 반영 사항을 놓치는 경우가 있어, 디자이너 개별 작업 파일을 공유한다.
3. 피그마 Branch 기능 도입 시도
장점도 이었지만,
원본 파일을 유지한 채 사본에서 작업하고 병합 가능
동시작업 시 원본 유실 방지, 병합 시 자동으로 아카이빙 처리
단점도 존재했습니다.
일반적인 브랜치 예시와 달리, 우리는 flow chart + 와이어프레임이 결합된 형태라 머지 시 반영 방식이 모호하다.
시안 변경점과 플로우 변경점 체킹이 어렵다.
결론적으로, 브랜치 기능은 현재 상황에 맞지 않는다고 판단해 보류하기로 했습니다.
4. 겹치는 화면에 대한 명확한 역할 분담
기능이 겹치는 경우, 각 스쿼드 구성원이 모여 최종 협의를 진행하고, 그 내용을 반드시 문서화한다.
예시 : 홈 화면 진입 시 노출되는 팝업 영역
A 스쿼드 신규 기능 알림 팝업,
B 스쿼드 긴급 점검 공지 팝업을 띄우려는 상황
둘 다 같은 위치에 다른 알림을 띄우려 하면 UX 충돌 발생
협의 후 우선순위 결정, 관리 방식 정리하여 문서화한다.
5. 기획 문서의 디테일 강화(추가 문제)
문서를 읽는 사람들이 모든 맥락을 파악하고 있는 것이 아니기 때문에 가능한 모든 정보를 충분히 포함시킨다.
주어, 술어, 목적어를 명확히 작성한다.
평이한 용어를 사용하되, 전문 용어를 사용해야 한다면 등장배경과 의미를 명확하게 작성한다.
비전문가도 이해할 수 있는 정도로 작성한다.
최최종을 향해
새로운 스프린트가 시작되기 전, 이전에 시도했던 디자인·개발 핸드오프 방식에 대한 회고를 진행했습니다. 각 스쿼드의 디자이너와 개발자가 함께 참여했으며, ‘Try’ 항목 중 다음 스프린트에 적용해 볼 만한 시도들은 논의를 거쳐 실제 반영하기로 했습니다.
회고에 앞서 팀원들의 의견을 듣고 싶어, 간단한 체크리스트를 미리 작성해 공유했습니다.
Check list
공통
- 디자이너 주도의 flow 리뷰 회의 도입 이후, 누락되는 화면이 줄어들었나요?
개발자
- 디자이너 개별 작업 파일을 통한 최종 시안 공유 방식은, 누락되는 화면을 줄이는 데 도움이 되었나요?
- 커뮤니케이션 이슈로 생성된 QA 티켓이 줄어들었나요?
디자이너
- 겹치는 화면에 대한 명확한 역할 분담이, 작업 누락을 줄이는 데 도움이 되었나요?
Keep (만족, 잘한 점 / 앞으로의 업무에서 지속하고 싶은 부분)
A개발자 : 디자이너가 개별 작업 파일로 최종 시안을 공유해 줘서, 개발 시 필요한 화면을 한눈에 파악하는데 도움이 되었어요!
B개발자 : flow 리뷰 회의를 통해 구현될 화면을 이해한 상태에서 개발 작업에 들어갈 수 있어서 좋았어요!
A디자이너 : 이제는 겹치는 화면이 생기면 회의로 역할을 명확히 나누니까, 눈치 보지 않아도 돼서 좋았어요!
Problem (부정적인 요소로 작용했거나 아쉬웠던 점)
A디자이너 : flow 리뷰에서 "이 정도는 알고 있겠지" 하고 공유하지 않은 부분에서 이슈가 생겼어요.
B디자이너 : 개발 진행 상황이나 디자인 공유 이후 개발자가 확인했는지 파악하기 어려워요.
B디자이너 : QA 전날까지 완료되지 않은 항목을 인지하지 못해, QA 당일 Jira 티켓을 일일이 만드는 일이 반복되고 있어요.
Try (Problem에 대한 해결 방식으로 다음에 시도해 볼 점)
QA 전에 디자인·개발 리뷰를 진행한다.
flow 리뷰 시, 세부적인 부분까지 공유한다.
개발자는 원활한 커뮤니케이션을 위해 이모지를 적극적으로 사용한다.
눈 이모지: "보고 있어요", "보기 시작했어요"
이름 이모지: "확인 완료했어요"
완료 이모지(선택): 개발 완료 체크용으로, 디자이너 참고용으로만 사용
QA 전날까지 완료되지 않은 항목은 개발자가 슬랙에 직접 공유한다.
그래서, 어떤 결과가 있었냐면요!
1. QA 리소스를 약 30% 절감했어요!
QA 과정에서 커뮤니케이션 이슈로 인해 생성된 티켓 수를 기준으로 개선 전후를 비교한 결과, 이전 스프린트 대비 약 30% 감소한 것을 확인할 수 있었습니다.
2. 구성원들로부터 긍정적인 피드백을 받을 수 있었어요!
정량적 지표 외에도, 구성원들로부터 불필요한 커뮤니케이션으로 인한 시간 손실이 이전보다 체감상 40% 이상 줄었다는 피드백을 받았습니다. 특히, 전달 누락이나 진행사항 파악의 어려움이 줄면서 업무 흐름이 매끄러워졌고, 집중도 있게 작업할 수 있었다는 피드백이 많았습니다.
글을 마치며
이번 개선은 더 나은 프로세스를 만들어가는 여정의 시작이라고 생각하는데요. 그럼에도 이런 결과가 나올 수 있었던 건, 목적을 이루기 위해 누구나 의견을 낼 수 있고, 좋은 의견을 따르는 문화가 자리 잡고 있기 때문이에요. 이 안에서 직무 구분 없이 모두가 오너십을 갖고 움직이는 덕분에, 빠르게 실행하고 회고할 수 있었습니다.
끝으로, 제 글을 읽어주신 모든 분들께 감사합니다 :)
