Anders Abel是生活在瑞典斯德哥尔摩的一位软件开发者,他在自己的网站上撰写了一系列文章,箭头直指“项目破坏者”。 该系列的第三篇是《项目破坏者反制手册》,指出对付项目破坏者的一些方法。
在开头Anders指出:
尽早识别、应对项目破坏者,以有效地反制他们,这是任何大型项目成功的关键,因为在某个地方总会有项目破坏者
他认为“了解敌人”很重要:
如果想成功反制任何破坏项目的企图,你需要了解你的敌人。你必须知道想要反制什么样的行为。如果能找到破坏的动机,效果更佳。一般来说,除非发现破坏的根源,很难让项目免遭破坏。如果是这样,最好先开始反抗破坏行为,观察破坏者的反应,找出这个人到底是谁。
Anders接下来列举了6种反制方法:
他提到:
即使项目中没有破坏者,采纳这些习惯应该也是对项目有好处的。
对付破坏者的第一号武器,就是文档。要一直记录笔记(即使有人作正式会议记录,自己也要把重要决策记录下来)。项目开始时,无法知道谁最终会成为破坏者,从好的文档记录开始,这有助于识别出破坏者。
保证创建清晰的行动列表,每点对应一个负责人,还要有完成截止时间。会议记录中,所有决策都应该有对应行动,确保决策得以实施。行动非常重要,因为它们易于跟进。下一次会议上,每个人汇报自己进度时,就可以把行动列表中勾掉。
破坏者的第一个标志,通常是拖延完成分配的任务,不只是错过一个截止时间,而是多个。识别出破坏者之后,跟踪文档对于管理人员来说就是无价之宝。
保证会议有明确的议程,并且提前发放。确保做出合适的决策,并写在会议记录中。破坏者意图让决策模糊不明,或是绑架整个会议,不讨论重要问题。好的议程和强有力的主持人能确保讨论正确的事情,并做出决策。
在某些时候,没有选择,只能冲突。真到那时候,不要犹豫。尽早展开冲突是最容易的。冲突酝酿时间越长,当它最终爆发时破坏力越大。
有些冲突无关紧要。如果破坏者的某些行为对项目没有重大影响,也许随它去是最好的办法。赢得每场战役,也许不是赢得整个战争的最好策略。
Anders在与别人讨论“项目破坏者”系列前两个帖子时,常听有人说:谦虚的问题会起到帮助。
—— 如果用户在“姓”这一栏中输入数字怎么办?破坏者会问
—— 也许我比较笨,但相对于人们在名字中出现打字错误来说,这个问题还算问题吗?
Anders认为:这种回答回应会让大多数不是破坏者的人开动脑筋,然后他们会觉得难为情。
(接上文)
—— 也许不会。
—— 避免用户在自己的名字出现打字错误是很难的,我们能否先跳过它,相信用户的水平?
—— 是,你是对的。咱们继续。
一个谦逊的问题让另一个人思考,然后撤回建议。但如果这是一个真正的项目破坏者,后面发展就不是这样了。
(接前文) —— 我们必须保护系统没有任何错误输入。数字不应该在姓中出现。
—— 数字算是一种输入错误么?其他输入错误更常见不是?
—— 数字在姓中出现就是不对的,我们必须检查。
—— 如果其他输入错误还不能检测,花费时间识别数字,值得吗?
—— 只检查数字应该不难。
—— 确实不难,但实现总要花时间。
—— 这应该是个标准检查项,互联网上应该可以找到一些标准代码。你必须学会搜索互联网,寻找现成的解决方案,实在不行再自己去实现。我觉得这是常识吧,你得多长进啊。
这个结果就不怎么样。谦虚的问题变成了破坏者建立这样一个(当然是错误的)事实的机会:你在自己写代码前,竟然没有去搜索互联网……这时候,就需要一个冲突了。不是说说服破坏者不可能,但是要确保其他在场的人不受破坏者错误事实的影响,这个事实是建立在他们自己所谓真相基础上的。
如果破坏者不像前一个例子中那样总想挑事儿,把破坏者加入到项目里,有时候是个好策略。如果破坏者感到不安全,担心被项目推到一边,这可能是个好策略。没人喜欢被搁置一旁、被无视,有不安全感的人更是如此。
在讲述完这六个策略后,Anders指出:权力很重要。
无论破坏者的策略和类型有哪些,归根结底,有一样东西永远重要:权力。如果破坏者没有权力,那他只不过是小打小闹,构不成问题。要是他有某些权力,而且与破坏方法结合起来,那就是问题了。如果你的权力足以反制他,可能有时候就得采取某些(甚至是丑陋的)方法来展示你的权力。
如果你自己的权力不足以应对破坏者,那么重要的是:你要确定自己组织内有人给你撑腰。假如你参与了知道如何胜出的冲突,在你让大家都看清楚破坏者要做什么之前,要是破坏者让一个经理介入,那么一切都可能功亏一篑。到那时,你就输定了。破坏者现在让人觉得你是个制造麻烦的人,他还得以脱身,而且破坏还在进行中。
最后,Anders的总结是:
反制破坏很难。
如果想了解项目破坏者的伎俩和分类,请点击如下链接:
InfoQ的读者们,你们有什么反制破坏者的经验吗?请在留言中分享。