VUCA环境下，项目进度延迟是经常遇见的问题，如何解决此类问题？
今天分享一个案例，在这个案例中，基于“根因分析法”，对某主题客户端项目的进度延迟问题进行了分析，找到根本原因，提出了改进的策略，并给出了验证的策略，希望能够对大家处理类似的问题有所启发。
01
项目背景
某主题，致力于为消费者提供精品原创的个性化手机主题、表盘、字体、壁纸、AOD、铃声、美化等业务。
某主题秉持“匠心设计，灵感点亮生活”的品牌理念，助力全球优秀设计师、艺术家、开发者等内容生产者的优质作品获得全球曝光及丰厚回报。
2010年发布第一个版本后，截止2022年4月底，已经过28轮迭代，主要为用户提供主题商店和主题内容管理服务、会员服务、造字服务、评论、社区和互动服务、活动及福利、问题与建议、帮助和客服、产品运营和维护、第三方服务、购买服务、账号安全等服务。
从架构上看，可分为服务器端（即云端）、客户端（App），其中，客户端可装在手机、平板、车机等电子产品上。本文重点关注的是主题客户端项目交付过程中出现的进度延迟问题并讨论如何改进。
02
项目环境
01
外部环境
这个项目的外部环境呈现明显的VUCA特征。
VUCA是什么呢？VUCA是Volatility（易变性），Uncertainty（不确定性），Complexity（复杂性），Ambiguity（模糊性）的缩写。
VUCA这个术语源于军事用语并在20世纪90年代开始被普遍使用，随后被用到从盈利性公司到教育事业等组织的战略规划和项目治理中。
VUCA环境主要有如下特征：
V=Volatility（易变性）：用户尤其是移动互联网时代的用户，他们的需求和欲望一直在增加，这会催生更多的变化。
U=Uncertainty（不确定性）：对信息掌握得的不完备，会造成管理者缺乏预见性,缺乏对意外的预期和对事情的理解和意识。
C=Complexity（复杂性）：项目为各种力量，各种因素，各种事情所困扰。
A=Ambiguity（模糊性）：对现实的模糊，是误解的根源，各种条件和因果关系的混杂。
02
内部环境
项目是由团队成员来做的，但是项目管理者也会出于追求短期生产率和稳定性的目的而牺牲掉系统的自组织特性。
例如，把人和其他有机系统当做机器和生产过程中的附属品，长期以往，会造成核心骨干和核心成员的流失（IT行业的年度平均流失率为18%左右，远高于其他行业），在需求工作量不变的情况下，现有人员完成原定工作量的压力会加大。
03
定义问题
进度延迟
我选取了主题客户端5期项目（时间范围为：2022.1-2022.5），经过测算，项目平均周期79天（工作日）；
同周期内，主题客户端的基线版本计划交付周期平均为24天/版本，而版本实际交付周期平均为28.8天/版本。
由此可知，与计划相比，每个版本出现了平均延迟4.8天的情况。这就是我们客户端项目现在遇到的主要问题。
04
分析问题
1.分析方法：
根据3M1P1E原因分析法（即从传统的“人机料法环测”改造而来的“人机法流环”），并参考项目控制类型示意图（如图1），针对项目的进度延迟问题进行系统分析。
图1项目控制类型示意图分析过程
2.分析过程：
（1）项目团队：这个项目的人员包括，客户自研人员5名和合作方员工33人，合计38人。合作方员工即我方人员，2022年春节后到2022年5月23日，存在较大人员变动，比如项目经理和SE（系统工程师），整个团队平均在岗1-2年的员工，人员整体能力不够稳定。
（2）项目环境: 服务器，数据中心、开发终端、手机，PAD等电子装置，都比较齐全。常用3类环境有开发环境（主要是开发人员用）、测试环境（主要是测试人员用）、模拟生产环境（有的业务存在）；办公环境，符合EHS（职业健康安全）要求；网络4G/5G，WIFI信号是否足够强，经排查，环境影响较小。
（3）开发模式：项目组的产品开发采用的是DevOps模式（图2），没有变化。DevOps是Development和Operations的组合，可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集（如3）。
图2 DevOps流程和关键活动图
图3 DevOps组成结构图
经过详细分析，主要的原因有：
（1）客户端14.300之前的版本创建计划时，存在需求评估不充分、资源因素（时间）未考虑进去，导致后期开发时间短，无法按时交付出来成果。
（2）虽然走的是DevOps门户发布，但是这个门户的功能也是在不断迭代升级中，基本上平均每周都有2-3次的小的功能升级，每月会有一个大的功能发布或升级，而功能变化，开发人员、测试人员和QA可能都需要学习适应，这个过程也会影响版本的整体交付进度单。
（4）开发过程：通过拉通SE、项目经理、开发和人员，确认版本进度计划过于紧张分析，规划过于简略。
（5）过程控制：通过2022年2-5月4个月的流程遵从度审计，QA发现部分开发人员存在不遵守开发流程的情况，如在存在部分员工，每日编码完成后未充分自自验证就合入代码、未及时提交代码以及用其他非关联需求单或问题单合入代码的情况。未验证合格就提交代码会造成代码质量差，影响产品的功能、性能或安全；未及时合入会导致开发完的功能无法及时与其他代码实现联调，影响功能的及时实现，甚至产品的按时发布；而借单提交则会出现代码的追溯风险（端到端考虑）。
05
解决问题
针对进度延迟的原因，经过详细分析，项目团队提出了如下改进策略
1.优化产品需求和功能开发过程
（1）系统工程师（SE）引入用户故事地图、卡诺模型等工具技术,优化产品和需求规划和设计，确保对客户来说高价值的需求能够优先设计。
（2）基于Scurm框架，项目经理进一步梳理版本及迭代需求列表、调配资源、做好迭代计划和跟踪，以确保高价值需求得到优先开发。
（3）迭代开发过程中，改进迭代评审及回顾会议，以及时解决问题并做好迭代和阶段总结。
2.增强持续集成和持续部署能力
（1）完善代码托管，确保软件资产安全性、做好代码变更的管理工作。
（2）优化持续集成（CI）功能，执行快速代码检查，QA跟踪，确保开发人员及时修改问题并闭环。
（3）持续开展工具链建设，提高持续构建和持续部署（CI）的自动化程度、并加强流水线的质量控制。
3.改善持续反馈和知识管理过程
（1）VOC驱动，利用画像系统和缺陷跟踪系统，项目经理组织团队做好客户的声音（包括建议和问题）的分析，测试和开发人员协同快速响应客户的需要。
（2）基于历史和当前数据，产品经理和项目经理动态调整规划，确保高价值的需求和功能得到优先发布。
（3）持续学习与改进，从项目经理到员工都要主动思考、持续改进，做好事中评估和项目总结。
06
效果验证
1、验证方法：
进度控制有效的验证的方法，是比较计划交付时间和实际交付时间的差异，偏差在3天以内，方可认为，进度控制是有效的，改进措施是暂时有效的。比如客户端15.300版本，与原定计划（4月30日）相比，正常发布，无延迟，初步认为进度控制是有效的。
2、验证结果：
16.300版本预计发布时间是2022年6月24日，实际发布时间也是6月24日。这个结果短期内是符合预期的，但是还需要观察2-3个版本，再评估改进长期是否有效，如果只是短期有效，长期无什么效果，需要进一步分析。
07
总结
在上述案例中，我介绍了这个项目的背景和环境情况，整体采用的是“定义问题-分析问题-解决问题-效果验证”框架，基于这个模型框架，我认为主题客户端项目进度延迟的主要原因是资源不足、计划不合理、迭代总结不及时、流程遵从度较低，因此提出了需要优化产品需求和功能开发过程、增强持续集成和持续部署能力和改善持续反馈和知识管理过程等三大建议，另外在效果验证上，我认为验证需要兼顾短期改进和长期改善。
