제7화. 기획자와 개발자 사이, 그 깊은 골짜기에 다리를 놓는 법
아들아, 프로젝트 현장에는 영원한 숙적(?)이 존재한단다. 바로 기획자와 개발자이지. 기획자는 "이게 왜 안 돼요? 그냥 뚝딱하면 되잖아요"라고 말하고, 개발자는 "이건 구조상 절대 안 돼요. 다시 정리해주세요"라고 받아치곤 해. 양쪽의 말이 다 맞지만, 그 사이에서 다리를 놓지 못하면 프로젝트는 한 발자국도 나갈 수 없단다. PM으로서 그 골짜기를 어떻게 메워야 하는지 알려줄게.
기획자는 사용자의 편의성을 극대화하고 싶어 하고, 개발자는 시스템의 안정성과 효율성을 지키고 싶어 한단다. 둘의 언어는 완전히 다르기 때문에, 네가 그 중간에서 공감적 해석을 해주어야 해.
서로의 언어를 이해하지 못할 때 발생하는 갈등은 비난이 아니라 '언어의 차이'일 뿐이란다.
아빠의 노하우: 아빠는 갈등이 생기면 양쪽을 한자리에 모았어. 그리고 기획자에게는 "이 기능이 왜 사용자에게 꼭 필요한지"를 설명하게 하고, 개발자에게는 "그 기능을 구현할 때 서버에 어떤 무리가 가는지"를 숫자로 말하게 했지. 서로의 사정을 '데이터'로 확인하고 나면, 비로소 타협점이 보이기 시작한단다.
개발자가 "안 돼요"라고 말하는 건 게을러서가 아니야. 나중에 터질 장애나, 꼬여버릴 로직에 대한 전문가로서의 공포 때문일 때가 많단다.
개발자의 거절은 시스템을 지키려는 '방어기제'임을 이해해야 소통이 시작된단다.
아빠의 노하우: 그럴 땐 "그럼 어디까지는 가능한가요?"라고 물어보렴. "전체는 안 되더라도, 핵심 기능만 이번에 넣고 나머지는 다음 버전으로 미루면 어떨까요?"라고 대안을 제시하는 거야. 개발자가 느끼는 부담을 덜어주면, 신기하게도 안 된다던 기능이 "한번 해보겠다"로 바뀌곤 한단다.
기획자가 그린 화면 설계서에는 보이지 않는 수많은 로직이 빠져 있을 때가 많아. 개발자는 그 구멍을 볼 때마다 답답함을 느끼지.
기획 문서는 그림이 아니라, 개발자가 코딩할 수 있는 '설계도'가 되어야 한단다.
아빠의 노하우: 아빠는 기획서 검토 단계에서 개발자와 미리 소통했단다. "이 화면에서 이 버튼을 누르면 어떤 테이블의 데이터를 가져와야 하지?"라고 먼저 물어보는 거야. 개발자의 고민을 기획 단계에 미리 반영해주면, 나중에 "기획이 엉망이라 개발 못 하겠다"는 소리가 쏙 들어간단다.
싸움은 대개 "내 일, 네 일"을 가르기 시작할 때 커진단다. 기획자가 기획만 하고, 개발자가 개발만 하면 그 프로젝트는 망한 거야.
우리는 서로를 공격하는 적이 아니라, 함께 정글을 빠져나갈 동료라는 사실을 잊지 마라.
아빠의 노하우: 갈등이 심해지면 아빠는 가벼운 티타임을 제안하며 분위기를 바꿨어. "이 프로젝트가 끝나면 우리가 얼마나 성장할지"에 대해 이야기하며 목표를 다시 상기시켰지. PM인 네가 팀원들의 고생을 알아주고 같은 편이라는 확신만 준다면, 그들은 스스로 다리를 놓기 시작한단다.
한 마디
"소통의 다리는 화려한 말재주로 만드는 것이 아냐. 상대방의 고충을 내 언어로 번역해주는 '이해'와 '배려'로 만드는 것이 라고 생각해. 그 다리가 튼튼할 때, 프로젝트라는 배는 거친 풍랑을 뚫고 목적지에 닿을 수 있을거야."
협업의 골이 깊어져 회의실 분위기가 싸늘해졌다면, PM은 다음 5가지를 즉시 실행해야 한다.
[목적의 재확인] 현재 논쟁 중인 기능이 '사용자의 가치'와 '시스템의 안정성' 중 어디에 더 비중이 큰지 우선순위를 다시 정의했는가?
[감정어 제거] "말이 안 된다", "무조건 해야 한다" 같은 감정적인 단어를 "A 로직의 복잡도", "B 화면의 사용성" 같은 실무어로 치환했는가?
[대안의 가시화] 양측의 주장을 화이트보드나 문서에 나란히 적어, 서로가 무엇을 걱정하고 있는지 시각적으로 확인시켜 주었는가?
[작은 성공 공유] 갈등 중에도 합의된 작은 부분(예: 데이터 구조 확정 등)을 먼저 칭찬하여 "우리는 협의가 가능한 팀"이라는 신호를 주었는가?
[오프 더 레코드 활용] 공식 회의에서 풀리지 않는 앙금이 있다면, 가벼운 티타임이나 개별 면담을 통해 '진짜 거절의 이유'를 들어보았는가?