반응형
출처 : http://agile.egloos.com/5252946


앞으로 몇 번 동안은 AC2 내용을 조금씩 소개하는 글을 실어볼까 합니다. 첫번째로 "피드백을 잘 주고 받기"에 대한 입문격의 소개글로, 부정적 피드백을 받았을 때 대처법입니다.

그거 피드백 맞어?

상상해 봅시다. 오늘 프로그래밍하다가 나름 멋진 기술을 발견했습니다. 재미있어서 점심도 샌드위치로 때우고 더 다듬는 작업을 했습니다. 너무 뿌듯합니다. 오후에 팀 리뷰할 때 팀장에게 코드를 넌지시 보여줍니다.

팀장이 코드를 한번 휙 훑어보더니 아무일도 없는 듯 한마디 던집니다. "아, 이 기법. 내가 고등학교 때 봤던 C 교재에 나왔던 거네."

이 말을 듣는 여러분의 마음은 어떨까요? '아이구, 그래 너 잘났다. 너한테 보여준 내가 잘못이지.' 혹은 '그래, 내가 뭘 대단한 걸 알아내기나 하겠어. 용써봐야 팀장님 발끝에도 못미치지.' 등의 극단적 반응을 하기 쉬울 겁니다. 어느 쪽이건 기운이 팍 빠지겠죠.

피드백 훈련을 못 받았다

문제는 팀장이 피드백을 주는 훈련을 받은 적이 없다는 사실입니다. 그 팀장의 팀장도 필경 제대로된 피드백을 주지 못하는 사람이었을 겁니다. 가족 치료에서는 가족 내부의 문제는 대대로 이어지는 경우가 많다고 하는데(예컨대 아버지가 가진 문제는 아들이 학습하고, 다시 손자에게로 이어짐), 팀내의 역동도 비슷한 면이 있습니다. 팀의 문제는 전승되는 경향이 있습니다.

이럴 때 팀원이 할 수 있는 것은 무엇일까요? 여러가지가 있겠지만, 이 글에서는 첫번째 단계로 피드백을 해석하는 방법을 이야기하도록 하겠습니다.

주는 이의 사실

우선 기억해야할 명언이 있습니다. 초기에는 항상 마음 속에 담아두는 훈련을 하면 좋습니다.

피드백 정보는 그것이 어떻게 보이든 간에 상관 없이 거의 모두, 받는 사람보다 주는 사람에 대한 것이다. (No matter what it appears to be, feedback information is almost totally about the giver, not the receiver)

--제럴드 와인버그

이 원칙에는 이름이 있습니다. 주는 이의 사실(Giver's Fact)이라고 합니다(QSM3 p.220). 쉽게 말해, 누군가가 나에게 피드백을 주면 그 피드백에는 내가 어떤 사람이고, 내가 한 일이 어떻고 하는 정보보다, 피드백을 준 사람이 어떤 사람이고 스스로를 어떻게 생각하는지 등의 정보가 더 많다는 겁니다.

팀장 피드백 속의 정보

앞에서 팀장이 한 이야기는 나(팀원)에 대한 정보보다 팀장 자신에 대한 정보가 더 많다고 볼 수 있습니다. 어떤 정보들이 있는지 볼까요?

  1. 팀장은 다른 팀원들에 비해 자신의 지식 수준에 대해 자신이 없고,
  2. 가만히 있으면 다른 사람들이 자신의 지식 수준을 낮게 보지 않을까 걱정하고 있다. (만약 그게 아니라면, 사람들에게 말 안해줘도 잘 알텐데 왜 자신의 지식을 이런 부적절한 순간에 알려야 했을까)
  3. 팀장은 자신이 많이 알아야 팀장으로서의 권위가 선다고 생각하며, (팀장의 권위를 세우는 다른 효과적 방법을 모르고)
  4. 팀장으로서의 권위와 리더십에 자신이 없다. (만약 그게 아니라면, 왜 이런 간접적인 방법으로 자신을 보호하려 했을까)
  5. 결과적으로 상대나 맥락과 연결되지 못하고 있다. (그의 피드백에는 팀원이나, 팀 리뷰라는 맥락에 대한 언급이 없다)
여기에서 보다시피 흥미로운 점은 스스로 피드백 뒤에 숨으려고 노력하면 할수록 자신을 더 많이 드러내게 된다는 점이지요.

주는 이의 사실에서 얻을 수 있는 것


이 원칙을 잘 활용하면 어떤 이득이 있을까요?
  • 피드백을 줄 때 : 내가 혹시 이 피드백을 통해 주려는 정보는 무엇인가? 나에게 어떤 느낌과 의도가 있는가? 상대는 이 피드백을 받고 어떤 생각을 할까? 등을 미리 파악하고 생각해볼 수 있으며, 좀 더 적절한 피드백으로 바꾸어 전할 수 있다. (물론 과거에 내가 줬던 피드백을 반성할 수도 있다)
  • 피드백을 받을 때 : 부정적이거나, 사람을 조종하려는(manipulating) 피드백을 대했을 때 우선 마음의 평온을 얻을 수 있고, 내 감정에 너무 휘둘리지 않으면서 상대의 느낌, 욕구 등을 파악할 수 있다. 그리고 더 나아가 이 피드백 정보를 나에게 도움이 되는 쪽으로 해석하고 이용할 수 있다. (물론 과거에 받았던 "가슴 아픈" 피드백도 새로운 관점에서 볼 수 있다)
처음 소개한 상황에서 팀원이 "주는 이의 사실" 원칙을 따르면 직전의 "피드백을 받을 때"의 이점들을 얻을 수 있겠죠. 부정적 피드백을 들으면 머리 속이 꽉 차버립니다. 도무지 다른 생각을 할 수가 없게 되죠. 하지만 이 원칙을 적용하면 머리 속에 공간과 여유를 만들어 낼 수 있습니다. 그러면 아무래도 피드백을 나에게 도움이 되는 쪽으로 받아들이기가 훨씬 수월하겠죠.

좀 더 효과적인 피드백을 주는 방법과 그런 피드백을 이끌어내는 방법(팀원, 팀장으로서)에 대해서는 다음에 기회가 나면 글을 써보도록 하죠.

--김창준

p.s. 참고로 이 글은 앞에서 언급했던 QSM3의 17.7.4 실천문제에 대한 제 답안이기도 합니다.
반응형
반응형

#include <boost/signal.hpp> <= 요걸 일단 선언해야 한다. 

class Test
{
public:
typedef boost::signal<bool (const Event& arg), SignalTrue> KeySignal;
KeySignal OnKeyDown;
};
위의 코드에서 signal< void (const float time)> TimeSignal; 이런식으로 호출될 수도 있다. 
위의 코드는 편의상 SignalStopWhenResultTrue라는 객체를 선언했는데, 내부적으로 처리(주로 구분용)되는 것을 하면서 인자로 활용되는 녀석을 선언하는 것이고, 필요 없으면, 그냥 없이 선언해도 된다. 
뒤에 오는 두번째 인자는 키값이라고 보면 된다.

connect()함수를 호출하게 되는데 이때, boost::bind()라는 함수를 사용하게 된다. 
이때, 첫번째 인자는 호출된 함수와 해당 호출될 객체의 주소(파생된 객체가 선언될 경우도 있으니...)

test_.OnKeyDown.connect(boost::bind(&GUISystem::OnKeyDown, &guiSystem_, _1)); <= 인자가 하나일때
test_.OnHotkeyCommand.connect(boost::bind(&GUISystem::OnHotkeyCommand, &guiSystem_, _1, _2)); <= 인자가 두개일때


등록 콜백함수 지우기
boost::signal::connection a = timeManager_->OnRunUpTime.connect(boost::bind(&class::OnRunUpTime, this, _1));
// ....
a.disconnect();


                   http://jangyeol.springnote.com/pages/412787
반응형

+ Recent posts