"사람들은 당신을 좋아하기 때문에 따른다"
훌륭한 관리를 위한 4가지 필수 요건
l 적절한 사람들을 구한다.
l 그들에게 알맞은 일을 할당한다.
l 항상 동기 부여를 한다.
l 팀이 결속하도록 하고, 그 상태를 유지하도록 돕는다.
(이 외의 나머지 일은 전부 허드레 관리업무다.)
안전과 변화
l 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다.
l 변화는 프로젝트를 성공시키기 위해서 (그리고 그만한 가치가 있는 대부분의 노력을 위해서도) 필수적이다.
l 안전성이 부족하면 사람들은 위험을 감수하려고 하지 않는다.
l 위험을 피하는 것은 치명적이다. 위험과 연관되어 있는 잇점도 놓치기 때문이다.
l 사람들은 직접적으로 위협을 받거나 자신들에게 악용될지도 모르는 권력을 인지할 때 불안함을 느낄 수 있다.
부정적인 압력
l 협박은 실적을 유도하기에는 불완전한 방법이다.
l 처음부터 할당된 시간이 충분하지 않다면 아무리 진지하게 협박하더라도 작업은 제 시간에 끝나지 않는다.
l 설상가상으로 목표한 바를 얻지 못하면 협박한 대로 이행해야 할 수도 있다.
관리자가 가져야 할 필수 감각
l 관리에는 마음과 본능과 정신 그리고 후각이 필요하다.
l 그러므로
마음으로 이끌고,
본능을 믿고 (직감을 믿어라),
조직에 정신을 심어주고,
거짓말을 식별할 수 있는 후각을 키워라.
관리의 메타포(metaphor): 전투지휘
l 전투가 시작되면, 관리자의 실제 업무는 이미 끝난 것이다.
인터뷰와 채용
l 채용할 때는 모든 관리 감각이 필요하다: 마음, 정신, 후각, 그리고 본능 (하지만 대부분 본능이 필요하다.)
l 혼자 하려고 하지 마라 – 두 사람의 본능이 한 사람의 본능보다 두 배 이상 좋다.
l 새로 채용한 사람에게 자신이 이미 증명했던 바로 그 수준의 프로젝트를 수행하게 하고, 능력을 확장할 수 있는 목표는 다음으로 미루도록 요청한다.
l 조언을 부탁한다: 당신이 가장 채용하고 싶어하는 사람이 또 다른 훌륭한 사람을 알고 있을 수도 있다.
l 말하기보다는 들어라.
자료를 정리해 놓으면 모든 일이 수월하다.
생산성 향상
l 생산성에 관한 단기적인 해결방안은 없다.
l 생산성 향상은 장기적인 투자의 결과다.
l 즉각적인 결과를 보장하는 것은 모두 헛소리다.
위험관리
l 프로젝트의 위험을 관리하는 것으로 프로젝트를 관리한다.
l 각 프로젝트의 위험을 조사하고 관리한다.
l 궁극적으로 바람직하지 않은 결과를 추적하는 것이 아니라 원인이 되는 위험을 추적한다.
l 각 위험에 대한 발생 확률과 예상되는 소요 비용을 평가한다.
l 각 위험에 대해 위험이 구체화되는 것을 나타내는 초기 증상을 예상한다.
l 무엇이든지 ‘할 수 있다’는 자세를 갖고 일하지 않아도 되는 사람을 위험 담당자료 임명한다.
l 나쁜 소식이 조직의 계층구조 상위로 전달되는 데 용이한 (필요하다면 익명으로) 채널을 수집한다.
방어하기
l 손실을 줄인다.
l 성공을 낙관하기 보다는 실패를 견제한다면 전반적인 효율성을 향상시킬 수 있다.
l 실패한 작업은 초기에 적극적으로 취소하도록 한다.
l 팀의 결속에 대해 위험을 무릅쓸 필요가 없다면 굳이 그렇게 하지 않는다. 이미 편성된 팀을 찾고 이용한다.
l 후속 관리자가 더딘 결속력이나 결속이 되지 않는 팀으로 인한 문제를 피할 수 있도록 하기 위해 (팀원들이 원한다면) 훌륭한 팀은 계속 유지시킨다.
l (이미 준비되어 있고 새로운 작업을 할 의향이 있는) 결속된 팀을 프로젝트 산출물의 하나로 간주한다.
l 프로젝트 초기에 읽어버린 한 시간은 프로젝트 마지막에 잃어 버린 하루와 같은 손실이 된다.
l 하루를 잃는 데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한가지 방법조차도 존재하지 않는다.
1/ 프로젝 성공은 (팀원이 아니라) 매니저의 능력임을 보이기 위해서
2/ 인재들을 다른 프로젝에 재 분배하기 위해서
3/ 끼리끼리 친한 무리들을 만들지 않기 위해서
개발 프로세스 모델링과 시뮬레이션
l 작업을 완료하는데 필요한 프로세스에 관한 자신의 직감을 모델링한다.
l 동료들간 상호교류와 프로세스가 어떻게 작동하는지에 대한 사고를 개선하는데 그 모델을 사용한다.
l 결과를 모의실험하기 위해 모델을 사용한다.
l 실제 결과에 따라 모델을 조정한다.
병적인 정치학
l 직업을 언제든지 담보로 할 의향이 있어야 한다.
l 하지만 그렇게 하는 것이 병적인 정치 때문에 영향을 받지 않는다는 것을 보장해 주지는 않는다.
l 병적인 정치 논리는 어디서든지 자랄 수 있는데, 심지어는 가장 건강한 조직에서 조차 생길 수 있다.
l 병적인 정치학의 특성을 정의하자면, 개인적인 권력과 영향력으로 인한 목표가 조직의 현실적인 목표보다 우위에 선다.
l 이 말은 병적인 목표가 조직의 목표와 완전히 반대가 되더라도 일어날 수 있다는 뜻이다.
l 이 병이 갖는 부작용 중 하나는 알맞은 인원으로 된 프로젝트 팀을 갖는 것조차 위험해 진다는 것이다.
프로세스와 프로세스 향상
l 좋은 프로세스와 지속적으로 향상되는 프로세스는 모두 훌륭한 목표가 된다.
l 이들은 또한 매우 당연한 목표이기도 하다. 훌륭한 개발자들은 그렇게 하라고 말을 하든 안 하든 간에 여기에 초점을 맞춘다.
l 공식적인 프로세스 향상 추진 계획은 시간과 돈이 든다. 그러한 프로세스 향상 작업은 프로젝트 작업을 위쳐지게 할 것이다. 생산성 향상이 실현된다 하더라도 그 계획을 실행한 프로젝트가 프로세스 향상에 들인 시간을 상쇄하지는 못한다.
l 프로젝트에서 그 기간동안 하나 이상의 향상 방법을 수용하기를 바라는 것은 무리다. 여러가지 기술을 한번에 향상 시키려는 계획 (Multi-skill improvement program 예를 들어, 전체 CMM 레벨을 증가시켜서 얻을 수 있는)은 그 계획을 실행하지 않았들 때보다 프로젝트를 더 지연시킨다.
l 표준 프로세스는 사람들이 중요한 지름길로 갈 기회를 놓치게 할 위험성이 있다.
l 특히 인원이 과다하게 투입된 프로젝트의 경우 모든 사람들에게 돌아갈 만큼 일 (유용한 일이거나 그렇지 않은 일이라도)이 충분하지 않다면 문제가 발생하게 된다.
작업 방식 바꾸기
l 전체 디버깅 시간을 상당량 줄이지 않고는 프로젝트가 평균 이상으로 능력을 충분히 발휘하도록 할 수 있는 방법은 없다.
l 높은 성과를 보이는 프로젝트는 디버깅에 훨씬 적인 시간을 소모한다.
l 높은 성과를 보이는 프로젝트는 설계에 훨씬 많은 시간을 투자한다.
l 사람들을 좋아하지 않고 제대로 돌봐 주지도 않는다면 어떠한 일이든 간에 그들에게 일을 하도록 만들 수 없다. 사람들을 변화시키기 위해서는 그들의 생각이 무엇에 근거하고, 왜 그런지를 이해(인정)해야 한다.
압력의 효과
l 스트레스를 받는 사람들은 머리가 빨리 돌아가지 않는다.
l 초가근무 시간 증가는 생산성 감소 기법이다.
l 단기간에 가하는 압력과 초과근무는 사람들을 집중하게 만들고 일이 중요하다는 느낌을 심어 주기 때문에 유용한 전술이 될 수는 있지만, 압력을 장기간에 걸쳐 가하는 것은 언제나 실수하는 것이다.
l 관리자가 압력을 가하는 이유는 그가 할 일이 없거나 아니면 (압력을 피하는 쪽의)대안 실행에 엄두가 나지 않기 때문이다.
l 끔찍한 생각: 압력과 초과근무 시간을 사용하는 실제 이유는 프로젝트가 실패하더라도 모든 사람들이 최선을 다한 것처럼 보이기 위해서일 것이다.
화가 난 관리자
l 관리에서 화와 모욕은 전염된다. 상급 관리자가 직원들을 학대하면 그 밑에 있는 관리자들도 그와 같은 행동을 따라한다 (학대받은 아이들이 학대하는 부모가 되는 것과 비슷하다)
l 관리차원에서 모욕을 주는 일은 사람들이 자신의 능력에 좀 더 투자하도록 만드는 자극제 역할을 해야한다. 그것은 당근과 채찍 두 가지 관리법 중 가장 자주 사용되는 ‘채찍’인 것이다. 하지만 모욕이 능력을 더 발휘하도록 만든다는 증거가 어디에 있는가?
l 관리자가 직원들을 자극하기 위해 모욕을 주는 것은 직원이 무능하다기보다는 관리자가 무능하다는 표시다.
애매모호한 명세서
l 명세서에 나타난 애매모호함은 시스템의 여러 이해당사자들 간에 해결되지 않은 마찰이 있음을 의미한다.
l 입력과 출력에 관한 완전한 개수를 포함하지 않은 명세서는 출발에서부터 실패한 것이다. 간단히 말해 명세서 작업을 시작하지도 않은 것이다.
l 아무도 당신에게 명세서가 엉망이라는 것을 말해 주지 않는다. 사람들은 명세서를 탓하기보다 자신을 탓하는 경향이 있다.
마찰 (Conflict)
l 개발 작업에 여러 이해 집단이 연관되어 있을 때는 언제나 서로 모순되는 관심사가 있기 마련이다.
l 시스템을 구축하고 설치하는 분야는 특히나 마찰이 일어나기 쉬운 분야다.
l 대부분의 시스템 개발 조직은 마찰 해결 기술을 가지고 있지 않다.
l 마찰은 존중되어야 한다. 마찰이 비전문적인 행위를 나타내는 것은 아니다.
l 모든 사람들의 승리조건은 존중될 것이라고 미리 선언한다. 그리고 그러한 승리조건이 모든 면에서 명확하게 되도록 보장한다.
l 협상은 어렵지만 중재는 쉽다.
l 승리 조건이 상호 배타적이거나 부분적으로 배타적일 때 양자는 마찰을 해결하기 위해 중재 과정을 거치게 되다는 것을 미리 합의해 정한다.
l 기억하라. 우리는 무두 같은 편이다. 다른 편이 있다면 그것은 문제 그 자체일 뿐이다.
촉매자의 역할
l 촉매적인 성격이라는 것이 있다. 그런 사람은 팀이 형성되고, 결속되고, 건전하고, 생산적이 되도록 매개함으로써 프로젝트에 기여한다. 촉매자가 (주로 다른 많은 일을 하지만) 아무 일도 하지 않더라도 그들의 역할은 주요하고 가치 있다.
l 중재는 촉매적인 역할에 있어서 특별한 경우다. 중재는 조금만 투자하면 배울 수 있는 것이다.
l 시작을 위한 작은 의식인, “제가 중재하도 될까요?”는 마찰 해결에 있어서 중요한 첫 걸음이다.
인간의 실수
l 당신을 괴롭히는 것은 당신이 모르는 것이 아니다. 그것은 안다고 생각했지만 사실은 제대로 알고 있지 못한 것이다.
투입 인력의 수
l 초기에 인원을 과다하게 투입하면 프로젝트 팀은 중요한 설계활동을 (모든 사람들에게 할 일을 주기 위해서) 간단하게 해 버리는 경향이 있다.
l 설계가 완성되기 전에 많은 사람들에게 작업을 나눠 주면, 사람들 간의 인터페이스와 작업 그룹 간의 인터페이스가 많아진다.
l 이것은 상호의존성, 회의시간, 재작업, 초조감을 증가시킨다.
l 이상적인 인력 투입을 위해서는 대부분의 프로젝트에 소규모 핵심 팀을 운영하게 하고, 프로세스 후반에 상당한 수의 사람들을 추가 투입한다. (늦게는 스케쥴 상 마지막 6분의 1이 될 때에 투입한다)
l 놀라운 발견: ‘공격적인’ 스케쥴에 매인 프로젝트는 좀 더 타당한 스케쥴을 따랐을 때보다 프로젝트를 끝내는 데 더 오래 걸린다.
프로젝트의 사회학
l 없어도 될 사람이 참석하지 않도록 회의는 소규모로 유지한다. 토론 주제는 반드시 공고해야 하는데, 이는 불참해도 안전하다는 것을 보장해 줄 수 있는 가장 손쉬운 방법이다.
l 프로젝트에는 의식이 필요하다.
l 소규모 회의, 무결함 등 프로젝트 목표와 이상에 집중하기 위해 의식을 사용한다.
l 가학적인 화로부터 사람들을 보호하기 위한 조치를 취한다.
l 기억할 것: 화 = 두려움. 아래 사람들을 학대하고 화를 내는 행위를 하는 관리자는 거의 대부분 자신들이 두렵기 때문에 그렇게 한다.
l 관찰한 바: 두려움은 표현하지 않으려는 경향이 있기 때문에 사람들은 더 이상 화를 표출하지 못하는 것이다. 그러므로 만약 모든 사람들이 ‘화 = 두려움’ 이라는 것을 안다면, 화를 내는 것은 두려우하고 있다는 명백한 표시가 될 것이다 (그렇다고 화를 내는 당사자의 문제가 해결되지는 않지만 나머지 사람들이 감당하기가 훨씬 수월해진다).
병적인 정치 (재탕)
l 아래로부터는 병적 증세를 해결하기 어렵다.
l 그런 시도로 시간을 낭비하거나 자신의 위치를 위태롭게 하지 말라.
l 가끔 유일하게 남아 있는 선택은 문제가 스스로 해결될 때까지 기다리거나, 일을 진행시킬 수 있는 때를 기다리는 것뿐이다.
l 기적이 일어날 수도 있다 (하지만 그것에 의지해서는 안 된다).
비용삭감
l 비용 삭감은 실패에 대해 책임이 있는 사람들이 만들어 낸 공식이다.
l 이것은 ‘번영하며 서로 돕는다’는 모든 조직의 일반적인 목표와는 반대다.
l ‘비용삭감’ 이라는 망릉 들을 때마다 그 속에 담긴 참뜻으로 그 말을 대체시킨다. ‘실패하고 있고 두려워하고 있다.’
근본적인 상식
l 프로젝트는 목표치와 추정치 모두가 필요하다.
l 그 둘은 서로 달라야 한다.
'공부 > 책' 카테고리의 다른 글
| 내일이 바뀌는 새로운 습관 - 잠자기전 30분 / 다카시마 데쓰지 (0) | 2010.08.12 |
|---|---|
| 공부도둑 / 장회익 (0) | 2009.09.27 |
| 겸손한 개발자가 만든 거만한 소프트웨어 / 신승환 (0) | 2009.09.27 |
