달력

072010  이전 다음

최초의 문제 제기는 다음과 같은 모양을 띤다. 한 문장이지만, 여러 가지 문제를 함께 의미하기도 하고, 대개는 문제의 수준에 관계없이 쭉 나열한다.

The only thing that does not fully convince me in your articles is usage of Guice. I’m currently unable to see clearly its advantages over plain factories, crafted by hand. Do you recommend using of Guice in every single case? I strongly suspect, there are cases, where hand-crafted factories make a better fit than Guice. Could you comment on that (possibly at your website)?

답을 내놓기 전에 문제를 분명하게 다시 정의하는 일은 널리 쓰이는 방법이다.

I think this is multi-part question:

  1. Should I be using dependency-injection?
  2. Should I be using manual dependency-injection or automatic dependency-injection framework?
  3. Which automatic dependency-injection framework should I use?

대화하는 상황이라면 순발력과 지속적인 훈련이 없이는 불가능한 일이다. 추상화 수준을 맞추는 일과 MECE에 입각하여 문제를 정제하는 연습의 생활화가 필요하다.

출처: When to use Dependency Injection
Posted by 영회
잘 적응되어 있을수록 적응력은 감소하는 경향이 있다. 61쪽
품질 팀이 있고, 가이드와 규정이 잘 갖춰진 곳을 보면 전형적인 업무는 매우 효율적으로 처리한다. 반면 새로운 요구나 환경 변화가 불어닥치면 잘 정비한 규정이 오히려 발목을 잡기도 한다. 환경 변화가 심해지는 추세에 따라서 애자일(Agile)이 부각하는 것과도 관계가 있다.

고객은 항상 자기 문제를 어떻게 푸는지 알고 있으며, 항상 해결법을 처음 5분 내에 말해준다. 116쪽
대단히 인상적인 문구라 책을 접어두었던 모양인데, 잘 기억이 안난다. 역시 메모는 바로 해야 한다. 돌연 프로젝트에서 RFP가 프로젝트 후반까지 매우 중요한 척도 역할을 하는 점이 떠오른다.

통상 무엇을 간과하는지 찾아보고 다시는 빠뜨리지 않도록 확실히 해주는 도구를 설계하라. 128쪽
공부법 설명할 때도 항상 '오답노트'가 등장했다. 고르게 신경쓰기 보다는 취약지구에 초점을 맞추는 것이 효과적이다. 위험요소에 초점을 맞춘 프로젝트 관리를 강조하는 UP(Unified Process)도 유사한 맥락이다.

뭔가를 잃는 최선의 방법은 그것을 지키려고 애쓰는 것이다. 201쪽
얼마전에야 그 의미를 알았고, 요즘에야 실천을 할 수 있다.

품질을 위한 마케팅(물량을 위해서가 아니라 품질을 위해서 마케팅하라.) 274~275쪽
1. 컨설턴트는 다음 두 상태 중 하나만 될 수 있다. 한가한 상태 아니면 바쁜 상태.
2. 고객을 얻는 최상의 방법은 고객을 갖고 있는 것이다.
3. 일주일에 적어도 하루는 노출에 시간을 할애하라.
4. 고객에게 당신이 중요한 것보다 당신에게 고객이 훨씬 중요하다.
5. 절대로 한 고객이 전체 사업의 1/4 이상을 차지하게 하지 말라.
6. 최상의 마케팅 도구는 만족한 고객이다.
7. 당신의 최고 아이디어를 거저 주어라.
8. 손수 넣은 계란 하나가 커다란 맛의 차이를 낳는다.
9. 최소한 자기 시간의 1/4은 아무것도 하지 말고 보내라.

주옥같은 지침이다. 나는 이 지침을 실천하기 위해서 주기적으로 스스로를 검증할 것이다.

최소 후회의 원칙: 어느 쪽으로 하든 후회하지 않게 가격을 책정하라. 289쪽
욕심 때문에 무리하게 협상을 하다가 스스로 자충수를 두는 경우는 종종 발생한다.

사람들은 절대 거짓말쟁이가 아니다. 적어도 자신의 눈에는 302쪽
그래서 사람을 신뢰해야 한다. 비난하거나 비판하지 말고... (하지만 너무 힘들어)

농장에서 얻은 교훈 316~317쪽
1. 절대 싸구려 씨를 사용하지 말라.
2. 준비된 토양이야말로 경작에 성공하는 비결이다.
3. 시기가 정말 중요하다.
4. 가장 단단하게 자리잡은 작물은 스스로 뿌리를 잘 내린 것이다.
5. 과하게 물을 주면 강해지는 것이 아니라 약해진다.
6. 최선을 다해도 일부는 죽을 것이다.

역시 자연과 함께 하면 주옥같은 교훈을 얻는다.

컨설팅의 비밀 - 10점
제럴드 M. 와인버그 지음, 홍성완 옮김/인사이트
Posted by 영회
리팩토링(Refactoring)과 프로세스 개선은 일반적으로 비교 대상은 아니다. 하지만, 목적의식에 있어 공유하는 부분이 있다. 추상화 수준을 높여서 보면 대상이 다를 뿐 '무언가 현재 상황을 개선하여 효과를 보려는' 의도는 동일하다. 거기에다가 개선 대상의 기능 자체를 바꾸지 않는다는 점에 있어서도 뜻을 같이 한다.

컨설턴트는 언제나 변화를 몰고 다닌다. 그리고, 대부분의 사람들은 변화를 싫어하거나 적어도 번거롭게 여긴다. 거기에는 컨설턴트 자신도 포함된다. 상식적으로 사고해보면 변화해야 할 이유나 당위성은 쉽게 찾을 수 있다. 하지만, 변화의 동력은 논리가 아니다. 변화의 주체가 되는 이들의 의지가 동력이다.

오늘 오전까지 고객들이 변화를 받아들일 수 있도록  세 차례의 회의를 소집했다. 이를 위해서 두 개 프로젝트에서 참고 자료를 얻었고, 고객이 갖고 있는 업무 규정과 업무를 개선할 수 있는 각종 도구(소프트웨어), 그리고 현실적인 제약(작업자와 일정)을 종합하여 대안을 제시했다.

흥미로운 사실은 컨설턴트로써 해야 하는 논리적인 작업은 준비 작업만으로도 충분하다는 점이다. 정작 고객을 대면했을 때는 그들이 변화를 수용할 수 있도록 시간을 주고 기다리는 것이 할 일의 전부였다.

지난 날 고객과 협상하는 자리에서 논리적으로 설득하려들었던 것은 바람직한 태도가 아니었던 것 같다. 방법론/프로세스 전문가의 가치에서도 언급한 바 있지만, 컨설턴트에게 논리적인 사고보다 더 중요한 것은 상황에 맞춰 적절하게 일이 흘러가도록 조치할 수 있는 능력이다.

Posted by 영회
컨설팅의 비밀 1장에 다음과 같은 표현이 나온다.

첫 문제를 해결하고 나면 둘째 문제였던 것이 첫 번째가 된다.

문제를 발견하고 해결하고 나서 성취감을 느끼려는 찰나가 되면 여지 없이 뒤에 기다리던 문제가 부상한다. 최근에 내가 처한 상황을 절묘하게 설명하는 표현이기도 하다. 인지하지 못했을 뿐, 늘 그래왔던 것이다.

혼란스런 프로젝트 초기에서 컨설턴트의 임무를 정리할 즈음 미션으로 삼았던 일이 대략 마감할 즈음 그보다 더 큰 파도가 밀려왔다. 삽시간에 아수라장이 되었지만, 곧 정리가 되었다. 아수라장이 된 건 결국 스스로의 마음상태뿐이었는지도 모르겠다.

컨설팅의 비밀
제럴드 M. 와인버그 지음, 홍성완 옮김/인사이트

1장 마무리의 다음 표현을 본 뒤에 머릿말만 읽고 정리한 컨설팅의 비밀은 오판이었음을 깨달았다.

나 자신을 돕는 것은 남을 돕는 것보다 훨씬 어렵다.

늘 그렇듯 어느 정도 경지에 오르면... 수신(修身) 혹은 도를 이야기 한다. ㅡㅡ;
Posted by 영회
2년쯤 전에 컨설팅이란 무엇인가?라는 글을 썼을 때가 명함에 박힌 '컨설턴트'라는 직함에 회의적일 때였다. 진로 변경에 대한 고민을 할 정도의 상황이었으니까.

여차저차 흘러왔고 지금은 어느새 내가 서 있는 자리가 오래 입어온 옷처럼 편안해졌다. 프로젝트 현장에 가면 문제점이 선명하게 보인다. 컨설팅의 비밀에서 말하는 것처럼 '문제는 항상 있기' 때문에 과거의 경험에 비춰보면 그대로 드러난다.

다소 거만한 것인지 몰라도 이제야 컨설턴트라고 불리우는데 부끄러움이 없는 상태에 들어선 것 같다. 문제를 인지하면 빠르게 해결안 후보를 추려내고 이를 위한 기술(기법) 관점에서 분석을 하고, 다시 한번 조직(정치)관점에서 분석하게 된다.

컨설팅의 비밀
제럴드 M. 와인버그 지음, 홍성완 옮김/인사이트

만일 프로젝트의 관리자가 특정 시점에 어떤 일이 진행되어야 하는지 모른다면 프로젝트는 어떻게 될까? 대개 절차에 의해서 계획을 수립하는 과정에서 관리자는 상황에 대한 장악력을 갖게 된다.

수개월동안 수행하는 프로젝트의 경우 해야 하는 일과 작업자가 워낙 많다 보니 복잡한 세부 일정이 만들어지기 마련이다. 현명한 관리자라면 복잡한 일정을 자신이 인지하고 진행내역을 장악할 수 있는 방안을 만들어야 한다. 주간 단위로 주요한 포인트는 메모를 별도로 한다던가 일정 자체를 다단계로 만들어 놓는다던가 방법은 많지만, 자신에게 맞는 것을 고안해야 한다.

관리자가 프로젝트에 대한 장악력이 없을 때 어떤 일이 발생할까? 다행히(?)도 나는 실전에서 많은 관리자를 만날 수 있어서 상상으로 답을 낼 필요는 없었다.

  • 새로운 물품이나 정보를 획득했을 때, 팀원의 역할(R&R)을 잘 모르는 관리자는 즉흥적으로 주변의 키맨에게 사실을 알린다. 이렇게 되면 실제 그 사실을 알아야 할 사람에게 전달이 될런지는 미지수다. 그것은 키맨의 의지, 양심 혹은 기억력에 달려 있다.
  • 산출물을 제출할 시점이 되었거나 어느날 고객이 뭔가 요구해오면 관리자는 누군가 주변의 키맨을 찾는다. 갑자기 주어진 일에 대해서는 대부분 자신에게 일이 떨어질까 염려하게 된다. 결국 팀원이 소극적이 되고, 핑퐁 현상에 따른 갈등/다툼이 벌어진다.
암튼... 컨설턴트(이름이야 뭐든 실제로 하는 일이 컨설턴트라면)는 대개 키맨으로 분류된다. 별의별 질문과 요청을 다 받게 되고, 해결책을 내놓을 수 있는 경우가 많다. 하지만, 현실적으로 실천 가능한 일인지 판단해봐야 하고, 가능하다면 누가 할 것인지 아이디어가 있어야 한다. 그렇지 않고 내놓은 방안은 무책임한 발언이 될 뿐이다.

완벽한 컨설팅에 명기된 바대로 컨설턴트는 스태프로 일해서는 안된다. 일시적으로 관리자 대행이 된 상황이라면 관리자가 빨리 본연의 일을 할 수 있게 상황을 개선시켜야 한다.

완벽한 컨설팅
피터 블록 지음, LGCNS 엔트루 컨설팅 외 옮김/인사이트

Posted by 영회
최근 들어 대립하지 않으려는 의지는 균형감을 자꾸 생각하게 한다.
합리적인 판단과 조화로운 결정 사이에는 많이 차이기 있지만
여기서 그것에 대해 긴 이야기를 늘어놓고 싶지는 않다.

최근 몇 차례 한 가지 기술적 이슈에 대해 자문 요청을 받았다.
자문을 할 수록 내가 정말 하고 싶은 말은
'나는 A라는 툴을 싫어한다.'에 가깝다는 것을 알았다.
(물론, 최대한 완곡하게 이야기 하면서, 내면에서는 그렇게 말하려는 욕구를 달래고 있다.)

기술과 툴 자체에 대해 공부하는 위치에 서면
스스로 세운 어떤 기준에 부합하지 못하는 기술/툴에 대해서는 비판적이 될 수 밖에 없다.
그것이 나를 위한 항변이지만...
반대 편으로 돌아서보자.
A가 아니라면 대체할 수 있는 뭔가가 있어야 한다.
사실 A에 완전한 비교 우위를 점하는 어떤 툴을 써보지 않은 이상
다른 어떤 툴도 지지하기는 힘들다.

또한, A라는 툴을 공급하는 업체와 그 직원들까지 생각하면 더 신중하게 발언해야 하기에
섣불리 A가 나쁘다라고 말할 수도 없다.

이런 류의 자문은 대개 급작스러운 순간에 구두로 물어오는 경우가 많아
말을 하면서 판단도 해야 한다.

여기서 최선 안은 무엇일까?

몇 차례 이런 경우를 겪으면서 내가 도출한 몇 가지는 아래와 같다.

1. 직접 해보지 않은 단순한 느낌이나 어디선가 들은 얘기는 언급하지 않는다.
모호한 지식을 풀어놓다 보면 스스로의 선호가 개입되기 쉽고
자칫 별 근거도 없는 주관적인 의견을 내놓을 수 있다.

2. 가능한 구체적으로 언급한다.
자문을 받는 의뢰인은 몰라서 묻는 것이다. 따라서, 오해의 소지가 존재한다.
구체적일수록 오해의 폭은 작고
추상적일수록 오해의 폭은 크다.

3. 차분하게 발언의 폭을 조절하여 리듬을 유지하라.
혹시 상대가 조급하여 질문 공세를 하게 되면
호흡 조절없이 정신없이 답변할 수 있다.
이렇게 되면 여유를 잃어 충분히 생각하면서 발언할 기회를 놓친다.
답변 와중에 한번 쯤 웃을 수 있는 여유를 갖을 수 있다면
분명 더 진솔한 답을 낼 수 있다.
Posted by 영회