|
Anders Abel是生活在瑞典斯德哥尔摩的一位软件开发者，他在自己的网站上撰写了一系列文章，箭头直指“项目破坏者”。 该系列的第一篇是《项目破坏者手册》，他在其中列出了自己在多个项目中遇到的破坏项目的方式。 首先，他指出了破坏一个项目的关键成功因素：
接下来，他提供了一些让项目失败的策略。 关注边界问题 项目中有很多处于最高优先级的关键因素，优先级低一个等级的是重要的问题，然后是大量的相关问题。很多项目没有足够时间去应对所有相关问题。 破坏者应该关注的是下一个层级：最细微的边界问题，这些问题通常被忽略，但不能轻易作为相关问题排除掉。类似问题比如：
这些问题特别有效，能达成两个目的。首先：解决这些问题，项目中的技术专家需要付出时间和精力，因为这些问题没有正确的答复很难忽略。其次：管理层会认为项目破坏者有很好的技术知识，能够提出技术专家无法回答的问题。关键是：提出这些问题不需要精深的技术水平，只是看起来如此。 提出不理解答案的问题 提出确实需要答案的问题，但是你不具备理解这个答案的知识，这会让所有人都感到不平衡。问问为什么HTTPS会话可以保证信息安全，虽然它的算法人所共知。从数学角度解释加密算法很复杂。只要提到算法背后的数学问题，那就要他们给出一个非数学的解释。如果项目中有人知道如何从数学角度解答问题，这就会让他们疯掉，因为要简化这些答案，同时又不失重点，难上加难。 不写文档 文档是对破坏的第一号威胁。尽量让文档越少越好。几个月前的官方会议准确记录会扼杀很多“创造力”【译注：这里指破坏项目的创造力】。没有文档，就很容易歪曲真相，从而怪罪其他人。防止产出优秀文档的最简单方式，就是主动要求做会议记录，然后无视任务部分（参见下面的无视任务）。如果你主动说要发送记录，就没人会再去做详细记录了，也就不会留下文字记录。 避免清晰的决策 与文档一样，清晰的决策对破坏者也是威胁。讨论要稀里糊涂，没人知道有哪些决议，应该做些什么，这样最好。技术人员的工作效率会迅速降低，同时也能为破坏项目的创造力提供更大空间。 无视分配给你的任务 破坏者所能做的最好的事情，就是无视所有任务。不仅如此，还要无视与任务相关的问题。坚决否认存在与任务相关的任何知识。如果没有文档说明分配给你的任务，很可能你就不用完成它了。要调动一切说服力，证明你从不知道这个任务。除非是最强硬的主管，所有人都会质疑：这些任务怎么会应该是你负责？ 把焦点放在别人的少数缺点上 有时，会有人发现你几乎没做什么事情，而且试图怪罪于你。要无视证明你自己没有干活的明显证据，最好的防守，就是把焦点放在那个人的缺点上，包括他工作中的任何一点小问题。问题越小，那个人的野心越大，那么指出他的问题，对他造成的伤害也就越大。当你的对手开始给自己辩护时，大家的关注点很快就不再是你的失败。 没有纲领或条理的会议 高效会议的关键是按照大纲开展有条理的讨论。尽量避免大纲。如果一个讨论行将结束，这就标志着要有决议了。这次，你应该迅速将讨论从当前问题上转移开，避免清晰结论。具备正确的技巧，能让同一个问题在多次会议中反复讨论，而不会得出任何决议或结论。对于有价值的项目时间来说，这是绝佳的黑洞。 在评论中，Pia F?k Sunnanbo引用了CIA现在已解密的“敌方区域破坏简单指南”：
他指出：任何参与过大型项目的人，肯定都见过其中大多数条目成为现实。 Johan Svard在评论中提到：
您在自己的项目中遇到过哪些破坏者，他们有哪些破坏行为？欢迎留言。 |
|
|
