posts - 178,comments - 176,trackbacks - 0
产品从0到1上线运行了大半年,上线初期为了里程碑、KPI,项目组难免会存在完成任务式的心态,尤其是项目成员由各方技术团队抽人拼凑而成、某些业务性强的模块开发过程中,技术在驱动产品的情况,产品可扩展性和健壮性的设计情况可想而知。在着手产品重构任务时,首先想到的便是了解现状,含:业务和技术两方面。技术方面,主要从表结构开始、跑产品的门户流程,通过门户流程看数据生成规则和数据流向来梳理产品现状。业务方面,和运营、用户沟通了解目前产品存在的痛点,优先级情况。在摸清楚业务和技术现状后,和市场、运营伙伴沟通业务规划、对标了解竞品业务、与用户沟通挖掘潜在需求则是下一步要做的工作,该阶段需要尽可能收集多的信息输入,以让设计可以考虑到更多的业务场景,使设计更加科学、合理和具备扩展性。
下面回顾产品重构的思考过程和心得体会,与君共勉,不对指正:
1、首先自己回答几个问题
产品遇到了什么问题、哪些是亟需解决的、这些亟需解决的问题不重构是否能解决、能解决的代价有多高?
接下来的业务方向是什么、产品需要做哪些支撑、重构后能提升多少支撑效率?
2、想方设法摸清产品现状
和开发、测试沟通,导一份产品表结构、产品的接口清单,了解产品的数据存储逻辑、接口逻辑。
如果产品需求文档没有,可以结合对表结构、接口的了解,反向编写和整理出产品需求文档说明书,整理的过程便于系统和全部了解产品现状。
3、调研竞争对手的同类产品设计情况
系统产品不像门户产品直接露出可以看到,但可以通过一些博客文章或通过门户表现做一些推导,将调研情况归纳、整理成一份分析报告,报告讲清楚三部分内容:
1.对于需要新引入的业务单元做介绍说明,再结合竞品的门户露出做进一步阐述和印证。
2.梳理产品现状,更多从业务的角度说明现状可能会带来的一些问题。
3.产品优化思路,从业务方面梳理产品应该支撑的点、从系统方面梳理产品应该设计的哪些点,对优化前后做横向对比。
4、产品内部沟通碰撞
1.与不同产品经理碰撞、沟通,使产品重构思路能在产品全局层面得到认同,保持思想一致。
2.在竞品分析的基础上和市场、运营、产品领导主动沟通以了解规划方向,以将模型抽象得更充分,更好支撑中/长期规划,虽然实际上会逐步迭代去实现这些业务规划,但模型的设计必须尽可能考虑全面,否则后续的业务会使产品模型伤筋动骨。
5.设计过程注意点:
1.产品模型只描绘含哪些业务实体,各业务实体间关系,两个实体之间直接相连时不需单独设计一个连接实体(这属于开发做表结构设计时会考虑的多对多情况)。
2.产品模型中只列业务相关的属性,主键可以换成业务ID,涉及工作流可以用一个业务实体描述清楚,具体工作流如何设计由开发考虑。
3.考虑模型承载不同类型业务的区别都多大,如果大,模型中单独去描绘各自业务实体,揉一起反而产品模型不清晰,而开发表结构设计成一套还是两套由技术考虑。
4.模型除了使用业务实体关系图表达思路之外,可以设计一份商品数据存储示例,从门户的使用场景出发,描述模型如何支撑门户的这些场景,每个场景操作完成后的数据如何落到模型中,以更好理解模型上下文。
6、编写产品立项材料
1.和运营明确业务目标、数据指标,评估运营/产品/UED/技术/测试的人力和时间计划时考虑投入产出比,最好量化出来。
2.思考产品价值在哪里,做这些功能能为用户、平台带来什么。
posted on 2016-07-24 23:54 cheng 阅读(800) 评论(0)  编辑  收藏 所属分类: 互联网产品

只有注册用户登录后才能发表评论。


网站导航: