不论是文档作者还是评审人员、下游人员都应当防止以技术为导向,避免为了学习新技术而不管软件系统需求是否需要这些技术,也不考虑这些新技术有多大风险。
3.注意各种心理问题
在心理上最常见的是面子问题,被评审人员把他人对文档的意见认为是个人批判而紧张拘谨,这是人之常情。而造成的双方急于辩护,敌视或对抗在心理学上称为“知觉防御”,即对不利于自己的信息回避并否定。
另一问题就是评审人员做好好先生。也可能是能力不足,不提问题,只会附和。亚里士多德说:“我们很容易回避批评——不说什么、不做什么、不存在什么”。知错而不发言是道德问题。
各方应该针对工作成果中的问题,而不是针对作者,互相尊重,以减少双方挫折感。
戴明14点之一:“驱除恐惧,所有同事必须能大胆发言,提出问题或表达意见”。
Cosgrove说:“不愿意为设计书写文档的原因,不仅仅是由于惰性或者时间压力;相反,设计人员通常不愿意提交尝试性的设计决策,再为它们辩解”。通过设计文档化,设计人员将自己暴露在每个人的批评之下,他必须能够为其书写的一切进行辩护。如果团队架构因此受到任何形式的威胁,则没有任何东西会被文档化(引自《人月神话》)。
不知道这些大师有没有夸大这种现象。
程序员既不愿写文档,也不善言谈。在软件工程学术上基于不同的假设出现了不同的软件开发过程模型,主要分为轻量级和重量级。因为项目成员不愿意写文档,所以有轻量级过程强调项目团队成员之间、项目团队与用户之间的充分随时的沟通;因为项目成员不善言谈,所以有重量级过程,强调“把要做的事情写出来,按写的去做,把做的事情记录下来”。这有点像管理学中的X理论和Y理论,似乎是分别基于性恶说和性善说的假设。
注意“金鱼缸效应”,一些新建的办公系统软件为什么受到抵制?在各种“金”字头的的工程建设中,政府部门为了有效了解各类业务的办理情况,提高业务透明度,开发了相应的办公系统软件,然而使用初期这些办公系统却在基层使用单位受到了冷遇。因为透明度提高了,一些工作疏忽或作弊很容易被发现,统计数字也真实了,难以“随心所欲”。这就是金鱼缸效应:“人人都喜欢把鱼放在金鱼缸,但人人都不愿意做里面的金鱼”。
Jesse Liberty在《Clouds to Codes》中说:“程序员认为他们是周围人群中最聪明的”,这里的程序员实际上泛指软件开发人员。因此不论是评审人员,还是被评审人员,都应该秉持谦虚、谨慎、尊重、感恩,以及协商的学习态度,避免过于自负、情绪化或有伤害的言辞。评审过程中要心态客观,眼光专业,对事不对人,重在讲道理。各方都应当把评审工作作为帮助,而不是批评。评审会议主持人要及时地限制各方的不良态度,但不限制评审人员有根据地指出问题,也不限制对方对问题进行解释。
在软件开发项目中既要考虑管理、风格、设计等各方面的一致性,又要考虑独特性;既要考虑使各项工作具有规范性,又要保护项目团队成员的创造性;既要讲究原则性,又要讲究灵活性;既要讲究管理上的可控性,又要保护员工的积极性。而质量管理、项目管理工作应该做到以上4个方面的平衡。
4.注意信任的副作用
同事之间相互信任是人类的本性,也是人类交互中的不可缺少的部分。诺曼先生在《情感化设计》中提醒:盲目的信任造成错误。
人数多时产生的盲目信任,当更多人参加一个任务的检查时,安全性会降低,这称为“旁观者淡漠”。因为检查的人越多,每个人对其他人就有依赖心理,责任心就会降低,每个人完成的任务就越不仔细。当有更多的人负责时,信任起到了妨碍的作用。
在评审工作中由于盲目信任造成的对评审效果的影响情况是较普遍的,最常见的是组内评审中出现的盲目信任,还有就是对资深技术人员的盲目信任和对上级的盲目信任。
当一个人质疑另一个人的工作成果时,会被认为含有缺乏信任的意思。但我们应该学会习惯于把质疑作为一种尊重的标志,而不是缺乏信任的象征,评审就是要有怀疑一切的态度。
5.评审工作完整性
评审工作的完整性很重要,遗漏重要的部分可能造成不可估量的损失,这方面的建议主要有以下几条。
① 规划好应该评审的不同的部分、角度和层次。
② 不同的人员评审覆盖不同的部分或角度。
③ 大规模的软件可分物理或逻辑部分进行评审。
④ 要考虑软件系统的泛一致性,要兼顾前后左右系统和标准。
⑤ 要考虑各阶段工作成果的可追溯性,上下游的作者可互相评审,如设计人员评审需求,分析人员评审设计。
⑥ 需求和设计变更是难免的,要给出需要进行“变更评审”的准则,注意必要的评审。
麦肯锡系统思维的结构化思路核心概念Mutually Exclusive Collectively Exhaustive(MECE)对我们评审工作的完整性具有深刻的指导意义。评审工作就应该在整体思维下做到没有遗漏,没有重复。但是为了更好地利用有限的资源条件,要有优先级并突出重点。