Mosh产品研发工作流程规范.doc

Mosh产品研发工作流程规范 产品研发总流程图： 流程中的角色和分工： 产品经理：负责需求收集和分析，产品的调研和设计，MRD的编写，实现的跟踪，以及其他相关产品工作。 产品总监：负责产品部门的工作划分，时间人员协调，总体工作安排和进度跟踪，跨部门的协作安排。 产品总负责人：负责战略性产品的审核和战略方向的把握。 研发工程师：负责系统前后端的设计和开发。 测试工程师：负责系统的测试。 系统架构师：负责重大设计的指导和审核，关键系统操作的确认。 其他：可能包括UE/UI/VI以及其他部门 流程块描述： 需求收集调研： 工作内容：产品部门通过各种途径收集市场和用户需求，开展基本的调研工作，确定需要实施一个项目来满足这些需求。 注意事项：原创类产品，最好给出定量的需求分析和调研报告；模仿类产品，最好给出对模仿对象的分析和模仿的理由。给出产品重要性与优先级，是否符合大战略，对其他产品的影响，预期的运营性价比。 项目立项： 工作内容：产品部门组织，和涉及到该项目的所有相关部门和同事开立项会，给出项目的意义、产品需求、预期效果、人员工作范围、时间计划等。 注意事项：立项会原则上不展开讨论问题，仅着重于通知并协调各部门相关人员的工作。 MRD编写： 工作内容：产品经理将市场需求和产品需求编写为MRD文档，并以此做为整个产品实施和效果评估的标准指针。 注意事项：根据产品改动的大小，分别使用MRD或mini MRD模板来编写文档。后期过程中的任何产品设计改动需要反映到对应MRD文档中。 产品讨论确定： 工作内容：产品经理组织各种形式的沟通和讨论，不断修改和调整MRD文档。在经过立项相关人员的一致同意后，基本确定产品的设计和获得基本确定版的MRD文档。该过程种包括UE/UI相关的设计工作，并包含初步的用户调查/测试。 注意事项：首页、持久导航的产品上的新增和重大产品变革，需要产品总负责人同意。如果出现较大分歧，则首先需要寻求沟通和解释；产品部门拥有最终决定权。 技术设计： 工作内容：研发工程师针对MRD文档，进行技术实现上的讨论和设计，并确定方案。 注意事项：增加新的较大的模块或者对重要模块的较大改动，需要提供设计文档，并需要架构师审核通过方可实施。设计文档需要按照标准模板来编写。 技术开发： 工作内容：研发工程师按照设计来进行开发，并进行必要的自测和代码交叉检查。 注意事项：开发的代码要遵守Mosh PHP编码规范。复杂和关键的代码，尽可能安排交叉检查。 测试： 工作内容：测试工程师按照产品MRD文档的要求来执行测试过程，检查系统的功能、性能、容错性等内容。产品经理按需安排进行用户测试。 注意事项：重大改动需要进行整体回归测试。用户测试获得的信息，可能会导致需要重新回到MRD修改。 上线： 工作内容：工程师准备上线方案，并将实现的系统放到线上提供服务 注意事项：架构师确认放可上线。上线过程尽可能少的影响服务。上线完成，相关各部门人员检查各自负责的部分是否正常工作，有异常要及时通告技术部门。 基本工作准则： 每项任务的每个阶段，都需要确定负责人和基本时间计划。 每项关键工作完成以后，都需要进行效果评估和情况通报。 不能按计划完成，需要提前通知上级负责人，并给出原因。 大会前充分沟通，而不是大会上讨论。 所有的产品修改需求都提交给产品部门，经过产品确认再提交技术部门（紧急性bug除外）。 MRD文档是整个流程的中心文档，各项工作的开展围绕MRD文档进行。