入门与不同需求文档的应用场景

　　今天给大家带来的是几种产品需求写作方法，以及它们的优缺点。
　　一、流程的划分
　　随着C端产品的不断完善和市场扩充，让传统行业看到了互联网他们的魅力所在，由此如今的TOB行业很火爆，在此很多做TOC的小伙伴在转行的时候写需求的话会忽略业务流程的梳理，这也是你快速入行和成为行业专家的第一步，当然最好搭配上5W2H分析发效果更佳哦。
　　下面拿采购来说明：
　　从中可以发现哪些问题呢？
　　需要纸质表格填写，不方便管理；
　　需要当面和负责人对接说明，消息滞后处理不及时；
　　特殊情况，需要协调更多负责人的时间，错过最佳处理时间；
　　财务需要通过人事统计表格去对账，不严谨有误差风险。
　　在你对现有流程比较熟悉之后（当然可以把这一步看作是用户调研），就可以着手准备优化后的业务流程，以及使用流程去讨论了，尽可能的在前期去把风险降到最低。TOB的产品注重与逻辑和业务，所以在这一步大家一定要慎重，不要一上来就直接画页面。
　　我们解决方法：
　　线上化，方便记录与管理；
　　及时通知，避免时间不对称的风险；
　　自由添加审核人、抄送人或者后台管理员编辑，解决消息同步和职责不清晰问题；
　　减少人力成本，财务对账信息更严谨。
　　下图为个人申请的一个使用流程，当这个流程被确认，你就可以画出信息架构图，去进行详细的页面设计。
　　二。四种需求说明
　　纯文字说明
　　样例：
　　1。1搜索栏：
　　1。1。1、地区显示固定为北京，暂不提供基于定位显示位置信息。
　　1。1。2、搜索栏搜索内容增加为可搜索场地（默认显示今天场地，按时间排序）、作家、和作品信息。
　　1。1。3、搜索界面搜索场地默认显示今天场地，按时间排序。
　　优点：
　　简洁明了，易于阅读；
　　单区域可观性强；
　　便于初学者描述需求。
　　缺点：
　　整体逻辑性不强；
　　模块描述不清晰；
　　流于细节，不利于整体流程框架通读。
　　应用场景：
　　主要应用于逻辑简单的小型产品。在最开始开始阶段，进行MVP（敏捷）开发的时候，可以使用该功能需求的写作方法。而对于逻辑复杂的产品线来说就不适用，像OA、CRM等重逻辑的TOB产品相对就不是很适用
　　模块描述型
　　样例：
　　优点：
　　突出模块与效果；
　　功能模块可观性强；
　　编写需要对产品模块有了解。
　　缺点：
　　偏向状态描述；
　　单条篇幅较大；
　　模块与模块之间无联系；
　　编写需要对产品模块有了解。
　　应用场景：
　　此需求说明主要的功能是去描写页面的一些动效和页面流转效果，多适用于注重交互的产品。是上一个需求的加强归纳版本。
　　用户场景型
　　样例：
　　优点：
　　以业务流程为主，从起始到完结；
　　逻辑清晰，不容易产生遗漏。
　　缺点：
　　细节描述，有所欠缺；
　　编写需要对业务流程有理解。
　　应用场景：
　　主要应用在有比较完善，有设计规范、UED、资深开发、等已经形成默契的团队。重点集中在事件流程，前段用户操作和系统如何处理，方便开发快速阅读，形成逻辑流转在脑海当中。
　　用户场景细化型
　　样例：
　　优点：
　　以业务流程为主，从起始到完结；
　　逻辑清晰，不容易产生遗漏；
　　主要为异常流（备选事件流）的积累，便于完善产品。
　　缺点：
　　细节描述，有所欠缺；
　　编写需要对业务流程有理解；
　　对技术开发、团队合作需要一定经验。
　　应用场景：
　　与用户场景型的应用场景一致被验证过的成熟产品，不过它的重点是在备选事件流程上。20时间放在其他描述，80的时间是放在备选时间流程上，去梳理、准备各种异常情况下，产品应该给用户一个什么样的解决办法。
　　总结
　　世界方法千千万，没有最好的只有最合适的。方法是让我们更好、更快去解决问题的途径。学习各种方法，再去提炼出最适合自己的方法，形成自己的体系，那么你就是下一个大神了。今天就分享到这里了，期待下次与爱智求真的你相见。