심플 사보타지 - 관리자 및 감독관 (1)

지난 심플 사보타지 - 조직과 회의 (1), 심플 사보타지 - 조직과 회의 (2)에서 심플 사보타지 필드 매뉴얼의 항목 (11) General Interference with Organizations and Production 중 (a) Organizations and Conferences를 살펴봤습니다. 이 내용들을 주변에 공유하고 받은 반응은 세계대전 당시 미국으로부터 이런 공작을 당한 상대가 얼마나 열불 났을지에 대한 것, 그리고 여기 나열된 여러 가지 항목들이 현대에도 별로 낯설지 않다는 것입니다. 이 반응에 저 역시 동의하지 않을 수 없었습니다. 개인적으로는 정보기관이 과거에는 기밀로 취급하던 이런 문서들을 공개하는 이유는 현대에 이런 매뉴얼이 더 이상 필요하지 않거나 상대가 이 매뉴얼을 이미 알고 있으리라는 가정 하에 새로운 전략을 수립하고 있기 때문이라고 생각합니다. 공개된 여러 영상으로부터 이전에 정보기관에서 일했던 디렉터급 인물들이 정보기관의 여러 가지 전략을 설명하는 모습을 볼 수 있는데 개인적으로 이는 후자, 즉 정보기관을 의식하며 행동해야 하는 개인이나 조직들이 이미 이런 행동에 대한 정보를 알고 있는 상태에서 전략을 수립하도록 만들기 위함이 아닐까 하는 생각입니다. 하지만 다른 한편으로는 이제 이런 매뉴얼에 의해 훈련된 요원들보다 그냥 옆 부서 김부장이 이런 사보타지에 더 능통하기 때문에 굳이 이런 일을 위한 훈련이 필요 없어졌을 수 있습니다. 자, 그러면 이번에는 지난번에 이어 29페이지의 (b) Managers and Supervisors 항목을 살펴보겠습니다.

(1) 모든 요청을 서면으로만 받으세요. 문서는 정보사회에 업무를 처리하는 가장 기본적인 의사소통 수단입니다. 문서가 아닌 다른 의사소통 수단 가령 말, 메모, 슬랙 메시지, 메일 같은 수단은 휘발되기 쉬울 뿐 아니라 잘못 해석될 여지가 높습니다. 중요한 요청이 잘못 해석되어 여러 사람들의 시간을 낭비하게 만들거나 계획을 전면적으로 재조정하게 만들 위험을 감수하는 것은 적절하지 않습니다. 만약 업무 요청을 서면으로 받는다면 이럴 가능성이 줄어들고 만약 문제가 발생하더라도 문제의 원인을 찾아 책임을 추긍할 수 있을 가능성도 높아집니다. 개발팀에서는 이미 작성된 문서와 실제 개발할 범위가 서로 맞지 않을 수 있습니다. 어떤 조직에서는 작성된 문서에 표시해 개발할 부분과 그렇지 않을 부분을 구분하기도 합니다만, 가장 안전한 방법은 개발할 부분에 맞춰 문서를 재작성하는 것입니다. 사실 문서는 이미 이 문서의 전체 범위에 걸친 개발을 염두하고 작성했을 가능성이 높습니다. 때문에 문서의 일부에 표시하는 방식으로 개발 범위를 표시하면 표시를 잘못 인식하거나 개발하지 않을 부분을 읽느라 시간을 낭비할 가능성이 높습니다. 때문에 새로운 개발 범위에 따라 문서를 전면 재작성하도록 해야 합니다. 그러면 문서를 잘못 읽어 필요하지 않은 부분을 개발하거나 엉뚱한 부분을 읽느라 시간을 낭비할 필요가 없어집니다. 때때로 개발 범위는 실제 계획을 실행하는 가운데 변경될 수 있습니다. 각각의 변경에 맞춰 올바른 문서가 준비되지 않으면 함부로 업무에 착수해서는 안됩니다. 가령 군에서 내일 새벽에 실행하기로 한 작전 목표의 위치가 밤 사이 상황 변화로 인해 변경되었다고 해 봅시다. 그리고 이런 일은 실제로도 자주 일어난다고 합니다. 하지만 여러 조직에 걸쳐 조율된 계획은 새벽에 실행되어야만 합니다. 그렇다면 이 변경사항이 문서에 아무렇게나 표시된 상태로 작전을 실행해야 할까요? 그렇지 않습니다. 변경된 올바른 목표와 절차가 기입된 새로운 문서가 준비되기 전까지는 아무 것도 수행해서는 안됩니다.

(2) 요청을 의도적으로 오해하세요. 요청에 대해 끝없이 질문하고 긴 서신을 주고받으세요. 가능하면 이의를 제기하세요. 세상에 뻔한 것은 없습니다. 요청을 구성하는 여러 언어들은 직관적이어야 하고 명백히 다른 의미를 포함하고 있어서는 안됩니다. 과거 법률을 만드는 사람들은 그들의 법률을 의도적으로 해석의 여지가 있도록 작성한 것 같습니다. 영미법의 경우 사건 속에서 보편적인 원리를 발견한다고 말하는데 이는 법조문에 해석의 여지를 남기곤 합니다. 반면 대륙법은 상황의 판단을 주로 문서를 중심으로 하는데 이에 따라 상황에 연루된 모든 사람들이 같은 문서에 기반해 동일한 이해에 기반한 결정을 내리도록 합니다. 이러한 관점에서 문서에 기반하지 않은 요청은 해석의 여지를 두어 결과를 예측하기 어렵게 만듭니다. 때문에 아주 작은 표현이라도 해석의 여지가 있다면 업무에 착수하기 전에 이런 위험 요소를 충분히 제거할 필요가 있습니다. 이는 지난 심플 사보타지 - 조직과 회의 (2)의 '(5) 의사소통, 회의록, 결의안에 대한 정확한 표현을 놓고 흥정하세요.'와 결이 비슷합니다. 지난번에는 조직과 회의의 관점에서 정확한 표현을 놓고 흥정하기를 반복해 회의의 생산성을 저해하고 참가자들을 정신적으로 망가뜨리는데 초점을 맞췄다면 이번에는 관리자 및 감독관의 관점에서 조직이 업무를 수용하고 추진하기 위해 대단히 정확한 문서를 요구하는 점이 서로 다릅니다. 개인적으로는 이미 문서가 작성되었더라도 의도적인 오해를 통해 문서를 전면적으로 재작성하거나 제기된 의문을 해결하는 별도의 문서를 작성하도록 해 문서 작성 부하를 늘려 시간을 낭비하도록 만들 수 있습니다.

가령 어떤 기능을 개발하기 위해 작성한 소위 기획서에는 여러 부서에 걸쳐 참고할 다양한 내용이 포함되어 있을 수 있습니다. 기능의 목적과 로드맵은 주로 문서에 내용이 온전히 언급되지 않았을 때 이를 예상하기 위한 용도로 사용되거나 이 기능을 개발할지 말지를 결정하는데 사용됩니다. 또 주요 인터페이스와 이들의 동작은 실제로 기능을 구현하는 사람과 인터페이스 에셋을 제작하는 사람, 데이터구조는 주로 이를 구현하는 사람, 여러 에셋 목록은 각각의 에셋을 제작하는 사람들에게 필요합니다. 그런데 한 사람이 이 모든 내용을 필요로 하지 않는데도 이 모든 내용이 포함된 문서를 받아 읽을 필요가 없는 부분을 읽는데 시간을 낭비하거나 자신이 담당할 부분을 찾기 위해 노력을 들여야 할까요? 그렇지 않습니다. 먼저 명백히 자신이 수행할 부분이 아님을 알고 있더라도 다른 사람이 담당할 부분에 대한 질문을 하고 의도적으로 이 부분이 자신이 수행할 부분이 아님을 확인 받기를 반복하세요. 또 자신이 할 일이 문서에 기능 단위로 분산되어 서로 다른 곳에 위치하고 있을 수 있습니다. 문서 곳곳을 찾아다니며 자신의 작업 범위를 추적하는 것은 효율적이지도 않을 뿐 아니라 실수를 유발하고 책임을 추긍 받게 만들 수도 있습니다. 때문에 자신이 작업할 부분을 별도의 문서 또는 문서의 어느 한 지점에 정확히 나열하도록 요청하고 그렇지 않을 경우 의도적으로 작업 중 일부를 빠뜨려 문서에 분산되어 있어 빠뜨릴 수밖에 없었다고 말할 수도 있습니다. 모든 업무에 별도의 ‘발주서’를 작성하도록 하세요. 이런 문제 제기들은 최대한 메일을 통해 주고 받으세요. 팀에서 슬랙을 사용하고 있다면 어쩔 수 없이 대화가 조금 더 빨라질 겁니다. 하지만 그럴 때에도 최대한 채널에서 말하지 말고 채팅을 통해 말하고 비슷한 이야기를 서로 다른 곳, 가령 한 가지 주제 채널에서 말하다가 DM에서 이어 말하거나 그 반대로 말하며 서신을 분산시키면 효과를 최대화 할 수 있습니다.

(3) 작업 완료 시점을 지연 시키기 위해 가능한 모든 조치를 취합니다. 작업 일부가 이미 완성되어 있더라도 전체가 완전히 준비될 때까지 전달하지 마세요. 기획서는 대체로 여러 가지 요구사항의 지합으로 해석할 수 있습니다. 어떤 기능은 기능의 핵심을 담당하여 목적 그 자체를 담당합니다. 또 다른 기능은 핵심을 담당하지는 않지만 목적을 더 잘 수행할 수 있도록 돕습니다. 이들의 특징은 이들이 최종 상태에 포함될 경우 완성도가 올라가기는 하지만 이 기능들이 없다고 하더라도 기능의 핵심 기능이 동작하지 않는 것은 아닙니다. 개발 중에는 양해할 수 있는 수준의 불편함이 있을 뿐입니다. 나아가 어느 정도 고객들이 용인하는 상황에서는 고객들에게 전달되어도 상관 없을 수도 있습니다. 하지만 기획서에 언급된 모든 기능이 완전히 준비되기 전까지 기능이나 에셋을 전달하는 것은 올바르지 않습니다. 먼저 준비된 기능이나 에셋을 넘기면 작업 진행 상황을 실질적으로 노출하게 되어 작업 완료 시점을 종용받게 될 뿐 아니라 아직 문서 전체 범위에 대한 개발이 완료되지도 않은 상황에서 먼저 전달된 기능이나 에셋의 테스트 결과에 따라 또 다른 요구사항, 결함 따위가 미리 피드백 모양으로 넘어올 수 있습니다. 이는 개발 업무를 방해하고 전체 업무를 방해할 가능성이 높습니다. 그래서 요청 받은 기능의 전체, 혹은 에셋의 전체가 준비되기 전에는 전달하지 않아야 합니다. 또한 모든 작업 완료 및 전달 시점은 주 초반, 기왕이면 월요일인 편이 좋은데 완료 상태를 전달한 다음 돌아오는 피드백을 이어지는 주중에 대응해 빠르게 처리할 수 있기 때문입니다. 이 말은 곧 월요일이 아닌 날 작업이 완료되었다면 다음 월요일이 될 때까지 작업을 전달해서는 안된다는 말이기도 합니다. 가령 실무자 선에서 화요일에 작업이 완료되었다면 의도적으로 늦게 컨펌해 팀 내에서 목요일 정도에 작업이 완료되도록 만듭니다. 그리고 금요일에 굳이 전달해봐야 집중 받지도 못할 테니 주말이 지난 다음 월요일에 전달하는 식입니다. 이를 통해 전체 작업을 주 단위로 딜레이 시킬 수 있습니다.

작업 요청을 월 단위로만 받는 것도 좋은 방법입니다. 가령 프로젝트 전체에 걸쳐 에셋 제작 요청을 받는 부서가 있다고 가정해 봅시다. 여러 부서들로부터 산발적으로 들어오는 에셋 제작 요청을 제각각 대응하려면 부서 내에 관리 역량이 필요해집니다. 물론 관리자가 이 요청들을 중간에서 관리할 수 있지만 팀원들의 작업 현황을 관리하는 것도 만만찮은데 외부에서 온 작업들을 관리해 이를 팀에 분배하는 업무 전체를 떠맡을 필요도 없습니다. 이 대 사용할 수 있는 좋은 방법은 업무 요청을 한 달 단위로만 받는 것입니다. 한 달 동안 업무 요청을 받아 이를 한 번에 모아 다음 한 달 동안 진행해 월말에 전체를 한 번에 전달합니다. 또 그 사이에 받은 업무 요청을 그 다음 달에 진행해 전달하기를 반복합니다. 이는 팀에 들어오는 전체 업무량을 예측하고 통제할 수 있도록 해 주며 한 달 단위로 팀 스케줄을 관리할 수 있기 때문에 각 인원의 부재에 따른 퍼포먼스를 예측하고 관리할 필요를 현저히 줄여 줍니다. 이런 방법을 꼭 결과물을 제출할 때만 사용할 필요가 없습니다. 기획서에 피드백 할 때도 같은 요령을 사용할 수 있습니다. 여러 문서를 한 번에 검토해야 한다면 문서 각각의 검토 결과를 그때그때 전달하지 말고 전체 검토 결과를 한 번에 전달해 전달 시점을 늦출 수 있습니다. 문서 하나를 검토하면 바로 다음 날 피드백 할 수 있지만 문서 열 개를 검토한다면 최소 2주, 혹은 3주 후에 피드백 할 수 있습니다. 이렇게 한 번에 피드백 함에 따라 문서 전체에 걸친 요구사항을 더 깊이 이해하고 피드백 할 수 있는 장점이 있으며 피드백을 받는 입장에서도 전체를 조망하는 더 훌륭한 피드백을 받을 수 있는 장점이 있습니다. 여기에 앞서 설명한 월요일 이외에는 피드백 하지 않는 전략을 함께 사용하면 전체 업무 진행을 한 달 단위로 지연 시킬 수 있음을 명심하세요.

(4) 현재 재고가 거의 소진될 때까지 새 작업 자료를 주문하지 마세요. 주문이 조금만 지연되어도 가동이 중단될 수 있습니다. 이 항목은 제조 및 생산에 초점을 맞춰 작성된 것이 사실입니다. 이 문서가 작성된 시점은 최초의 진공관 방식 컴퓨터인 에니악이 나타난 시점과 비슷하다는 점을 감안하면 내근자들에 초점이 맞춰져 있지 않다 해도 이상하지 않습니다. 하지만 이 문장을 조금만 더 살펴보면 현대에 컴퓨터를 사용해 사무실에서 일하는 사람들에게 적용할 구석이 적지 않음을 알 수 있습니다. 엔터테인먼트 소프트웨어를 개발하는 과정은 여러 사람이 관여하는 길이가 긴 파이프라인이 동작하는 것에 비유할 수 있습니다. 맨 앞에서 누군가 요구사항을 작성하고 이를 바탕으로 다른 누군가가 코드를 작성하고 또 에셋을 제작하며 이를 다른 누군가가 받아 조립해 완성하고 이를 테스트 해 완료 선언을 하는 식으로 동작합니다. 프로젝트 초반에 비해 중반 이후에는 이미 구축해 놓은 기능들이 올바르게 유지보수된다는 전제 하에 전체 파이프라인이 동작해야 하는 요구사항은 서서히 감소하는 모습으로 나타납니다. 이런 파이프라인은 중간에서 누군가 작업을 지연 시키면 이후 전체 파이프라인에 문제를 일으킬 수 있다는 것을 의미합니다. 가령 파이프라인 상에 다음 사람은 이전 사람으로부터 작업이 완료되어 자신에게 도달해야만 작업을 시작할 수 있습니다. 가령 게임 상에서 마인크래프트처럼 여러 블록을 규칙에 맞게 쌓는 기능을 만든다고 해 봅시다. 블록은 종류에 따라 서로 다른 쌓는 규칙이 있고 블록의 외형은 블록 종류에 따라 서로 다릅니다. 실제 마인크래프트는 소수 인원이 이 모든 파이프라인 전체를 담당해 통제하는 방식으로 개발되었지만 이를 대규모 개발팀에서 여러 사람이 단일 파이프라인을 담당하는 방식으로 해석해 보면 누군가는 코드로 블록들이 쌓이는 규칙과 상호작용 하는 방법을 작성하고 또 다른 누군가는 블록 각각의 외형을 제작합니다. 그 다음 사람이 코드가 컴파일된 빌드와 에셋을 받아 이들을 조립해 플레이를 만들어 냅니다. 그런데 조립 담당자가 자신에게 도달할 코드와 에셋이 예상된 날짜에 도착하지 않을 수 있음을 눈치 챌 수 있습니다. 직접 관리 업무를 담당하지는 않지만 낌새를 보아하니 그럴 가능성이 높아 보입니다. 하지만 이를 절대로 미리 문제 삼지 말아야 합니다. 절대 미리 상황을 파악하고 문제 여부를 조사해 문제를 발견해 해결하지 않도록 주의합니다. 그냥 가만히 있다가 하루 이틀 정도 늦어지더라도 아무 행동도 하지 않으면 쉽게 이 기간 만큼 전체 일정을 책임 없이 딜레이 시킬 수 있습니다.

또 팀에서 필요한 신규 하드웨어를 의도적으로 늦게 요청하는 것도 좋은 방법입니다. 가령 새로운 스토리지 사용 정책에 따라 기존에 팀 전체에 지급된 스토리지가 두 배로 많이 필요하게 될 것임을 예상할 수 있을 겁니다. 개발에 영향이 없도록 하려면 최대한 빠른 시점에 새로운 스토리지를 주문해 스토리지 확장이 필요한 시점 이전에 팀 전체의 하드웨어가 미리 준비되어 있도록 하는 것입니다만, 의도적으로 주문 시점을 쉽게 지연 시킬 수 있습니다. 먼저 이미 회사는 각 사용자들에게 지급된 하드웨어를 완전히 파악하고 관리하고 있지만 이를 무시하고 사용자 개개인으로부터 스토리지 필요 여부를 취합합니다. 사실 회사는 우리들에게 말하지는 않지만 우리들이 사용하는 하드웨어를 강력하게 모니터링 하고 있습니다. 때문에 지급된 하드웨어 목록 뿐 아니라 스토리지 잔여량 역시 자동화된 모양으로 모니터링 하고 있을 가능성이 높지만 이는 주로 보안을 위한 것이므로 우리들이 사용할 필요도 없고 사용해서도 안됩니다. 때문에 개인 별 스토리지 필요 여부를 조사해 취합하도록 합니다. 가장 좋은 방법은 컨플루언스 페이지나 메일을 통해 취합하는 것인데 이 방법을 추천하는 이유는 비동기 방식의 의사소통 방식이기 때문입니다. 의도적으로 누군가 회신이 늦더라도 보채지 말고 그 사람이 회신할 때까지 한 주 이상 충분한 시간을 주도록 하세요. 만약 그 사람이 회신해야 한다는 사실을 잊어버렸다면 더 좋은 상황입니다. 책임 없이 전체 일정을 딜레이 시킬 수 있기 때문입니다. 또한 모든 사람으로부터 스토리지 필요 여부를 조사했더라도 앞서 설명한 월요일 제출 원칙에 따라 주말이 지난 다음 제출한다면 아무런 책임 없이 전체 일정을 조금이라도 더 늦출 수 있으며 여기에는 아무런 책임도 추긍되지 않을 겁니다.

(5) 구하기 어려운 고품질의 재료를 주문하세요. 만약 이 요청이 받아들여지지 않는다면 품질이 떨어지는 재료는 작업의 질을 떨어뜨릴 수 있음을 경고하세요. 이 역시 항목 (4)와 마찬가지로 언뜻 보면 제조와 생산에 초점을 맞춰 현대의 우리들에게 시사하는 바가 거의 없을 것처럼 느낄 수 있지만 실은 그렇지 않습니다. 생각해보세요. 기획팀에서 써 오는 기획서는 차마 눈 뜨고 봐 주기 어려운 수준입니다. 과거 요구사항을 문서화하는 역할은 전체 업무에 대한 이해도가 가장 높은 사람들이 담당했습니다. 이에 비해 현대 게임 개발팀에서 기획서를 작성하는 사람들은 주로 경험이 가장 부족한 신입에서 중니어 사이의 사람들인 경우가 많고 이들은 가장 기본적인 상식 조차 갖추지 못하고 있을 겁니다. 분명 이전에 거의 같은 기능을 다른 이름으로 개발한 적 있는 것 같지만 그들이 서로 이야기하지 않아 똑같은 요구사항을 마치 다른 기능인 것처럼 보내올 때가 있습니다. 이는 그들의 경험이 부족해 현 상태의 개발팀에는 그들이 작성한 요구사항에 해당하는 기능 정도는 이미 갖춰져 있거나 자신들이 플레이 하는 개발 빌드가 그 기능 없이는 이미 의도 대로 동작하지 않을 것임을 유추하는 능력이 떨어지기 때문입니다. 그들이 서로 이야기를 더 잘 한다고 해서 해결될 문제가 아닙니다. 그렇다면 이런 지점을 파고들 수 있습니다. 실제로는 주니어에서 중니어 사이의 스탭들이 작성한 문서 속에서 작업을 원활하게 해 주고 나아가 결함마저 줄여 주는 사려 깊이 작성된 좋은 문서는 구하기 어렵습니다. 그렇다면 그런 문서를 요청하세요. 마치 스텝 바이 스텝 매뉴얼처럼 매뉴얼에 드러나지 않는 숨겨진 항목이 없는 상태가 될 때까지 기획서를 보완하도록 요구하세요. 예측 가능한 부분이라도 함부로 예측하지 말고 원하는 부분이 추가될 때까지 기획서가 작업을 시작할 만한 수준에 도달하지 못했다는 피드백으로 돌려보내기를 반복하세요. 특히 이는 높은 분들이 사용하곤 하는 ‘내 마음을 맞춰봐’의 하위 호환 버전으로써 실행할 수 있습니다.

어느 시점에는 기획서의 불완전함에도 불구하고 작업에 착수할 수밖에 없는 시점이 올 겁니다. 그렇다면 저 문구대로 기획서가 불완전한 상태에서 작업을 시작해 작업의 품질이 떨어질 수밖에 없다는 사실을 경고하세요. 이미 전체 일정이 딜레이 된 가장 큰 원인은 기획서가 불완전하기 때문이라는 공감대가 널리 형성되어 있을 겁니다. 하지만 이것 만으로는 부족하기 때문에 상황에 쐐기를 박는 의미가 있습니다. 분명 이미 일정이 많이 딜레이 된 상태이기 때문에 불완전한 기획서의 모든 기능을 개발하거나 기획서에 언급된 모든 에셋을 제작하기 위한 시간은 부족해졌을 겁니다. 그렇다면 이러한 일정 부족을 이유로 결과물의 퀄리티를 떨어뜨리거나 결과물의 수량을 제한하는 식으로 협상할 여지도 있습니다. 결과물에 결함이 더 많이 발견되는 표면적인 이유는 짧은 일정 동안 급하게 진행했기 때문이고 일정이 짧은 이유는 기획서가 불완전하게 작성되었기 때문입니다. 이미 모든 책임은 불완전한 기획서를 작성한 담당자에게 가 있지만 좀 더 완벽하게 책임을 회피하고 싶다면 불완전한 기획서의 전체 요구사항들을 앞서 설명한 핵심적인 기능과 그렇지 않은 기능으로 구분해 우선순위를 설정하도록 종용하세요. 우선순위를 설정하는 동안 전체 일정을 딜레이 시킬 수 있고 우선순위를 평가하고 동의하거나 동의하지 않는 방식의 협상 동안 전체 일정을 딜레이 시킬 수 있을 뿐 아니라 이에 따라 확정된 높은 우선순위의 항목만을 결함이 많은 상태로 제출하더라도 아무런 책임을 추긍 받지 않을 겁니다. 항상 파이프라인의 앞단으로부터 고품질의 결과물을 요청하세요. 그리고 기억하세요. 파이프라인의 가장 앞에 있는 사람이 누구인지를요.

(6) 작업을 배정을 할 때는 항상 중요하지 않은 작업부터 배정하세요. 중요한 작업은 이를 수행하기에 가장 부적절한 작업자에게 배정되도록 합니다. 중간관리자는 사실 별다른 권한이 없는 것이 사실입니다. 관리자로써 책임은 있지만 사실상 권한은 없는 것이나 마찬가지입니다. 하지만 이런 중간관리자에게도 활용할 수 있는 작은 권한이 있는데 이는 바로 팀에 도착한 업무를 각 담당자에게 배정하는 것입니다. 별 것 아니라고 생각할 수 있지만 배정을 잘 하는 것 만으로도 팀의 사기, 생산성을 크게 좌우할 수 있습니다. 방금 완전히 새로운 팀을 맡게 된 것이 아니라면 팀의 구성원 별로 그들이 선호하는 업무와 선호하지 않는 업무를 어느 정도 파악하고 있을 겁니다. 가령 누군가는 스토리텔링에 가까운 업무를 선호하고 또 다른 누군가는 드로잉에 가까운 업무를 선호할 수 있습니다. 또 다른 누군가는 자신이 프로덕션 코드를 작성하는 사람이 아니면서도 좀 더 기술적이거나 설계에 가까운 업무를 선호하는 사람도 있습니다. 재미있는 점은 이들이 좋아하는 업무가 있다면 이들이 싫어하는 업무 역시 반드시 존재한다는 점입니다. 조직의 위계 상 이들은 싫어하는 업무를 직접적으로 말하지 않는 경우가 많습니다만 이들이 선호하는 업무로부터 어렵지 않게 추측할 수 있습니다. 일단 각자의 선호 및 비선호 업무를 알고 있다면 중요한 작업을 가장 부적절한 작업자에게 배정하기는 쉽습니다. 다만 작업자가 자신의 업무 배정에 문제를 제기하지 못하도록 하기 위해 중요하지 않은 작업들을 먼저 배정해 맨 나중에 자신에게 할당된 자신이 수행하기에는 그리 적절하지 않은 중요한 작업을 다른 사람에게 미루거나 다른 사람의 작업과 바꿀 수 없는 상태를 만들어야 합니다. 앞서 같은 작업 내에서도 핵심에 가까운 기능과 그렇지 않은 기능이 있다고 했는데 팀에 도착하는 업무 역시 그렇습니다. 고위 의사결정자들의 관심을 끄는 중요 기능이 있는가 하면 그렇지 않은 기능도 있습니다. 그렇다면 이들의 관심을 끌지 않는 기능을 올바르거나 대략 중립 정도인 사람들에게 할당한 다음 이들이 업무를 시작하게 두세요. 일단 업무를 시작하고 시간이 조금 지나야 업무를 재할당하기 어려운 상태가 되기 때문입니다. 그리고 거의 마지막으로 중요한 업무를 이 일을 맡기에 가장 부적절한 사람에게 어쩔 수 없이 이번 한 번만 양해해 달라는 느낌으로 할당합니다. 작업은 문제 없이 수행 될 겁니다. 결과의 퀄리티와 이를 수행한 사람의 사기를 고려하지 않는다면요.

이 챕터는 총 (14) 까지 있고 우리는 지금까지 항목 (6) 까지 다뤘습니다. 사실 이 모든 항목의 핵심 맥락은 대체로 비슷하기 때문에 어떤 항목이나 설명은 중복된다고 느낄 수 있습니다. 지난 심플 사보타지 - 조직과 회의 (1), 심플 사보타지 - 조직과 회의 (2)에서는 제목 그대로 ‘조직’, ‘회의’를 사보타지 하는 방법을 설펴봤고 이번에는 ‘관리자’ 및 ‘감독관’ 관점에서 실행할 수 있는 사보타지 방법이라는 점이 서로 다르다는 것을 유념해야 합니다. 이번에는 크게 의사소통을 서면으로만 수행하고 그 서면에 높은 품질을 요구하며 의도적으로 결과를 더 늦은, 그러면서도 자연스러운 시점에 제출하고 또 필요 없는 취합 과정을 기다리면서도 책임을 회피하는 방법들을 살펴봤습니다. 이런 방법들의 무서운 점은 이런 행동들은 프로젝트나 회사 차원에서 문제로 지목될 가능성이 매우 낮다는 점입니다. 그럼 다음에는 오늘 다루지 않은 ‘관리자 및 감독관’ 챕터의 나머지 항목을 살펴보겠습니다.