一个需求的正常迭代流程
墨菲定律
- 任何事都没有表面看起来那么简单
- 所有的事都会比你预计的时间长
- 会出错的事总会出错
- 如果你担心某种情况发生，那么它就更有可能发生
遇到的问题
- 业务方(BP)不知道自己需要什么，或者知道自己需要什么，但是描述不清楚，表达不出来
- 产品经理(PM)不知道BP需要什么，或者知道BP需要什么，但是不能向下游(开发，测试等)阐述清楚，或者再信息传递的过程过失真
- 项目经理(PMO)不明白自己需要做什么，或者知道自己需要作什么，但是不知道该怎么做，亦或是知道该怎么做，但是推行不下去
- 开发人员(Developers)喜欢盲目自信，有时候缺乏大局观，部分人员缺乏持续学习精神及能力，和上下游以及其它合作域沟通存在障碍
- 测试人员(Testers)对整个项目或者业务的理解不够，测试用例覆盖程度不达标，最测试这个角色认知不够，大多停留在功能性测试上，对必要的测试工具缺乏掌握
解决问题的方法
上面的问题在日常工作中都遇到了，在我看来，这些问题都是可以解决的
- 对于来自BP,PM的需求不清晰的问题，在需求调研阶段，PM应该多喝BP沟通，深入了解BP的工作流程及需要，有代入感，从自己作为业务的角度去总结提炼；需求出来后，评审前这一段时间，应该提前放出需求，让各阶段参与人员提前看到需求，要能接纳不同的意见；需求是根据业务需要讨论完善的，越早完善，成本越低；其次，作为PM，个人能力很重要，有时候，需求阐述不清晰，流程混乱，就是产品经理的能力问题，作为产品经理，应深入了解自己所在行业，提升个人整体逻辑能力
- 对于PMO，和很多PMO合作过，很多PMO根本不理解自己的职位，不知道自己需要做什么，更多的则仅仅在需求的前期阶段参与排期，排期定下后，很少参与整个迭代的运转；PMO最主要的、核心的职能是通过各种方式支持PM工作；不论是在人力、物力、财力等方面，只要这个项目和PM（项目经理）是企业批准的，PMO就有责任和义务全力支持项目经理工作，调配资源；但是在工作中，这些属于PMO的职责范畴的东西，PMO都不知道该去怎么协调，怎么规范，不能有效的形成一套规范，一种可持久体现、不依赖个人行为的组织行为；当然，这一切都是需要一个好的环境，有的时候，整个企业的氛围就不好，也就很难形成这种规范的组织能力。作为PMO，首先得了解自己的职能；其次，需要有和各部门不同迭代参与人员良好沟通的能力，个人能力达标，再依据公司赋予的组织能力，调动必须的资源，达到目的。
- 对于开发人员，因为开发人员是具体的需求实施人员，在整个迭代总有着举足轻重的地位；但是开发人员有时候会只专注眼前的事情，对整个项目，整个需求，缺少完整的认知，从而也会影响到具体的方案设计以及具体实现，有时候也会因此影响项目进度；还有部分开发人员，没有良好的开发规范及编码能力，这些都是项目中的不可控因素，因为这些在项目中后期，经常会造成项目延期及难易维护；作为开发人员，首先要认识到自己的职责以及这个职位的重要性；首先，要保持并持续增强自己的基本编码能力；其次，要有人人都是产品经理的意识，对参与的需求要有全局认识；要能够写出可维护的代码；对每一个逻辑最好都要有单元测试能覆盖到，不要盲目自信；最后，还要提高自己的沟通能力，多和不同域的人对接，培养自己的综合素养
- 对于测试人员，不能只停留于简简单单的页面测试，要多了解整个业务流程，要能写出覆盖率好的测试用例；同时，也要多学习，提高自己的专业技能；测试是一项高深的学问，涉及到严格的逻辑思考及方法论；测试的好坏直接关乎对产品质量的把控，要形成一个持久的流程及规范，把因为个人行为对产品质量的影响降到最低。
- 上面阐述的所有方法及注意事项，都要参与人员有积极向上的态度和强烈的主观能动性；需求迭代的各参与方，都应该有一个好的责任感和使命感；
- 最后，多和优秀的人合作