B端金融产品笔记一（prd写作的思考）

写在前面

逛小红书发现工作大半年以来只在埋头干活，缺少了对经验和方法论的总结，故开此文章记录。

写prd需要考虑的几点细节

1.此需求什么业务背景、解决了什么问题
2.此需求对其他使用此功能的客户造成什么影响、是否需要做数据迁移
3.此需求对其他上下游功能会有什么影响，取数或计算逻辑会有什么改变
4.此需求开发好后是客户公司的谁来用这个功能，谁来维护这个数据。

小需求写好的基础——对系统的了解

很多需求看上去小，就是加个字段，或者加个限制、或者放开一个限制，但prd却难写。是因为需要考虑到对系统的整个影响，不然很容易考虑不全，开发完成、验收完成后都可能觉得没啥问题，但有一天突然发现某个下游报表或下游功能，从很早就开始错了，于是又要写事故报告。尤其是金融系统这种整个软件or网页基本上就是一个大型数据库管理系统的地方。所以对系统的了解是写好prd的前提。

大需求的考虑点——拟合业务、通顺、实用、全面

大需求因为要做的事情比较清晰，而且一般是做一个新的功能或者页面，所以相对独立，反而不会考虑那么多对系统已有功能、已有数据的改动，所以要考虑的更多是功能本身，反而是好下手的。

拟合业务

在没有这个功能前，公司此项相关的业务是怎么做的？是人工处理？还是有python脚本？人工处理有哪些特殊处理逻辑？python脚本写了哪些内容？系统具体帮忙自动化的是哪部分工作内容，一句话概括要此功能要做到的事情。

通顺

页面设计好后，也要自己跟自己过一遍操作流程（最好跟开发也过一遍，自己很容易陷入思维定式），这么做出来后，客户常用的使用流程是先点哪个，再点哪个，做完什么流程能完成什么事情，不要出现设计时候觉得很不错，全做完了真正客户用的时候发现在某个节点会被卡住的情况？

实用

设计好的页面解决问题了吗？用户操作简单吗？怎么设计功能通用性更强？怎样设计流程清晰不让人迷惑？在程序逻辑清晰的前提下，有没有一些操作节点是可以合并的？

全面

有没有没有考虑到的业务上的极端情况，有没有需要特殊处理的特殊数据？每一个很强的判断逻辑都可以思考下有没有不成立的反例。