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

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

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

 

개인 아티클 정리

아티클 정보

제목: 7년 차 기획자의 커뮤니케이션 실제 사례

작성자(저자): 큰그림기획

 

 

핵심 내용 요약

이 아티클의 주요 메시지:

PM에게는 디자이너, 개발자, 영업팀, 유관부서, 외부 협업사 등 내외부 소통 능력이 특히 중요하다. 타 직군 대비 커뮤니케이션 역량이 특히 강조된다.

목표 달성을 위해 팀원의 불편 사항은 빠르게 이해하되, 업무 전달은 명확해야 한다.

 

1. 디자이너: 창의력의 방향성 제시
    디자인 톤앤매너 , 디테일 , 기획 의도 설명 부족. 기획 의도와는 다른 디자인이 나올 가능성 높음.
    디자인 방향성에 대해 사전 회의를 진행해 톤앤매너와 레퍼런스 정리(경쟁사, 시장 점유율, 트렌드 등의 논리로 고려)
    레퍼런스를 토대로 디자이너와 회의, 경쟁사 UIUX 및 프로젝트에서 중요한 정보의 강약 설명
    이러한 논리를 포함한 회의를 진행하면 의도에 벗어난 디자인이 나오는 횟수가 줄었고 수정 방향도 명확했다. 디자이너도 초기 컨셉 및 레퍼런스를 찾을 필요없이, 필요한 디자인 구현에 집중 가능.
    

2. 프론트엔드 개발자/퍼블리셔: 시안과 기획서를 동시에 봐야 하는 고충 해결
    스크립트 누락이 빈번. 작업자에 따라 디자인 시안을 기획서처럼 자세하게 요구하는 경우도.
    작업 범위가 크다면 디자인 시안 1차 완성 시, 개발에 넘기기 전 리뷰 회의를 진행해 프론트 구현 시 이슈에 대해 취합하는 프론트엔드 회의.
    이를 위해서는 시안 제작 시 기획서 페이지와 매칭이 되도록 대분류 넘버링을 맞추고 기획서에서는 시안에 담기지 못한 데이터 노출 표현 및 동작 시점을 정의해야 한다.(몇 줄까지 노출, 절삭처리, 이미지 자름 기능 등)
    

3. 백엔드 개발자: 요구 명확, 일정 협의 유연, 기획서 읽기 쉽도록
    개발 도중 기획서에 없는 스펙 추가로 공수 증가. 주로 기획자 누락 또는 외부 요구사항.
    확장성을 고려하여 사전의 문서 작성과 방향성 회의를 진행해야 한다. 추가되는 일정과 구현할 사항에 대해 유연한 협상이 필요하다.
    
    1. 사전 문서 작성 및 킥오프 회의
        프로덕트의 쓰임새, 그리고 확장 가능성을 기획하고 사전에 공유. 폭포수 모델처럼 가능한 모든 케이스를 작성해주는 게 베스트.
        일단 미리 ‘~ 기능을 추가로 넣을 수도 있다.’라고 가능성을 미리 설명해두는 게 낫다.
        
    2. 개발 진행 도중 누락/추가 기능 요청
        요청 배경과 중요도를 먼저 설명.
        외부 요청에 의해 추가된 것이라면 구체적으로 설명 후 이 기능에 어떤 영향이 있는지 설명. 기획자 누락이라면 솔직하게 잘못을 먼저 설명 후 사과 후 설득.
        개발의 공수 파악 후 개발 일정을 확보한다. 확보하지 못하면 핵심 기능 위주로 구현하는 등 합의가 필요.
        

프로젝트 중 불필요한 회의 증가 또는 불만 사항을 듣는다면 스스로 각 실무자들의 특성을 이해하지 못했나 반성할 필요가 있다.
동료와의 커뮤니케이션에는 그들의 특성을 이해하고, 업계의 언어로 얘기할 필요가 있다.
동료에게 질문하고, 친해지고 대화를 통해 그들을 이해하고 이해하기 위한 역량을 쌓도록 하자.

 

 

핵심 키워드:

공수: 필요한 인원수나 작업 시간(통틀어 노동력을 의미하는 듯)

 

 

흥미로운 점/새롭게 알게 된 점

백엔드는 개발 경험이 없어서, 그 부분을 읽으면서 확실히 그렇겠구나 이해가 되었다.

백엔드는 신규 기능을 개발하면 주로 DB 설계부터 시작해서 개발을 시작할 것이다. 그런 사양을 갑자기 바꿔달라고 한다면 DB에 저장한 것들 전부 삭제부터 테이블 다시 설계하고 다시 깔아야 하는 거 생각만 해도 너무 귀찮고 짜증난다.

그리고 문제가 개발 중 스펙 변경 등으로 트러블이 발생한다는 얘기인데, 근본적으로 이런 상황을 없앨 수도 있는 게 아니라서 더 힘들어보인다.

 

 

나의 한 문장 요약

이 아티클을 한 문장으로 요약하면?

동료들과의 원활한 소통을 잘하는 PM이 되기 위해선 그들의 특성을 이해하고 관련된 지식을 익혀 배려하는 태도가 필요하다.

 

 

논의하고 싶은 것

• 각각 분야에서 예시로 소개된 것 말고 어떤 트러블이 더 생겨날 수 있을까?
• 각각 분야에 관해 알고 있는 게 있다면 논의로 서로 질문을 주고받는 것도 좋을 것 같다.

XD는 진짜로 한국에서 사용이 되는 것인가……

 

---

 

 

오늘 논의했던 아티클 주제를 정리

1. 아티클 제목:

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

 

튜터님께 질문

• 각 직무별 방향성에 대한 제안의 범위를 어느정도로 잡아야할 지 감이 오지 않습니다.
• XD는 진짜로 한국에서 자주 사용되나요.

 

2. 팀 전체 논의 요약:

오늘 나의 관심 있는 도메인에 대해 얘기를 나누었습니다.

• 핀테크, 에듀테크, 게임, IoT

 

3. 팀 공통 인사이트 or 느낀 점 요약:

동료들과의 원활한 소통을 잘하는 PM이 되기 위해선 그들의 특성을 이해하고 관련된 지식을 익혀 배려하는 태도가 필요하다.

도메인 결정하기 어렵다.