[Okky-퍼옴]좋은 피드백을 받기 위한 질문 방법

신입 개발자로 입사한 친구가 첫 코드리뷰를 앞두고 긴장된다는 얘길 하더군요. 어떤 얘길 해야 할지, 내 바닥이 드러나지 않을지, 너무 까이지 않을지 등등…

오늘은 그 친구에게 얘기했던 내용을 요약해서 상사 (혹은 그 누구에게라도) 좋은 피드백을 받기 위한 질문 방법을 공유하고자 합니다.

1. 질문에 앞서 준비하는 시간 갖기
2. 질문을 하기 전에 꼭 질문을 준비하기 위한 시간을 가지세요. 대부분의 사람들은 라이브로 얘길 하면 중언부언을 하게 됩니다. 정리되지 않은 질문을 해석하는 노력은 듣는 사람에게 부담입니다. 질문 및 회의 상황에서 이야기 할 요소들을 메모나 자신이 편한 형태로 정리하세요.
3. 질문 및 대화의 목적 분명하게 하기제 친구의 예를 들면, 이 코드 리뷰의 목적은 뭘까요? 당장 프로덕에 들어가는 코드를 짜는게 아니라 적응을 위한 토이 프로젝트를 하고 있던 친구의 상황을 고려하면, 상사는 얼마나 지금 짜는 코드를 이해하고 있는지, 문제에 제 친구가 어떻게 접근하는지를 파악하고 더 나은 방향으로 공부할 수 있게 피드백을 주는 것이었을겁니다.만약 이런 준비가 되어 있지 않은 상황에서 미팅에 들어가면 그냥 첫번째 줄부터 한줄 한줄 코드를 보게 될 것이고, 들여쓰기 등의 formatting이나, 특정 코드 실수에 대한 지적으로 미팅이 진행될 것이고, 결국 시간이 지나면서 집중력이 떨어지면 혼나고 끝나버리는 최악의 미팅을 하게 될거라고 생각했습니다.
4. 즉, 목적을 확실히 하고 그 목적을 달성하기 위해 준비해야 합니다. 평판 같은걸 떠나서, 많이 배워와야죠.
5. 제가 친구에게 한 조언은, 평가 받는 자리라고 생각하지 말고 최대한 배울 수 있는 질문을 하는 자리라고 생각하자는 거였습니다. 최대한 배우기 위해서라면, 최근에 짜고 있는 부분에서 막히는 파트에 대한 너의 접근을 공유하고, 생각의 흐름에서 어떤 선택을 하는게 더 나았을지를 물어보는 것을 제안했습니다.
6. 이 회의의 목적, 대화의 목적이 뭐죠? 정보를 전달 받는 것이 목적인지, 의사 결정을 하는 것이 목적인지, 비판적으로 바라봐 주길 바라는지 등등… 분명히 질문의 목적을 정해야 합니다. 이 과정에서 생각해보니 물어볼 필요가 없을 때도 있고, 질문의 방향을 바꿔야 하는 상황도 생깁니다.
7. 상사의 대답 비용 줄이기 (핵심)첫번째로, 회의의 목적을 개괄하세요. 이 회의는 이러한 목적의 시간이 되었으면 하고, 이러이러한 부분에 대해 의견을 듣고 싶습니다. 라고 이 시간을 정의해 주세요. 그 관점에서 바라보기만 하면 되니, 훨씬 에너지 소모가 줄어듭니다.세번째로, 더 간단한 답변을 의도하도록 질문하세요. 최대한 객관식의 질문으로 유도하세요.B에 대해서 어떻게 생각하세요? 라는 질문은 더 낫지만 역시 핑퐁이 오가야 하는 질문입니다. 주관식 질문은 어쨌든 어렵습니다.마지막으로, 답보다 피드백을 받으세요. 어쨌든 답을 주는 것은 부담스럽습니다. 내가 틀릴 수도 있고, 최고의 방법이 아닐 수도 있지 않겠습니까. 또한 답이 질문자의 상황과 거리가 먼 전제를 갖고 있다면 더욱 답을 주는 것은 어려운 일입니다.
8. 그에 반해, 피드백을 주는 것은 더 낫습니다. 질문자의 상황을 듣고, 그 상황에서 특정 부분만 요렇게 바꾸는게 어때? 라는 식의 제안이 가능하기 때문에, 질문자의 상황을 기반으로 하고 있어 변경이 용이하고, 당장 한걸음만 더 좋게 하는 것이기 때문에 이 피드백은 최고의 방법일 필요도 없어서 부담이 훨씬 덜합니다.
9. 제 질문은 XX이고, 저는 여기에 답1, 답2, 답3이 있다고 생각합니다. 어떻게 생각하시나요? 라는 질문이 제일 듣는 사람 입장에서 쉽습니다. 하나만 고르면 되고, 왜 그런지를 설명할 때도 질문자가 이 문제를 어떻게 바라보는지가 분명하기 때문에 설명이 쉽습니다. 다만, 이런 질문을 만드는 것은 라이브로 하기 매우 매우 어렵습니다. 꼭 준비하는 시간을 가지고 어떤 대화가 오가게 될지 시뮬레이션 해보세요.
10. A를 알려주세요 ㅠ 라는 질문은 매우 매우 어려운 질문입니다. 질문자가 A와 관련된 지식이 얼마나 있을지 모르고, 내가 해야 할 말이 많습니다. 게다가 내 의견만 정답은 아닐 것이고, 그럼 어디까지 설명해야 하는지도 모릅니다. 최악의 질문이죠.
11. 두번째로, 두괄식으로 말하세요. 결론 먼저, 결론에 다다르게 만드는 중요한 포인트들은 A, B, C가 있고, 구체적으로 가면 A는 이거고 B는 이거고 C는 이겁니다. 그래서 결론은 이것입니다, 하는 식의 구조적인 설명을 하면 듣는 사람 입장에서 정리가 잘 됩니다. 중요한 얘길 앞으로, 부차적인 얘길 뒤로 빼세요.
12. 상사는 회의가 많습니다. 에너지에 한계가 있습니다. 최소한으로 그의 에너지를 쓰면서 내가 뽑아먹을 것들을 뽑아야 합니다.
13. 필요한 양해 구하기
14. “제가 질문 드리고 싶은게 있어서 메모를 해 왔는데, 이걸 보면서 여쭤봐도 될까요?” “제가 조금 더 설명을 잘 하고 싶어서 그런데, 잠깐 1분 정도 생각할 시간을 가져도 될까요?” 등등, 질문이나 회의 시간에 필요한 양해를 구하세요. 대부분은 적극적이라고 생각하지, 답답하거나 바보 같다고 느끼지 않을겁니다.

1. 답변을 자기 버전으로 다시 설명하기
2. 질문에 대한 답을 들었을 때, ”말씀 하신 답을 ~~라고 저는 이해했는데 답 주신 내용이 맞나요?“ 라는 질문을 하세요. 한쪽은 말만 하고 한쪽은 듣고만 있을 때 커뮤니케이션 오류가 발생하는 가장 빈번한 상황은 듣는 쪽에서 자신의 이해가 맞는지에 대한 확인을 안해서 각자 다른 길로 가는 커뮤니케이션이 일어날 때라고 생각합니다. 영어로 are we on the same page? 라고 말하는데, 서로 이 대화에서 의도하고 이해한게 맞는지 확인해 가야 합니다.
3. 선의를 가정하고 듣기하지만 업무에서 소통을 할 때 악의를 가정하면서 듣는다면, 이것은 그대로 비용입니다. 상대방의 말에서 신호와 잡음을 걸러내는 필터링을 해야 한다는 것인데, 쉽지 않을 뿐더러 피곤해지고, 이는 커뮤니케이션 자체를 줄이는 문제로 작용합니다.또한 이런 대화의 경우 회의록을 작성해서 함께 회의에 참석한 사람들을 cc걸어 메일로 보내는 방법도 있습니다. 이 역시 선의로 듣는다고 하더라도 하면 좋은 행동이죠.
4. 상대방의 악의가 걱정된다면, 차라리 책임 소재를 분명히 하고 상대에게 듣는 정보의 검증 수단을 고려하세요. 이것은 선의로 들을 때도 누가 어떤 책임과 의무를 갖는지, 그 정보가 옳다는 것을 어떻게 검증할지를 고려하는 것은 필요합니다.
5. 직장에는, 아니, 인간사에는 당연히 악의를 가진 사람과 선의를 가진 사람이 모두 있습니다. 자기 자신 안에서도 복합적으로 존재하는걸요.

1. 겁나 바쁜데 이럴 시간이 있나?하지만 잘못된 커뮤니케이션을 하는 조직이 프로덕을 잘 만드는 것은 매우 어렵습니다. 마치 무거운 바위를 옮기기 위해 함께 힘을 내서 당겨야 하는데, 서로 줄다리기를 하는 것처럼 되는 상황이 일어나면 열심히 일한 사람의 노력까지 무산되기도 하니까요.
2. 이런 질문을 간혹 받습니다. 분명히 질문을 하고 답변을 하는 것은 시간과 에너지가 듭니다. 내가 모르는걸 인정하고 물어보는 것도 창피하기도 하고, 때론 혼나거나 잔소리를 듣는 것 같기도 합니다.

오늘도 잔소리가 길었지만, 누군가에겐 도움이 되시길 바라면서 씁니다. 한 주 잘 보내세요 ㅎㅎ

 

https://okky.kr/articles/1413056

OKKY - 좋은 피드백을 받기 위한 질문 방법