一个好的产品是不需要产品文档这种东西的，但当你还做不到这种程度的时候，那么至少要做到将你的文档乐观、具体、客观的表达出来。

在一个项目中，需求文档是实施项目中极其关键的环节，它不应该被割据成一个单独的部分，而应该是随着项目发展，不断地动态去更新调整的。最近在看《用户体验要素》这本书，结合书中提到的关于需求文档的三点想法，再结合我目前的项目经验来简单来谈谈我的理解。

▍乐观

需求文档所要表达的内容应该是乐观的。不应该告诉我不能做什么，而应该告诉我如果要那样做，有什么办法。比如描述：“这个系统不支持在线开具纸质发票”。这样写就不太好，对应地如果换种方式来说，“如果你想开发票，你可以通过拿到网站用户的邮箱，然后通过邮箱来发送电子档的发票，用户可以拿着电子档的发票去打印纸质发票”。一个积极乐观的描述对于一个来查阅文档的读者而言，得到也是乐观的信号。开发者或者设计人员也就清晰地明了自己做出来的产品最后是怎么应用到实际中，然后又是怎样解决用户问题的。有时候在项目中也会遇到这种情况，这么专业的问题我不知道，可是谁天生又是专业的呢，你不知道这个问题怎么做，但你至少要知道，要解决这些问题应该需要哪些人一起来配合解决，然后又应该以怎样的途径来 debug 这个问题。对于有些专业性很强的问题，可以尝试自己去查下，最怕的往往不是你不会，而是你自己不去学、去寻求办法。

▍具体

要想项目组人员快速解决问题，你所反馈的问题一定要是清晰明确的，越具体对于他们而言看得就越轻松。项目管理中总是会看到很多项目管理者说，这个问题处理好了吗？其实大多时候并不是一味地催进度，而应该是偶尔停下来看下、想下，目前问题出在了哪里，怎样才可以快速去解决问题？去找有经验的老司机 or 去网上搜寻？其实你遇到90%的问题，别人已经遇到了，并且也给出了一套不错地解决方案。看看别人是怎么做的，结合自己的情况又该如何去做。比如，对于涉及输入文本的输入框，一个不好的需求描述是 “这里是一个输入框，用户可以输入文字” ，这个需求隐藏着很多未具体的点，比如：文本格式是什么？字数的最大，最小限制是多少？超出了应该如何去处理？怎么样做能够更大程度上减少用户的输入成本？等等，这都是在产品规划中需要考虑的问题。总之，你给到的需求越具体，做出来的产品也就离你想要达到的目标越近。

▍避免使用主观的语气

你以为的或许都是错的，在需求撰写的时候避免使用主观的语气。如何来反映呢？一个客观的需求是可以验证这个需求是否有得到满足。在项目中经常有客户是这样要求我们设计师们的，“嗯，这个网站的设计要有逼格，要有时尚感”，但是这种时尚和逼格在不同的人来看，所得到的看法也是不一样的，正如世界上本来就没有一模一样的叶子一样。再进一步，可以找一些你认为的有逼格或者时尚感的给客户看，然后让客户自己去选择。但是本质上来说还是主观的，因为这个是从客户这个角度来讲。如果在更进一步，“这个网站的设计应该符合该品牌的设计指南文档”，这样来说就很客观了，因为它有了具体的衡量标准。最后我们再把标准进一步量化，输入框应该是什么颜色，文字应该用多大，主色应该是用什么，辅助色应该是用什么。就得到了相对客观的需求。

当然乐观、具体、避免使用主观的语气，这三者往往是结合在一起使用的，当你懂得如何恰当的将这三点应用到你的需求文档中的时候，或许下次项目组的小伙伴就不会再追问你，这个应该如何做。好的，今天就码到这里了，有什么想法，可以在底部留言一起交流分享啊~，哈哈哈~

作者：猴哥，一枚产品er，关注产品也闲聊生活。个人公众号【猴哥】，欢迎围观