背景
你的需求是否被延期，交付出来是否质量不好，辛苦做的内容是否在无限期整改，一个个看似是人的问题，其实是项目管理的问题，认知不到位的问题。
本系列文章共上，中，下三篇。
归纳表格
| 现象 | 原因 | 行动（改善方法） |
|---|---|---|
| 研发交付之后，测试或者产品，提出了更多细节要求，然后要求实现，并且这些都是必要的 | 1 团队整体对需求评审把控不够；2 对产品需求理解不透彻 | 1 评审时，要求针对重大评审，产品的tl，技术的tl必须把控细节，挖掘细节，确定细节处的内容 2 产品在投入研发阶段前，产研团队做足够的需求细分，提前把细节完善 3 针对需求细节分三六九等，不重要的内容走后续迭代 |
| 研发交付效果不好，只是效果不好，或不够细致 | 1 实现效果没做预期 2 技术系分不到位 | 1 针对要达成的需求，给出技术方案的可能结果 2 针对结果，列出优劣，看验收方是否接受 |
| 研发实现了一种，产品觉得这样不好，这样不对 | 1 期待不同 | 1 对齐共识，除了日常迭代外，产品和技术要经常碰头，解决一些常见的共识问题，大概是什么类别的需求可以做到什么程度，会有什么缺陷（短期内解决不了或者一定要调研才能解决的） |
| 研发交付之后，提出了本次迭代还要做的衍生需求 | 1 就是和本次无关的需求 2 和本次有关 但是可有可无 3 和本次有关 ，并且一定要做的底层支持 | 1 不做 2 不做，放后续迭代 3 本次迭代延期，或者资源调动完成 （备注：无论哪种，都需要针对原因做复盘） |
| 提测质量不高 | 1 用例考虑不全 2 测试周期不够 3 研发质量确实有问题 | 1 增加完善的测试用例 2 根据迭代经验评估合适的测试周期，尽可能长，保证质量 3 做技术细分，做复盘，针对复杂的，自己不会的，要求多人参与设计 |
| 线上问题频发 | 1 脏数据 2 逻辑保护 3 测试期测试用例不全 4 历史数据 | 1 定期线上数据做分析 2 针对异常，做数据保护，访问保护 3 完善测试用例，尤其是预发环境的数据可以进行模拟功能测试 4 历史数据要做清洗，并在线下模拟历史数据（也可以不定期做线上的数据拷贝到线下） |
| 前后端联调效率低 | 1 并未提前定义接口文档以及mock数据 2 前端对业务，对接口的使用不熟悉 | 1 前后端均需要对数据敏感 2 前后端均需要对页面，对交互敏感 3 前后端均需要对业务敏感，并针对每个接口的影响面，执行逻辑，有明确的认知 |
| 前端的前松后紧 | 1 前松后紧多为前端，ui开发周期内可能没有接口实际调试，有些流程也无法实现动态链路，但后期接口联调，功能测试，自测工作量倍增 | 1 前端需要联系后端提前给出接口文档以及mock数据，这样至少在前期可以实现数据结构的使用的稳定，也可以就业务部分写正确的代码；另外建议如果ui完成后，可以先去做ui验收 |
| 后端的前紧后松 | 1 前紧后松多为后端，前期为系分，接口设计以及实现，但接口单测之后就坐等联调，等前端反馈问题 | 1 后端要结合产品去思考，为前端提供友好的调用方式和调用结构，前端完成部分功能后，可以协助前端共同完成测试而不是只等着有自己的后端bug才介入；另外一点也非常重要，除了保证单接口的冒烟，后端可以在能力上保证接口链路的畅通，比如下单，通过选择商品，加购物车，下单，付款几个接口的连续调用，后端预先实现相关的接口是稳定的可用的 |
| 要求尽善尽美，多在ui要求像素级还原；以及功能上和某某产品一致 | 1 盲目的要求完美 2 尽可能抄袭 | 1 多了解团队的能力在哪里 2 抄袭本身可取，但每个细节都抄就没有必要，想清楚重要的部分 3 迭代思想，如果你想做一个完美的事情，那么首先就是接受不完美，去长期迭代吧细节打磨的足够好 |
| 迭代前后没有关联 | 产品没有规划 | 1 做季度规划 2 每个迭代符合季度规划，符合整体目标 |
| 一个类似的需求反复修改 | 1 没有想清楚怎么做 2 试错之后，不知道如何复盘 | 1 多做市场竞品调研 2 针对每一次迭代要有指标可以衡量本次迭代的质量，效果，带来的收益 |
| 研发中后期发现实现不了 | 评估能力不足 | 1 邀请大佬参与评审，确定错误边界，能力边界，周期 2 做技术细分，评价风险点，如果实现不了，思考相应的替代方案 3 每一次有问题的迭代都去复盘，最终有没有实现，如何实现的，实现的缺陷在哪里 4 后续思考，还有没有可能倒退，当时还可以如何讨论这个需求 |
| 需求责任扯皮 | 责任边界不清楚 | 1 每个人负责什么，不可以做什么，明确清楚 2 敏捷，敏捷教练参与 |
| 具体需求的具体研发时间与评估有出入 | 1 不够细化 | 如果出入很大，一定要针对不确定工时的需求做足够的细分，可以不出完整的成果，但要有相应的原因列表，采坑列表 ，方案列表 |
| 技术系分做了没用 | 1 有能力没经验 2 超出能力 3 不会系分 | 1 提供模板 2 提供优秀的案例，是如何通过系分解决的 3 提供优质的资源，带领团队实现系分，而不是坐等 |
| 偶现问题 | 1 常规研发对交互对数据不敏感 2 没有监控机制 | 1 提供前后端的监控体制 2 有完整的链路在具有监控数据后复现场景 |
| 多人协作，某些思想不一致 | 团队磨合 | 1 敏捷培训 2 求同存异 |
更多
我的更多文章，收藏整理在语雀，1700+的文档，多年的小白复盘，希望能对你有些帮助，
