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