从到端产品阶段小结

　　从零到一，toB端的产品的MVP阶段结束，总结记录一下其中的得失和思考。小团队，没有很多的方法论，以对具体事情做的思考，做总结了。
　　产品
　　1。产品开始前，产品部门一定要里了解产品的商业模式，规划清楚主线功能。能以流程图表示的，一定要做出流程图提供给团队。
　　2。有改动的时候，一定要先产品内部思考、研究，捋清可能会关联到的所有流程、页面、字段，再去找其他部门的同事讨论。首先保证沟通高效性，另外能让产品部门能对相关改动，做整体规划、资源协调。
　　3。做减法。产品摸索期，把握业务主线，保证核心业务功能完整的基础上，做减法。快速开发试错。重功能，少花精力在界面、交互细节。
　　4。产品初期，原型图或者需求评审后，及时与研发确认技术时间节点，列出需要哪些资源协助。初期，出文档要慎重，效率慢且改动可能性大。口述更高效，且便于团队磨合。当然，仅限团队初期。
　　5。定规矩的文档一定要出。比如统一字段命名，跨部门沟通的东西，一定要出文档，开发有据可依，也防止扯皮。
　　6。能具体到人的工作，沟通好后，具体指派到某个人负责。一是赋能给别人，二是事情有负责的主心骨后，参与这件事的其他人，就知道可以往哪儿凝聚。
　　7。产品部门提前练习，怎么把业务流程清晰、准确的讲给别的同事。像要去参加TED演讲一样认真准备，这很重要。
　　UI
　　1。出图前：
　　产品部门也要给UI同事讲业务和背景，便于他们对产品色调定位。
　　产品要参与UI与研发人员关于出保真图的沟通，帮助确认哪些界面是需要出图的。减少出同类型重复图。提高效率。
　　2。出图后：
　　UI出图，产品一定要先把关，确认界面风格不跑偏，确认重要位置处图片的质量和防止遗漏。
　　面对决断性不强的UI同事，产品部门需及时跟进，首要做鼓励和赋能，告诉他们会尊重他们在专业领域的判断，实在不行，产品部门再参与确定图片样式。
　　研发
　　1。很多时候研发拿着草图就开始写代码了，边开发、边催要图的情况比较多。这样开发是高效，但是容易埋下天坑。所以，一开始，产品部门逮着沟通机会了，就要给研发多讲业务流程。确保研发的主线不跑偏。
　　2。抓异常。研发同事大都逻辑严谨，很容易在实现业务中找出问题。
　　这儿产品部门就得注意，不可深入掉入到异常处理中。凡是不影响主线业务的异常，都做简单处理。非常规操作引发的问题，不处理。一定要时刻围绕业务主线做事。
　　关于问题，建立bug池，排出优先级。让提问题的同事知道已被记录任何同事的参与感和被尊重感一定要有。同时还要给他们讲主线业务是做什么，优先处理影响业务主线的问题。
　　3。提供给研发部门的文档。
　　有时花两小时出需求文档，还不如拿凳子坐研发跟前，告诉他要修改的需求。文档只是表达形式，我们要的是效果和效率。而且从平时聊天就知道，大多数研发是不乐意看需求文档的。原因不做分析了。
　　开发文档处理方法：记录事件节点、定规矩、容易出现扯皮的文档，一定要出。
　　界面交互处理方法：a在草图上加注释进行处理，b原型上加入交互效果，c面对面讲。
　　数据库表单处理方法：（掉过得坑）拿出来说一下。这儿产品要做的是整理新增或者功能改动时，可能会出现的牵连性改动（产品自己心里没谱的也算），讲给开发听。能让数据库这边分析、先行准备。要是真有数据库改动的话，这块提前沟预知过，就能为后面技术开发，提高巨大的效率。
　　一些想法
　　目前对产品岗位的一些理解：
　　要兼听则明，从各个角度、角色去分析问题。会做取舍，这很重要。工作重心一定要落在产品核心业务流程上。
　　对产品，对事情，有担当，负责任。规划总是很好，但回归现实，大多是要做落地性事情。出现错误了，自己的锅就主动背，别人的锅，合理范围内，尽量减少别人的尴尬。不要逃避责任，做产品岗，一定要有责任心和肚量。
　　关于沟通：能把别人话里的意思，快速、准确的提炼出来。能把自己的想法流畅、准确的表达出来。沟通、交流事情的同时，也能照顾着别人的面子。达到这三点就够了，不要把沟通能力想的太玄乎。
　　作为产品经理来说，一定要学着赋能。二八定律在哪儿都适用。但如果懂得协调、调动队友。有时候他们迸发出的能力，也很惊人！！！
　　生活就像盒子里的巧克力，你永远不知道下一颗你拿的是什么。产品也一样，whatwecandoiskeepmoving。