1. 背景
响应公司业务、客户发展，移动端需针对客户需求进行产品研发。
2. 项目情况
在2019.12.30完成发布，逾期1个月24天（计划2019.11.06）
进入开发周期后，进行两次需求删减
未达到应用于项目的标准，且未应用于项目
3. 需求来源
客户直接提出的需求
4. 较好的思路与收获
1) 注重用户体验
根据客户的反馈，进行功能的设计，更多考虑的是用户体验，特别是客户模块；
2) 初步了解取数逻辑
在功能设计时，要考虑到数据是否可取到，因为移动端的数据是要依托PC端进行取数的；
3) 初步接触toB产品的角色、权限体系
要先理清客户的整个组织架构，再设计角色，然后根据角色的需求、特点，进行权限及功能的设计。
4) 学习到参数体系的原理
用于权限功能的配置（显示与隐藏）、同一功能不同内容（如，资产显示为准确值还是范围）。
5) 强化了消息提醒功能的使用情况
toB产品的消息提醒是辅助主流程的顺利进行，故以小模块提醒为主；社交类产品才适合用对话列表的方式展示消息提醒。以及功能设计逻辑（角色—提醒类型—提醒内容—内容算法—提醒规则—跳转关系—功能数据）。
5. 做得不足需提升的地方：
1) 没有产品迭代意识
一个新的版本，相当于一个新的产品，一上来就把所有的需求做得尽善尽美，没有抓住核心需求，导致整个版本的技术实现难度较大，无法按时按质量完成。第一版本应先做核心需求。
2) 需求调研不彻底
在需求阶段，仅以遗留的过程文档进行需求分析，没有找到最初的需求提出者或相关参与人进行需求的细化，给核心需求的判断带来相对较大的误差。
3) 没有系统意识
只关注表层的需求实现，一个需求，转化成功能点之后，名词怎么定义、公式怎么计算、数据怎么来、现有数据能否支持，不能支持的情况下，需要新增什么接口，新增的接口数据银行能否及时取到等，这些没有从一个整个流程去思考产品的功能，只是从客户提出的角度来思考功能。
4) 在需求阶段，设计周期略长，
需求调研及设计超出了原计划的时间，进度把控不到位
5) 在文档上，需求原型图不完整
新版本基于标准版来进行功能设计，画原型图时，站在一个原标准版技术人员对产品的认识度与技术熟悉度的较高的基础上，而在开发过程中，后台人员基本是新的技术人员，对标准版的认识度等基本为零，导致在开发过程中，需求文档存在很多不明确的地方，需要给技术人员澄清需求及补充需求文档
6) 删减时，关键功能被删减
在做功能删减的时候，没有根据客户的主要痛点来进行功能的删减，导致在发布以后，客户想查看的功能，已经被删减。
- - - - - - - - - - - -
【一个小目标】5/365，记录产品经理之路的思考，做一个讲故事的人，讲一个好故事。
网友评论