搜索
产品工作规范为了让PM部门能清楚定位自己在产品流程中扮演的角色，明确工作职责，形成良好的工作习惯和工作方法，撰写此文。(一)产品工作中需要注意的事：1.主动思考，多问为什么。不要被动地接受上级布置的具体事务，应该思考为什么要做这件事——目的和意义，对应了怎样的业务需求，怎么做这件事最好。2.思考问题的角度要从现实业务出发，我们做的所有工作都与业务有直接或间接的联系，一定要在了解业务运作的情况下来设计和规划产品。3.学会使用沟通技巧，工作中很多地方需要和其他部门交流，对不同的沟通对象，沟通方法是不一样的。比如，为确保能够被正确理解，与业务部门交流需要使用更生活化简明易懂的语言，与技术部门的交流就可以使用带有技术性的专业术语。总之，想尽一切办法降低沟通成本。4.产品工作还需要有控制力。这一点涉及了很多地方，比如在整个产品开发流程中，需要管理和控制开发成本，优先级，开发的时间、开发进度等等；再比如日常事务处理的时候，需要评估各项事务的优先级和紧急度、控制完成进度。5.善于总结，不要让自己陷于繁琐的日常事务之中，定期给自己一定思考的空间。总结不足（怎样改进）、犯过的错误、工作方法、工作中遇到的问题，吸取周围人的优点。(二)pm内部规定：1.信息保密。在与其他部门的交流中一定要清楚地知道，哪些信息是应该让对方知道的，哪些是对方不需要知道的。一般地来说，属于规则策略的部分，不要轻易向其他部门透露。2.线上测试前需要准备checklist.，写明总负责人、测试项目、各项目测试人等。3.在测试完成时的测试设计里面，需要包含：哪些地方与mrd不一致，怎么不一致的，为什么会不一致。预留回归测试的时间。4.每次升级以后，对于这次升级的整个过程做一次总结，包括质量总结和进度总结。质量总结要总结这次升级发现的所有bug、出现原因、修复情况；进度总结总结升级过程的时间延误，延误原因。(三)产品开发流程1.图示：PM确认分析需求PM撰写需求分析说明书MRDRD开发系统TEST测试系统业务部门提出需求PM从产品策略层面提出需求，调整产品系统投入使用工作流1工作流22.具体步骤介绍：以工作流1为例，介绍产品工作的具体流程和pm主要职责。第一步业务部门向PM部门提出需求参与部门业务需求部门、PM部门第二步PM部门确认分析需求参与部门业务需求部门、PM部门PM部门主要考虑因素确认每一个需求是否真的是需求？考虑是否可以在现有情况下找到替换方案（替代新开发）？——成本最低考虑在众多需求中根据需求的紧迫性、开发难易等各因素评定需求的优先级，安排近期的开发/升级计划和此次开发/升级的内容第三步PM部门设计/升级产品——撰写需求分析说明书MRD参与部门PM部门流程撰写人提交MRD，需要经过PM内部审核，最后由产品经理审核通过并且签字同意PM部门在撰写MRD过程中需要考虑的因素1.功能上：怎样设计最优。（最优：完整满足需求；RD开发的代价较小；为将来功能升级留下接口）2.规则策略上：怎样让产品最符合现有的业务模式，让客户更喜欢产品，让内部使用者更易管理、避免所有违规操作3.在MRD撰写上特别注意：用语清晰易懂无歧义，对于功能的描述需要尽量的详细，让技术人员没有“想象空间”，对于一些比较难说明的地方可以画图。（便于RD、TESTING和部门其他人阅读），若是对现有产品升级，注意说明升级前后的功能差异。每一个功能点考虑仔细全面透彻，必须考虑到涉及到它的系统的每一个部分并将之写入文档。这是开发过程中最重要的文档，必须起到架构产品、指导全局的作用。第四步RD开发系统参与部门RD部门、PM部门、业务部门流程与研发部门探讨需求实现，可以根据开发难易调整实现方式，找到需求实现和开发瓶颈的平衡点。在此期间，如果需要调整MRD，须和需求部门再次进行沟通确认。Pm部门提交MRD给评审会，并且按照评审意见修改MRD，评审会审核通过后，MRD正式定稿。需求部门和技术部门必须在最终的MRD文档上签字确认。此后如还有需求变动的地方，需要提出需求变动的部门提出申请，经过评委会的审核通过，并且各个部门签字，并且更新的MRD中。PM部门此过程主要做的事控制整个开发进度：协助开发人员的开发——不断沟通，确保他们完全理解开发内容大致了解每个功能的实现方式——怎么取数、怎么做得规则判断。最重要的是了解功能是不是完整实现了，有哪些没有实现，为什么没有实现。怎么才能让它在现有情况下实现第五步TEST测试系统参与部门TEST部门、PM部门PM部门此过程主要做的事1.在开始测试之前所有参与测试的人员需要共同完成的测试设计文档。2.仔细阅读全部的测试报告或者测试用例。主要从系统（功能和规则策略上）思考测试不完善的地方，容易出错的地方和需要重点测的地方。3.与测试部门沟通以上的结论，协助测试。4.功能测试目前由PM部门负责，所以在RD提交测试以后，PM部门会重点进行功能测试，在测试过程应该尽量做到：全面的测试：每一个点涉及到的地方都要测到重点测试：薄弱地方和容易出错的重点测回归测试：以确保测试的质量5.在正式上线之前，需预留出一天以上时间，总结测试的结果，包括测试过程的bug及修复情况。哪些没实现，哪些没按MRD实现等第六步系统投入使用参与部门业务需求部门、PM部门PM部门此过程主要做的事1.对使用系统的部门安排相关此次升级的培训2.准备线上测试的checklist3.提前将此次升级的新功能告知相关部门4.上线以后的线上测试和线上观察5.此次项目总结6.整理MRD和更新说明文档7.收集业务部门对于系统升级的反馈意见，了解他们对升级功能的使用状况。如果出现问题及时了解，查明原因，进行处理！备注如果是大版本的改动，为了保险起见，可能会先产生一个试用版，小范围内投入使用，观察效果，待时机成熟以后再大规模投入使用。若发现问题也可以及时回滚，减少损失。作为产品的设计者，PM还可以不断从专业角度，调整产品策略，优化产品，于是产生了工作流2；其实这两条流程并不是严格分隔。在大部分时候，对于业务部门提出的功能需求，pm同样会站在专业的角度来设计和规划。所以，这两条工作流可以说互相渗透互相影响的。