最近产品组内共同读书学习了《启示录：打造用户喜爱的产品》一书的18-23章，就产品说明文档方面，作者认为：
1、大部分产品说明文档既没有提供必要的细节，也不包含关键信息，更不能解决问题
2、虽然花费了大量时间撰写产品说明文档，却很少有人读
作为一名产品经理，我不得不说：老铁扎心了。
这两条观点原本是一句话，我把他拆开来看：
第一条观点中提到的关于大部分产品说明文档的情况确实存在，而且较为普遍，不少产品经理把产品说明文档做成了一种形式主义的产物，并不注重文档的实际应用效果。
我把这句话拆开来看的原因是，我认为现实中这两条没有必然的因果关系：
即便是认认真真的完成了产品文档，也很可能同样没有人认真去读。
回想我和现在的团队第一次合作时，我还是团队里的新人，和这群优秀的程序员配合让我诚惶诚恐，生怕因为自己的问题影响到项目进度和质量。
因此我在编写产品说明文档时，可以说是尽了我当时最大的努力，务求能通过文档在团队中传递业务需求和产品设计理念，我之前所在的团队也确实是这样配合的。
可现实的情况是，这些开发人员并不习惯看那几十上百页的产品说明文档，他们向来只看产品经理提供的产品原型和其他简明扼要的业务逻辑说明资料。
无奈之下，我又只能一点点把原型设计中没有包含到的细节部分和逻辑说明部分进行了补充，还配套了一个专门说明业务逻辑的表格文件辅助说明。
为此，我不仅白白多辛苦了两个星期去写那没人读的产品说明文档，还因为后面扩展原型设计的信息而导致需求和设计环节进度滞后，在后面的项目复盘中还被开发经理吐槽我的原型设计不够精细……
起先我也有一些抱怨，认为这些程序员太懒，不愿意静下心来看文档。
可后来我认真反思，发现了主要问题的所在：
团队的统一工作模式，决定了产品经理应该产出何种产品说明文档。
在这个例子中，我根据以往的项目经验先入为主的认为应该以详尽的Word文档资料对产品进行说明，可事实上团队不会为我一人而改变习惯，产品经理应该首先让个人融入团队。
即便团队已有的习惯中确实存在不合理之处，产品经理也应该徐徐图之，而不应该拿项目进度和质量冒险去急于证明自己。
曾经有产品组的成员问我，是否可以考虑在组内推广下UML，让大家使用UML进行分析和设计。对于此建议我并没有同意，我并不否定UML，也不否定其他任何一种成熟的分析和设计方式。
我要考虑的是，这些分析设计方式，是否符合现有团队成员的共同习惯，如果不符合习惯又是否具备在团队中推广成功的可能性。
UML本身有其优秀之处，以往我也甚为推崇并常常用来辅助分析。可当前团队中了解UML的人太少了，在没有一定基础的情况下推广成功的可能性微乎其微。
最后我只能建议这位产品经理可以自己使用UML辅助分析设计，至于最终交付的成果还是需要符合团队当前的统一工作模式。
《启示录：打造用户喜爱的产品》一书的作者在书中积极推荐读者尝试以高保真原型取代Word文档，并指出了许多Word文档的问题和高保真原型的好处。我认为作者说的很有道理，但是具体尝试时也要看具体团队的统一工作模式，因为保不齐有些团队的程序员不看到Word文档就无法开发呢。
当然，作者说的是一种趋势，也就是说作者认为未来应该往这个方向去做才是对的。我也同样认可作者的观点，但正如前面提到的，对于趋势性的东西我们应尽力去推进和尝试，但是不能让项目因此而“涉险”，应徐徐图之。
同样还值得引起重视的是，作者毕竟是在国外，所处的大环境和我们差别较大。特别是参与一些偏传统项目的产品经理，文档的作用不仅仅是为了给需求方确认和交付给开发团队，更是许多项目交付物的一部分。因此有时候即便我们在项目过程中不去写这些文档，在项目结束前也得花费时间去补充这些文档，要实现“只交付产品高保真原型”的效果恐怕还需要很长时间。
我们可以在业务需求分析和产品设计环节，把“输出物须满足团队统一工作模式”作为一条默认的工作原则，这样才能保证产品经理工作的有效性。
