저는 예병일에 경제노트라는 메일링리스트에 가입되어 있습니다.
덕분에 매일 경제에 관련된 글과 함께 예병일씨의 견해가 하루 한통씩 들어오는데 오늘 프로젝트 진행에도 도움이 되는 좋은 글이 있어서 올려봅니다.
오늘 저에게 메일로 온 내용은 요청에 응하게 만드는 심리기법이라는 글입니다.
일단 원문을 읽어보시길 바랍니다.
|
요청에 응하게 만드는 심리기법... foot-in-the door technique (예병일의 경제노트, 2008.8.19)
매달 높은 이자나 수익을 주겠다며 적은 돈을 빌린뒤 처음에는 꼬박꼬박 약속한 돈을 지급합니다. 그뒤 거액을 돈을 빌리고는 약속을 지키지 않습니다... 우리가 뉴스를 통해 자주 접하는 전형적인 금융사기범의 수법이지요. 신문과 방송에 잊을만 하면 나오고, 그들이 제시하는 이자나 수익배분 액수가 터무니없이 많아도, 여전히 그런 사기꾼에게 넘어가는 사람들이 있습니다. 사람의 심리가 그렇기 때문이겠지요. '풋 인 더 도어 테크닉'(foot-in-the door technique)... 사람을 요청에 응하게 만드는 이런 기법을 심리학에서는 이렇게 표현합니다. '문간에 발들여놓기' 기술이라고도 번역합니다. 세일즈맨은 어떻게든 일단 문간에 발이라도 들여 놓는데 성공하면, 물건을 팔 가능성이 높아집니다. 현관문을 열게 만든뒤 대화를 시작하고, 거실에 들어가고 소파에 앉습니다. 그러기 위해 사용하는 것이 사은품, 샘플 같은 것들이지요. 심리학에서는 이런 기술이 효과를 보는 이유를 이렇게 설명합니다. 어떤 작은 요구에 동의한 사람은 그것에 '관여'가 되어서 미래의 요구에 더 잘 응하게 된다는 겁니다. 저자가 예시한대로, 뻔한 정답을 보내주면 추첨을 통해 경품을 주겠다는 광고들, 길거리에서 신제품이라며 한 잔 따라주는 음료들은 바로 이처럼 사람들을 그 제품과 '관여', '개입'시키기 위해 하는 마케팅 기법들입니다. 사람은 어떤 형태로든 그 제품과 '관여'되었다고 생각하게 되면 나중에 그 제품을 구매할 가능성이 꽤 높아집니다. 상반되는 기법으로 '도어 인 더 페이스 테크닉'(door-in-the face technique)도 있습니다. '면전에서 문닫기' 기법입니다. 처음에 매우 큰 요구를 한 뒤에 작은 요구를 하는 겁니다. 그러면 처음에는 문을 쾅하고 닫게 되지만, 그 뒤의 작은 요구에는 응할 가능성이 높아진다는 것이지요. 노사협상에서 노사는 첫 협상에 까다로운 요구를 들고 나오는 경우가 많습니다. 처음에는 서로 총파업과 직장폐쇄를 협박하지만, 결국 적정선에서 타협을 하지요. 양측 모두 이 기법을 쓴 셈입니다. 비싼 가격을 부른뒤에 깎아주면서 물건을 사게 만드는 노련한 상인도 마찬가지입니다. 심리학에서는 이 기술의 효과를 이렇게 설명합니다. 어떤 사람이 큰 요구를 했다가 작은 요구로 수위를 낮추면, 그는 '타협'을 할 줄 아는 사람으로 인식이 됩니다. 그러면 상대방은 이제 자신이 '양보'할 차례가 됐다는 압력을 받게 됩니다. 자연 뒤의 요구를 들어줄 가능성이 높아지지요. foot-in-the door technique과 door-in-the face technique. 다소 상반되는 기법과 해석이긴 하지만, 모두 사람의 심리를 일정부분 설명해주는 개념입니다. 우리 경제노트 가족들도 성과를 내기 위해서건, 아니면 '당하지' 않기 위해서건, 이런 심리학적인 개념들을 이해하는 것이 필요합니다. |
이글에서 나온 foot in the door 기술은 고객과 개발자 사이에서도 빈번히 발생되는 테크닉입니다.
또는 관리자가 초급 개발자에게 많은 일을 시키는 (노련한?) 방법이기도 합니다.
사용 방법은 위에 나온 방식과 같습니다.
기능의 핵심만을 간단하게 말함으로써 개발자로 하여금 쉽게 개발할 수 있을 거라는 생각을 품게 만드는 것입니다.
일단 개발자가 OK 하고 나면 개발자에게는 가시밭이 펼쳐질수도 있습니다.(정말 말처럼 쉽게 끝나는 경우도 있긴 합니다.)
막상 해당 기능을 추가하려고 하니까 점점 어려운 문제들이 나타나는 것입니다.
가벼운 기능 때문에 전체 구조를 바꿔야 하는 문제가 생길수도 있고 기존 기능에 배척되는 기능일 수도 있습니다.
하지만 개발자 입장에서는 일단 수락한 상황이기 때문에 늪에 발을 담근 것처럼 빠져나오기 어렵게 됩니다.
그나마 개발자가 수락한 것이라면 자기가 한 일에 대한 책임을 지는 것이지만 프로젝트 팀장이 foot in the door technique에 당했다면 문제는 심각해집니다.
빠듯한 일정내에서 열심히 작업하던 팀원들 입장에서는 정말 허무한 일입니다.
팀장이 일거리를 줄여주지는 못할망정 늘리기 까지 한다면 팀장이 없느니만 못한거 아니겠습니까?
그렇게 때문에 팀장은 이런 대화법에 같이 동조해서는 안됩니다.
물론 그렇다고 해서 무조건 BJR방식(배째라)을 사용하자는 것은 아닙니다.
일단 기능이 아무리 간단해 보여도 같이 동조하기 전에 기능 구현을 하기위해 필요한 것들이 무엇인지 생각해보면 됩니다.
특히 기술적으로 쉽다는 생각에 현재 구조와 맞는지 그리고 정말 필요한 기능인지에 대한 생각을 못할수도 있습니다.
기술적으로 아무리 쉬운 기능이라 할 지라도 현재 프로젝트에 어울리지 않는 기능이라면 기존 일정에 충실하는 것이 더 좋을 수도 있습니다.
또 하나 고객이 아주 어려운 기술을 덜컥 요구 한 후에 쉬운 기능이라도 대신 넣어 달라는 방식을 사용할 때가 있습니다.
이때도 개발자는 어려운 작업을 안해도 되겠구나 하는 안도의 마음에 덜컥 작업하려고 하면 안됩니다.
꼭 필요한 기능을 요구했다고 하더라도 기존 작업목록에 있는 중요 기능과 비교한 후 중요 순위대로 작업해야 합니다.
노련한 고객이라면 또는 관리자라면 분명 자신이 원하는 것을 이루기 위한 가장 좋은 방법으로 개발자와 대화를 할 것입니다.
그리고 노련한 프로젝트 리더라면 고객의 요구 사항을 객관적으로 판단함으로써 프로젝트가 산으로 가는 것을 사전에 막을수 있을 것입니다.
http://wpfkorea.egloos.com/737449

그럼.. 저희팀은 지리산 종주는 어렵겠고...
북한산이나 관악산은 가나요?^^