[아티클 스터디] 7년차 기획자의 커뮤니케이션 실제 사례

🔗 아티클 출처

https://yozm.wishket.com/magazine/detail/2274/

7년차 기획자의 커뮤니케이션 실제 사례 | 요즘IT

---

🗨️ 선정 이유

▪️ 기획 직무 공고를 보면 ‘원활한 커뮤니케이션’이 요구사항으로 주로 언급된다.

▪️ 개발/디자인/QA를 포함하여 다양한 유관부서와 협업하며 의견 조율을 하는 기획자에게 커뮤니케이션 능력은 중요하다.

▪️ 기획자로서 어떻게 효과적인 커뮤니케이션을 할 수 있는지에 관한 경력자의 의견을 살펴보고자 선정하였다.

---

📑 내용 정리

🏁 커뮤니케이션도 기획의 영역이다

▪️ 서비스 기획자는 프로젝트를 관리하는 PM으로서 디자이너/개발자 등 실무자뿐 아니라 영업팀, 유관부서, 외부 협업사 등 내외부 소통 능력이 중요하다.

▪️ 소통 부재 → 큰 비용 손실로 이어질 수 있다.

▪️ 국내 유수 기업은 서비스 기획자에 대한 JD(Job Description)에 타 직군 대비 커뮤니케이션 역량을 특히 강조한다.

▪️ 서비스 기획자는 목표 달성을 위해 팀원의 불편 사항은 빠르게 이해하되, 업무 전달은 명확해야 한다.

1️⃣ 디자이너: 창의력의 방향성 제시하기

▪️ 발단

• 개발 명세에 집중하여 디자인 톤앤매너, 디테일, 기획의도에 대한 설명이 부족했음.

▪️ 이슈

• 기획 의도와는 다른 디자인이 나옴. (스토리보드와 다르게 중요도가 낮은 기능이 강조되는 등)

▪️ 해결

• 이를 해결하기 위해 디자인 방향성에 대한 사전 회의를 진행함.
• 기획서와는 별도로 디자인의 톤앤매너 레퍼런스를 정리함.
• 레퍼런스를 선택하는 기준은 경쟁사, 시장 점유율, 트렌드 등의 논리로 선별
• 레퍼런스 문서 바탕으로 디자이너와 회의 후, 경쟁사 UI/UX 및 프로젝트에서 중요한 정보의 강약을 설명

▪️ 결과

• 의도에 벗어난 디자인이 나오는 횟수가 줄고, 수정 방향이 명확해짐.
• 디자이너도 초기 컨셉에 대한 고민없이 필요한 디자인 구현에 집중할 수 있음

▪️ 의의

• 디자인은 창작의 영역으로 경우의 수가 무한함.
• 기획자는 경우의 수를 좁히는 노력을 해야함.

2️⃣ 프론트엔트 개발자/퍼블리셔: 시안과 기획서를 동시에 봐야 하는 고충 해결하기

▪️ 발단

• 프론트엔드/퍼블리셔는 시안과 기획서를 동시에 봐야 함.
• 기획자는 ‘기획서에 썼으니까’라고 생각하기 쉬움

▪️ 결과

• 외적으로는 시안처럼 구현했지만, 데이터의 노출 케이스나 동작 등 스크립트 누락이 빈번함.
• 작업자에 따라 디자인 시안을 기획서처럼 자세하게 요구하는 경우도 있음

▪️ 이유

• 시안에서는 데이터의 모든 노출 케이스와 동적 흐름을 보여주지 않음.
• 시안이 많은 경우 기획서와의 맵핑이 되지 않아 일일이 찾아보기 힘들어짐.

▪️ 해결

• 작업 범위가 큰 경우는 1차 시안 완성 후 개발에 넘기기 전 별도로 리뷰 회의를 진행했음.
• 전체 킥오프와 달리 시안의 수정사항과 프론트 구현 시 이슈에 대해 취합하는 ‘프론트엔드’만을 위한 회의.
  • 시안 제작 시 기획서 페이지와 매칭될 수 있도록 대분류의 넘버링을 맞춤 → 시안 별 확인해야 하는 기획서 쉽게 찾을 수 있음.
  • 기획서는 시안에 담기지 못한 데이터 노출에 대한 표현과 동작 시점을 정의해야 함 e.g. 몇 줄까지 노출, 절삭처리, 이미지 자름 기능 등)

▪️ 의의

• 해당 시안이 어느 기획서를 참고하고 있는지 제목 등에 넘버링을 잘 표기해줘야 함.
• 백엔드에 넘기기 전, 디자이너와 함께 구현 이슈는 없는지 체크해야 함.
• 리뷰 회의를 통해 디자인 가이드에 표기할 것, 기획서에서 확인해야 할 것을 구분해야 제 목적에 맞는 산출물이 나올 수 있음.

3️⃣ 백엔드 개발자: 요구는 명확하게, 일정 협의는 유연하게, 기획서는 읽기 쉽게

▪️ 발단

• 개발 중 기획서에 없던 스펙이 추가됨 → 공수 늘어남. (기획자의 누락 or 외부 요구사항)

▪️ 결과

• 개발자가 요구사항에 대해 방어적인 태도를 취함. → 서로 간의 소통이 경직됨.

▪️ 이유

• 개발자는 전체 모듈을 생각하여 코드를 짜야 함. → 개발자의 업무 특성을 이해해야 함.

▪️ 해결

• 기획자는 확장성을 고려하여 사전의 문서 작성과 방향성 회의를 진행해야 함.
• 추가되는 일정과 구현할 사항에 대해 유연한 협상 필요
  • Case1. 사전 문서 작성 및 킥오프 회의
    • 개발자가 전체 코드 설계를 잘 할 수 있도록 ‘프로덕트의 목표와 쓰임새, 그리고 확장 가능성’을 기획하고 사전에 공유함 (폭포수 모델처럼 가능한 모든 케이스를 작성해주는 게 베스트이며, 애자일일 경우 MVP의 핵심 기능과 목표 명시)
    • 개발자는 확정 기능과 가변 기능을 따로 분리하여 아키텍쳐 설계와 모듈 단위 작업 시작 가능
  • Case2. 개발 진행 도중 누락/추가 기능 요청
    • 개발자와 공감대를 형성할 수 있도록 요청 배경과 중요도를 먼저 설명해야 함
    • 기획자의 누락으로 발생한 경우에는 솔직하게 잘못을 인정하는 태도 중요
    • 누락된 개발 공수 파악 후 개발 일정 확보
    • 일정 확보가 불가한 경우, 핵심 기능만 구현하거나 우선순위 산정하여 후속개발로 산정해도 됨
    • 기획자가 조정할 수 있는 것은 일정과 스펙이기 때문에, 개발자와 원만한 협의를 도출해야 함.

▪️ 의의

• 기획자는 국어로 코딩하는 사람 → 개발자의 입장에서 기획 문서를 설계해야 함.
• 프로덕트의 핵심 기능, 부속 기능에 대해 정의하고 개발자와 공유해야 함.
• 개발자가 일하는 방식에 대해 끈임없이 탐구할 것

✔️ 커뮤니케이션도 프로덕트 기획처럼, ‘이해’가 먼저다

▪️ 프로덕트를 출시하기 전, 기획 대상인 사용자와 시장을 파악하듯 동료와의 협업에서도 그들의 특성을 이해하고, 업계의 언어로 이야기해야 한다.

▪️ 프로젝트의 리드는 기획의 영역이며, 커뮤니케이션은 문제 해결 역량이다.

---

💡 생각 정리

▪️ 기존에는 커뮤니케이션을 통합적으로만 생각하고 있었던 것 같다. 함께 일하는 상대방의 직무를 고려하면 더 효과적으로 소통할 수 있음을 알게 되었다.
▪️ 저자는 함께 일하는 동료들의 특성을 이해하기 위해 피그마, XD 실습 및 HTML/CSS 강의를 듣고, SQL과 개발 언어들을 챗GPT나 블로그를 통해 꾸준히 학습하고 있다고 한다.
▪️ 소통이 잘 되는 기획자로 기억되고 싶다는 욕심이 생겼다.

 

---

린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee

맛있는 게 좋아 : 네이버 블로그