105. 상품개발 이해관계자 의사소통
성공적인 소프트웨어 신상품 개발가이드
이해관계자는 의사소통의 대상이며 프로젝트를 성공적으로 이끌려면 이해관계자의 이해관계를 파악하여 충족시켜야 한다. 특히 상품관리자는 신상품개발 단계별로 다양한 이해관계자의 참여를 이끌어내고 상충되는 이해관계를 조정하여 상품개발팀과 원활하게 협력하게 해야 한다.
이번 섹션에서는 이해관계자의 유형, 이해관계를 분석하는 방법, 이해관계자 관리시 유의사항에 대해 설명한다.
1) 이해관계자 정의와 이해관계자 유형
이해관계자는 ‘프로젝트 결과에 영향을 받기 때문에 프로젝트 수행과정과 프로젝트 팀원에 영향을 미치려고 하는 개인이나 그룹’이다. 신상품 개발 프로젝트를 정치에 비유하는 것은 다양한 이해관계자들을 조율하는 것이 중요하기 때문이다. <죽음의 행진, 2005>은 이해관계자 관리를 결혼에 비유하여 다음과 같이 설명하고 있다.
프로젝트는 결혼과 비슷하다. 시작할 때는 희망과 순진한 기대로 가득 차 있지만 서서히 현실을 깨닫게 되면서 서로 각자의 기대치를 다시 조정해야 한다.
이해관계자의 영향력 관리가 중요한 이유는 다음과 같다.
• 이해관계자의 이해관계는 때로는 상충된다. (프로젝트 결과가 특정 이해관계자에게는 긍정적, 특정 이해 관계자에게는 부정적 영향을 미칠 수 있음).
• 상품개발의 내부 및 외부 상황에 따라 이해관계자의 이해관계와 영향력이 달라진다.
• 부정적 영향을 받는 이해관계를 식별하지 못하면 프로젝트에 악영향을 미친다. 프로젝트를 잘되게 하기는 힘들어도 잘못 되게 하기는 쉽다.
신상품 개발 프로젝트의 대표적인 이해관계자는 다음과 같다.
• 상품관리자(Product Manager) : 상품기획, 출시를 총괄적으로 책임지는 사람.
• 프로젝트 관리자(Project manager) : 정해진 일정/예산내에 상품요구사항을 책임지는 사람
• 프로젝트 팀(Project team) : 프로젝트의 업무를 수행하는 그룹
• 고객(Customer) : 프로젝트의 결과물(상품)을 요구하고 구입하는 사람
• 사용자(User) : 프로젝트의 결과물을 사용하는 사람
• 실행부서(Performing organization) : 상품개발 프로젝트 팀원들이 소속된 조직의 고정부서 (설계부서, 디자인 부서, 품질부서, 개발부서, 아키텍트 부서 등)
• 지원부서(Supporting organization) : 상품개발 프로젝트를 지원하는 부서 (법무, 구매, 마케팅, 재무, 영업부서 등)
• 스폰서(Sponsor) : 상품개발 프로젝트를 후원하고 자금 지원을 담당하며, 외부로부터 프로젝트 팀을 보호해준다. 상품관리자와 함께 상품개발의 최종성과를 책임지는 사람이다. 중요한 사안에 대한 의사결정을 하기도 한다.
• 포트폴리오, 포트폴리오 검토위원회(Portfolio Manager/Portfolio Review Board) : 조직의 포트폴리오 거버넌스를 책임지는 그룹. 포트폴리오 검토위원회는 조직의 임원진들로 구성되며 프로젝트의 투자 수익, 프로젝트 가치, 프로젝트 진행에 수반되는 위험을 검토한다.
2) 이해관계자를 분석하는 방법
이해관계자 분석이란 프로젝트 수행 도중 고려할 이해관계자의 정성적, 정량적 관심사항을 체계적으로 정리하는 활동을 의미한다. 이해관계자의 관심사항, 기대수준, 영향력을 분석해야 하며, 우호적인 파트너십을 가져갈 이해관계자뿐 아니라 부정적인 이해관계자도 빠짐없이 식별해야 한다. 이해관계자 분석 절차는 다음과 같다.
① 이해관계자들의 기본 정보 파악
• 역할, 관심사항, 부서, 기대수준, 프로젝트에 미치는 영향력
② 다음 항목을 참조하여 이해관계자의 유형을 정의하고 매핑
• 관심사항, 참여수준, 영향력(계획과 실행을 변경시킬 수 있는 영향력)
• 우호, 중립, 적대의 관점
③ 이해관계자 유형분석 결과를 고려하여 이해관계자 관리전략을 수립
• 부정적인 영향력은 최소화하고 긍정적인 영향력은 최대화
그림 *는 PMBOK이 제시하는 이해관계자 유형별 이해관계자 관리전략의 예이다.
던컨의 조직 환경 불확실성을 설명하는 이론을 이해관계자 분석에 대입하면 아래 그림과 같이 네 가지 유형으로 정리할 수 있다.
이해관계자의 복잡성은 이해관계자 유형이나 수가 많다는 것을 의미하고, 이해관계자의 역동성은 이해관계자의 이해관계가 명확하지 않거나 상황에 따라 변하는 정도를 의미한다. 각 사 사분면에 속하는 이해관계자 불확실성의 예는 다음과 같다.
Q1. 이해관계자 유형은 많지만 이해관계가 비교적 안정적인 경우 (예 : 기존에 출시된 중요 상품의 큰 개선)
Q2. 이해관계자 유형도 적고 이해관계가 안정적인 경우 (예 : 기존에 출시된 상품의 소규모 개선)
Q3. 이해관계자 유형은 적지만 이해관계가 역동적인 경우 (예 : 전략적으로 중요한 상품개발의 파일럿 프로젝트)
Q4. 이해관계자의 유형도 많고(복잡하고) 이해관계도 역동적으로 자주 변
하는 경우 (예 : 조직의 미래를 좌우할 중요한 신상품 개발 프로젝트)
3) 이해관계자 관리시 유의사항
- 초반부에 이해관계자의 이해관계를 식별한다
상품기획 초기부터 상품관리자와 프로젝트 관리자는 이해관계자와의 소통전략을 수립해야 한다. 소통하려면 상대방의 관심사항을 알아야 하고 그러기 위해서는 이해관계자를 직접 만나야 한다. 상대방이 이번 상품개발에서 무엇을 바라는지 직접 듣는 자리를 많이 만들어야 한다. 조직 내 상품개발과 관련된 이해관계자들이 자주 바뀌지는 않기 때문에 익숙한 이해관계자보다 신규 이해관계자의 이해관계 식별에 유의해야 한다.
- 이해관계자들의 요구사항을 파악한다
이해관계자별로 “무엇을 원하는가?” “혹시 그 요구사항이 프로젝트 진행단계별로 달라지지는 않는가?” 또한 “각 요구사항별로 기대수준은 어느 정도인가?” 이 모든 것을 파악해야 한다. 이때 상품관리자나 프로젝트 관리자가 임의로 이해관계자의 요구사항과 기대수준을 가정하면 안 되며, 핵심이 되는 이해관계자는 직접 만나서 그들의 이야기를 청취해야 한다. 때로 중요한 이해관계자를 만나기 힘들어하거나 부담스러울 수 있는데, 이는 바람직하지 않다. 핵심 이해관계자의 이야기를 듣는 것은 우물의 마중물과 같은 역할을 하여 다른 이해관계자들의 요구사항을 파악하는 데 많은 도움을 준다.
- 실무자를 통해 핵심 이해관계자의 요구사항을 파악하는 것은 금물이다
핵심 이해관계자를 만나기 힘들어 그를 보좌하는 실무자를 통해서 파악한 핵심 이해관계자의 요구사항과 기대수준을 믿고 프로젝트를 진행하다간 낭패를 보기 쉽다. 실무자와 관리자의 생각이 다른 경우 실무자가 관리자를 설득할 수 있는 가능성은 낮다.
- 중요한 이해관계자별로 따로 소통전략을 수립한다
상품관리자나 프로젝트 관리자가 직접 대응하고 관리해야 할 이해관계자를 식별한 다음에는 이해관계자와의 소통전략을 수립한다. 소통전략은 언제, 어떻게, 어떤 정보를 제공할 것인가를 의미한다. 중요한 이해관계자일수록 상대방이 원하는 정보를 사전에 공유하고 조언을 받아야 한다. 이를 위해서는 공식적인 프레젠테이션보다 커피 한잔 하면서 가볍고 짧게 소통 할 수 있는 역량도 길러야 한다.
- 중요한 이해관계자들에게는 기획심의, 중간 게이트, 출시심의 전에 미리 발표내용을 설명한다
이해관계자들과 협의하는 과정에서 새로운 요청이 있을 수 있다. 그렇지만 그러한 요청은 어차피 나올 이야기다. 발표 전에 파악하여 대응하는 것이 불편한 상황을 피하고 부작용도 줄일 수도 있다.
- 쟁점 사항은 쉽게 해결되지 않는다
이해관계자끼리 서로 상충되는 의견이 있을 때, 특정 이해관계자나 그룹이 일시적으로 양보를 하는 것처럼 보여도 신상품 개발 도중 다시 불씨가 살아나기가 쉽다. 사람들은 본인들이 중요하다고 생각하는 사안은 쉽게 양보하지 않는다. 잠시 숨을 고르다가 때가 오면 다른 명분을 만들어 패자부활전을 요구한다. 상품관리자나 프로젝트 관리자는 쟁점이 되었던 사항들을 꺼진 불이라 생각하지 않고 상대방의 입장을 헤아림과 동시에 지속적으로 관심을 가져야 한다.
- 상품관리자와 프로젝트 관리자는 프로젝트 내용을 숙지해야 한다
상품관리자와 프로젝트 관리자는 장소, 상대를 불문하고 프로젝트의 핵심내용을 이해하고 암기하여 설명할 수 있는 준비가 되어있어야 한다. 톰 피터스는 프로젝트 관리자는 다음의 질문에 항상 답할 준비가 되어 있어야 한다고 한다.
• 현재 자신의 프로젝트를 한 문장으로 설명할 수 있는가? 차별화 포인트와 프로젝트가 가져올 이익을 말할 수 있는가?
• 그 프로젝트를 하는 이유를 13~15살짜리 아이들이 완벽하게 이해하도록 설명할 수 있는가?
• 파워포인트 없이 9분 동안 CEO에게 완벽하게 프로젝트에 대해 설명할 수 있는가? 경영층에 따라 파워포인트 1페이지를 넘기기 전에 본인이 궁금한 내용에 대해 속사포와 같은 질문을 할 수 있는데 이때 해당 페이지로 이동하지 않아도 간단한 대답을 할 수 있어야 한다.
• 프로젝트 팀의 가장 막내 사원이 프로젝트에 흥미를 가지게끔 할 수 있는가?
• 프로젝트의 재정에 대해 컴퓨터를 켜지 않고도 펜으로 종이에 적을 수 있는가?
• 자신이 왜 그 프로젝트에 적합하고, 자신이 고른 전략이 왜 옳은지 간단하게 설명할 수 있는가?
• 프로젝트 실행과정에서 뛰어넘어야 할 벽 5가지와, 그 벽을 어떻게 뛰어넘을지 말할 수 있는가?
- 논리적 설명보다 정서적 공유를 중요하게 생각한다
상품개발을 진행하다 보면 어떤 이해관계자와 서로의 논리를 평행선으로 주장하는 경우가 발생한다. 사람들은 설득 당하기 보다 설득하기를 좋아한다. 현실에서 상대를 변화시키려고 하면 관계가 깨질 수 있다. 정서가 공유되지 않은 상황에서는 얽힌 실타래를 풀 수 없어 아무것도 못한다. 합리적인 말로 상대방을 설득하기보다는 상대방 입장에서 그 사람이 어떤 감정을 느끼고 있는지 이해하여 먼저 공감을 해주는 것이 중요하다. 정서의 교감이 있으면, 논리적인 설득이 훨씬 쉬워진다. 반대로 정서의 교감 없이는 논리적 설득은 힘들다. 잘해봐야 설득 당하는 척할 뿐이다. Understand는 상대방보다 아래(under)에 서는 것(stand)이다.
- 좋은 소식과 나쁜 소식을 전달할 때 유의한다. <결정적인 순간에 써먹는 선택의 기술, 2011>
• 여러 가지 나쁜 소식은 반드시 한 번에 발표
• 여러 가지 좋은 소식은 나누어 발표
• 크게 좋은 소식과 조금 나쁜 소식은 동시에 발표(좋은 소식에 나쁜 소식을 희석)
• 크게 나쁜 소식과 조금 좋은 소식은 나누어 발표(좋은 소식이 나쁜 소식에 희석되지 않도록)
- 관리자는 좋은 소식보다 나쁜 소식에 집중해야 한다.
좋은 소식은 내일 들어도 좋지만, 나쁜 소식은 내일 들으면 더욱 나쁜 소식이 된다.
- 중요한 메시지는 반복적으로 강조하는 소통을 한다.
<구글은 어떻게 일하는가, 2014>에서 이를 ‘넘치는 소통’으로 정의하였으며 관련된 구글의 지침을 다음과 같이 설명하고 있다.
첫째, 이 소통으로 모든 사람이 알 필요가 있는 핵심주제가 다시 부각되는가? 넘치는 소통을 잘하려면 핵심주제가 무엇인지 잘 알아야 한다. "반복구절이 기도를 망치지 않는다"는 말에서 우리가 말하려는 부분은 '기도'에 해당한다.
둘째, 이 소통은 효과적인가? 넘치는 소통을 잘하려면 뭔가 새로운 내용이 들어가야 한다. 반복자체만 강조하거나 학교에서 학생들에게 의미와는 상관없이 머리에 새길 때까지 억지로 주입시키는 충성맹세가 아니다.
셋째, 이 소통은 관심을 끌고 재미가 있으며 영감을 주는가? 호기심을 자극하라 예를 들어 조너선은 "무어의 법칙은 필연적인가?"에 링크를 걸어놓고 간단히 요약한 내용과 질문 몇 가지를 달아놓았다. 이 이메일은 뜨거운 논쟁과 대화에 불을 붙였고 일주일이나 지속되었다. 주제는 구글사업과 직결되는 문제도 아니고 논쟁에 참여한 이들의 직무와 관계된 것도 아니었지만 기술의 미래에 모든 것을 거는 구글의 광범위한 전략과는 일치되는 것이었다.
넷째, 이 소통은 근거가 확실한가? 당신의 이름이 들어간 주제라면 거기에는 당신의 생각이 담겨야 한다. 경험은 여러분의 것이어야 하고 소통에는 진실성이 담길수록 좋다.
다섯째, 이 소통은 올바른 대상을 향하고 있는가? 누가 받아봐도 되는지 확실하게 모를 때엔 신경 쓰지 말고 추가하라.
- 툴을 활용한 의사소통에만 의존하지 않는다.
의사소통을 지원하는 협업 툴(예:JIRA, Confluence, Slack)의 사용이 확대되면서 이해관계자간 소통을 툴에 의존하는 경우가 많다. 기획자끼리 사용하는 툴, 기획자와 개발자가 사용하는 툴, 개발자끼리 사용하는 툴이 따로 있을 정도이다. 툴은 분명 효율적이지만 효율 이상은 아니다. 효율은 쉽고 빠르지만 공감과 합의를 위한 의사소통에는 적절하지 않다. 바로 옆자리 팀원에게도 메신저로 소통하여 키보드 소리만 나는 상품개발팀은 의사소통을 잘하고 있다고 할 수 없다. 프로젝트 팀은 약간 시끄러워야 한다.
https://brunch.co.kr/@kbhpmp/160
