2015.10.14

블로그 | 아이디어 평가에 '정석'을 경계하라

Paul Glen | Computerworld
IT 매니저들은 하루의 상당 부분을 아이디어를 상대하며 보낸다. 초기 아이디어를 가다듬고, 평가한다. 다른 사람의 아이디어에 퇴짜를 놓거나 수락하기도 한다. 사실 매일 각종 아이디어에 치여 산다고 할 정도다. 자신의 아이디어일 수도, 부하 직원이나 상사, 심지어 미디어에서 본 아이디어일 수도 있다.



- “SQL의 그 섹션을 다시 써서 커서 사용을 피할 수 있다면 퍼포먼스가 훨씬 더 좋아질 것이다.”

- “모바일 리포팅 앱을 디플로이 할 경우 세일즈 파트에서도 클라이언트들이 이미 주문한 것들을 확인할 수 있을 것이다.”

- “헬프 데스크를 우회하려는 유저들을 돕지 않으면 결국 우리가 의도한 지원 프로세스를 따르게 될 것이다.”

IT 관련 아이디어를 누가 제기했든, 결국 그 과정과 결과를 감당할 인물은 IT 매니저다. 아이디어를 얼마나 잘 내놓고, 선택하고, 수집하고, 평가하고, 수정하고, 우선순위를 정하고, 테스트하고, 도입하고, 의논하는지에 사실상 매니저로서의 성공이 달려 있다 해도 과언이 아니다.

좋은 아이디어를 선택하면(다시 말해 옳은 의사결정을 내리면) 영웅이 되는 반면, 잘못된 선택을 할 경우 골치 아픈 일도 발생한다.

물론 가만히 앉아 컴퓨터를 두들기며 ‘옳은 선택을 해라’라고 말하는 건 쉽다. 하지만 복잡하고 정신 없는 일터에서 좋은 아이디어를 추려내려면 어떻게 해야 할까?

내 경험상 매니저들은 의사결정을 할 때 3옵션 중 하나를 선택한다(혹은 이들 중에 적합한 것들을 조합하기도 한다). 3 옵션 모두 각각의 장점이 있음은 물론이다.

방법 1: 아이디어의 철저한 분석. 각 아이디어를 실현 비용, 장점, 성공 확률, 문화적 적합성 등 다양한 각도에서 분석하는 방식이다. 아이디어의 기저에 깔려 있는 각종 가정들을 검토하고 기존의 팩트나 과거 경험들과 얼마나 잘 맞아 떨어지는지를 살펴본다. 그 후에야 비로소 그 아이디어가 쫓을 만 한 가치가 있는 것인지 결정한다.

제대로 하려면 꽤나 시간이 걸리는 방식이다. 정확한 의사 결정을 내릴 수 있다는 장점이 있으나 의사결정의 적기를 놓쳐 때늦은 결정이 될 수도 있다.

방법 2: 직관적 생각 따르기. 아이디어를 처음 들었을 때 드는 생각이나 느낌을 의사결정의 가이드로 사용하는 방식이다. 주관적 느낌이라고 해도 객관적 분석이나 증거를 완전히 결여하고 있는 것은 아니다. 사람의 감정이나 느낌은 그 사람의 경험, 선입견, 선호도, 지식, 그리고 그 동안 쌓아온 평가에 기반해 일어난다.

좋은 느낌이 든다면 그 아이디어를 채택해도 괜찮다. 정말 확신이 들 정도의 아이디어라면 말 할 것도 없고 말이다. 이 방식은 철저한 분석을 거쳐 결정을 내리는 방식보다 훨씬 빠르며, 또 대부분의 의사 결정이 어쨌거나 불완전한 정보를 기반으로 내려진다는 사실에 더 부합하는 방식이기도 하다. 그렇지만 한편으로는 편견과 아집으로 인해 잘못된 결정을 내리게 될 가능성도 있다.

방법3: 아이디어의 ‘정석’을 따르는 것. 각 아이디어를 검토함에 있어 일반적으로 널리 받아들여진 ‘정석’적인 통념들에 부합하는지를 살펴보는 방식이다. 맞는다 싶으면 하면 된다. 아니면, 폐기한다.

여기서 말하는 정석이란 일을 처리하는 데 있어 단 하나의 정해진 답을 말한다. CMMI나 PMBoK, ITIL, Scrum같은 프레임워크나 방법론에 기반하고 있다. 일부 매니저들은 과거 성공했던 경험을 바탕으로 그 때와 똑같이 행동하여 똑같은 성공을 이끌어내려 하기도 한다.

대부분 사람들이 2번의 방법을 게으른 방법, 일을 쉽게 처리하려는 태도로 생각하곤 한다. 그러나 사실은 다르다. 3번처럼 ‘정답’에 의지하는 것이야말로 고민 없이 쉽게 일하려는 태도다. 어느 아이디어를 평가하는 기준이 현재의 구체적인 상황이 아니라, 정해진 단순한 룰과 원칙이 되기 때문이다.

이상화 된 방법론에 아이디어를 비교, 평가하는 것이야 말로 가장 쉬운 변칙이다. 위의 3가지 방법 중 이 방법은 유일하게 의사 결정자에게 부담을 지우지 않는 방법이기도 하다.

게다가 극단적인 경우(극단적인 경우는 생각보다 자주 발생한다), 정답에 의존해 개인적 판단을 완전히 유보해 버림으로써 잠재적으로 좋은 아이디어가 될 수 있는 것들도 놓치고 마는 경우가 발생한다.

문제는 바로 이럴 때 발생한다. 매니저들이 의사결정의 부담을 피하기 위하여 잘 짜여진 각본에 맞춰 행동할 때, 살아 숨쉬어야 할 아이디어는 추상적인 사고의 대상이 되고 만다.

최선의 의사 결정은 매니저가 자신의 결정에 책임을 지고, 자신의 판단에 기반하여 결정을 내리며, 자신에게 주어진 모든 툴(분석, 주관적 느낌, 정석적 방식들에 들어 있는 지혜들)을 활용할 때 가능한 것이지, 남들이 정답이라고 써 붙여 준 방식을 생각 없이 따른다고 주어지는 것이 아니다.

* Paul Glen은 리딩 긱스(Leading Geeks)의 CEO이자 20년 이상의 경력을 보유한 IT 전문 칼럼니스트, 컨설턴트다. ciokr@idg.co.kr
 

2015.10.14

블로그 | 아이디어 평가에 '정석'을 경계하라

Paul Glen | Computerworld
IT 매니저들은 하루의 상당 부분을 아이디어를 상대하며 보낸다. 초기 아이디어를 가다듬고, 평가한다. 다른 사람의 아이디어에 퇴짜를 놓거나 수락하기도 한다. 사실 매일 각종 아이디어에 치여 산다고 할 정도다. 자신의 아이디어일 수도, 부하 직원이나 상사, 심지어 미디어에서 본 아이디어일 수도 있다.



- “SQL의 그 섹션을 다시 써서 커서 사용을 피할 수 있다면 퍼포먼스가 훨씬 더 좋아질 것이다.”

- “모바일 리포팅 앱을 디플로이 할 경우 세일즈 파트에서도 클라이언트들이 이미 주문한 것들을 확인할 수 있을 것이다.”

- “헬프 데스크를 우회하려는 유저들을 돕지 않으면 결국 우리가 의도한 지원 프로세스를 따르게 될 것이다.”

IT 관련 아이디어를 누가 제기했든, 결국 그 과정과 결과를 감당할 인물은 IT 매니저다. 아이디어를 얼마나 잘 내놓고, 선택하고, 수집하고, 평가하고, 수정하고, 우선순위를 정하고, 테스트하고, 도입하고, 의논하는지에 사실상 매니저로서의 성공이 달려 있다 해도 과언이 아니다.

좋은 아이디어를 선택하면(다시 말해 옳은 의사결정을 내리면) 영웅이 되는 반면, 잘못된 선택을 할 경우 골치 아픈 일도 발생한다.

물론 가만히 앉아 컴퓨터를 두들기며 ‘옳은 선택을 해라’라고 말하는 건 쉽다. 하지만 복잡하고 정신 없는 일터에서 좋은 아이디어를 추려내려면 어떻게 해야 할까?

내 경험상 매니저들은 의사결정을 할 때 3옵션 중 하나를 선택한다(혹은 이들 중에 적합한 것들을 조합하기도 한다). 3 옵션 모두 각각의 장점이 있음은 물론이다.

방법 1: 아이디어의 철저한 분석. 각 아이디어를 실현 비용, 장점, 성공 확률, 문화적 적합성 등 다양한 각도에서 분석하는 방식이다. 아이디어의 기저에 깔려 있는 각종 가정들을 검토하고 기존의 팩트나 과거 경험들과 얼마나 잘 맞아 떨어지는지를 살펴본다. 그 후에야 비로소 그 아이디어가 쫓을 만 한 가치가 있는 것인지 결정한다.

제대로 하려면 꽤나 시간이 걸리는 방식이다. 정확한 의사 결정을 내릴 수 있다는 장점이 있으나 의사결정의 적기를 놓쳐 때늦은 결정이 될 수도 있다.

방법 2: 직관적 생각 따르기. 아이디어를 처음 들었을 때 드는 생각이나 느낌을 의사결정의 가이드로 사용하는 방식이다. 주관적 느낌이라고 해도 객관적 분석이나 증거를 완전히 결여하고 있는 것은 아니다. 사람의 감정이나 느낌은 그 사람의 경험, 선입견, 선호도, 지식, 그리고 그 동안 쌓아온 평가에 기반해 일어난다.

좋은 느낌이 든다면 그 아이디어를 채택해도 괜찮다. 정말 확신이 들 정도의 아이디어라면 말 할 것도 없고 말이다. 이 방식은 철저한 분석을 거쳐 결정을 내리는 방식보다 훨씬 빠르며, 또 대부분의 의사 결정이 어쨌거나 불완전한 정보를 기반으로 내려진다는 사실에 더 부합하는 방식이기도 하다. 그렇지만 한편으로는 편견과 아집으로 인해 잘못된 결정을 내리게 될 가능성도 있다.

방법3: 아이디어의 ‘정석’을 따르는 것. 각 아이디어를 검토함에 있어 일반적으로 널리 받아들여진 ‘정석’적인 통념들에 부합하는지를 살펴보는 방식이다. 맞는다 싶으면 하면 된다. 아니면, 폐기한다.

여기서 말하는 정석이란 일을 처리하는 데 있어 단 하나의 정해진 답을 말한다. CMMI나 PMBoK, ITIL, Scrum같은 프레임워크나 방법론에 기반하고 있다. 일부 매니저들은 과거 성공했던 경험을 바탕으로 그 때와 똑같이 행동하여 똑같은 성공을 이끌어내려 하기도 한다.

대부분 사람들이 2번의 방법을 게으른 방법, 일을 쉽게 처리하려는 태도로 생각하곤 한다. 그러나 사실은 다르다. 3번처럼 ‘정답’에 의지하는 것이야말로 고민 없이 쉽게 일하려는 태도다. 어느 아이디어를 평가하는 기준이 현재의 구체적인 상황이 아니라, 정해진 단순한 룰과 원칙이 되기 때문이다.

이상화 된 방법론에 아이디어를 비교, 평가하는 것이야 말로 가장 쉬운 변칙이다. 위의 3가지 방법 중 이 방법은 유일하게 의사 결정자에게 부담을 지우지 않는 방법이기도 하다.

게다가 극단적인 경우(극단적인 경우는 생각보다 자주 발생한다), 정답에 의존해 개인적 판단을 완전히 유보해 버림으로써 잠재적으로 좋은 아이디어가 될 수 있는 것들도 놓치고 마는 경우가 발생한다.

문제는 바로 이럴 때 발생한다. 매니저들이 의사결정의 부담을 피하기 위하여 잘 짜여진 각본에 맞춰 행동할 때, 살아 숨쉬어야 할 아이디어는 추상적인 사고의 대상이 되고 만다.

최선의 의사 결정은 매니저가 자신의 결정에 책임을 지고, 자신의 판단에 기반하여 결정을 내리며, 자신에게 주어진 모든 툴(분석, 주관적 느낌, 정석적 방식들에 들어 있는 지혜들)을 활용할 때 가능한 것이지, 남들이 정답이라고 써 붙여 준 방식을 생각 없이 따른다고 주어지는 것이 아니다.

* Paul Glen은 리딩 긱스(Leading Geeks)의 CEO이자 20년 이상의 경력을 보유한 IT 전문 칼럼니스트, 컨설턴트다. ciokr@idg.co.kr
 

X