项目破坏者伎俩大观

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. 不考虑项目的范围和边界,如果这一点做得好,项目就可以无休止地拖延下去……

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

郑柯 郑柯,实用的理想主义者,相信:每天改变一点点,这个世界会更好。

This entry was posted in Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s