开发人员对需求的正确打开方式
开工第一周有点憨,都忘记去年是怎么做需求的了,以至于上周有点蒙
- 一开始没有搞清楚核心诉求,以为用户提出的解决方案就是需求
- PRD和技术文档搞在一起,以至于一直在思考修改每个小部分的细节实现,按顺序走到最后又要去推翻修改前面的流程设计
故记录一下我认为的合理流程
我认为的合理流程
需求的再次分析
这是最重要且最容易被忽视的一步
- 为了解决什么问题:一定要探究到用户的核心诉求而非解决方案。
- 能够带来什么价值,多少价值:利用数字化评估+业务理解确定是不是真的存在问题,以及这些问题的解决能够带来什么收益。
- 上述核心价值能用什么指标去度量:以数值的方式去定义功能价值。
- 避免过度思考:有些需求是雪中送炭,不做流程就没办法继续,有些是锦上添花;上述是针对锦上添花,对于雪中送炭,不要太纠结于价值。
- 发现需求创造价值:锦上添花的需求值得好好分析,与用户站在同一边去提高产品能力,说服老板,创造价值
需求的PRD设计
- 用户最终能看到的东西:根据需要解决的问题以及价值来设计PRD
PRD不能和技术文档混在一起:以终为始,技术上很少有完全不能实现的需求无非是成本问题。如果过多的思考技术方案,思考流程,不仅会出现思维混乱,而且有可能会不断返工。
需求的技术文档
- 功能流程设计:从PRD开始倒推,然后依次铺开各个模块的功能
- 功能细节设计:在完成大流程的设计之后,需要进入各个模块中进行小块的设计,此时可能需要验证方案在技术上能否实现,以及实现的成本
- 排期:按模块排期