brunch

You can make anything
by writing

C.S.Lewis

by 오늘 May 06. 2022

직장 동료간 업무 피드백의 5가지 원칙

기획자-개발자 간 피드백을 하고 싶다면

원치 않는 순간에
요청하지 않은 동료에게
'조언' 받기를 즐기는 사람은 없다.



최근 상호 동료평가, 팀장 평가 등이 많은 회사들에 도입되면서, HR 관점에서 피드백의 시스템화에 대한 논의가 활발하다. 인간은 건설적인 피드백을 통해 성장할 수 있다. 그러나 친구 혹은 지인 사이에 '조언'이 어려운 커뮤니케이션 방식인 만큼, 회사 동료 간의 (비공식적인 맥락에서) 피드백 역시 아주 조심스럽고 신중해야 한다. 회사에서 함께 업무하는 동료라면 그동안 쌓아올린 미묘한 관계 속 상호작용과 업무, 팀 간의 맥락이 더해져 같은 말도 다르게 들릴 수 있다.


프로덕트 매니저인 나는 개발자와 매일 소통하고 협업한다. 최고의 구성원이 모인 팀이라 할지라도 장기간 운영되는 프로젝트 팀에서는 업무적인 충돌이나 우선순위 경합이 발생한다. 이 자연스럽고도 건강한 충돌을 어떻게 해소하느냐가 커뮤니케이션의 핵심이다. 데일리 루틴에서 기획자와 개발자 간의 커뮤니케이션은 숨쉬듯 이루어지지만, 피드백은 또 다른 차원의 이야기다. 특히 서로 다른 업무를 하는 개발자와 기획자는 동상이몽의 스탠스를 갖고 있을 수 있다.


나를 당황스럽게 만들었던 개발자의 피드백이 있다. 내가 피드백을 요청하지 않은 사람이, 내가 가장 원하지 않았던 시간에(서비스 릴리즈 전 날의 퇴근시간) 내가 요청하지도 않은 피드백을, 내 옆자리에 서서 갑작스럽게 시작한 것이다. 당연하게도 이 상황은 결코 달갑지 않았고 나는 그 순간 열린 마음으로 피드백을 들을 수 없었다. 게다가 그 피드백의 내용 또한 어쩌면 너무 당연했기에 나에게는 별로 도움이 되는 내용이 아니었다. 요약하자면 내가 개발자에게 타이트한 일정 속에서 수정을 자주 요구한다는 것이었다. (게다가 그날 아침 내가 요구했던 건 수정 요청이 아닌 협의였는데!) 기획팀에 대한 공식적인 컴플레인이었다면 차라리 더 이해가 갔을 내용이지만, 안타깝게도 평소 친밀한 관계였던 개발자는 나에게 애정을 담아 나름의 '피드백'을 주고 있었다.

기획대로 열심히 제품을 개발하고 있는 개발자에게, 갑작스럽게 일정이나 피쳐에 수정이 가능할지 묻는 내 역할이 부담스러우리라는 것은 알고 있다. 그러나 그것이 나의 역할 중 하나다. 나는 기획자이자 PM이지만, 동시에 서로 다른 이해관계를 가진 유관부서 및 상사의 지시를 가운데에서 소화해내는 행정가다. 내가 개발자에게 요구하는 것은 나만의 요구사항이 아니다. 서비스 오픈 직전까지도 나의 상무, 팀장, 부장, 다른 유관부서의 담당자는 PM에게 여러 변수를 확인하고 수정이 가능한 부분을 문의한다. 물론 모든 요구사항을 반영하지는 않겠지만 현재로서 개발이 불가능한 것과, 개발은 가능하지만 우선순위가 낮거나 서비스와 핏하지 않기 때문에 개발하지 않기로 결정하는 것은 전혀 다르다. 따라서 이 두가지를 구별하기 위해서라도 나는 이 수정개발이 가능할지, 불가능하다면 왜 불가능한지 확인하기 위해 개발자와 소통해야 한다. '협의'는 어떤 사안에 대해서 함께 검토하고 결론을 도출하는 과정이다. 기획자가 협의를 요청하는 것만으로 기획자가 '수정'을 요구한다고 인식하는 개발자가 있다면 안타깝다. 그가 어떻게 생각하든 나는 앞으로도 변수가 발생할 때마다 계속 개발팀에게 사실 확인을 요청하고 필요시 협의를 요청하게 될 것이다.


실무에서든 인터넷상에서든 개발자의 애로사항을 기획자가 이해해야 한다고말하는 경우를 많이 보았다. 그 반대의 경우, 기획자의 업무와 역할에 대한 존중은 지켜지고 있는가?


양질의 피드백은 인간을 성장시키는 거름이 되지만, 한편으로 가장 존경하고 따르는 사람에게조차 온전히 수용하기 어려운 것이 피드백이다. 사람이라는 것이 그렇다. 직장에서 동료에게 불현듯 피드백을 하고 싶어진다면 아래의 다섯가지 업무 피드백 원칙 리스트를 다시 한번 생각해보자.(내가 만든 리스트다.)


1. 나는 이 사람의 역할과 업무환경을 전체적인 관점에서 이해하고 있는가?

2. 나의 피드백이 이 사람의 업무 개선에 실제로 적용 가능할까?

3. 나와 이 사람의 관계는 (서로 요청하지 않은) 피드백을 주고받을 정도로 준비가 되었는가?

4. 일방적인 피드백이 아니라 나도 이 사람에게 피드백을 받을 준비가 되어 있는가?

5. 지금 이 사람이 나의 피드백을 원하고 있을까?


이 5가지 원칙에 하나라도 '아니'라는 생각이 스친다면, 지금 당신의 동료에게 비공식적인 피드백을 건네는 건 그렇게 좋은 아이디어가 아닐지도 모른다.





나에게 피드백을 준 동료도 많은 고민 끝에 나에게 피드백을 주었겠지, 생각하면 한없이 부끄럽고 겸손해진다. 받아들일 건 받아들이고 개선하되, 스스로 너무 위축되거나 의기소침해지지 말자고 다짐하며 글을 썼다. 나의 약점을 고치려다가 나의 강점을 잃어버려선 안 되는 거니까.

작가의 이전글 비전공자 SQLD 합격기 (제 44회)
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari