近期工作问题总结:
1.拍脑袋想功能, 未对功能进行深度思考
解决方案: 多看竞品,做竞品分析
2.用户体验优化
解决方案: / (1)看老板感觉(不是 (2)自行学习分析
3.功能内未对基础信息进行说明(默认值等)
解决方案: 确定文档框架以及功能叙述格式
4.外部平台对接/第三方对接
解决方案:/
5.功能未形成闭环
解决方案: 画流程图,完善用户路径. 从所有类型用户的角度体验一遍功能.
6.需求想太复杂
解决方案: 出完流程后考虑一下能否简化
文档框架
1.功能分类表
2.主流程链路
3.子流程链路
- 原流程说明
- 现流程说明
- 流程变更说明
4.具体功能说明
- 页面入口: 进入流程
- 页面变更: 是否为新增页,或在原有页面基础上新增什么内容,变更了什么操作
- 字段说明: 默认值, 输入限制, 操作限制
- 操作: 操作说明, 操作链路
- 状态: 不同状态下所有页面展示
- 异常: 异常情况下的页面展示
需求变更处理方式
1.开发前需求变更: 及时反馈给设计
2.开发中需求变更: 与开发讨论技术可行性,并给出低成本解决方案,尽量不影响项目进度
3.开发后需求变更: 开发完成后发现有需要变更的情况时,先判断此项变更是否涉及整体需求的完整性,若影响不大则可放到下一次涉及到该项功能时再进行优化.(注: 及时修订文档以防下次忘记)
第三方平台对接
1.可事先向开发咨询
2.自行查阅开发者文档,定义可能产生的情况,以及对应的反馈结果:
1).操作限制
2).需输入哪些信息,输出哪些信息
3).状态对应结果
其他记录
订单: 只需要产生下单时间等于其关联的内容,即可形成一个订单
抽出模型: 争对同一类的功能/数据,可将其抽离成模板进行整合.
功能可拓展性: 设计功能时,需要考虑未来可拓展性, 因此可以先往复杂的角度考虑,后对复杂的功能进行规划, 区分成几期去实现. 即: 在设计需求时, 给未做的功能留下坑位, 防止后期变更时改动过多.
产出文档及评审时应尽量避免歧义,以免开发理解出现偏差
