前言
UML 本质是面向对象，适合用来和开发沟通。我是从公司的一位10年经验程序员那听说 UML 这个词的，后来了解到这是软件工程的基础知识。
最近看到一篇文章：《程序员到底需要什么样的需求文档?》，扫一眼就知道是老手了。
作者陈峰，挖财的卓越财富产品负责人。跟挖财的朋友问了一下，卓越财富是高净值产品线。
前端产品
通用逻辑：原型与文档并重，功能结构图与页面结构图为首，流程图为辅。
目前前端产品设计目前比较主流的方法论有：场景论、数据论、功能论、设计论。无论哪一种方法论前端产品就是给C端用户看并且使用，所以原型跟文档不可缺少。
后台产品
通用逻辑：流程图、时序图、架构图、数据表为主，文档次之，原型为辅。
（1）后台产品设计主要方法论有：业务流论、效率成本论、性能论。主要面向企业内部用户，目的是提升企业整体效率：人的效率与钱的效率，包括获客效率、服务效率、管理效率、信息流转效率等，对于感性体验没有C端产品那么苛刻，而对于逻辑与数据会加强。
（2）通过图、表更能便捷、快速的反映基于业务流的本质。一张图表现的东西，可能用10个原型页面都未必能画清除。
复杂的2C、2B功能文档
（1）抄家伙
（2）业务流程图、系统交互图、信息流图、资金流图为主
（3）功能列表、页面结构表次之
（4）原型最末
宽度、深度、长度、量度
如何让需求文档考虑更周全？我们从4个角度来说：
宽度：考虑到90%的完整性
（1）重要业务关联模块梳理。
（2）重要业务流节点梳理。
（3）高内聚低耦合的设计理念。
（4）如果业务逻辑的分离不够导致耦合，则会导致产品功能逻辑耦合在一起，进而使得代码逻辑耦合在一起，对于扩展、重构就是件很蛋疼的事情。
深度：100%的逻辑清晰程度
（1）产品逻辑可以简单类比成代码中的输入于输出关系。我的习惯是画流程图避免逻辑上的遗漏。
（2）如果文档中出现思虑不周的情况，而技术小伙伴已开工，根据我的经验，不要去弥补这个逻辑的漏洞轻易衍生出新的逻辑。有些漏洞是因为不重要，所以PM会遗漏，如果不重要那么就放在下个迭代进行优化。
（3）不要老搞幺蛾子变动，尤其是已经定稿的开发逻辑。一定要改变，PM自己先想清楚是否会影响到其他功能。
长度：50%的预见性
从0到1，从1到10，从10到100，是产品的不同阶段。PM有时像一个军师需要运筹帷幄。根据市场情况、竞争环境、公司情况、团队能力、产品成熟度决定什么时候做什么功能，做到什么火候，都是需要提前考虑的。
量度：100%的价值数据化
（1）功能价值数据化
（2）与团队达成一致
（3）让开发小伙伴更有成就感
