产品从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 阅读(1009)
评论(0) 编辑 收藏 所属分类:
互联网产品