敏捷模式下团队需求交付延期分析

一、背景

每个团队的交付质量不一，有的团队能够保质保量交付，而有的团队交付质量则差强人意，时常发生延期交付的问题。

二、延期的原因及解决方案

是什么原因导致了需求总是延期交付？多方面因素！

原因一：需求不明确，理解歧义或存在漏洞，在开发阶段发生需求变更

这个最为普遍的问题，因为短时的需求评审会，或者不够充分的需求

建议实践：

• 建立产研需求前置沟通机制：在正式需求评审前，产品经理同对应的技术侧同学进行前置的非正式的需求沟通并达成一致，使技术人员提前介入并了解需求
• 建立需求产品内部自评机制：产品团队内容有限完成内部评审并达成一致，而后再发起产研测大范围的正式需求评审
• 产品团队建立标准PRD参考模板，尽量标准化、规范化RPD文档形式
• 团队建立对RPD的评审检查单，提升需求评审的质量

原因二：研发团队交付提测质量不佳，导致测试阶段问题较多，极大阻碍测试工作
由于开发工期的紧张，以及极力避免 “延期提测”，研发人员在开发质量没有得到保证的情况下依然发起提测，导致在测试阶段出现大量的、低级的测试缺陷。虽然，这类缺陷解决成本并不高，但依然对测试同学的工作造成影响。

建议实践

• 增加研发自测环节，在提测前研发须完成对自身代码的测试工作
• 严格把控代码评审，在提测前发起执行
• 引入代码扫描工具、AI分析工具前置分析代码问题

原因三：测试缺陷修复不及时，影响测试进度
测试阶段发现缺陷后，研发人员解决的及时性和效率较低。原因在于研发提测之后，其主要精力不再完全关注当前迭代，可能会分散到其他工作中，导致测试缺陷迟迟不能得到解决，影响了测试进度。

建议实践：

• 团队建立缺陷解决相应机制，例如要求上午发现的缺陷必须在当天解决，下午发现的缺陷不迟于第二天上午解决
• 团队采用更灵活的协作机制，如果可以，测试人员直接面对面驱动研发协作解决缺陷。
• 对于可能由外部团队导致的缺陷阻塞，团队层面建立协调机制，一般由产品经理作为接口人对外协调推动。

原因四：联调过程不顺利，特别是外部联合调
一般情况下，同一团队内的前后端联调工作相对会比较顺利，大家的工位相隔不远，可以及时的面对面沟通。但是当涉及到与外部系统进行集成联调试时，在跨团队甚至是跨地域情况下，联调的沟通协调工作会变得困难，并且，联调过程中出现问题后解决的效率远不及内部团队。

建议实践

• 建立内外部集成联调机制

原因五：设计方案不明确，开发过程中调整技术方案技术方案
理论上不应该出现变更，但实际上却非常普遍。在快速迭代的环境中，受设计周期因素的影响，技术方案不可能设计的面面俱到，总有一些细节会在后续落地过程中显现出来。

建议实践

• 团队建立技术方案参考模板，规范化技术方案的文档形式
• 团队建立技术方案评审检查单，并在评审会完成check
• 如果确实出现无法识别的问题导致技术方案变更，评估是否可能导致延期。如果延期及时上报并接受或协调资源吃掉延期

原因六：研发成员对开发周期评估不足，开发过程中产生额外工足量，导致无法按里程碑完成开发工作
技术方案设计阶段对开发工期评估不足，任务拆分不够详细或者有遗漏，或者没有考虑单元测试的工作量等等，都会无形中增加研发投入工期，导致不能按时自测和提测。

建议实践

• 技术方案中包括明确的开发任务拆分、人员分配和工期评估
• 单元测试按照1:1.2 - 1:1.5进行合理评估
• 对于涉及外部集成的需求评估外部集成联调工期
• 技术方案评审确保开发团队都能准确理解，降低理解歧义

原因七：上线过程不能顺利，系统无法正常发布或无法正常验收，导致上线失败并延期上线

建议实践

• 团队增加上线计划评审环节，正式发布生产环境前必须要经过上线计划评审。同时，上线过程中，完全按照上线计划约定的上线脚本进行操作。
• 引入CICD流水线进行自动化发布，降低人为操作影响

三、我的观点

• 观点一：需求延期并非“不可原谅”，某些客观因素可能导致延期发生，团队应该保持客观、理性看待。从需求到发布的多流程阶段进行管控有助于降低需求延期交付
• 观点二：管理者应当切忌把“延期交付” 作为打压团队绩效的 “抓手”，优秀的管理者应该引导团队进行适当的反思和优化