*项目研发架构：
需求方： 商务/运营
产品经理： 马*，王*，王**
项目经理： 刘**
设计： 若干
技术： 若干
测试： 若干
【序】：对该项目过去一段时间的工作总结，仅总结了一些在项目研发过程中遇到的一些问题及解决方案。整理出一些相对合理的工作流，为后续的项目管理做的更好积累经验。
一. 需求阶段
- 需求方提出需求之后，产品经理和项目经理应该做什么？
1.需求提出。确定此需求要解决的核心问题是什么？明确需求方是谁？
2.需求分析。产品经理和项目经理，应持有自己的观点，与需求方相关人员共同探讨需求的合理性和可行性，对系统的每个功能进行详细需求分析。
3.UI原型设计。确定需求可行性之后，产品经理根据需求完成UI原型设计（是加强前期需求方需求挖掘和减少后期需求变更的重要手段）。
4.需求评审。结合 UI原型、需求方相关人员、项目经理和产品经理、测试人员等 共同评审，修复优化相关UI原型细节，确定最合适的需求方案和原型设计。【应该邀请测试人员一起参加。测试人员需要了解需求，便于撰写测试用例】
5.需求确认。产品经理完善UI原型设计之后，发送邮件给需求方相关人员，予以确认。回复确认之后，再进入设计阶段。
此项目中，遇到过的代表性问题：
>> 推广系统和渠道系统，需求方对要解决的核心问题没有梳理清楚，项目在“是否要支持二级渠道”的需求上面一直处于模糊状态，导致需求中途变更。结果：导致项目延期。
>> 需求评审阶段，有的系统忽略了邀请测试人员的重要一环，导致测试用例的不全面性，延长了测试的时间。
比如：涉及到的多个系统的测试用例，都应该考虑到16种情况
新老CP | 新老游戏 | 新旧SDK | IOS/Android
二.设计阶段
- 产品经理和项目经理应该清晰的把需求及系统要解决的核心问题，传达给系统架构师。（避免架构师错误的理解，导致系统架构设计的彻底失败）
- 系统架构设计：尽量控制在1~2个技术负责人完成，保持概念完整性和设计的统一
- 系统架构设计上，考虑系统对旧数据的兼容性和迁移方案，数据库的设计，功能上的扩展性等。
此项目中，遇到过的代表性问题：
>> 在推广系统中，由于系统架构师错误的理解了需求，开发后期在 “平台”和“渠道”之间存在很大的功能差别，导致分出的游戏包无法正确的兼容用户系统和支付系统。
解决方案：在游戏分包的时候，“平台”调换到“渠道”的位置，才得以解决此问题。查询的时候，也得做相应的调换处理，才能查询到正确与之对应的数据。
总结：此问题的导致，归根结底是在传达需求的过程中，出现了模糊不清或者错误传达的情况。应该避免这种情况出现，否则，严重的可能导致整个系统进行重构。后果就是：系统架构设计彻底失败。
>> 在开放平台项目中，没有考虑到兼容老数据的问题。导致即将上线前，非常被动的处理老数据问题。
三.研发阶段
- 产品经理和项目经理，按照项目的计划安排，实时的关注项目的进度，协调好各个部门之间的沟通工作。【控制进度风险】
- 产品经理，应善于对功能设计做出取舍。在有效的保证项目进度的同时，可以把不核心的功能舍弃。
- 项目经理，应监督开发技术人员确立编码规范，重视开发文档的维护与更新。【防止在人员变更的情况下，项目衔接上出现问题】
- 产品经理和项目经理，应该实时的监督项目的质量。【控制质量风险和技术风险】
- 开发人员，在对某些功能的实现上，考虑功能的扩展性。
- 开发人员，应该加强自己编码的可读性(如维护一份开发详细文档 ，或者 在关键的地方，写清楚注释等)
此项目中，遇到过的代表性问题：
>> 多个系统，现在都缺乏编码规范和开发文档。如果出现人员变动的情况，在项目交接或衔接上会出现一些问题。在项目研发过程中，没有充足的时间撰写，在项目上线之后，应该补充完善开发文档。
>> 多个系统，多个开发组织之间都有技术接口的互相调用，系统之间的接口调试时间过长，导致项目的开发时间延长。
改进：项目经理，应该每天或每周及时组织技术主管一起讨论技术接口之间的协调工作，以利于各个系统的顺利研发。（通过早会或者周会，及时对各个系统之间的串联接口进行协调）
>> 需求时刻在变。开发人员应该尽量的考虑程序的扩展性。
比如：渠道系统与推广系统，功能相类似。通过渠道系统移植出了推广系统。初始需求，产品经理与需求方确认之后，取消掉企业申请的注册入口。但开发人员，比较好的做法应该是隐藏这个企业申请的注册入口，非删除。后期的需求方又要求添加上次入口，导致上线时间延迟了。
四. 测试阶段
- 测试流程
开发自测（单元、集成）-> 提测（系统）-> 内测 -> 回测
> 开发自测，需要开发人员严谨的进行单元测试和集成测试。只有通过自测之后，才能提测。
> 提测，需要测试组人员按照测试用例进行详细的系统功能测试。
> 内测，小范围的线上测试。此项目中，是少数几个CP配合我们进行测试多个系统。
> 回测，也称回归测试。通常是在项目上线之后，进行的测试，可能进行多轮。项目上线之后可能进行小的调整和优化，要做回归测试。
- 产品经理和项目经理，应该严格的把控提测的项目质量。避免因功能缺失或功能错误，延误整个的测试时间，导致项目延期。
- 在提测和内测这两个里程碑式的节点，产品经理应该加强把控。最好，是发邮件给项目经理，经确认之后，再进行后续的提测和内测工作，尤其是内测。
此项目中，遇到过的代表性问题：
>> 由于本项目中，涉及到多个系统且关联性很强。必须从整体上把控每个系统的风险及计划安排。
比如：在SDK内测完成，宣布正式上线的邮件中。提及到了开放平台系统可以正式对外的相关讯息，商务部门勿以为开放平台可以正式对外，故对很多CP下发了对外的通知，但开放平台还没有做好正式对外的准备工作。
造成原因：可能是由于各个系统之间信息的不同步导致的，项目经理应该及时的向各位产品经理同步该项目的进度。
工作流程改进：在工作流程上面，大家应该达成一致。在提测和内测(开始和结束)等相关里程碑节点应向项目经理发送邮件进行确认，确认之后，再进行下一步的工作。
- 产品经理，应多于测试人员进行沟通交流。详细的仔细阅读系统的测试用例，保证测试用例的全面性。(上述有16种情况)
- 测试人员，应该多角度的考虑系统的各种使用情况，保证测试用例的覆盖全面性。
五. 需求变更
- 建立需求变更（添加）响应机制
需求方提出需求（邮件形式，包括具体内容及原因等） -> 发送给产品经理、项目经理 -> 需求评审 -> 产品经理将确定后的需求方案，邮件形式发送至需求方 -> 需求方确认 -> 项目功能变更或添加
- 需求评审阶段，应该包括 产品经理、项目经理、需求方相关人员、对业务熟悉的相关人员（VP/COO/其他），经评审确定最合适的需求解决方案。
此项目中，遇到过的代表性问题：
>> 需求方突然针对某些业务（X手游吧）提出，在推广系统中加入(“平台”可以有二级渠道)和("平台"可以给某二级渠道的某用户返利)的需求。
现状：原推广系统设计，只有平台的概念，无二级概念；只有按照某笔订单返现，无按照某用户返现功能。
解决方案：在需求评审过程中，邀请了商务部门需求方、VP(相对来讲对业务较熟悉)、产品经理和项目经理共同参加。最终，制定出比较合适的解决方案 —— 推广系统对外隐藏注册入口，商务部门代X手游吧进行部门渠道管理工作；在用户管理里面，添加返现操作的功能。[即不延迟系统的上线时间，又能满足需求方的业务需求]
- 产品经理和项目经理，应该维护一张需求变更跟踪表。（1.便于检查需求是否都已经实现，有无遗漏 2.为了做变更影响分析使用）