BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

项目破坏者伎俩大观

| 作者 郑柯 关注 3 他的粉丝 发布于 2013年2月9日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

说的太对了 by DAN LEE

有一个项目的甲方二把手就是这么干的,他成功的使得该项目拖期整整2年!

Re: 说的太对了 by shi mike

其实原因很简单,就是那个人其实不懂开发,所以只能整些虚的,反正就是不能显得自己无能。这样的人,总会遇到一些。

Re: 说的太对了 by DAN LEE

我记得那个人好像是刚刚参加了一个国内的什么管理培训班,马上就把班上的那一套拿过来了,对我们乙方的要求永无止境,所有的东西都要验证文档、神马测试数据,关注的全是边界问题,一到核心问题就东拉西扯,最后光是工作说明书就来来回回的墨迹了四个多月,气死我了。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT