데드라인

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS

FrontPage보드카구슬꿰기 데드라인

http://image.aladin.co.kr/cover/cover/8995300973_1.jpg



다음은 이 책의 주인공인 톰킨스의 일지를 옮겨 적은 것입니다. 책을 마무리하면서 저자는 원본을 세상에 바친다고 했으니, 우리가 여기에 배껴썼다고 저자가 나서서 토 달지는 않을 것이라 여겨집니다. 그런데, 이 일지의 내용들이 자신이 처한 현실과 다른 부분들도 많이 있을 겁니다. 코멘트를 달아 가면서 소중한 경험들을 나눌 수 있었으면 합니다. 급하게 하지 않아도 되겠지요? "실수 실수 실수 하지만 적게 적게 적게"를 생각하며, 천천히, 지혜의 샘으로 가는 길로 올라 서 보실까요. --맑은 2011.3.2 (토)

{{|
훌륭한 관리를 위한 4가지 필수요건 (p42)
∙적절한 사람들을 구한다.
∙그들에게 알맞은 일을 할당한다.
∙항상 동기부여를 한다.
∙팀이 결속하도록 하고 그 상태를 유지하도록 돕는다.
(그 외의 나머지 일은 전부 '허드레 관리업무"다.)
|}}

{{|
안전과 변화 (p49)
∙사람들은 안전하다고 느기지 않는 한 변화를 수용하지 않는다.
∙변화는 프로젝트를 성공시키기 위해서 필수적이다. (그리고 그만한 가치가 있는 대부분의 노력을 위해서도 필수적이다.)
∙안전성이 부족하면 사람들은 위험을 감수하려고 하지 않는다.
∙위험을 피하는 것은 치명적이다. 위험과 연관되어 있는 이점도 놓치기 때문이다.
∙사람들은 직접적으로 위협을 받거나 자신들에게 악용될지도 모르는 권력을 인지할 때 불안함을 느낄 수 있다.
|}}

{{|
부정적인 압력 (p62)
∙협박은 실적을 유도하기에는 불완전한 방법이다.
∙처음부터 할당된 시간이 충분하지 않다면, 아무리 진지하게 협박을 하더라도 작업은 제시간에 끝나지 않는다.
∙설상가상으로, 목표한 바를 얻지 못하면, 협박한 대로 이행해야 할 수도 있다.
|}}

{{|
관리자가 가져야 할 필수 감각 (p76)
∙관리에는 마음과 본능과 정신 그리고 후각이 필요하다
∙그러므로 마음으로 이끌고, 본능을 믿고 (직감을 믿어라), 조직에 정신을 심어주고, 거짓말을 식별할 수 있는 후각을 키워라.
|}}

{{|
관리자의 메타포(metaphor) : 전투지휘 p86
∙전투가 시작되면 관리자의 실제업무는 이미 끝난 것이다.
|}}

{{|
인터뷰와 채용 p86
∙채용할 때는 모든 관리감각이 필요하다 : 마음, 정신, 후각 그리고 본능 (하지만 대부분 본능이 필요하다.)
∙혼자 하려고 하지 마라 : 두 사람의 본능이 한 사람의 본능보다 두 배 이상 좋다.
∙새로 채용한 사람에게 자신이 이미 증명했던 바로 그 수준의 프로젝트를 수행하게 하고 능력을 확장할 수 있는 목표는 다음으로 미루도록 요청한다.
∙조언을 부탁한다 : 당신이 채용하고 싶어하는 사람이 또 다른 훌륭한 사람을 알고 있을 수도 있다.
∙말하기보다는 들어라.
∙자료를 정리해 놓으면 모든 일이 수월하다.
|}}

{{|
생산성의 향상 p102
∙생산성에 관한 단기적인 해결방안은 없다.
∙생산성 향상은 장기적인 투자의 결과다.
∙즉각적인 결과를 보장하는 것은 모두 헛소리다.
|}}

{{|
위험관리 p102
∙프로젝트의 위험을 관리하는 것으로 프로젝트를 관리한다.
∙각 프로젝트의 위험을 조사하고 관리한다.
∙궁극적으로 바람직하지 않은 결과를 추적하는 것이 아니라 원인이 되는 위험을 추적한다.
∙각 위험에 대한 발생확률과 예상되는 소요비용을 평가한다.
∙각 위험에 대해 위험이 구체화되는 것을 나타내는 초기증상을 예상한다.
∙무엇이든지 "할 수 있다"는 자세를 갖고 일하지 않아도 되는 사람을 위험담당자로 임명한다.
∙나쁜 소식이 조직의 계층구조상위로 전달되는데 용이한(필요하다면 익명으로)채널을 수립한다.
|}}

{{|
방어하기 p112
∙손실을 줄인다.
∙성공을 낙관하기보다는 실패를 견제한다면 전반적인 효율성을 향상시킬 수 있다.
∙실패한 작업은 초기에 적극적으로 취소하도록 한다.
∙팀의 결속에 대해 위험을 무릅쓸 필요가 없다면 굳이 그렇게 하지 않는다. 이미 편성된 팀을 찾고 이용한다.
∙후속 관리자가 더딘 결속력이나 결속이 되지 않는 팀으로 인한 문제를 피할 수 있도록 하기 위해 (팀원들이 원한다면) 훌륭한 팀은 계속 유지시킨다.
∙(이미 준비되어 있고 새로운 작업을 할 의향이 있는) 결속된 팀 자체를 프로젝트 산출물의 하나로 간주한다.
∙프로젝트 초기에 잃어버린 한 시간은 프로젝트 마지막에 잃어버린 하루와 같은 손실이 된다.
∙하루를 잃는 데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한 가지 방법조차도 없다.
|}}

{{|
개발 프로세스 모델링과 시뮬레이션 p136
∙작업을 완료하는데 필요한 프로세스에 관한 자신의 직감을 모델링한다.
∙동료들간 상호교류와 프로세스가 어떻게 작동하는지에 대한 사고를 개선하는데 그 모델을 사용한다.
∙결과를 모의실험하기 위해 모델을 사용한다.
∙실제 결과에 따라 모델을 조정한다.
|}}

{{|
병적인 정치학 p154
∙직업을 언제든지 담보로 할 의향이 있어야 한다.
∙하지만 그렇게 하는 것이 병적인 정치 때문에 영향을 받지 않는다는 것을 보장해 주지는 않는다.
∙병적인 정치 논리는 어디서든지 자랄 수 있는데, 심지어는 가장 건강한 조직에서조차도 생길 수 있다.
∙병적인 정치학의 특성을 정의하자면, 개인적인 권력과 영향력으로 인한 목표가 조직의 현실적인 목표보다 우위에 선다.
∙이 말은 병적인 목표가 조직의 목표와 완전히 반대가 되더라도 일어날 수 있다는 뜻이다.
∙이 병이 갖는 부작용 중 하나는 알맞은 인원으로 된 프로젝트 팀을 갖는 것조차 위험해진다는 것이다.
|}}

{{|
측정 (Metrics) p174
∙모든 제품의 규모를 측정한다.
∙단위 때문에 고민하지 말라. 객관적인 측정방법을 만들기 전까지는 주관적인 단위를 사용한다.
∙이용할 수 있는 모든 원시적인 요소(소프트웨어를 계량화할 수 있는 특징)를 활용해 통합 측정모델을 만든다.
∙완료된 프로젝트에서 생산성에 관한 경향을 파악하기 위해 과거 프로젝트에서 데이터를 수집한다.
∙통합 측정모델에 의해 나온 값이 과거 프로젝트의 공수(effort)와 최적의 상관관계를 나타낼 때까지 그 공식을 가지고 계속 작업을 한다
∙데이터베이스를 가지고 통합 측정모델이 예상한 공수를 트렌드 곡선으로 그린다.
∙이제 추정할 새로운 프로젝트마다 통합 측정모델로 값을 계산하고, 그 값을 트렌드 곡선에서 예상 공수와 비교하는 데 사용한다.
∙예상치에 어느 정도의 허용오차를 적용할지를 나타내기 위해 생산성 트렌드 곡선에 오차의 범위를 사용한다.
|}}

{{|
프로세스와 프로세스 향상 p185
∙좋은 프로세스와 지속적으로 향상되는 프로세스는 모두 훌륭한 목표가 된다.
∙이들은 또한 매우 당연한 목표이기도 하다. 훌륭한 개발자들은 그렇게 하라고 말을 하든 안 하든 간에 여기에 초점을 맞춘다.
∙공식적인 프로세스 향상 추진 계획은 시간과 돈이 든다. 그러한 프로세스 향상작업은 프로젝트 작업을 뒤쳐지게 할 것이다. 생산성 향상이 실현된다 하더라도 그 계획을 실행한 프로젝트가 프로세스 향상에 들인 시간을 상쇄하지는 못한다.
∙프로젝트에 향상 방법을 하나만이라도 제대로 선정한다면 본전(그러한 변화에 투자한 시간과 비용)을 뽑을 수 있을 것이라고 생각한다.
∙프로젝트가 그 기간 동안 하나 이상의 향상 방법을 수용하기를 바라는 것은 무리다. 여러가지 기술을 한 번에 향상시키려는 계획 (Multi-skill improvement programs 예를 들어, 전체 CMM 레벨을 증가시켜서 얻을 수 있는)은 그 계획을 실행하지 않았을 때보다 프로젝트를 더 지연시킨다.
∙표준 프로세스는 사람들이 중요한 지름길로 갈 기회를 놓치게 할 위험성이 있다
∙특히 인원이 과다하게 투입된 프로젝트의 경우 모든 사람들에게 돌아갈 만큼 일(유용한 일이거나 그렇지 않은 일이라도)이 충분하지 않다면 문제가 발생하게 된다.
|}}

{{|
작업 방식 바꾸기 p205
∙전체 디버깅 시간을 상당량 줄이지 않고는 프로젝트가 평균 이상으로 능력을 충분히 발휘하도록 할 수 있는 방법은 없다.
∙높은 성과를 보이는 프로젝트는 디버깅에 훨씬 적은 시간을 소모한다.
∙높은 성과를 보이는 프로젝트는 설계에 훨씬 많은 시간을 투자한다.
∙사람들을 좋아하지 않고 제대로 돌봐주지도 않는다면 어떠한 일이든 간에 그들에게 일을 하도록 만들 수 없다. 사람들을 변화시키기 위해서는 그들의 생각이 무엇에 근거하고, 왜 그런지를 이해(인정)해야 한다.
|}}

{{|
초과근무의 부정적 효과
∙사람들을 지치게 한다.
∙에너지를 소모시키고
∙실수할 확률을 증가시키고
∙정상 근무 시간 대의, 시간을 낭비한다 : 개발자가 초과근무를 하게 되면 전체 팀은 정상근무 시간에 회의를 많이 하게 되고 다른 팀에서 개발작업을 방해하는 일이 생겨도 괜찮다고 생각하거든. (그런 일이 생기면 제재할 생각보다는) 자기들이 저녁 시간에 그 시간을 보충할 거라고 생각하니까.
|}}

이건 톰킨스 일지가 아니라 중간의 내용을 요약한 것 같은데, 전 책을 도서관에 반납해 버려서 페이지를 찾을 수가 없습니다. 누가 보면 페이지 좀 적어주세요. 고맙습니다. --맑은 2011.3.12 (토)

{{|
압력의 효과 p227
∙스트레스를 받는 사람들은 머리가 빨리 돌아가지 않는다.
∙초과근무 시간 증가는 생산성 감소 기법이다.
∙단기간에 가하는 압력과 초과근무는 사람들을 집중하게 만들고 일이 중요하다는 느낌을 심어 주기 때문에 유용한 전술이 될 수 있지만, 압력을 장기간에 걸쳐 가하는 것은 언제나 실수하는 것이다.
∙관리자가 압력을 가하는 이유는 그가 할 일이 없거나 아니면 (압력을 피하는 쪽의) 대안 실행에 엄두가 나지 않기 때문이다.
∙끔찍한 생각 : 압력과 초과근무 시간을 사용하는 실제 이유는 프로젝트가 실패하더라도 모든 사람들이 최선을 다한 것처럼 보이기 위해서일 것이다.
|}}

{{|
낙관적 자세 비판 p232
톰킨스 : 우리가 왜 안 해도 될 항공교통관제시스템 일을 받아들이는 거죠? 벨록이 이 새로운 짐에 대해 언급도 하기 전에 이미 일에 파묻혀 버렸군요.
케노로스 : 우리가 이렇게 많은 과제를 받아들이는 것은 ... 두려워 하는 게 너무 적기 때문이지. (뭐든 다 할 수 있을 듯이...)
|}}

이건 일지가 아니라 대화 내용입니다. 일지에 썼을 만한 내용인데 없길래 추가합니다. 이 이야기가 Doodoori2님이 좋은프로젝트매니저에서 하신 바로 그 Yes맨의 한계라는 것과 통하는 바가 있는 것 같습니다. 위의 대화는 두려움을 약간씩, 아주 조금씩만은 가지고 있어야 한다든 얘기로 들리네요. 동감합니까? 하지만, 실제는 약간이 아니라 엄청 두렵지요. 끝이 보이지 않는데, 얼마나 두렵습니까. 그렇게 두려운데도 불구하고, 새로운 요구를 꾸역꾸역 받아들입니다. 너무 두려워서 정신이 쏙 빠져 있기 때문에, 상황에 대한 분별력이 떨어져서, 추가되는 일에 대해 그 어떤 생각도 함께 하지 못합니다. 바로 TunnelVision의 상태입니다. 눈에 뵈는 게 없지요. 딱 내 눈 앞에 것 밖에 안 보입니다. 다른 무엇을 봤는지, 무엇을 들었는지, 누가 무슨 부탁을 했는지, 아무 생각이 없게 넋이 빠진 상태라는 거지요.

따라서 위와 같은 상황을 돌파하기 위해 필요한 것은 케노로스가 말한 조금만은 두려워 하기가 아니라 사람 정신 차리게 해 주기 라고 생각합니다. 케노로스가 말하는 건 스스로 해야 할 몫이지만, 맑은이가 말하는 후자는 다른 누군가가 해 주어야 하는 일입니다. 스스로는 절대 할 수 없는 일이지요. 그래서 그 무엇보다도 나를 지켜보는 사람이 있어야 하는 것입니다. 그 사람이 도움을 줄지 안줄지는 아무도 모르지만 적어도 다른 누군가가 없다면 그 후자의 답안은 얻어 낼 방법이 없는 거지요.

케노로스의 입을 통해서는 이런 말을 했지만, 결국 저자는 맑은이의 생각에서 크게 벗어나지 않았습니다. 이 책의 후반부에서 락사가 톰킨스를 프로젝트 도중임에도 불구하고 휴가를 가도록 상황을 만듭니다. 대부분이 그렇듯이, 아니 모두가 그렇다고 해 버립시다, 톰킨스도 스스로는 절대 프로젝트 도중에 휴가를 가지 않을 거니까, 억지로 등 떠밀어 내 보내는데요(전사휴가), 바로 그러한 일이 필요한 거라고 생각해요. 그 휴가 길에 톰킨스가 얼마나 큰 물고기를 잡아 왔는지를 눈 여겨 보셔야 합니다. 그렇게 정신 차릴 기회들을 만들어 주는 것만이 'Yes맨의 한계를 극복할 수 있는 길'이라고, 맑은이는 소리 높여 외칩니다.

--맑은 2011.3.12(토)

{{|
화가 난 관리자 p239
∙관리에서 화와 모욕은 전염된다. 상급 관리자가 직원들을 학대하면 그 밑에 있는 관리자들도 그와 같은 행동을 따라한다 (학대받은 아이들이 학대하는 부모가 되는 것과 비슷하다)
∙관리차원에서 모욕을 주는 일은 사람들이 자신의 능력에 좀 더 투자하도록 만드는 자극제 역할을 해야 한다. 그것은 당근과 채찍 두 가지 관리법 중 가장 자주 사용되는 '채찍'인 것이다. 하지만 모욕이 능력을 더 발휘하도록 만든다는 증거가 어디에 있는가?
∙관리자가 개발자들을 자극하기 위해 모욕을 주는 것은 개발자들이 무능하다기보다는 관리자가 무능하다는 표시다.

여기서 worker는 직원이 아니라 개발자로 번역하는 것이 맞지 않을까? 그래서 직원으로 된 부분을 개발자로 살짝, 아주 살짝, 놀라지 않을 만큼만, 바꾸었다. --맑은 2011.3.12(토)
|}}

{{|
애매모호한 명세서 p245
∙명세서에 나타난 애매모호함은 시스템의 여러 이해 당사자들 간에 해결되지 않은 마찰이 있음을 의미한다.
∙입력과 출력에 관한 완전한 개수를 포함하고 있지 않은 명세서는 출발에서부터 실패한 것이다. 간단히 말해 명세서 작업을 시작하지도 않은 것이다
∙아무도 당신에게 명세서가 엉망이라는 것을 말해주지 않는다. 사람들은 명세서를 탓하기보다 자신을 탓하는 경향이 있다.
|}}

{{|
마찰 (Conflict) p256
∙개발 작업에 여러 이해 집단이 연관되어 있을 때는 언제나 서로 모순되는 관심사가 있기 마련이다.
∙시스템을 구축하고 설치하는 분야는 특히나 마찰이 일어나기 쉬운 분야다.
∙대부분의 시스템 개발 조직은 마찰 해결 기술을 가지고 있지 않다.
∙마찰은 존중되어야 한다. 마찰이 비전문적인 행위를 나타내는 것은 아니다.
∙모든 사람들의 승리 조건은 존중될 것이라고 미리 선언한다. 그리고 그러한 승리조건이 모든 면에서 명확하게 되도록 보장한다.
∙협상은 어렵지만 중재는 쉽다.
∙승리 조건이 상호 배타적이거나 부분적으로 배타적일 때 양자는 마찰을 해결하기 위해 중재 과정을 거치게 된다는 것을 미리 협의해 정한다.
∙기억하라. 우리는 모두 같은 편이다. 다른 편이 있다면 그것은 문제 그 자체일 뿐이다.
|}}

{{|
촉매자의 역할 p268
∙촉매적인 성격이라는 것이 있다. 그런 사람은 팀이 형성되고, 결속되고, 건전하고, 생산적이 되도록 매개함으로써 프로젝트에 기여한다. 촉매자가 (주로 다른 많은 일을 하지만) 아무 일도 하지 않더라도 그들의 역할은 중요하고 가치 있다.
∙중재는 촉매적인 역할에 있어서 특별한 경우다. 중재는 조금만 투자하면 배울 수 있는 것이다.
∙시작을 위한 작은 의식인, '제가 중재해도 될까요?"는 마찰 해결에 있어서 중요한 첫 걸음이다.
|}}

{{|
인간의 실수 p276
∙당신을 괴롭히는 것은 당신이 모르는 것이 아니다. 그것은 안다고 생각했지만 사실은 제대로 알고 있지 못한 것이다.
|}}

{{|
투입 인력의 수 p290
∙초기에 인원을 과다하게 투입하면 프로젝트 팀은 중요한 설계 활동을 (모든 사람들에게 할 일을 주기 위해서) 간단하게 해 버리는 경향이 있다.
∙설계가 완성되기 전에 많은 사람들에게 작업을 나눠주면, 사람들 간의 인터페이스와 작업그룹 간의 인터페이스가 많아진다.
∙이것은 상호의존성, 회의시간, 재작업, 초조감을 증가시킨다.
∙이상적인 인력투입을 위해서는 대부분의 프로젝트에 소규모 핵심 팀을 운영하게 하고, 프로세스 후반에 상당한 수의 사람들을 추가 투입한다. (늦게는 스케쥴 상 마지막 6분의 1이 될 때에 투입한다)
∙놀라운 발견 : '공격적인' 스케쥴에 메인 프로젝트는 좀 더 타당한 스케쥴을 따랐을 때보다 프로젝트를 끝내는데 더 오래 걸린다.
|}}


{{|
프로젝트의 사회학 p305
∙없어도 될 사람이 참석하지 않도록 회의는 소규모로 유지한다.
회의에 없어도 될 사람이 영문 모를 회의에 참석하여 일할 시간을 낭비하도록 해서는 안 된다는 이야기. --성애 코멘트
∙토론 주제는 반드시 공고해야 하는데, 이는 불참해도 안전하다(불이익이없다)는 것을 보장해 줄 수 있는 가장 손쉬운 방법이다.
∙프로젝트에는 의식이 필요하다.
∙소규모 회의, 무결함 등 프로젝트 목표와 이상에 집중하기 위해 의식을 사용한다.
∙가학적인 화로부터 사람들을 보호하기 위한 조치를 취한다.
∙기억할 것 : 화=두려움. 아래 사람들을 학대하고 화를 내는 행위를 하는 관리자는 거의 대부분 자신들이 두렵기 때문에 그렇게 한다
∙관찰한 바 : 두려움은 표현하지 않으려는 경향이 있기 때문에 사람들은 더 이상 화를 표출하지 못하는 것이다. 그러므로 만약 모든 사람들이 '화=두려움' 이라는 것을 안다면, 화를 내는 것은 두려워하고 있다는 명백한 표시가 될 것이다. (그렇다고 화를 내는 당사자의 문제가 해결되지는 않지만 나머지 사람들이 감당하기가 훨씬 수월해진다.)
|}}

{{|
병적인 정치 (재탕) p320
∙아래로부터는, 병적 증세를 해결하기 어렵다.
∙그런 시도로 시간을 낭비하거나 자신의 위치를 위태롭게 하지 말라.
∙가끔 유일하게 남아 있는 선택은 문제가 스스로 해결될 때까지 기다리거나, 일을 진행시킬 수 있는 때를 기다리는 것 뿐이다.
∙기적이 일어날 수도 있다. (하지만 그것에 의지해서는 안 된다.)
|}}

{{|
비용 삭감 p305
∙비용 삭감은 실패에 대해 책임이 있는 사람들이 만들어 낸 공식이다.
∙이것은 '번영하며 서로 돕는다'는 모든 조직의 일반적인 목표와는 반대이다.
∙'비용 삭감'이라는 말을 들을 때마다 그 속에 담긴 참뜻으로 그 말을 대체시킨다. '실패하고 있고 두려워하고 있다.'
|}}

{{|
근본적인 상식 p336
∙프로젝트는 목표치와 추정치 모두가 필요하다.
∙그 둘은 서로 달라야 한다.
|}}

여기서 목표치인 6월 1일에 끝낼 수 있었던 것은 각 제품의 해체된 A팀들이 이미 준비된 사람들로서 B와 C팀에 충원되었기 때문이라고 맑은이는 생각합니다. 벨록의 주장과 요구도 맞을 수 있다는 열린 태도는 좋았지만, 보통은 프로젝트의 내용을 전혀 모르는 사람들을 충원하기 때문에 목표치라는 새로운 일정을 따로 운영하기란 쉽지 않다고 생각합니다. 그래 봐야 결국 미루는 습관만 생기게 되죠. 추정치가 따로 있으니까요. 처음에는 목표치에 개발자 자신의 자존심을 걸어도 보겠지만, 임박해지면 그 목표치에 대해 반응하면서 추정치가 있으니 괜찮다는 결정을 내리기까지 마음이 우왕좌왕 하면서 시간을 낭비하게 됩니다. 목표치라는 일정이 넘어가는 순간, 아직 추정치가 남아 있으니까 자존심을 챙길 기회는 남아 있어, 그 제서야 마음이 편안해지고 다시 일이 손에 잡히게 되거든요. 이런 일을 자주 하면 미루는 습관에 젖게 됩니다. 11월 달이었던 데드라인을 거의 반년이나 앞당겨 놓은 목표치라는 건, 결코 긍정적인 시도가 못된다고 생각해요. --맑은 2011.3.12(토)



"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>