“项目破坏者” 手册

42顶
2踩

2013-01-18 16:15 by 副主编 wangguo 评论(30) 有19599人浏览

项目管理开发

要想将一个开发项目搞砸，有很多种方法。开发者Anders Abel将他经历过的项目中的破坏者的轶事整理成了一个手册，如果你想搞砸你们公司正在做某些软件项目，完全可以借鉴这个手册中的方法。（项目管理者不必担心，我后续会写一篇文章来讲述如何应对这些招数。更新：《反制“项目破坏者”》手册）

成功破坏一个项目的关键是要从对项目最重要的地方下手，将开发者的注意力从最重要的工作上转移走，并耗尽开发者的精力。用你的想象力和创造力，不要放过任何机会，将项目一步一步拉向失败的边缘。

下面介绍一些主要战略，一定要认真领会、学习。

1. 专注于边缘问题，以证明你知识渊博

在一个项目中，都有几个关键的、能够促使项目成功的因素，它们拥有最高的优先级。其次是一些重要的问题和一些相关的问题。大多数项目都没有足够的时间来顾及所有的优先级。

作为一个“知识渊博”的破坏者，你应该关注别人往往不太关注的地方——最边缘的问题，但同时不要忽视这些边缘问题相关的一些问题，比如，你可以质问其他开发者：

你能保证不存在兼容性问题？微软刚刚发布了一个操作系统补丁KB12345。（了解系统补丁对软件的影响需要大量的时间，拿出证据需要更多的时间）
如果用户在姓氏字段中输入数字，会发生什么情况？
在下一代IE、Windows……发布时，我们需要做哪些改变？

此类问题相当有效，可以很容易地将其他开发者的注意力转移走。这需要破坏者有一定的水平，来问一些技术专家难以回答的问题，最好的方式是不要问技术深入的问题，而是问一些没有合适答案的问题，这样就不会被轻松驳回了。

2. 问一些你不理解答案的问题，并坚持弄懂

比如，一个问题已经有了答案，但是由于你缺乏必要的知识，而不能理解。比如，HTTPS会话安全是如何实现的（这个算法大名鼎鼎）。关于数学方面的加密算法相当复杂，只要提及算法的数学原理，再问一些简单的非数学方面的问题，这有可能会将你问的人逼疯的。

3. 拒绝文档或会议记录

文档是你的首要破坏目标，尽可能少地写文档。一份几个月前的正式会议的记录，有可能扼杀很多创意。尽可能地不要文档，且歪曲事实，把责任推给别人。防止产生高质量会议记录的最好的方法是，主要要求做会议记录，然后忽略一些方面（如何忽略见下文）。

4. 避免明确的决定

一个明确的决议，可以对破坏者的行为产生很大的阻力。最好方式是，当某些人明确说出应该如何做时，你开始含糊讨论。如果没有明确的的决定，开发者的生产力将急剧下降。

5. 忽略分配给你的任务

最好的破坏者应该忽略所有分配到的任务，同时也忽略掉任何相关的问题。如果分配任务时没有任何文档记录，那么这将是一个很大的机会，比如，你可以说你从来没有听说过这些任务。

6. 专注于其他人的缺点

如果你以上的行为被发现了，在项目中你将很难办。此时，你需要进行防守，最好的方式就是把重点放在其他人的很小的一个缺点上。没有缺点？不可能，你总会找到一些的。一个人的缺点越少，他的完美主义情结就越大，如果你指出他的缺点，他将更痛苦。那么，问题的焦点会很快从你身上转移走。

7. 没有议程或结构的会议

富有成效的会议的关键是围绕一个议程进行结构化的讨论。你需要做的是，避免议程。如果一个讨论接近尾声，这通常意味着马上要做决定了，这种情况下，你应该快速转移讨论的问题，避免做出明确的决定。然后，在每次会议中故技重施，这对于时间宝贵的项目来说，是非常致命的。

8. 消耗能量

请记住，成功地破坏一个项目最关键因素是在项目最重要的点上转移开发者的注意力，并消耗开发者的能量。你可以使用各种方式来做这些事情。

无论如何，这是一场艰难的战斗！向你“致敬”！

英文原文：The Project Saboteur’s Handbook

查看图片附件

分享到：

42
顶

2
踩

评论共 30 条请登录后发表评论

30 楼 dwangel 2013-03-24 16:02

9esuLuciano 写道

就只第一条看，本文作者是一个典型的只要功能实现，其他管我蛋事的，鼠目寸光的开发人员。

其实第一条描述的是实际问题。但是，描述的并不准确。
我也是突然想到的。

边界条件属于哪个级别很重要。实际上，分为系统级边界条件和模块级边界条件。一般来说，系统边界条件范围小于等于模块级边界条件范围，系统就可以正常运作。

因此，第一条实际上说的是在讨论模块级边界条件时，无限扩展，而忽视系统级边界条件，而导致花了更多无效的工作时间和精力。

而系统级边界条件，是由需求分析和系统架构工作共同决定的，在模块级别不应该花太多时间。

29 楼 liangtu33 2013-02-21 17:37

这是心里学的知识。

28 楼 laolik 2013-02-20 14:47

一针见血。。。

27 楼梦幻小子 2013-02-17 15:59

太厉害了我的领导就是这么一个人

26 楼 xingkongxieyang 2013-02-06 10:25

为什么呢？？？？？？

25 楼 wangguo 2013-01-29 16:57

ayaga 写道

我也写了一篇《土鳖反制“项目破坏者”》手册
http://ayaga.iteye.com/blog/1779173

24 楼 ayaga 2013-01-29 15:56

我也写了一篇《土鳖反制“项目破坏者”》手册
http://ayaga.iteye.com/blog/1779173

23 楼 hq2999 2013-01-23 15:51

我特讨厌人数超多的团队，有时我倒希望项目只有我一人在做

22 楼 inta 2013-01-23 14:02

9esuLuciano 写道

就只第一条看，本文作者是一个典型的只要功能实现，其他管我蛋事的，鼠目寸光的开发人员。

不能看完，听完别人的话，这足以说明你听风就是雨，自我、自闭

21 楼 coffeesweet 2013-01-23 09:27

期待下一篇解决方案。。。

20 楼 9esuLuciano 2013-01-22 22:50

就只第一条看，本文作者是一个典型的只要功能实现，其他管我蛋事的，鼠目寸光的开发人员。

19 楼 dingran 2013-01-22 14:25

songjudong 写道

这个话题非常的有意思。我前一个项目开了很多恶心的会议。
会议的最终目的不是解决问题。如果某个人提出一个解决方案。另外几个家伙会用各种不重要而又复杂的细节跟你讨论一天。最后会综合出一个无比扯蛋的玩意。

你们真是太幸福了，哈哈，要是我们公司，早就被老总踢了。

18 楼 damoqiongqiu 2013-01-22 12:38

啦登2010 写道

学习。。。

同学

17 楼 ycyangcai 2013-01-22 10:11

现在项目正是有这些人，该昨办！

16 楼风的足迹 2013-01-22 09:51

看了以后发现确实存在这些现象，不过有些人可能不是蓄意要达到破坏的目的，有可能是无知或无能，也有可能是不想担负责任

15 楼 brucewei777 2013-01-21 16:27

我得说我身边有这样的人，但是并不是一无是处，我个人觉得把这样的角色放到对外上面，比如对抗铺天盖地的需求，效果非常好。

14 楼 brucejia 2013-01-21 11:15

按照这个标准，我们很容易把那些无知或者狡猾的人揪出来

13 楼 brucejia 2013-01-21 11:10

哈哈，一针见血

12 楼 diggywang 2013-01-21 10:35

每个项目里，或多或少都有这样的人存在

11 楼 eisenwolf 2013-01-21 10:07

这个太牛了，作者很幽默

发表评论

您还没有登录,请您登录后再发表评论

42顶2踩