项目破坏者伎俩大观

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在评论中提到：

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

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

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

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

4. 有意曲解所有的问题和工作任务中的文字。然后向错误的方向尽量多做工作。这种行为可以掩饰为“学习”，可以造成潜在的长期破坏……

5. 个人最爱：尽量以彼此隔离的方式完成任务，不许有大局观的想法，不去思考用户如何理解、接受工作成果，或者不去考虑其他任务如何与这个任务延续。

6. 不考虑项目的范围和边界，如果这一点做得好，项目就可以无休止地拖延下去……

您在自己的项目中遇到过哪些破坏者，他们有哪些破坏行为？欢迎留言。

相关厂商内容

12306插件引发GitHub故障，GitHub资深运维工程师确认参加QCon北京2013，现身说法

《程序员必知97件事》合著者Kevlin确认参加QCon北京2013并发表主题演讲

阿里巴巴大数据专家鬼厉将在2013北京QCon分享淘宝云梯Hadoop最佳实践

相关赞助商

您可能也会喜欢