项目管理日志(一)

1.理论与实践差异
问题场景：计划和风险(进度、质量等)在实践操作中有偏差
解决办法：计划先行，尽早暴露不好的风险，最小成本处理

2.研发质量提高
问题场景：功能调整影响原功能(反复、验证成本)
解决办法：自测、草稿设计、草稿场景验证

3.测试质量提高
问题场景：常规、非常规测试，功能点测试要点不足
解决办法：多业务场景测试用例、功能点测试要点罗列

4.计划执行偏差较大
问题场景：过于理想评估计划，实际执行不可预期偏差较大
解决办法：要做充分计划，罗列计划要点，预留足够缓冲时间

5.集中测试对进度干扰大
问题场景：功能开发调整完毕，集中提交，测试验证时间较长
解决办法：局部交付，做阶段性验收测试，确保已验证功能稳定性

6.客户验收缓慢
问题场景：客户迟迟不愿验收，是因为一些不太愿意说、做的事情要做完
解决办法：多与客户沟通，找到客户顾虑，解决痛点，推进下一步

7.后期测试发现重大漏洞
问题场景：发现重大漏洞，虽不是我们这边导致的，但对整体项目影响不好
解决办法：项目经理要多想，要替客户多想，把控范围、进度、质量、风险等

8.注意与客户沟通方式
问题场景：与客户沟通，不要用理论的形式交流，多关注客户的痛点
解决办法：注意把控不同角色关注点，平静、平和、淡定，莫着急，平稳推进
              注意良好沟通方式学习，平息对方顾虑和急躁，以合作共同解决为出发点

9.多做一点，可减少很多成本
问题场景：研发提交的功能总会留一个小尾巴，测试覆盖测试也不太严谨
解决办法：在不超范围前提下，如果只是成本(进度、质量、实现难易程度)很小，风险很小，
              对功能优化、功能Bug修复、功能体验升级，那就随手多做一点，可以达到很好的效果

10.客户提出的无理要求
问题场景：客户针对模糊的需求提出可扩展的无理要求，甚至超需求的无理要求
解决办法：跟客户很好的沟通，把范围往小了圈定，针对最根本的痛点，满足最小的需求
              不是不做，可以做，往小了做，解决目前最紧急、最根本的痛点问题，以解决问题为宗旨

11.客户提出的需求和问题
问题场景：客户说要对某个功能设计进行修改，客户说要实现某某需求
解决办法：客户告诉你的未必是他真的想要的，需要多场景、多角度帮他分析，让他自己深入分析，并告诉你结论这到底是不是他想要的
如果不具备快速验证发布条件，不需要那么快的响应速度，避免朝令夕改，很是头痛和疲惫，帮他们深入分析，让他们想清楚他们真正想要的是什么

---

 

1.研发提交测试流程

问题场景：

研发修改Bug完毕，未进行代码发布，直接将Bug状态进行修改，测试回归Bug，未通过是因为未发布。

假设 昨天测试提交的Bug，昨天开发改好了，把Bug状态改为 已解决，却没有进行发布。

今天测试登陆，看到Bug已解决，进行回归测试，验证还是不可以。其实 是没有发布导致，浪费测试时间。

解决方法：

为提高团队运作效率，大家有成效的工作。

研发修改完Bug，在相关调整功能发布之后，再到Bug管理平台修改Bug状态。

 

2.缺陷提交规则

问题场景：

测试测过的功能，还潜藏着严重的Bug，或是一些不合理的逻辑操作、不合法的数据操作还是会有Bug产生。

用户使用场景测试不全，只进行符合规则的数据进行测试，却没有进行非法数据、非法操作进行测试，测试深度不够。

测试使用操作不方便，不好用，跟常规的使用习惯不一致。

解决方法：

测试为确保项目质量，需要进行多浏览器、多边界值、各种可能的用户场景、不合规的操作、不合法的数据进行测试。

Bug都要登记Bug管理平台，严重Bug需要研发进行解决，非严重Bug研发酌情处理，

非严重Bug登记，也是以防问题或是好的优化建议被遗忘(优化需要讨论确定修改方案)，为孵化产品做优化储备，提高产品易用性、提高用户体验。

 

3.为什么要组织相关评审活动

评审的目的是为了在真正投产前，进行设计把握，整合大家的意见，以确保该项文件或是该项活动是正确的、有价值的，降低一些不可预期的成本损失。

如：需求的遗漏、设计的不合理、项目管理的不到位、质量风险等等。

 

4.某模块问题层出不穷

问题场景：

研发对一个功能完好的模块进行功能调整，导致产生不必要的Bug和问题，而且未经充分测试直接丢给客户。

尤其是在推动用户验收，进行验收测试的时候，更需要保持运行环境的稳定性，如果出现重要模块的重大Bug很不好。

解决方法：

研发对功能进行调整，不能盲目自信，一定要自测，且覆盖到相关的使用场景；

如果研发没有时间测试，一定提交到测试部，让测试人员进行充分测试，不能把未经测试的代码直接发布丢给客户使用。

 

5.研发工作被打扰

问题场景：

来自客户的问题、现场同事的问题、测试同事的问题，直接找到研发这边处理的，都会对研发的开发工作造成中断。

研发一旦被打断需要重新梳理思路，容易导致代码不严谨，潜藏一些Bug在里面。

或是陷入整天忙于处理问题，而忽略主体功能开发工作；处理的小问题，而影响大功能。

解决办法：

紧急严重问题，及时响应处理；非紧急严重问题，可参考如下建议：

(1).客户的问题、现场的问题，及时记录汇总，集中抽时间，向研发请教或讨论；

(2).测试的问题，登记Bug管理平台，集中抽时间，向研发反馈问题，沟通状况；

(3).项目经理把关，项目经理有责任保护研发团队的开发工作不受干扰，可以帮助协调处理、登记非必要问题；

(4).研发自我把控，告知相关人员，研发工作相对重要，请将问题记录，在某天某时找我沟通，确认问题细节；

 

6.常规功能的常规验证和提示

问题场景：

有些功能缺失常规的校验逻辑，基本的验证逻辑不能得到保障，不合法的数据得不到控制，影响项目的质量。

对于可以明确对应不合法操作或不合法数据的，最好可以提供明确的信息提示，便于客户、测试、开发自己理解。

如：表单页面，两个起始日期的大小校验；上传附件功能，文件格式校验、文件合法校验(exe程序)、文件服务器找不到；

表单录入存储，基本的邮箱、手机号码、输入长度、输入类型、非法字符录入、SQL注入等等

解决办法：

常规功能的常规验证，可以建立问题知识库，而不是仅仅存在每个人凭经验的脑海里，梳理出来。

研发每次开发常规功能时，要注意逻辑的严谨性，确保最基本的验证必须通过；

测试每次测试常规功能时，必须先把基本验证，验证通过才可以进行业务测试或高级测试；

这个可以慢慢的汇总积累起来，可以来自个人、来自团队、来自外部开放的资源。

7.UAT测试通过而生产环境出问题

问题场景：

在UAT环境下测试通过的功能，在生产环境下出现问题，除了环境搭建的差异导致问题的其他问题；

在UAT环境下测试的数据过于简单，在生产环境真实的生产数据，发现一些Bug和体验性的问题；

解决办法：

尽可能模拟生产环境，一些初始化的数据和配置项，尝试模拟搭建一套生产环境；

尽可能用生产环境的数据进行UAT测试，不要做简易数据的功能测试，尽早发现问题，不要推到生产环境再解决；

 

8.源代码的版本管理

问题场景：
对于要交付的功能，已经开发完毕，测试完毕，代码已经稳定，没有进行发布部署。

继续进行新功能开发，新功能还未开发完毕，就进行发布部署，在同一套代码里面进行修改。

解决办法：
需要确保交付的代码稳定，做好代码分支管理，代码版本管理，熟练使用源代码管理工具TFS；

 

转载于:https://www.cnblogs.com/SanMaoSpace/p/4924661.html