一份开发喜欢的文档应具备的4个特点

                                                写文档是一个产品经理的必备技能。产品经理需要将写的文档交给上司，交给开发，交给设计。但往往产品经理们殚精竭虑写出长篇累牍的文档，在开发那里只是瞅几眼就扔到一旁了。其实这也不能怪开发，因为一般在需求评审的时候，开发已经将产品的整个逻辑了解的差不多了。如果开发过程中有什么问题，直接和产品沟通的效率也要比一页页的翻看文档有用多了。这个时候产品经理就会很郁闷，我已经在文档里写的清清楚楚 ，为什么还要来问我？这个时候，写出一份开发喜欢不烦人的文档就皆大欢喜啦~

我觉得，作为一份开发喜欢的文档，应该具备以下几个特点：
[ol]

尽量精简文字，少些套话，将需求和逻辑写清楚即可；

可以将复杂的需求可以进行拆分。单条逻辑不要过于复杂；

多配合原型图将抽象的逻辑转化为具象的可进行操作的行为路径；

逻辑环要封闭，不能出现开发写着写着写不下去的情况。
[/ol]
一、尽量精简文字，少些套话，将需求和逻辑写清楚即可
一些刚开始写文档的产品经理，为了标榜自己的专业性，将给开发看的文档写的特别多。一个小小的迭代某个功能的项目就可能写几十页，然而里面有一大部分的内容都是一些数据分析，商业市场分析或者是用户行为的一些叙述。并不是说这些东西不能写，因为一个完整的需求文档是必然包括这些部分的。但是对于一份要交给开发的文档来说，他们接到文档后看了好长时间发现和自己一点关系都没有，就很难有再继续看下去的耐心了。
另外，在关于逻辑部分，尽量使用通俗易懂简洁的语言去叙述。有时候产品经理在写文档的时候为了体现自己的专业性以及严谨性，许多的话写的特别官方、拗口，或者比较啰嗦。比如下面是从网上找到的需求文档中的一段话：
“系统自动分配：系统跟进客户申请的地址，自动分配数据，优先按县级分配、若无匹配的县级服务机构，则按市级服务机构分配，若无市级机构，则按省级服务机构分配，若无省级机构，则进入手动分配，由风控管理人员手动分配信息”
其实这段话描述的逻辑是比较简单的，我认为完全没有必要将一个重复的逻辑都写出来。这段话可以缩减成“系统根据用户申请的地址，自动匹配到县级服务机构，若没有该级机构就向上匹配“市级，省级”。如果都没有就由风控管理人手动分配信息”
如果我是开发人员，我可能就会更加倾向于后面这种，即便语言看起来并不是特别官方，但是文字较少同时逻辑也明了的文档。
二、可以将复杂的需求可以进行拆分。单条逻辑不要过于复杂
产品经理在接手一个比较大的项目的时候，功能和逻辑可能都会比较复杂。这个时候，文档里面的流程图以及思维导图就会比较长，比较复杂。其实这个时候，产品经理无论是在写逻辑叙述还是画流程图的时候，都可以将一个大的流程拆分成几个小的流程。这样交付给开发的话，单个逻辑较为简单开发也有看下去的耐心。那么，如何将一个复杂的流程拆分成简单的流程，我认为有以下几点：
1、在有判断逻辑的时候，尽量不要拆分，有跳转逻辑的时候，可以根据它的一个相关性进行拆分。
比如，在下面的这个流程图中，我可以将进入初审之前作为一个流程；进入授信之前作为一个流程，其余的作为一个流程。分为三个部分分别写逻辑，一个是可以降低开发的心理压力，另外单个模块开发流程的描述也会显得个更加简洁。但是，这样写的话如果后面的版块会涉及到前面版块的逻辑一定要写清楚，以免开发在开发后面版块的时候再去改动前面的逻辑。

2、闭环逻辑、双向逻辑也可以进行拆分。

可以想象，如果开发看到这样的逻辑图后会有什么样的反应。这是给人看的吗？算了，还是去问产品吧。如果我们仔细梳理一下这个逻辑图，发现它其实并不是特别的复杂。比如到封禁用户这一块，与其它的双向逻辑只有封禁解禁的功能，单项操作只有加入黑名单这样的一个。我们就可以把它单独拎出来，作为一个流程。

在我们去掉了仅仅是封禁用户这一个角度及相关逻辑后，回头再来看这个逻辑图，就已经简化了很多了，同时单独拎出来的这个逻辑图也比较简单。目的性较强，开发在写的时候并没有太大逻辑上的困惑。
三、多配合原型图将抽象的逻辑转换为具象的可进行操作的行为路径
在我们描述某个功能逻辑的时候，单纯文字上的叙述并不是十分的具象。这个时候如果我们已经将原型图画好了，那么完全可以在原型上将其标注出来，这个时候并不是指要画出交互线框图，而是我可以将逻辑写到我的原型上面。
比如可以在原型上面可以操作的区域标上①②③，然后在下面写清楚它的一个逻辑。这样的话，不仅可以将整体的逻辑拆分为一个个的单独逻辑，同时图像传递信息的这种方式也要比单纯的文字让人觉得更有看下去的欲望。
四、功能逻辑要把每一种情况都考虑到，不能出现开发写着写着写不下去的情况
关于最后一种情况，其实并不是为了让开发有兴趣读下去。而是出于自身所写文档的一个严谨性。由于产品经理在接触到某一项的业务的时候，首先考虑到的情况是大场景下面以及比较顺畅的业务流程，所以这个时候很多地方的逻辑就会被忽略掉，当开发写到这一块的逻辑时，才发现之前写的东西到这一块已经进行不下去了，这个时候不仅开发周期延误，做了许多无用功，而且之前所写的文档没准也需要进行大的改动。所以在写文档之前，不要怕麻烦，首先要通过思维导图软件，将每一种情况都写出来，即所谓的穷举。然后通过其每种情况再写逻辑，这样的话可以尽量的避免以上情况的发生。
上面的分析只是我自己的一些看法，可能有些公司对于需求文档这方面有着自己严格的格式和定义，所以这一套并不是特别的适用。但是如果是我们自己写文档的话，通过一些技巧将沟通成本降到最低，减小一些自己和开发的工作，岂不是皆大欢喜。