Day19. 바통터치 잘하는 PO의 화법

안녕하세요, 기획자 팥씨입니다.🥮

오늘은 여기어때 기술블로그에서 신입PO가 어떻게 개발자와 소통했는지 풀어낸 글을 다뤄보겠습니다. 

 

 

갓 입사한 PO는 어떻게 바통 터치를 잘하게 되었을까

좋은 글 써주신 @져니 님 감사합니다.😊

 

현직자 분들을 만나면서, '개발자가 자주 안 찾아오면 일을 잘 하고 있는거다'라는 말씀을 듣고 공감했습니다.

프로젝트를 진행하면서 세부 요구사항 정의가 잘 되지 않았을 때 개발자분과 핑퐁이 끊이지 않았던 경험이 떠올랐습니다.

 

바통(질문)에는 3가지를 명확하게 적는다 : 목적, 대상, 청자

작년 새로 PO를 맡았던 @져니 님께서도 다양한 상황에서 효율적으로 의사소통 하는 방법을 직접 부딪히면서 체득하셨다고 하는데요,

아래 '바통터치'의 나쁜 예와 좋은 예시가 있습니다.

(좌) 바통터치의 나쁜 예 (우) 좋은 예시

 

'혹시..'로 시작하되 두 줄 이상 넘어가지 않는다.

• '혹시'의 목적은 미리, 또는 더 늦기 전에 예상되는 이슈나 일정을 팀의 집단지성을 활용해 파악하기 위함
• 간단하게 두괄식으로 전달 (장황한 배경설명, 양해 구하는 말 불필요)

대상과 청자는 명확하게

• '혹시..'를 통해 빠르고 정확하게 이슈를 파악하려면, 두괄식 + 뾰족한 문장이어야 함
• 1. 대상이 명확할 것
  • ex. (bad) 예약 내역 메뉴에서요 ~ (good) 예약 내역 메뉴 하위 결제 정보의 어떤 값 대상, api 명세 링크 등
• 2. 청자도 명확할 것
  • 요청이 필요한 각 메뉴 담당자에게

 

서비스 내 데이터도 MBTI 가 존재한다

이 데이터는 어떤 상황, 어떤 메뉴에서 어떤 MBTI를 가지지?

 

(M) Mandatory : 꼭 필요한 값인가 vs 없어도 되는 선택적인 값인가,
(B) Belonging to : 독립적인가 vs 다른 테이블을 참조해야만 하는가,
(T) Timestamp : 중간 단계도 로그 남겨야 하는가 vs 불필요한가,
(I) Identity : 이 데이터와 저 데이터는 동일한가 vs 값은 같지만 다른가.

 

• 하지만, 같은 데이터라도 상황에 따라 MBTI가 다르게 나타날 수 있음
• 한번 고른 것이 항상 맞는 답은 아님
  • 좀 더 좋은 협업을 위해 I와 E, J와 P를 오가는 필자 처럼!

 

🥮 명확한 목표와 목적, 데이터를 보는 새로운 시각

목표와 목적이 명확하지 않은 질문, 요구사항은 협업부서(특히 개발)와의 의사소통을 지체시킨다는 것을 다시한번 확인했습니다.

저도 프로젝트를 진행하면서 '질문'을 어떻게 구성하여 전달드릴지 고민이 많았었는데요,

현재 제가 문제라고 생각하는 상황과 그 이유, 대상을 명확하게 구체화하여 아젠다로 올렸을 때

비교적 논의가 빠르게 진행되는 경험을 했습니다. + 청자 역시 명확해야 하고요.

 

또한, 서비스 내 데이터도 'MBTI'의 시각으로 바라본 것이 흥미로웠습니다.

기획서를 작성할 때 저 역시도 이 부분을 여러번 고민했었는데요,

4가지 조건이 우리에게 친숙한 'MBTI'로 표현되니 와닿았고, 앞으로 이 네가지 알파벳을 떠올리며 더 수월하게 기획서를 작성할 수 있을 것 같습니다 :)