개발자와 PM이 (매우) 사이좋게 잘 지내는 방법
같은 배를 탔다고 말은 하는데, 내가 느끼는것은 그건 아닌듯 하고
*글에서 인용하는 PM은 프로덕트/프로그램 매니저를 지칭하고자 사용하였습니다.
0. 로마황제도 포기한 부분 - "사람 변하기 힘들어요"
로마제국의 가장 위대한 황제중에 '철인 황제'라 불리고 스토아 학파의 철학자로 유명한 마르쿠스 아우렐리우스가 있습니다. 그가 지은 '명상록 Meditations' 에 이런 말이 나옵니다.
“아침에 일어나면, 스스로에게 말하세요. 오늘 내가 만날 사람들은 나를 간섭하고, 감사함이 없이 이기적이고 거만하며, 진실하지 못하고, 시기 질투에, 괴팍한 성격을 가진 사람들일 것입니다."
마르쿠스 아우렐리우스의 명상록당시 최고의 권력자에 최고의 철학적 지성을 지녔던 그 황제조차 해결하지 못하는 부분이 바로 사람들과의 관계였던 것이죠. 주위사람들로 부터 받는 스트레스가 얼마나 많았으면 매일 아침마다 사람들에 대한 기대치를 최소한으로 셋팅하는 일을 했을지 짐작하기도 쉽지는 않습니다. 즉 백성을 다스릴수는 있지만, 변화시키는 부분에 있어서는 한계성을 느꼈나 봅니다.
사람들의 행동을 연구할때 쓰는 르윈의 법칙/공식이라는 것이 있습니다.
B = f(P, E)로 표현이 되는데 사람의 행동(B-Behaviour)은 그 사람이 태어나면서 부터 가지고 있는 본성(P-Person)에 사회환경/경험(E- Environment, Experiences) 의 곱으로 구성(f-function)된다는 것입니다.
즉 사람의 현재 행동에 변화를 기대하려면, 가지고 태어난 본성은 변경시킬 수 없는 상수와 같기에, 사회환경과 경험 E 를 통해서만 가능하다는 것을 2천년전의 로마황제는 이미 파악했고 우리에게 가르침을 주는 것입니다.
우리는 함께 업무를 하는 동료들과 항상 관계가 원만하거나 좋기만 한것은 아닙니다. 같은 목표와 지표를 지녔다고 해도, 이해관계가 다르고, 전문분야가 다르면 충돌하고 의견이 다른 경우는 수시로 발생을 하게 됩니다. 갈등이 심해지면 "같은 배를 탔다"고 하며 중재자가 나타나서 서로를 다독이기도 하고 이해도 하려고 하지만, 근본적인 동질감은 갖기 힘든 경우가 허다합니다.
그러나 이천년전의 로마황제가 우리에게 알려주듯, 동료의 행동 변화를 기대한다면 나에 관한 그들의 경험치를 변경하는것이 유일한 방법임을 깨닫는 것은 매우 중요한 일입니다. 내가 보여주는 작은 말 한마디와 배려깊은 행동이 더 좋은 관계성, 더 훌륭한 품질의 제품/서비스를 만들 수 있는 큰 소스가 될 수 있습니다. 오늘은 소프트웨어 기업의 엔지니어링 그룹에서 빈번히 발생할 수 있는 여러 관계상황중에서 개발자와 PM (product / program manager) 사이를 더욱 친밀하게 만들 수 있는 소스의 레시피에 대해서 이야기를 해 볼까 합니다.
1.고정된 시선에선 상대방 입장이 다 보이지 않아요.
인터넷에서 우스갯거리로 퍼져있는 사진입니다. 개발자, 디자이너, PM이 서로 서로를 어떻게 보는지 그 단면을 매우 잘 표현한듯 합니다. 각각 본인의 업무는 자부심, 자존감 뿜뿜내는 이미지로 묘사되는데 반해, 개발자의 시선으로 보는 PM은 별 노력없이 그냥 놀고 편하게 지내는 스타일로 보여지고, PM의 시선에 들어온 개발자는 그냥 제조공정의 노동자로 비추어집니다. 저는 이 상황이 실제를 반영하지도 않을뿐만 아니라, 비슷한 면이 있다면 조금씩의 노력으로 충분히 개선이 가능하다는 판단입니다.
오늘의 글을 쓰게된 배경 설명을 드리자면, 저는 올해 직장생활이 30년째가 되는데, 처음 직장생활을 개발자로 시작을 해서 아키텍트까지 약 15년간 전문성을 갖춘 개발자 생활을 했었고, 그 이후에 PM으로 직무 전환을 하여 여러 프로덕트 릴리즈를 담당하고, 지금은 엔지니어링그룹 내에서 디자인 가이드라인과 표준 컴포넌트를 릴리즈하는 디자인 UX그룹에서 PM역할을 수행하고 있기에 누구보다도 더욱 위의 묘사된 개발-디자인-PM의 모든 역할별 사진의 상황을 잘 이해한다고 말씀드릴 수 있습니다. 그래서 매일 매일 내 역할을 수행하기 위해서 내 역할과 다른 일을 수행하는 엔지니어, 디자이너, PM들과 일을 하면서 느꼈던 것들을 정리해 보려고 했습니다.
내가 그 역할이 아닐때, 이해할 수 없었던 것들이, 그 역할의 자리에 앉으니, 이해가 됩니다. 투덜거리고, 같은 일을 하는 동료들끼리 뒷담화를 하던 것들이 모두 그 역할에 대한 지식과 이해 부족에서 나왔다는 것을 알고 참 부끄러웠던 시간이 있었습니다. 오늘 글에서는 디자이너의 입장은 다음으로 돌리고 개발자와 PM 간의 상호간 이해도를 높일 수 있는 서로간의 입장에 대해서 설명하고, 그 시각차를 줄여서 모두 사이좋게 즐거운 분위기로 업무를 진행할 수 있는 방법 몇가지를 소개하려고 합니다.
2. 개발자가 무한 신뢰하는 PM이 되기 (PM이 할 일)
일반적으로 개발자들이 신뢰하는 사람은 본인과 같은 업무를 하는 개발자들입니다. 그중에서도 특히 뛰어난 개발실력을 갖춘 개발자나 전체 설계를 담당하는 아키텍트의 한마디 한마디는 바이블과 같은 위력을 발휘하죠. 그러나 기업의 제품이나 서비스를 초기에 기획하는 일은 그런 개발자의 손에서 이루어지지 않습니다. 여러번의 지난 글에서 설명드렸듯, 프로덕트리더십이 설정한 비전과 전략에 따라서 프로덕트 매니저의 손을 거쳐 세부 기능 분류와 우선순위에 따른 릴리즈플래닝이 마련됩니다. 처음시작이 이러다 보니 개발자와 PM의 관계는 한쪽은 드라이브를 하고, 한쪽은 그에 맞추어 줘야하는 입장으로 해석이 되면 갈등의 기본원인이 될 수 밖에 없습니다. 이런 특성을 고려한다면 PM들은 최소한 진지하게 아래의 5가지 노력이 필요합니다.
A. 문제점/개선점/고객의 애로점만 설명하고 그 해결책/솔루션을 이야기 하지 마세요.
PM 본인은 제품/서비스 안에 "무엇을" "왜"에 집중하고 설명하는 일이며, 개발자는 그것을 현실 세계에서 "어떻게"로 풀어내주는 PM의 유일한 파트너 임을 항상 명심합니다.
PM의 업무는 고객/시장의 문제점/애로점을 우선순위화 하여 해결된 제품을 릴리즈 하는것이지, 각 문제의 해결책을 제공하는 일이 아닙니다. 해결책 제공은 개발팀의 고유권한입니다. 서로간의 영역 경계를 명확하게 해야합니다.
혹시 해박한 기술적 배경이 있는 PM이라 할지라도 개발팀이 제안한 솔루션을 무시/묵살 해선 안되며, 개발팀으로부터의 작은 (기술, 운영) 제안에도 적극적 수용을 노력합니다.
개발자는 회사의 '자원 resource' 가 아닌 제품을 실제로 구현하는 '빌더 builder'이고 동작을 지속시키는 'keeper'라는 개념을 갖습니다.
제공될 기능의 우선순위를 정하는 과정에서도 "왜"를 개발팀에 명확히 전달하여 필요없는 오해나 커뮤니케이션 백로그를 만들지 않습니다.
※ 이 부분에 관해서는 이 책을 추천드립니다. 번역본도 나와있네요. 나는 왜 이 일을 하는가? Start with Why - Simon Sinek
B. 가능한 한 프로젝트의 초기 단계부터 개발자들을 프로세스에 포함시키세요.
개발자가 매인이 되지는 않지만, 초기 플래닝 프로세스 (디자인 워크샵, 고객 요청사항 리뷰, 우선순위 토론, MVP 미팅등) 부터 적극적으로 참여시켜 제품/서비스 기능 요청에 대한 배경이나 우선순위설정에 대한 동일한 이해도를 가질 수 있도록 합니다. 많은 개발자를 참여 시키기 보다는, 대표성을 지난 각 부문 엔지니어링 프로덕트 코어팀 (PM, 스크럼 마스터, 개발매니저, UX 디자이너, QA매니저 등)으로 구성하는것이 좋습니다.
특히나 개발자에겐, '개발도 잘 모르는 저런 사람들이 마음대로 결정하여 통보한다.'라는 부정적 느낌을 주지 않기 위해서 투명한 커뮤니케이션은 필수입니다.
C. 개발자들이 경험하는 어려움에 적극적으로 공감을 표현 하세요.
개발 배경을 지닌 PM이라고 해도 개발자들이 최근에 사용하고 표현하는 테크니컬 디테일을 모두 이해하는것은 무리일 수 있습니다. 그러나 무엇이 어떻게 어렵고, 힘든 부분인지를 적극적으로 듣고, 이해하고 공감을 표현하는것만으로도 개발팀으로 부터 신뢰감을 얻을 수 있습니다. 신뢰감을 느낀 개발자들은 반드시 솔루션을 찾아 해결할 것입니다.
PM은 이런 소통을 통해, 제품/서비스의 기술 아키텍쳐를 이해 할 수 있는 기회가 되고, 개발 업무중 무엇이 어렵고 쉬운지를 알게되어 고객/시장에 어필포인트에 대한 아이디어를 얻을 수 있으며, 개발자들에게는 고객의 상황을 좀 더 공감할 수 있는 언어로 설명을 할 수 있습니다.
D. 데이터에 기초한 결정 (Data-Driven Decision) 과 투명한 커뮤니케이션을 하세요.
사용자리서치나 공식 고객요청서 등 데이터에 근거하여 명확한 고객/시장 요구사항 리스트, 사용자 스토리를 작성하고, 소통하되, 테크니컬 작업/업무에 관한 정의는 개발자 엔지니어의 풀파워로 남겨 놓습니다.
업무 회의후에는 명확하게 책임의 한계를 기술한 회의록를 참석자와 관계자에게 배포하여, 항상 같은 이해도를 유지합니다.
개발자나 엔지니어들이 PM에게 '기습당했다'라는 느낌 (예: 로드맵 변경, 우선순위 변경 등)은 절대 갖지 않도록 커뮤니케이션에 신경씁니다.
E. 실수를 인정하세요
프로젝트를 진행중에 우선순위가 바뀌거나, 지원대상이 변경되거나 하는 일은 자주 발생을 합니다. 그 이유또한 리더십과 PM의 시장분석이 잘못되었을 수도, 고객의 요청이 급히 바뀌었을 수도 있고 또 다른 100가지 이유가 있을 수 있습니다. 그 상황을 개발팀에게 설명하고, 미안함을 표현하는것, 때에 따라서 실수를 인정하는것 역시 PM의 역할입니다. 주저하거나 두려워 할 필요는 없습니다.
일반적으로 개발자들은 그런 실수를 PM의 개인적인 실패로 생각한다거나, 결정된 결과에 대해 크게 좌절 실망하지는 않습니다. 오히려 그렇게 투명하게 전달해주는 PM에게 신뢰 포인트를 보내줍니다.
3. PM이 무한 신뢰하는 개발자 되기 (개발자가 할 일)
PM의 생각은 한곳에만 머물러 있을 수 없습니다. 모든 이해관계자 stakeholders가 PM에게는 모두 고객이기때문 입니다. 제품을 사용하고 평가해주는 찐 고객뿐만 아니라, 회사내의 리더십, 프로덕트마케팅, 기술지원, 교육부서와 엔지니어링 그룹의 개발그룹, 디자이너, 사용자리서치, 데브옵스까지 모두가 고객입니다. 그 가운데서도 PM의 무한신뢰가 필요한 그룹은 개발자가 되겠죠. 모든 추상적인 아이디어를 실제로 보여주고 만들어 주는 사람들이기 때문입니다. 그럼에도 PM과 개발자 사이에는 텐션이 높아지는 상황도 발생하고, 서로를 못 믿는 불신의 상황도 나타납니다. 어떤 개발자가 PM과 동반자를 넘어 신뢰를 나누는 사이가 될 수 있을지 생각해 봅시다. PM이 무한 신뢰하는 좋은 개발자는 3가지 노력이 필요합니다.
A. PM은 개발자의 모든 기술을 다 알지 못하지만, 나름 잘하는 것도 많습니다.
PM은 종종 개발자의 상황 설명을 듣고 있으면 점점 더 이해가 안되고, 어려워 짐을 느낍니다. 하나를 설명하기 위해 또 다른 기술을 예로 들어 설명합니다 또 다른 기술언어를 사용합니다. 그리고 이해 못하는 PM을 가끔 한심하다는 표정으로 쳐다보기도 합니다.
PM의 역할은 고객/시장이 원하는 제품/서비스를 정해진 시기에 성공적인 품질로 릴리즈하는것입니다. 모든 개발기술을 해박하게 알고 있으면 좋겠지만, 그러지 못한것이 어쩌면 정상입니다. 대신 PM은 고객의 언어 (요청사항)를 해석(데이터 분석, 비전과 전략 수립)하여, 테크니컬 오브젝트( 릴리즈 플래닝, 우선순위리스트등)로 바꾸는 또 다른 특별한 기술자라고 생각해주면 됩니다.
개발자가 현재의 상황 설명을 조금은 쉽게 설명해 주면서, 이것이 현재 사용자스토리나 우선순위에 어떤 영향이 있는지를 알려 줄 수 있으면 PM들은 정말 감사해 합니다.
B. 전체 프로세스를 이해하고 생산적인 커뮤니케이션이 되도록 노력해 주세요.
개발자가 전체 프로세스를 보기는 쉽지 않습니다. 그러나 하나의 제품/서비스 아이디어가 실제 릴리즈 되기까지는 수많은 프로세스와 관계자들이 생성이 되고 유기적으로 결합해서 협업을 합니다. 개발이 그 프로세스중에 가장 중요한 부분중의 하나이지만 전체를 대표하지는 아닙니다. 제품/서비스가 성공해야 모든 프로세스 관계자들이 성공한다고 이해해 주길 원합니다.
PM들이 아마도 가장 힘들어하는 대화 상대가 개발자 일 수 있습니다. 기능테마를 리뷰할때면 개발자들은 "아 그건 안되요, 어려워요. 기간내에 맞출 수가 없어요" 이런 대답이 너무나 즉각적이고, 단호하게 나오는 상황이 빈번하거든요. PM 역시 안되고 무리한 것을 무작정 밀어 붙이고 싶어하지는 않습니다. 대신 어떤 대안이나 제안을 해 주길 원하고 어떻게 이 상황을 극복해 나갈 수 있는지 생산적인 커뮤니케이션이 되길 원합니다.
C. 릴리즈플래닝을 지켜 주고, 문제는 즉각적으로 알려주세요.
코드프리즈 시간이 되면 더 이상 수정될 수 없으며, 그때까지의 코드는 합의된 품질이 확보되어 있어야 합니다. 릴리즈계획대로 진행이 되지 않으면 왜, 어떤 이유로 인지가 명확해야 합니다. 그리고 얼마나 더 필요한지 정량화 할 수 있어야 합니다. 대부분의 개발자들이 이런 부분에 모두 민감하고 정확하게 움직여 주지만 그렇지 않은 상황도 끊임 없이 발생을 합니다. 더 심각한 상황은 꽤나 끔찍한 문제를 그때까지 꽁꽁 숨겨두었다가 프로젝트 마지막 순간에 발견이 되기도 합니다. 수많은 이유와 변명도 함께 테이블위에 올려지구요. 이런 상황은 진정으로 PM을 어렵고 힘들게 할뿐만 아니라 그 개발자/개발팀에게 더 이상 신뢰감을 줄 수가 없게 됩니다.
모든 PM은 문제 발생 소지는 즉각적으로 소통되고 이해되고 결정되기 바라고, 릴리즈 플래닝은 되도록 변경없이 지켜지길 바랍니다. 그러나 모든것에 예외가 있을 수 있고, 그것을 위해 팀이 함께 한다는 점도 잘 알고 있습니다.
4. 르윈의 법칙 B = f(P, E)
제 나름의 미천한 경험과 지식을 통해서 양쪽의 입장을 설명하고, 서로간에 잘 지낼 수 있는 치트키라고 생각하는 부분을 설명드렸습니다. 이런 부분이 "신뢰감이 먼저냐, 이런 방법들을 실행하는것이 먼저냐"로 또 다른 토론을 하는것은 무의미하다는 판단입니다.
서문에서 르윈의 법칙을 이야기하며, 사람 행동의 변화를 만들 수 있는 유일한 변수는 새로운 경험/환경 experiences/environments를 제공하는 것이라고 말씀드렸습니다. 여러분이 현재 PM이나, 개발자 라면 오늘이 내 동료에게 새로운 경험을 제공하는 day 1 이라고 결정하고 실행해 보면, 조금은 상호 존중하고, 동기부여되는 환경이 만들어 지고 그러는 사이 신뢰감이란 결과는 저절로 쌓이지 않을까요? 그 토양에서 품질 좋은 제품/서비스가 나오는 건 어쩌면 당연한 결과가 아닐까 합니다. 여러분들의 작은 노력이 큰 변화의 물꼬를 만들것입니다. 늘 응원을 보냅니다.
다음편의 글도 준비해 보았습니다.
