开发人员对需求的正确打开方式

开工第一周有点憨，都忘记去年是怎么做需求的了，以至于上周有点蒙

1. 一开始没有搞清楚核心诉求，以为用户提出的解决方案就是需求
2. PRD和技术文档搞在一起，以至于一直在思考修改每个小部分的细节实现，按顺序走到最后又要去推翻修改前面的流程设计

故记录一下我认为的合理流程

我认为的合理流程

需求的再次分析

这是最重要且最容易被忽视的一步

1. 为了解决什么问题：一定要探究到用户的核心诉求而非解决方案。
2. 能够带来什么价值，多少价值：利用数字化评估+业务理解确定是不是真的存在问题，以及这些问题的解决能够带来什么收益。
3. 上述核心价值能用什么指标去度量：以数值的方式去定义功能价值。

1. 避免过度思考：有些需求是雪中送炭，不做流程就没办法继续，有些是锦上添花；上述是针对锦上添花，对于雪中送炭，不要太纠结于价值。
2. 发现需求创造价值：锦上添花的需求值得好好分析，与用户站在同一边去提高产品能力，说服老板，创造价值

需求的PRD设计

1. 用户最终能看到的东西：根据需要解决的问题以及价值来设计PRD

PRD不能和技术文档混在一起：以终为始，技术上很少有完全不能实现的需求无非是成本问题。如果过多的思考技术方案，思考流程，不仅会出现思维混乱，而且有可能会不断返工。

需求的技术文档

1. 功能流程设计：从PRD开始倒推，然后依次铺开各个模块的功能
2. 功能细节设计：在完成大流程的设计之后，需要进入各个模块中进行小块的设计，此时可能需要验证方案在技术上能否实现，以及实现的成本
3. 排期：按模块排期