如何破坏一个项目:项目破坏者伎俩大观

　　Anders Abel是生活在瑞典斯德哥尔摩的一位软件开发者，他在自己的网站上撰写了一系列文章，箭头直指“项目破坏者”。

　　该系列的第一篇是《项目破坏者手册》，他在其中列出了自己在多个项目中遇到的破坏项目的方式。

　　首先，他指出了破坏一个项目的关键成功因素：

　　有些领域对于项目成功至关重要，要把人们的注意力从这些领域吸引开，而且要耗尽在这些方面投入的精力，任何能够达到这些目的的行为都是允许的。使用你的想象力和创意，确保你永远不会放过任何一个让项目一步步接近失败的机会。

　　接下来，他提供了一些让项目失败的策略。

　　关注边界问题

　　项目中有很多处于最高优先级的关键因素，优先级低一个等级的是重要的问题，然后是大量的相关问题。很多项目没有足够时间去应对所有相关问题。

　　破坏者应该关注的是下一个层级：最细微的边界问题，这些问题通常被忽略，但不能轻易作为相关问题排除掉。类似问题比如：

　　你能证明操作系统厂商刚刚发布的KB12345补丁没有兼容性问题吗?(要啃完操作系统补丁的发布说明得花大量时间，提供证明耗费的时间更多。)

　　如果用户在“姓”字段里面输入数字怎么办?

　　对于下一个版本的IE/Windows/其它什么，必须要做出哪些变更?(挑任何一个目前只提供有限可用信息的RC版本的软件吧)

　　这些问题特别有效，能达成两个目的。首先：解决这些问题，项目中的技术专家需要付出时间和精力，因为这些问题没有正确的答复很难忽略。其次：管理层会认为项目破坏者有很好的技术知识，能够提出技术专家无法回答的问题。关键是：提出这些问题不需要精深的技术水平，只是看起来如此。

　　提出不理解答案的问题

　　提出确实需要答案的问题，但是你不具备理解这个答案的知识，这会让所有人都感到不平衡。问问为什么HTTPS会话可以保证信息安全，虽然它的算法人所共知。从数学角度解释加密算法很复杂。只要提到算法背后的数学问题，那就要他们给出一个非数学的解释。如果项目中有人知道如何从数学角度解答问题，这就会让他们疯掉，因为要简化这些答案，同时又不失重点，难上加难。

　　不写文档

　　文档是对破坏的第一号威胁。尽量让文档越少越好。几个月前的官方会议准确记录会扼杀很多“创造力”【译注：这里指破坏项目的创造力】。没有文档，就很容易歪曲真相，从而怪罪其他人。防止产出优秀文档的最简单方式，就是主动要求做会议记录，然后无视任务部分(参见下面的无视任务)。如果你主动说要发送记录，就没人会再去做详细记录了，也就不会留下文字记录。

　　避免清晰的决策

　　与文档一样，清晰的决策对破坏者也是威胁。讨论要稀里糊涂，没人知道有哪些决议，应该做些什么，这样最好。技术人员的工作效率会迅速降低，同时也能为破坏项目的创造力提供更大空间。

　　无视分配给你的任务

　　破坏者所能做的最好的事情，就是无视所有任务。不仅如此，还要无视与任务相关的问题。坚决否认存在与任务相关的任何知识。如果没有文档说明分配给你的任务，很可能你就不用完成它了。要调动一切说服力，证明你从不知道这个任务。除非是最强硬的主管，所有人都会质疑：这些任务怎么会应该是你负责?

　　把焦点放在别人的少数缺点上

　　有时，会有人发现你几乎没做什么事情，而且试图怪罪于你。要无视证明你自己没有干活的明显证据，最好的防守，就是把焦点放在那个人的缺点上，包括他工作中的任何一点小问题。问题越小，那个人的野心越大，那么指出他的问题，对他造成的伤害也就越大。当你的对手开始给自己辩护时，大家的关注点很快就不再是你的失败。

　　没有纲领或条理的会议

　　高效会议的关键是按照大纲开展有条理的讨论。尽量避免大纲。如果一个讨论行将结束，这就标志着要有决议了。这次，你应该迅速将讨论从当前问题上转移开，避免清晰结论。具备正确的技巧，能让同一个问题在多次会议中反复讨论，而不会得出任何决议或结论。对于有价值的项目时间来说，这是绝佳的黑洞。

　　在评论中，Pia Fåk Sunnanbo引用了CIA现在已解密的“敌方区域破坏简单指南”：

　　下面这些东西破坏者用起来可能很方便：

　　(11) 组织或产品通用干扰指南

　　(a) 关于组织和会议

　　(1) 坚持一切事情都要通过“管道”完成。绝不允许为了加快决策采取任何捷径。

　　(2) 发表“演讲”，尽量多发言，长时间发言。使用冗长的轶事和个人经历说明你的“观点”，在做出一些“忠心爱国”的评论时，绝不犹豫。

　　(3) 尽可能让所有的事情都提交委员会讨论，以“进一步调查和研究”。要试着让委员会人越多越好，绝不要少于5个人。

　　(4) 尽可能多说不重要的问题。

　　(5) 斤斤计较通信、记录和决议中的精确用词。

　　(6) 再次讨论上次会议决定的事情，并尽量重新讨论当时的决议是否恰当

　　(7) 倡导“小心”。要“理智”，督促你的与会者要“理智”，别急着动手，避免以后造成尴尬局面或是困难。

　　(8) 担心任何决议的所有权，提出问题，指出计划的行动是否属于当前这群人的管辖范围之内，或者它是否与高层的某些政策冲突。

　　他指出：任何参与过大型项目的人，肯定都见过其中大多数条目成为现实。

　　Johan Svard在评论中提到：

　　我想你忘记了软件开发人员。我们也很善于这样的游戏：

　　反复声明：你已经完成了 直到有人推动。 这会让人与人之间充满不信任，而且，你将最终有机会假装成为错误对待的受害者。“为什么你总要问我?这是骚扰!”此言可让最好的会议陷入僵局……

　　选择Sprint、项目或是其他工作中的核心任务，然后丢在那里一两周。再交出来，还要说：“我不知道怎么做。”

　　让团队中资历最浅的人做最复杂的工作，还要掩饰以好意：“这对他发展有好处。”对项目可不是这样……

原文转自：http://www.infoq.com/cn/news/2013/02/ways-of-project-saboteurs