从许多管理类书籍中看到过关于“猴子”的比喻，无意中从再别康桥的微信中看到他晒出的一份书单，大部分我也读过了，只有《别让猴子跳回背上》这本没有认真看过。本来想看该书的英文版，可惜没有搜到，只能看中文版了。
在我以前的理解看来，猴子就是管理者扔给你的任务和项目，把猴子扔给你的上级或下属，相当于GTD中的委派，但读完此书后，发现这种理解并不完全正确。这本书说是写给管理者的，对于技术类人员不太适用，但遇到一些杂事时，也可以应用里面谈到的技巧，把猴子甩到上级或下属的背上，每每看到这里，总有一种罪恶感。原来工作事务，完全转变为一场猴子战争。
书中的“猴子”指的是双方谈话结束后的下一个步骤。猴子不是问题、项目、计划或机会；猴子只是解决问题、开展项目的下一个行动步骤（与GTD中的Next Action完全一致）。
有些下属关于把猴子扔到你背上，当你从下属身上接下责任，会发生两件事。第一，你让员工来监督你，你成为了项目的瓶颈。第二，你让他们不必做自己份内的工作。请记住，帮你的部属做事不是你职责所在。
书中提到了一个安肯自由量表，谈到了下属可运用的五个任务层级：
（5）独立行动，例行性报告（最高层级）
（4）行动，但须立即请示（意味着报告频率超过例行性报告）
（3）建议，等待裁示再行动
（2）请示要做什么
（1）等待指示（最低层级）
当下属处于（1）和（2）的任务层级时，实际上他已经成功地把猴子扔给了老板。如果老板全被下属的时间所占据，说明他处于一种逆向管理状态，这时员工游手好闲，而老板忙得焦头烂额、团团乱转。最糟糕的外行管理者是整天接受下属的猴子，被下属的时间占据；第二糟糕的业余管理者，是多产的猴子分配者，这种管理员每天会丢出去一千只猴子，连他自己也搞不清楚要干什么。
管理者的贡献来自于他们的判断力与影响力，而非他们所投入的个人时间与埋头苦干。如果一个人既有管理角色，又有技术角色，该怎么办？
书中最后指出了减少猴子在身的六条规则：
规则1：喂养它们，或射杀它们：千万不要让它们活活饿死。
像是GTD中的第二步“明确意义”，到底需不需要做这件事？如果对用户、对自己、对将来都没有用，就杀死它。
规则2：只要你找到需要喂养的猴子，你的部属就得找出时间喂食它们，但千万不要过量。
不要每天往下属身上扔一堆猴子。
规则3：按照喂食进度表上的时间和地点喂养猴子是部属的责任，主管不必再沿途追逐即将饿死的猴子，胡乱地喂食。
高层管理者不应该未通知直接下属，直接对更底层的下属发号施令（明显的例外是，攸关生死的情况），这项原则一旦遭到破坏，便会导致所谓的越级监督，混淆了任务的优先次序，让接到指示的下属费力不讨好。
规则4：如果有冲突发生，预定喂食猴子的时间可在任何一方的提议下，做出变更，但不被视为延误，事情毫无进展不能作为重新安排喂食时间的借口。
约定的时间可以协商变更，没有进展也要报告。为了汇报，总要弄出点进展来的。
规则5：无论何时，应尽可能面对面地喂食猴子，否则便使用电话，绝对不要用信件。备忘录、电子邮件、传真和报告可以使用于喂食过程，但不能替代面对面的对话。
你不该说：“寄给我一份会议记录。”你应该说：“把记录拿来给我看。”
下属真正想说的话根本不会出现在那份文字记录里，它暗藏在字里行间。
至于面对面的对话也会出现一个问题：如果对话结束，下一个具体的步骤显然属于你时，你要如何往下进展？
带着你的部属一起进行。通常这是一种很好的管理做法，这么做，猴子将不会乱窜。
规则6：超过好几页的备忘录，电子邮件、传真和报告应该在一页的摘要中写清楚，以便展开立即的对话。
长篇大论的报告一定要附上一份简短的摘要，以说明里面的内容。
本文转自申龙斌的程序人生博客园博文，原文链接：http://www.cnblogs.com/speeding/p/4472204.html，如需转载请自行联系原作者
http://www.cnblogs.com/speeding/
