Younghoe.Info v3

'컨설팅에 유감 많습니다'라는 글에서 인상적인 내용만 발췌해봅니다.




IT에서도 비슷하게 적용할 수 있는 듯...

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


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


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

출처: When to use Dependency Injection

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

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

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

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

품질을 위한 마케팅(물량을 위해서가 아니라 품질을 위해서 마케팅하라.) 274~275쪽

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

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

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

농장에서 얻은 교훈 316~317쪽

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

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

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

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

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

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

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

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

늘 그렇듯 어느 정도 경지에 오르면... 수신(修身) 혹은 도를 이야기 한다. ㅡㅡ;

2년쯤 전에 컨설팅이란 무엇인가?라는 글을 썼을 때가 명함에 박힌 '컨설턴트'라는 직함에 회의적일 때였다. 진로 변경에 대한 고민을 할 정도의 상황이었으니까.

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

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

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

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

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

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

• 새로운 물품이나 정보를 획득했을 때, 팀원의 역할(R&R)을 잘 모르는 관리자는 즉흥적으로 주변의 키맨에게 사실을 알린다. 이렇게 되면 실제 그 사실을 알아야 할 사람에게 전달이 될런지는 미지수다. 그것은 키맨의 의지, 양심 혹은 기억력에 달려 있다.
• 산출물을 제출할 시점이 되었거나 어느날 고객이 뭔가 요구해오면 관리자는 누군가 주변의 키맨을 찾는다. 갑자기 주어진 일에 대해서는 대부분 자신에게 일이 떨어질까 염려하게 된다. 결국 팀원이 소극적이 되고, 핑퐁 현상에 따른 갈등/다툼이 벌어진다.

암튼... 컨설턴트(이름이야 뭐든 실제로 하는 일이 컨설턴트라면)는 대개 키맨으로 분류된다. 별의별 질문과 요청을 다 받게 되고, 해결책을 내놓을 수 있는 경우가 많다. 하지만, 현실적으로 실천 가능한 일인지 판단해봐야 하고, 가능하다면 누가 할 것인지 아이디어가 있어야 한다. 그렇지 않고 내놓은 방안은 무책임한 발언이 될 뿐이다.

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

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