本周我所在的产品组共同分享了《启示录：打造用户喜爱的产品》中第11至17章，让我记忆犹新并认为最值得回顾的是作者关于“产品原则”的讲解。

作者认为：

产品原则不是产品功能的清单，不依赖于任何单独的产品，它是整个产品线的战略指南，是公司的价值宣言。

对这一点，我深表赞同，同时认为在特定情况下还需要扩展。

在软件公司或者互联网公司，作者的看法已经足够。但是我所在的是航企下面的IT部门，所面对的是多个业务部门主导的多条产品线。尽管我们属于同一家公司，有着相同的愿景和目标，但是具体到每个部门的每个产品都有不同的执行目标和原则，不能一概而论。

首先，整个公司的信息化层面确实应该建立统一的产品原则，这样才能让每个项目基于一定的共识开展，而不至于每次项目组成立后都要花费精力讨论一些基础问题。公司虽然没有明文规定这些原则，但是它们确实在每个项目中发挥着作用，例如“战略目标大于成本考量”，“允许产品分期建设”，“运行安全比其他的业务体系更为重要”等。

这些基于公司信息化总体层面的原则已经成为团队统一的价值观，往往不需要在每个项目中重复列出，因为这些已经是所有人的共识。除非在某个项目中对这些统一的价值观有特殊的解释，或者因为在某个项目中极容易违背它们而进行特别强调。

例如在某项目中，我为项目列出的原则中包括了“总体规划、分步实施”这一条，是因为在立项前的沟通中，我明显感觉到业务部门渴望一次完成整个产品广度和深度上全部内容的建设，而站在IT部门的角度，我分析判断认为这并不合理，很可能因此把整个项目拖入困境而导致非预期情况的出现。因此，我特别列出这一条原则，并解释：

要先抓重点、核心的业务部分予以实现，并通过这些核心业务摸索出系统建设的通用模式，再逐步的实现其他业务模块，从而降低系统建设的风险。

在立项阶段，我说服了业务部门重视并遵守该原则，得益于此，在后续项目执行中我很好的把控住了本期系统建设的边界，在预期的时间内完成了项目建设。

在公司内我常通过合理的项目原则与业务部门达成共识，从而在项目早期就很好的规避了一些重大风险。因此，相对于在项目中、后期花费大量精力和时间去协调解决一些冲突问题，在项目早期充分分析并提出这些原则就显得非常超值。

在具体的项目中，除了统一的价值观需要遵循和强调外，往往还需要根据项目的自身情况提出独有的原则。这些原则放在其它项目中也许并不合适，但是在当前项目中却必须提出并严格遵守。例如在某项目中我分析认为，业务部门有明显的倾向希望借本次项目颠覆原有的业务规范，但是却并没有对此可能造成的额外的资源投入做充分预估，为避免因此出现的项目风险，我提出了这样一条项目原则：

不过多改变用户工作习惯。

并解释道：

始终坚持在保持原有业务标准的基础上进行信息化建设，以项目建设目标为准进行适当优化，而不过多的打乱业务，保证相关业务在信息化转变中的顺利过渡，在具备一定系统应用基础后，再逐步考虑更大的业务创新与变革。

在很多项目中，随着信息化项目的建设和应用，业务规范的创新与变革十分常见，甚至有些项目就是以此为目标的。因此“不过多改变用户工作习惯”显然不是一条通用的企业信息化原则，但是在本项目中，因为业务部门要解决的核心问题并不在于此，在没有充分准备的情况下却想要顺带完成这样的过程，就必须提前建立这样一条原则，并基于此去规避相关的风险。

这类项目中特有的原则也就是作者讲到的“战术性”原则。

提出原则不仅仅是为了填补产品文档中“产品原则”章节的空白，其真正的目的是为了：

让团队在项目早期以相对较低的成本达成共识，为后续可能出现的争执提供判定标准和依据，更利于产品经理在项目中协调工作、规避风险。

书中也提到：

产品经理没有管理产品团队的实权。

如果需要产品团队的配合，产品经理只能摆事实、讲道理，不能强制执行。

而优秀的产品经理，应该具备非凡的预见性，能在所有人之前通过分析推导出可能出现的困局，基于此提出合理的产品原则，并尽早说服团队认可这些原则。

“能说会道”并不是产品经理解决冲突的全部倚仗，而只是一个必不可少的基本素质。解决冲突真正需要的是智慧，而制定并通过产品原则无疑是其中一条可行的途径。