|
作为IT大军的一员，不论从事什么岗位，产品、开发亦或是测试，项目实施中，大家都可能问出或者被问以下这些问题，我相信屏幕前的你一定也是感同身受，下面谈谈当总被这些惊魂之问环绕时，我们可以做些什么。项目管理者联盟
一、被嫌弃的产品小白项目管理者联盟
写出一份优秀的需求文档，以产品经理的本领，不算是一件困难的事情。但实际项目过程中，需求写的太简化，变更太频繁，开发和测试的抱怨和投诉接踵而至，产品经理这样的经历一定不会少。pmp.mypm.net
1、需求就这么两句话?项目管理者联盟
需求调研不可省：产品经理想要需求分析全面，初期可以“访谈式”沟通，通过访谈、问卷调查、调研会等获取业务真实诉求;中期可以“诱导式”演示，通过原型演示等收集业务反馈意见;在上述阶段成果基础上，可以通过“确认式”评审与业务进行达成一致。项目管理者联盟
文档模板标准化：好的需求说明书模板可以帮助产品经理将需求分析的更完备，特别是容易遗漏的非功能性需求，如安全性需求、性能需求、报表需求等;过程中可以根据反馈意见和常见问题，对模板进行持续升级。重要的事情说明三遍：模板制定后要使用，要使用，要使用。PgMp.mypm.net
需求评审有底线：需求文档是开发、测试阶段最核心的输入之一，开发和测试人员在参加需求评审时，针对需求描述不完整、有歧义、一笔带过的现象，主动提出评审意见，避免实施过程中自己对需求进行猜测和加工，带来各种返工。项目管理者联盟
2、需求怎么总在变?项目管理者联盟
提前识别、积极响应：大多数变更来源自业务方，产品经理要从源头识别存在的“假”需求，挖掘出业务真正的诉求(前文提到的“访谈式”沟通、“诱导式”演示、“确认式”评审)，降低后期变更几率。项目过程中关注内外部环境(市场、政策等)，定期对需求进行审视，发现需求不合适/遗漏的点，及时提出，做到“早发现、早治疗”，不可为避免变更而掩藏。talent.mypm.net
规范变更、守住底线：比变更更可怕的是变更不通知相关方，这也是测试常常吐槽产品经理的点;项目过程中各类变更应按规范组织变更评审，形成达成共识的结论。同时要控制评审准出，不是所有的变更都应得到批准，不合理的变更该拒绝的要拒绝，如临近上线要新加需求。talent.mypm.net
二、问题改不完的小开发training.mypm.net
1、这么简单的功能也出错?
程序员群体流转一句话：不写代码就没有BUG。项目中我们不苛求每个开发都能不引入BUG，我们要做的是争取少引入BUG，争取一次把事情做对。talent.mypm.net
代码规范要能落地：绝大多数组织都有自己成熟的编码规范，而能真正落到实处才能让规范发挥作用。一方面，可以制定易记忆的简化规约和checklist等各场景进行应用，另一方面，可以使用代码扫描工具的自定义规则将组织规范进行固化。项目管理者联盟
代码评审要有效果：评审可以最好的发现BUG，也容易流于形式，实操时可以多样化，根据情况因地制宜。评审方式上交叉评审、会议评审、代码走读、专家评审等结合使用，范围上可以重点覆盖核心模块、复杂业务逻辑、新员工负责模块等;项目经理圈子
自测试能力要建设：首先，要提升自测重视程度，自测通过才算编码完成，自测的工作量投入要得到保证;其次，自测范围需包含单元测试、接口自动化、冒烟测试，要能覆盖正向、逆向、正常、异常、并发等场景;最后自测的结果要保证，单测覆盖率、通过率、自测功能覆盖度等要符合准出要求。club.mypm.net
2、这么点功能要这么长时间?blog.mypm.net
我们常常因为工作量和业务进行争论，业务认为一个简单功能报这么多人天是在坑他，总结来说就是业务认为工作量不合理，我们又说服不了业务，让业务认为这个工作量合理。club.mypm.net
任务项分解合理是前提：可以基于需求功能清单进行拆解，估算各功能模块所需的产品、开发、测试等工作量，也可以基于项目阶段的WBS拆分进行各工作包的估算。需要注意的是避免有遗漏工作项，特别是支撑型活动，如评审类活动。这样各项任务所需工作量可以明明白白的展示给业务方。项目管理论坛
工作量专家评审更权威：工作量屡屡遭到质疑时，引入专家评审是最能让各相关方信服的手段。通常可以选取同领域的同行专家对项目工作量进行评审复核，专家选择上要尽量保证其独立性(非直接利益相关方)、权威性(该领域内的资深人员)。training.mypm.net
工作量最核心原则是要估算合理，其不仅预测未来，而且会影响未来，过低的估算会导致过低的质量，可能要返工，过高的估算可能减低工作效率。另外技术角度上，系统架构要做到可扩展和可复用，以弹性的架构来解决研发效率问题，降低研发成本投入。项目管理者联盟
三、总背锅的测试萌妹项目管理者联盟
1、这个BUG为什么测不出来?项目管理者联盟
这一定是大多数测试而言都是最怕遇到的灵魂拷问，漏测虽说是测试心中永远的痛，但只要不回避问题，不急于撇责甩锅，就是优秀的测试。pmp.mypm.net
漏测分析第一步：遇到生产问题，测试最先做的是第一时间组织测试复现和漏测分析，使用根因分析方法(5WHY、鱼骨图等)分析各个环节存在的问题，制定相应改进措施，不断反省改进，才能提高。项目管理者联盟
|
