“项目破坏者” 手册

jopen 11年前

英文原文: The Project Saboteur’s Handbook

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

“项目破坏者” 手册

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

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

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

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

“项目破坏者” 手册

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

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

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

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

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

        3.   拒绝文档或会议记录 

“项目破坏者” 手册

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

        4.   避免明确的决定 

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

        5.   忽略分配给你的任务 

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

        6.   专注于其他人的缺点 

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

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

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

        8.   消耗能量 

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

来自: www.iteye.com