Ting 이네 Software 이야기

최근 나는, KLDP에서 data structure와 algorithm(이후 D/A)에 큰 관심이 없는 SW Engineer(이후 SWE)가 구글 코리아에 지원했다가 떨어진 내용에 대한 글 + 거기에 대한 글타래를 읽었다. (http://kldp.org/node/78668)
글타래를 보다보면, D/A에 익숙치 않은 SWE의 가치를 비하한다고 생각되어지는 몇몇 글이 눈에 띄인다. 난 이 post를 통해서 거기에 대한 반론을 전개하고자 한다.

모든 직종이 마찬가지겠지만, SW역시 다양한 분야가 존재한다. 그리고 Engineering skill의 가치는 "현재 종사하고 있는 분야에 얼마나 적합한가?"에 따라 측정되게 마련이다. 예를 들면, SW Integration Engineer의 경우, 각종 System 및 개발 환경, script와 tool의 사용 등에는 굉장히 뛰어난 skill을 보유하고 있을지 모르나, D/A에 대한 지식은 상당히 부족할 가능성이 높다. 그러나 그렇다고 해서, 뛰어난 SW Integration Engineer의 가치가 약해지거나 하는 것은 아니다. 그 사람은 본인의 직무에 적합한 skill을 가지고 있으므로, 우리는 그 사람을 충분히 '뛰어나다'고 이야기 할 수 있다. 나는 D/A가 중요하지 않다는 이야기를 하는 것이 아니다. 다만, 모든 SW분아가 D/A에 대한 skill을 요구하지는 않는다고 말하고 싶다.

SWE의 가치를 이야기할 때도 반드시 이러한 요소가 반영되어야 한다. 관련 글타래 중, "Google에서 정한 SWE의 가치(급여)가 현재의 급여보다 작다면, 현재 자신의 가치 이상의 급여를 받고 있을지도 모른다"는 의미의 글이 보인다 - 물론 내가 잘못 이해했을수도 있겠으나, 최소한 나에게는 이런 의미로 다가왔다. 그러나, 이는 분명히 잘못된 논리이다. 물론 현재 그 사람이 과한 급여를 받고 있을지도 모른다. 그렇지만, 최소한 그 기준이 Google의 급여가 되어서는 안되는 것이다. 왜냐하면, 현재 그 사람이 종사하는 분야가 요구하는 skill과 Google이 요구하는 skill이 엄연히 다르고, 각 회사는 자신들의 분야에 초점을 맞추어 SWE의 가치를 측정하기 때문이다. 다시 말하면, 그 사람이 현재 받는 급여는 현재 회사가 요구하는 skill을 기준으로 했을 때의 가치이고, Google이 제시한 급여는 Google이 필요로하는 skill을 기준으로 했을때의 가치가 되는 것이다.

"어떤 사람이 모든 측면에서 더 낫다."란  있을 수 없다. 이는 Engineering의 세계에서도 마찬가지라고 생각한다. 어느 한 분야에 국한했을때, "A가 B보다 낫다."라고 이랴기 할 수 있는 것이지, "A의 SW Engineering skill이 B의 것보다 낫다."라고 이야기 하기는 대단히 어렵다. 따라서, SWE의 일반적인 가치에 대한 측정은 대단히 신중해야 한다.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

+++ 내가 Lead했던 첫번째 SW Project가 끝났다... 이 경험을 보존하기 위해 Review를 적어본다. +++

Project인원 : 나를 포함해서 3명
프로젝트 기간 : 약 4개월..
규모 : 한 10,000 라인 정도 되나??

내 관점에서 보기에, 다른 두명의 Programming능력 수준은 기대 이하였다.(아니면, 나 자신이 그들의 능력을 보지 못할 정도로 미숙했을 수도...)
Programming 경험이 많지 않은 사람과 같이 일하면서 크게 문제가 되었던 점들은 아래와 같았다.

+ 기본적으로... Code의 Stability가 떨어진다. (많은 Bug를 내포하고 있다. 일정이 짧아서 그럴수도 있지만, 일단 돌아가는 코드만 만들고 Program의 구조는 신경쓰지 않는다.)

+ SW design의 중요성을 전혀 인식하지 못한다. (이게 가장 큰 문제다!!!) SW design의 중요성을 모르고, 상호간 Interface간 정의의 중요성을 모르기 때문에, 여기에 큰 관심을 기울이지 않는다. 아무리 이게 중요하다고 이야기해도 전혀 반응하지 않는다.(소 귀에 경읽기??) 이번 프로젝트의 경우, Interface에 대한 communication을 초반에 상당히 강조했음에도, 결국 Integration단계에서, 그들이 전혀 Interface의 중요성을 인지하지 못했고 또, 관심조차 기울이지 않았음을 알게 되었다. 그들은 자신의 module과 연결될 다른 모듈의 동작 방식으로, 모듈 작성자와 communication하지 않고, 자기 나름대로 상상해서 API를 정했다. 결국 Integration단계에서, 문제가 발생했다..

+ Code re-factoring을 하지 않는다.... 내 개인적인 생각으로는, 그들은 자신이 짠 코드를 버릴 줄 모른다. 첫번째 짠 코드보다는 두번째 짠 코드의 질이 좋을 수 밖에 없다. 그리고 필요한 경우, 첫번째 짠 코드의 전체를 버릴 수도 있어야 한다. 그런데, 어설픈 구조로 짠 코드를 벗어나지 못해, bug를 양산할 가능성이 있는 불안한 코드에 땜질하는 형태로 project를 진행시키고 있고, 그게 Project를 빨리 그리고, 완성도 높게 끝낼수 있는 길이라고 생각한다. 이는 결국, SW design을 모르는 것과 어찌보면 그 맥을 가치하는데 - 보통 re-factoring은 design이 좋지 않은 경우 수행되어 진다. - 자신의 코드의 design이 좋지 않다는 사실을 인지하지 못하므로, re-factoring을 해야한다는 사실 자체를 모른다.

그럼 이런 경우 어떻게 이를 극복해야 하는가?
궁극적으로는 같이 일하는 사람의 능력을 향상시키는 것이 가장 중요하겠지만, 당장 일을하기 위해서는 결국 SW design과 Interface, API등을 모두 정의한 상태에서 상당한 수준까지 design을 구체화 한다음, 나머지 부분을 채워 넣으라는 방식으로 일을 할당했다.
(결국 이렇게라도 일을 시켜야, 생산성을 이끌어 낼 수 있었다.)

반성
+ 사람마다 능력과 경험이 다르고 일하는 방식이 다르다. "내가 아는 것은 다른 사람도 알 것이다."라는 전제 자체가 잘못 되었으므로, co-work에 어려움이 있었다. 사람들간의 차이를 알고, 상황에 맞게 생산성을 이끌어낼 수 있는 방법을 찾는 노력을 기울이지 않았다.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
======= 같은 실무자로서 일을 맡기기 (ex Lead Programmer) ========
일을 맡기기전에, "What"을 원하는지, 아니면, "What + How"를 원하는지 먼저 물어보고, 일을 시킬 필요가 있는 것 같다. 사람에 따라, "What"을 주고 일을 시킬 경우, 너무 막막해 하는 사람이 있고, "What + How"를 주고 일을 시킬 경우, 단순 노동을 시킨다고 짜증내는 사람이 있다.

따라서 일을 시키기 전에 미리, 이를 물어보고 선택의 여지를 주는 것이 좋아 보인다. 일에 자신이 있고, 자기 나름대로 무언가를 해 보고 싶은 사람 (사실 이런 사람을 원한다.) 에게는 "What"을 주고, 그렇지 않고, 아직까지는 일에 자신이 없고, 구체적인 일의 모습을 원하는 사람에게는 "What + How"를 주는 것이 좋다. 그러나 만약, 계속해서 "What + How"를 아주 상세한 level까지 줘야 하는 사람이라면, 같이 일하지 않는 편이 더 나아 보인다. 이런 사람은 관리하는데, 더 많은 시간이 소모되고, 또 더 많은 스트레스를 받게 된다.

또 한 가지 중요한 점은, 'What'을 주고 일을 시킨다고 할 지라도, 그 'What'의 내용이 너무 포괄적이거나, 추상적이여서는 안된다. 예를 들면, "좋은 코드를 만들어라". 같은건 말이 안된다. "Performance에 초점을 맞추어서 개발해라" 라는 식의 구체적인 모습을 주어야 한다. 이것이 중요한 이유는 일을 진행하는 중에, 서로 다른 가치가 충돌할 때, 어디에 더 비중을 두어야 할 지를 결정하는 기준이 바로, 일의 목적인 'What'의 내용이 되기 때문이다.

더불어 일의 진행상황이나 결과물을 reporting받아야하는데, 이때, deadline과는 조금 여유를 두고 받는 편이 좋다. 왜냐하면, reporting된 결과물이 원하는 형태가 아닐 확률이 높기 때문이다. 따라서, 2~3번 정도의 수정/검토를 염두해 두고 reporting 일정을 계획하는것이 좋다.

========= 실무를 모르는 관리자의 입장에서 일을 맡기기 ==========
실무에서 막 관리자로 역할이 바뀐 사람을 제외하고, 대부분의 경우, 관리자는 실무자에 비해 실무의 내용을 모른다. 또 몰라야 한다. (관리자가 이를 알려고 시간을 낭비하게 되면, 그 만큼 관리자가 해야할 일을 못하게 되기 때문이다.)

그럼, 실무를 모르는 관리자가 실무를 자신보다 더 잘 아는 실무자에게 어떤 식으로 일을 시켜야 하는가?

먼저 관리자는 자신이 실무자에 비해, 실무에 대한 구체적인 지식이 부족함을 인정해야 한다. (종종, 좋지 않은 관리자는, 자신이 실무자보다 실무경험이 더 많다는 점을 내세워 실무에 대한 구체적인 지식이 모자람에도 불구하고 이를 인정하지 않고 잘못된 방법론을 강요하는 경우가 많다.) 이를 전제로 관리자는 실무자에게, 구체적인 실무의 "How"에 대한 부분은 전적으로 맡기는 것이 좋다. 그럼 관리자가 할 일은? 관리자는 실무자에게 일의 방향성과, 요구되는 schedule등을 지시해야 한다. 즉 관리자는 "어떤 일을 언제까지 끝내야 한다."를 지시하는 것이지 "어떻게"를 지시하지는 못한다.(해서는 안된다.)

이때, 많은 경우 "언제까지"를 충족시키기 힘든데, 관리자는 이를 위해 실무자와 논의해서 최상의 결과를 얻을 수 있는 절충안을 찾아야 한다. 필요한 resource, requirement의 수정 등등.

다시 한 번 생각해 보면, 위의 과정은 관리자가 실무자를 신뢰함을 전제로 하고 있음을 알 수 있다. 즉 관리자는 실무자가 자신의 편의를 위해서 관리자를 속이지 않음을 전제한다는 말이다. 그런데 이는 너무 이상적인 가정이다. 많은 실무자가 자신의 편의를 위해, 일의 양을 부풀리거나 더 많은 resource를 요구할 것이다. 그렇다면 관리자는 어떻게 이를 방지할 것인가?

가장 좋은 방법은, 속이지 않는 실무자를 고용하는 것이다. ("인사는 만사") 자신에게 모든 인사권이 있다면 이런 사람을 뽑는데, 대부분의 시간을 할애해야 한다. 그렇게만 된다면, 이 문제는 더 이상 고민할 필요가 없다.

차선은, 실무자의 '도덕적 헤이'를 막기 위해, 해당 실무를 잘 아는 여러명의 실무자에게 같은 질문을 함으로서, 특정 실무자의 진심을 파악하도록 노력하고 이에 맞는 조치를 취해야 한다..

각설하고, 중요한 것은, 관리자가 실무자에게 "How"를 지시해서는 안된다는 뜻이다.!!!
손자병법에서도 전쟁에서 패하는 요인중에 하나를 "군주가 진격하지 말아야 할 때 진격을 명하거나, 후퇴하지 말아야 할 때 후퇴를 명하는 것"으로 뽑았다. 비단 전쟁 뿐이겠는가???

'물을 거울로 삼는 자는 자기 얼굴을 볼 수 있고, 사람을 거울로 삼는 자는 자기의 길흉을 알 수 있다.'고 합니다. 또 옛글에는 '성공했으면 그 자리에 오래 있지 말라'고 했습니다.
- '사기'(사마천)의 '채택열전' 중에서

내가 현재 처한 상황을 어떻게 알 수 있는가? 내가 앞으로 어떤식으로 처신해야 하는지 어떻게 알 수 있을까? '사기'의 '채택열전'에서 채택의 변론은 여기에 대한 답을 제시해 주고 있는 듯 하다. 채택이 응후에게 변론한 말 중 일부를 다시 한번 적어 본다.

"지금 당신의 군주가 충신을 가까이하고 옛 친구를 잊지 않는 점에서는 효공, 도왕, 구천만 못하고, 당신의 공적과 군주의 총애나 신임을 받는 정도 또한 상군, 오기, 대부 종만 못합니다. 그런데 당신의 봉록은 많고 지위는 높으며 가진 재산은 위의 세사람보다 많습니다. 만일 당신이 물러나지 않고 그대로 그 자리를 지키고 있으면, 당신에게 닥칠 근심은 세 사람보다 클 것입니다."

상군, 오기, 대부 종은 모두 큰 공을 세운 이후 군주로 부터 신임을 잃고 크게 해를 당한다. 채택의 변론은 이들을 거울로 당시 진나라의 재상이였던 응후가 취해야할 처세의 방향을 제시하고 있다.

나라고 다르겠는가? 나도 나와 비슷한 위치에 있는 다른 사람들을 거울로 보면, 내가 현재 처한 상황을 알수 있지 않을까? 그러면 자연스럽게 내가 취해야할 길도 알 수 있지 않을까? 그게 가능하기 위해서는 일단 여러가지 사례에 대해서 많이 알고 있어야 할텐데... 그래서 과거의 역사가 중요한가 보다. "과거를 통해서 현재를 안다."는 비단 국가의 존망, 역사, 성패 같은 거대한 흐름 뿐만 아니라, 작게는 내 자신이 성패, 상황, 처세를 읽는데도 중요하다는 것을 새삼 실감하게 된다..

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

어떤 사람을 회사에서 내 보내고자 할때, 어떻게 하는가? 그 중 하나가, "성취 불가능한 project에 자주 투입시키는 것"이라고 한다. ("회사가 당신에게 알려 주지 않는 50가지 비밀" - 산시아 샤피로). 뭐.. .실제로도 그렇게 보인다. 그렇게 해서, 그 사람으로 하여금 회사에 정나미가 떨어지게 만들어, 제 발로 걸어나가게 만들 수 있으니까.

그렇다면, software개발에서는?

거의 모든 회사에서, software개발의 schedule은 항상 overly optimistic하다. 또한 상당부분, overly optimistic을 넘어 impossible한 경우가 많다. 그래서 어느 순간에는, software 개발 schedule이 나오더라도, 당연히 못 지킨다고 생각하고 마음을 비우게 된다...-_-; 그렇다면, SW회사는 software engineer를 회사에서 떠나보내게 하려고 그러는 것일까? 물론 아니겠지만.... engineer는 떠나고 싶어진다... 문제는.. 안 그런 곳을 찾기가 어렵다는 것인데... 씁쓸하다...

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

필자가 국내 핸드폰 소프트웨어 개발 직종에 종사하면서, "이건 아닌데..."라고 생각한 부분이 몇가지 존재하는데, 그 중에 하나가 Test & Debugging Cycle에서의 문제점이다.
필자가 경험한 바로는 Test & Debugging Cycle에서의 업무는 다음과 같이 이루어 진다.

1. Test engineer(이후 TE)가 발견한 버그를 Issue Tracking system에 기록한다.
2. Engineer가 이를 보고 실제 재현을 해 본다.
3.1 문제없이 재현하였다면,   이게 정말로 버그인지 아닌지 확인한다.
3.2 재현에 실패했다면, TE에게 재현 방법을 물어보고, 3.1의 과정으로 간다.
4. 실제 버그가 맞다면, 수정에 들어간다.

그런데, 문제는 위의 과정에서 생산성을 저하시키는 일들이 필요이상으로 많이 발생한다는 것이다. 하나씩 살펴보자.
먼저, 1과 2사이를 보자.
보통의 경우 - 국내 업체 -  Product Specification, User Interface Specification(이후 UIS)같은 문서들이 대부분 상당히 부실하게 작성되어 진다. 이 중에서 SW측면에서 보았을때, 특히 중요한 것이 UIS인데, Specification이라는 이름에 걸맞지 않게 허술하게 작성되는 경우가 대부분이다. 필자의 소견으로는, 기업이 이 부분에 크게 투자하지 않는 것 같다.  SW를 경시하는 만큼 UIS도 경시하는 듯 하다. 따라서, TE입장에서는 무엇이 버그이고, 무엇이 버그가 아닌지 판단할 수 있는 확고한 근거가 없으므로, 그냥 본인이 이상하다고 생각하면 전부 버그라고 reporting하게 된다.

2와 3 사이의 경우, TE의 reporting미숙에서 오는 overhead가 상당히 크다. 개발자들은 bug report을 보고, 이를 어떻게 재현할 수 있는지 몰라서, TE에게 찾아가거나 혹은 전화로 다시 한번 확인하는 경우가 태반이다. 심지어는 "xxx를 하면 화면이 이상하게 보임." 이라고 기록된 어이없는 reporting을 본 적도 있다. 이는 TE의 역할에 대한 기업의 잘못된 정의가 가장 큰 원인이라고 필자는 본다.
보통  QA를 TE의 역할로 정의하는 업체가 많다. 물론, QA는 TE의 가장 중요한 역할 중 하나이지만, 국내의 경우 그 정도가 지나친 것처럼 보인다. 무슨 말이냐 하면, 오로지 bug를 찾아내는데만 TE의 역할이 집중되어 있다는 뜻이다. 보통의 경우, TE의 임금은 Developer에 비해 저렴하다. 그래서 TE라는 직종이 따로 생겼고 (만약 그렇지 않다면, developer가 TE의 역할을 같이 겸하게 되었을 것이다.)  SW의 bug를 찾고 품질을 검증하는 역할이 주어졌다. 그렇다면, 상대적으로 비싼 비용이 드는 Developer의 시간을 절약하고 이 역할을 TE가 해 줄 수 있도록 해야하지 않겠는가? 따라서 debugging을 위해 developer를 support하는 것 역시 TE의 중요한 역할 중 하나가 되어야 하고, TE의 성과 평가 항목에 반드시 이 부분이 반영되어야 한다. 이때, 가장 기본적인 것이 bug reporting이다. TE는 bug를 재현할 수 있는 방법을 명확하게 기술해야 하고, debugging에 도움이 되는 정보를 추가적으로 기록해 줄 필요가 있다. 에를 들면 아래와 같다.

menu -> setting -> time & data -> 24시 format으로, 12:00를 setting하면 phone이 reset됨.
menu -> setting -> time & data -> 12시 format으로 12:00를 setting하면 정상 동작함.
menu -> setting -> time & data -> 24시 format으로, 11:00를 setting하면 정상 동작함.

이런 정도의 reporting은 상대적으로 비싼 비용이 들어가는 Developer의 시간을 상당히 절약시켜 줄 수 있다.  물론, 너무 상세한 reporting으로 인해 쓸데 없이 많은 시간이 소모된다면, 그것 역시 피해야할 것이다.
좋은 TE를 유지하는 일은 상당히 어렵다. TE라는 일 자체가 가지는 특성때문에, 좋은 TE는 빨리 다른 직종으로 이직하고자 하기 때문이다. 따라서, 어떻게 좋은 TE를 유지할 것이냐 또한 심각하게 고민해할 문제이다.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
!!!사람을 힘들게 하는 것은 "Hard work"가 아니다. "Stress"다
사람들이 일을 즐기면 - 즐기지는 못하더라도 할만하면 -, 열심히 일해도 힘들지 않다.
그러나, 사람들은, 자신이 무엇을 하고 있고, 왜 이 일을 하고 있는지 알지 못하면 일을 즐길 수가 없다.
사람들은 자신이 하고 있는 일의 방향과 타당성을 알고 비젼에 공감하며, 열심히 일한 것에 대한 보상이 있을때, 일을 즐길 수 있고, 이때는 하루에 10시간 혹은 12시간을 일하더라도, "회사일 때문에 힘들다."라는 이야기를 하지 않을 수 있다.

반면, 내 경력에 전혀 도움이 되지도 않고, 왜 이 일이 필요한지도 모르겠는 일을 계속해서 하면서, 다른 사람과의 갈등으로 계속해서 스트레스를 받으면, 아무리 9-6 8시간 근무를 하더라도.."회사일 때문에 힘들다."라는 생각이 들 수 밖에 없다.

음.... 지금 당연한 이야기를 하고 있는 것일 수도 있으나.. 다시 한 번 되새겨 보자는 의미에서 한번 적어 본다....

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
"世有伯樂然後有千里馬, 天里馬常有而伯樂不常有." 라 했다.

좋은 사람을 알아 본다는 것은 그 만큼 힘든 일이고 어려운 일이다.

옛 중국에는 '사람을 추천했을 경우 추천받은 사람이 죄를 지으면 추천한 사람도 그와 같은 처벌을 받는다.'는 법이 있었다고 한다. 모르긴 몰라도, 그 반대로 추천받은 사람이 공을 세울 경우, 추천한 사람도 그 공을 나누어 가지지 않았을까?

따라서 사람을 추천한다는 것 혹은 추천받는 다는 것은 그 만큼 어렵고 또 중요한 일이란 뜻이다. 추천 받은 사람은 자신의 공과가 추천한 사람에게 그대로 이어짐을 명심해야하고, 추천한 사람또한 이러한 것을 충분히 고려한 후 추천해야 한다.

그렇지만 무엇보다도, 사람을 추천하기 전에 '좋은 사람을 알아본다'는 것이 얼마나 어려운 일인지 알고, '좋은 사람을 추천할 수 있는 사람' (伯樂)의 가치를 알며, 이를 소중히 여길 줄 아는 것! 이것이 아마도 가장 중요한 것이 아닐까? 그리고 나 또한 '좋은 사람을 알아볼 수 있는 안목'을 기르는데 노력해야 하지 않을까?

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

조직의 최고 책임자가 조직 전체를 세세히 알 수 있는 작은 조직에서는 밥그릇 싸움이 일어나기 힘들다. 밥그릇 싸움은 조직의 크기가 어느 정도 이상 커졌을 때 주로 발생한다.

다음의 시나리오를 생각해 보자.

처음에 10명으로 시작한 회사가 있다. 이 회사의 일이 처음에는 10명이 열심히 하면 되었다. 그런데 차츰 회사가 성장하면서 10명으로는 도저히 감당할 수 없을 정도로 일의 양이 늘어났다. 그래서 회사는 사람을 더 뽑았고, 이런 과정이 몇번 발생하면서, 회사의 인원은 100명으로 늘어났다.

그런데 회사가 계속 일이 늘어나기만 할 수는 없다. 어느 날 부터, 100명 분의 일이 80명 분의 일로 줄어들었다. 그럼 20명은 놀아야 정상인데, 놀고 있다는 사실이 위쪽에 알려지면 놀고 있는 부서는 그 규모가 축소되어지게 되므로, 80명 분의 일을 100명분의 일로 늘리게 된다. 즉, 실무자들은 이 일이 80명 분의 일이라는 것을 알고 있으나, 관리자는 추가적이고, 비생산적인 20명분의 일을 만들어서 자기 부서의 규모를 유지하고자 하게 된다. 구체적인 예를 들어보자.

프로젝트 A, B가 있다. B는 50명 A는 10명의 인원이 배정되었으며, A는 B의 결과물을 받아서, 약간의 수정/개선 을 통해서 제품화되어 지게 된다. 프로젝트 납기일은 A는 B보다 2달 늦다. 이 상황에서 A는 B에서 어떤 base line이 되는 결과물이 나오기 전에는 Project에 관한한, Project가 진행되고 있음을 위쪽에 보여줄 어떠한 결과물도 만들어낼 수 없는 상황이다.

이때, 보통의 회사, 그리고 보통의 관리자라면, A 프로젝트의 10명의 인원에게, 무언가 생산적이고, 장기적인 일을 시키기 보다는(이런 일은 보통, Project진행상황을 진척시키는 것처럼 보이게하는데 별 도움이 되지 못한다.) 프로젝트가 진행되고 있다는 사실을 윗사람에게 보이기 위해, B의 결과물을 받기 이전에, A의 10명에게 B에서 하는 것과 똑같은 일을 시키게 된다. (A 프로젝트도 뭔가 진행되고 있다는 것을 보이기 위해...) 이 일은 명백히 B에서의 일과 중복된다. 그리고, B에서 어느정도 결과물이 나오게 되면, A는 자신이 했던 거의 모든 일은 다 버리고, B의 결과물을 받아와서 새로 A 프로젝트를 시작한다. 그리고 보통, 이 상태는 그 동안 A에서 "보여주기 위한 일"을 했던 그 상태보다 더 진보된 상태가 된다. (왜냐하면 50명의 산출물을 가져 왔으므로...). 이렇게 해서, A의 관리자는 프로젝트 A가 뭔가 진행되고 있는 것처럼 위에 보고 한다. 더 한심한 일은, 대부분의 윗쪽 상급관리자는 A 프로젝트의 관리자가 일을 잘 하고 있다고 생각하고, 여기에 무엇이 잘못되었는지 전혀 알지 못한다는 것이다.

이런 일은 특히 Software Project에서 많이 일어난다. 왜냐하면, Software 산업에서, 의사결정권을 가진 위쪽 사람들은 Software를 전혀 모를 사람이 대부분이기 때문이다. 이런 비효율은 계속해서 발생하고, 회사가 심각하게 어려워지기 전까지는 항상 사람이 부족한 것처럼 아래에서는 보고가 올라오고, 위헤서는 그렇게 보일것이다. 내가 너무 비약해서 글을 썼을 수도 있으나, 실제로 이런 과정을 몇차례 겪어보았으니... 쩝...

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

아래는 모두 개인적인 의견임을 밝힌다.

전제 : 어떤 결정을 하기 전에, 최선의 결정이 무엇인지 아는 것은 불가능하다.

가능하다면, 의사결정을 민주적으로 하는 것이 좋다는데는 이견이 없다. 그런데, 회사에서는 '민주적'이라는 단어가 존재할 수 없다. 조직 자체가, 서열화 되어 있고, 의사결정권한은 한 사람에게 집중되어 있다. 따라서, 회사에서 말하는 '민주적'이란, 의사 결정권자가, 다른 사람들의 의견을 수렴해서, 최대한 여러사람이 공감할 수 있는 결정을 내리는 것을 말하리라.

그러나, 다음의 경우를 생각해 보자.

A와 B 라는 두가지 선택을 할 수 있는데, 의사결정권자의 마음이 이미 A로 기운 상황을 생각해보자. 이 의사 결정권자는 민주적인 결정을 하고 싶어한다 (누가나 그렇다.) 그래서 사람들을 불러 모아 놓고, 의견을 듣는다. 그런데 사람들은 B를 주장한다. 그렇지만 의사 결정권자의 마음은 바뀌지 않는다. 그래서 사람들을 설득하고자 한다. 동의를 얻어내기 위함이다. 그러나 설득이 되지 않는다. 따라서, 다시 사람들에게 시간을 준다. "A와 B 진정으로 어느 쪽이 옳은지 다시 한 번 생각해 보고, 다시 회의 하자." 그리고 다음 회의에서도 이전 회의와 똑같은 현상이 되풀이 된다. ("1+1=2" 와 같이 논리적인 답이 있는 것이 아니라면, 사람들은 자신의 뜻을 쉽게 바꾸지 않는다.)

위의 상황에서도 계속해서 소위 말하는 '민주적'인 의사결정을 고집해야 하는가? 물론, A와 B가 어떤 문제에 대한 의사 결정인지에 따라 다르겠지만, 만약, 이 결정이 부서 업무의 방향을 결정짓는 것이라면, 사람들은 이 결정이 내려지기 전까지는 아무일도 할 수 없고 시간만 보내는 상황이 될 것이다. 만약 이 문제가 시간을 다투는 것이라면, 차라리 어느 쪽이든 빨리 결정해서 밀고 나가는 것이 더 나을 수 있다. 이런 때는 의사 결정권자가 자신의 뜻을 독단적으로 관철시키는 것이 오히려 더 낫다고 생각한다.