brunch

매거진 IT 샌드위치

라이킷 41 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 에이치 Oct 19. 2020

커뮤니케이션의 요령

기획자의 패시브이자 액티브 스킬.. 아무튼 무조건 필요하다는 말입니다

기획자는 얘기를 하지 않는 파트가 없다. 무슨 일을 해도 하나부터 열까지 기획자를 거친다고 해도 과언이 아니다. 커뮤니케이션 역량은 누구에게나 중요하지만, 기획자가 소통을 현저히 못한다면 업무에 큰 차질이 있을 정도니 주요 기술이라고 생각한다. 의사소통이야 말로 솔직히 직접 부딪히고 깨지면서 터득하게 되는 부분이 많다. 게다가 워낙 천차만별의 상황이 벌어지기 때문에 그때그때 그간의 빅데이터를 동원해 대응해나가야 한다. ~~사실 얘기할 사람 성격이 제일 중요~~ 인간관계의 역학적인 부분을 제외하고, 여태까지 파악해서 대상에 따라 잘 써먹는 요령에 대한 고찰을 해봤다. 아직도 말단 나부랭이이므로, 철저히 말단의 입장에서 기술되었다.

1. 같은 팀 직원인 경우

그냥 눈치 좀 살살 보다가 얘기해도 되겠다 싶은 시점에 다가간다. 가족보다도 많이 보는 사람들이라 대충 그 정도는 파악 가능. 다만 어려운 건일 수록 대면해서 말하는 게 효과적이다.

2. 다른 팀 직원인 경우

모든 의사소통은 대부분 메신저나 메일 등 비대면으로 말하는 게 좋다. 전화나 대화 등으로 전달한 내용은 히스토리가 남지 않아 잘못하면 뒤집어쓸 (...) 공산이 크므로 기록을 남겨두는 게 중요하다. 먼저 보내 놓고 찾아가거나, 얘기한 후에 리마인드로 보내는 것도 좋은 방법. 현업이 IT 업무에 대해서 잘 모른다는 전제를 항상 깔아놓고 응대하는 게 중요하다. 최대한 쉬운 말로 풀어쓰되 우리의 입장을 견지할 수 있도록. 그리고 말단일수록 ㅠㅠ나 ㅎㅎ, ;; 이런 말 없이 간결하게 업무에 관한 말만 딱딱해 보인다 싶을 정도로 전달하는 게 좋다. 물론 처음엔 어렵겠지만, 저런 말은 친한 사이에 얘기할 때만 쓰도록 하자.

- 의사결정 요청 시 : 의사결정 필요사항과 기한 명시, 간단한 히스토리와 이유를 추가하면 금상첨화

- 요청한 내용을 거절해야 할 때 : 요청사항에 대한 확인 내용, 수용 불가 이유, 대안 전달

(인사말 생략) 마이페이지 SB와 검토 필요사항을 공유드립니다.

1. 마이페이지 메뉴 구성 (첨부파일 참고 : 마이페이지_시안.jpg)
1안) 아이콘 메뉴 + 2단 텍스트 메뉴 구성
  - 기존 UI와 유사하여 사용자에게 친숙
  - 화면 내 지나치게 많은 메뉴 노출로 복잡도 증가
2안) 1단 텍스트 메뉴 구성 + 더보기 버튼
  - 필요한 메뉴 구성으로 고객 피로도 감소
  - 기존 주요 메뉴 삭제로 인한 사용자 문의사항 일시적 증대 가능

2. NEW 아이콘 배지 우상단 적용 요건 (첨부파일 참고 : new_icon_example.png)
  : 우상단 동그라미 아이콘은 클릭 시 사라지는 형태로 주로 사용되어, 말씀 주신대로 뉴 아이콘을 유지하는 경우 첨부드린 예시 화면처럼 N 표기를 버튼 내부에 첨부해 유지하는 방식이 사용자 경험 측면에서 더 나을 것 같다고 제안드립니다. 확인 부탁드립니다.

3. 이런 식으로 추가 의사결정 사항을 나열합니다.

위 사항 검토 후 10월 21일 (수) 오전까지 회신 부탁드리겠습니다. (마침말 생략)

현업과의 커뮤니케이션에서 중요한 점은, 우리에게 말하지는 않지만 그들이 바라는 점이 생각보다 구체적인 형태라는 사실이다. 위 예시의 2번처럼 시안을 전달하면 이렇게 해달라는 경우가 많은데, 현업은 사실 디자인 가이드나 앱 정책 같은 건 신경 쓰지 않는다. 따라서 타협이 가능한 선을 명확히 정하고 내부에서 협의가 완료된 상태로 현업과 연락을 하는 것이 중요하다. 최악의 경우는 위 내용으로 전달했는데 어? 김과장님은 된다고/안된다고 하던데요? 가 등판했을 때다.

내부 협의가 안 된 공유는 재앙입니다...

기획자는 사방팔방으로 얘기를 많이 할수록 좋다. 그리고 기한 명시도 꽤 아니 사실 제일 중요하다. 높은 확률로 늘 기한 내에 피드백을 안 주는 사람이 분명히 있을 텐데, 몇 번만 봐주고 이후에는 기한 내 피드백이 없을 경우 반영이 어렵다는 점을 주지해두면 좋다. 말단이라는 이유로 찍어 누르려고 하면 더이상 상대하지 말고 우리 쪽 대장에게 떠넘기도록 하자.

3. 기획자인 경우

아직 일천한 경험 탓인지는 모르겠으나 기획자들끼리 의사소통이 어려웠던 적은 없다. 각자의 견해 차이로 의견을 나누는 정도지... 기획자는 모두를 생각하기 위해 노력합니다. 알아주세요 이 사람!

4. 디자이너인 경우

디자인에 대한 의견을 제시하기 전에 이유를 탄탄히 만들어가는 게 좋다. 아무렴 기획자인 내 눈보다 디자이너 분들이 정확할 거라고 마음을 먹는 게 좋다. 타협을 모르는 기획자가 되면 안 된다. 각자의 파트 업무가 우선이지만 운영팀은 언제나 서비스를 더 좋게 만들겠다는 공통의 목표가 있음을 항상 생각하자. 시안이 마음에 안 들어서가 아니라 정책적으로 이 부분이 더 강조되어야 한다던가, 현업의 요구사항이 있었다던가, 기존의 정체성은 유지하되 톤을 좀 더 바리에이션해서 새로운 서비스라는 걸 한눈에 띄게 하고 싶다던가 하는 식으로 어떤 부분을 왜 바꿔야 하는지를 충분히 전달하면 된다.

5. 개발자인 경우

특이한 경우를 제외하고는, 개발자와 코드에 대해서 이야기를 나눌 일은 거의 없다. 개발 중에는 대부분 스토리보드나 퍼블리싱 화면을 봤는데 이렇게 구현하실 거예요? 혹은 이렇게 구현이 가능할까요? 로 이어진다. 개발상 이슈가 있어 정책 수정이 필요한 경우 기획자는 사용성을 고려하고, 개발자는 안정성을 고려해 새로운 방향을 잡아야 한다. 개발자와 소통이 많을수록 안정적인 서비스가 만들어진다.

다만 이슈가 있는 개발 사항을 요청할 때는 어떤 이슈가 있는지를 충분히 파악하고 대응하겠다는 점을 어필하는 게 중요했다. 개발자는 어쩔 수 없이 서비스를 안정적으로 만들고 싶어 한다. 때문에 장애가 일어날 것 같은 모든 상황을 대비하고 피하고 싶어 하고, 리스크를 가지는 기능을 오픈하는 일에 대해 부정적일 수밖에 없다. 부정적인 반응에 너무 의기소침하지 말고 그 무리한 요구를 한 사람에게 끊임없이 경고를 하는 게 좋다. 최대한 일어날 사고를 방지하고, 일어난 일에 대해 적극적으로 대응하는 모습을 보여준다면 대부분의 개발자 분들도 상황을 이해해주시곤 했다.

6. 파트너사인 경우

주로 프로젝트 수행을 위해 파트너사가 파견되어 오는 경우가 많았다. 처음에는 어쩔 줄을 몰라서 파트너사에 많이 휘둘리곤 했었는데, 예의는 지키되 할 말은 할 줄 알아야 했다. (사실 이건 기획자보다는 PM의 입장에 좀 더 가까웠지만) 프로젝트가 일정대로 진행되지 않거나 근태가 나쁠 때, 요구사항과 다른 방향으로 개발이 됐을 때. 프로젝트팀과 싸울 일은 널렸다. 굳이 모든 일을 싸움으로 만들 필요는 없지만 무조건적으로 싸움을 피해서는 될 일도 안 된다. 다만 우리 팀의 상사 분이 해주신 조언은 지키려고 노력한다.

싫은 소리를 할 때는 남들이 보는 앞이 아니라 따로 불러서 얘기해라.

싫은 소리는 그냥 들어도 싫은데 남들이 보는 앞에서 들으면 맞는 말이라도 억하심정부터 생긴다고 하셨다. 모르는 바는 아니라 이 조언을 들은 후부터는 따로 회의실에 들어가서 얘기를 많이 했다. 평소에는 화부터 낸다고 생각했던 분들도 생각보다 말이 잘 통해서 그간의 소통 방식의 문제점을 돌이켜볼 수 었다.

여러 프로젝트를 진행하며 기억에 남는 말 중 하나가 있다. PM분이 프로젝트 종료 회식을 하면서, 이렇게 자기 일도 아닌데 나서서 도와주시는 고객사가 처음이라 기억에 많이 남을 것 같다는 말을 하셨다. 프로젝트 진행이 내 담당 업무인데 무슨 말인가 했더니, 문서 작성이건 정책 수립이건 테스트건 뭔가 요청했을 때 프로젝트 팀에 다 떠맡겨두고 결과만 확인하는 경우가 많다고 했다. 솔직히 프로젝트팀에서 해야 하는 일은 맞지만 고객사에서 도와주면 더 빨리, 더 좋은 결과가 나오는 경우가 많은데 그렇게 해주셔서 감사하다고 하셨다. 서로 감사 배틀을 하면서 끝난 그날의 회식이 아직도 기억에 남는다. 눈치가 있으면 다 안다. 해보지도 않고 일을 떠넘기는 건지, 의견을 묻고 협업을 요청하는 건지. 후자의 경우 지원하지 않을 이유가 없다. 기획자는 소통할수록 산출물의 결과가 좋아진다.