《A++ 敏捷开发》- 8 获取高层支持

我：对过程改进来说，最重要的成功要素是什么？
客户：最难的是如何得到高层的支持，这不仅仅是嘴巴说说而已，而是要切实地给人、给时间。高层往往不清楚什么是质量改进的重点，但他们对员工的人均收入、利润（比如员工可为公司盈利的时间占比。如果少，就表示这个员工对公司的盈利贡献不够。）等这些财务指标都非常清楚。
我：非常赞同。我们可以利用评估机会来引起高层对质量改进的重视，但往往评估组只说软件开发的各种问题，难以引起他们注意。一般人，尤其是高层，一听到问题都会觉得比较烦，没有动力听下去，更不要说有对应的改进行动了。
客户：你说的挺有道理的。确实我们每年都会有一些评估，发现了不少问题。高层也都会参加评估会，并同意这些问题需要改进。但很多时候过后就没下文了。
我：质量大师裘兰博士(Dr Juran) 有丰富的过程改进经验，他深知要说服高层真心投入、支持改进，就必须用高层的语言打动他们。如果与高层交流，不能把团队关注的事转化成高层关注的，就难以获得立项，做改进。
我：所以在最近的某评估里，我会引导公司内部的质量经理，跟公司高层汇报时，着重汇报能为公司节省成本的初步方案。你有兴趣听听这案例吗？
客户：非常有兴趣。

案例

我问公司内部评估组，高层有哪些关注点？他们就列出来，如人均收入、人均利润等商务指标。
然后我再问影响这些指标的因素很多，有些是软件开发团队无法控制的，例如销售人员与客户的关系，所以我们必须从这些高层关注的指标细分到一些团队实际可以影响到的指标。有哪些呢？
质量经理：项目进度的偏差，遗漏给客户的缺陷数。
我：这些我们都叫性能目标。这些指标是如何影响高层目标的？
质量经理：比如项目延误，成本就会超支。
我：是的。如果我们过程改进希望改善质量、减少缺陷，你们觉得会对成本有什么影响？
质量经理：改进要投入工作量，肯定会增加成本。但长远应可降低成本。
我：很多高层都不熟悉质量管理，所以很少关注和监控团队的缺陷。他们通常还是会觉得质量改进是好事，但要花成本。我做到客户满意的水平就可以了，不要追求十全十美，也正是这个误解，才导致他们认为大部分缺陷在系统测试或验收阶段才发现是正常、是常态。如果是开发软件产品的公司会好一些。在软件工程领域，因为缺陷发现越靠后，返工工作量是前期发现同样缺陷的2、30倍。所以如果我们能把返工缺陷预先发现并处理，必然会大量降低返工工作量，与相关成本。

理论上也可以用缺陷排除率来估算改进后的缺陷分布（会在后面迭代回顾里细讲），但高层一般不会注意这些细节，沟通越直接越简单越好，所以只需要简单估计改进后的数量，大家觉得合理便可。

第一版方案书

质量经理做了第一版的方案书。

我：挺好的。你在投资方面是保守型吗？
质量经理：不是啊，我还会定期买股票，因为单是靠银行定期，利息太低了。
我：但是看你在质量改进方面的目标很保守。比如你看，说如果做了改进以后，后面的缺陷可以降低10%到20%，然后最后算出来节省不到5个点。你估计高层会买单，投资你这个项目吗？
质量经理：确实有道理。
我：你这里有几个地方没做对，例如从我们过去的经验，因为很多团队在前面几乎没做好单元测试或代码扫描，反之，系统测试或者验收测试的缺陷几乎可以减少一半。低的目标不是好目标。还有，你评估在后面阶段返工的工作量也太低了，只是比前面发现的高一点点。你尝试依据这2个思路再调一下吧。
质量经理：你有所不知 ，我们虽然有些行业参考数据，但没有实际项目数据支撑，是否需要先找些实际数据才可以做方案，不然好像说不过去。
我：在初步方案阶段，其实不需要实际数据的支撑。你可以想象，目的是要让管理者有依据做决定，你可以利用实际数据把节省算得更准确，但对高层决策没有太大帮助。所以在初始阶段，合理的估算就足够了，不需要花精力在没有价值的事情上。

第二版与中层确认， 然后向高层汇报

做了第二版后，大家觉得这确实比之前更有说服力了，质量经理再跟中层确认。

质量经理跟高层汇报，并得到高层的认可后，高兴地说：以前都以为过程改进应先自己默默耕耘，先在试点取得效果，再跟高层要资源后再推广。现在看，还是应该一开始便提具体改进方案并立项，才有机会成功。
我：管理层是过程改进最重要的干系人，必须一开始便得到他们支持。你后面有什么计划？
质量经理：既然他们都同意，我就找项目试点，对吗？
我：虽然试点很重要，但不是第一步。你们一直有过程改进小组吗？
质量经理：懂你的意思，但实际没有。团队有关质量问题便会直接找我。
我：应让团队自己依据迭代数据分析根因，下一轮做改进。但有些需要跨功能或组织级改进，如完善复用框架，或完善规范/指南与相关检查单等，便需要依靠过程改进小组来推动。如果你们没有，便应尽快举办工作坊互动培训，邀请所有过程的利益相关者参加，一起讨论未来改进重点并制订具体短期长期目标与计划。
质量经理：你说的有道理，请发我相关案例，打铁趁热，我尽快跟高层说。

结束语 以上简单案例的经验教训: 有效的质量改进必须从获取高层支持开始。 中层要从高层关注点（￥）提改进方案。 在做改进方案时应根据现状估算，暂时不需要实际项目统计数据，以节省资源和时间。 如果确实有高层真正支持的话，就必须正式立项，再配上具体的团队与分工，否则整个改进计划还是一纸空文。 立项后，可以借助集体工作坊培训，让大家一起制定目标和行动计划。 反馈 某CTO： 方向很好，但高层不仅关注如销售额这些商业指标，也关心交付效率和质量相关指标。 公司老板针对于研发除了关注成本外，也关注以下内容： 人员：人均薪资、人均产能、人员参项率（有收入的项目）、人员闲置率 进度：是否能正常交付 质量：缺陷率、严重缺陷数 例如，公司都会用人均产值，人均交付金额等指标。但有些公司业务很稳定，公司不一定关注创新：例如，针对重复性工作，是否能基于以往项目形成公共组件或低代码平台，来大幅度提升生产率。质量方面，如果客户能参与使用，例如产品定义，需求的质量会大幅度提升（不仅依赖评审、测试）。为什么客户不愿意深度参与？是否因为没有让客户可以高效参与的工具。 例如，需求调研过程，90%以上的公司都是靠需求文档、需求场景和原型(RP)方式来沟通，效率不高。但如果低代码平台能快速形成需求和客户可体验的需求，效率和质量都会大幅度提升。 所以不应只关注如何尽量提前发现缺陷。 我：是的。但想要过程改进成功，首先必须得到高层的支持，很多高层不一定关注质量，只关注项目是否按时交付和财务指标。所以质量改进方案必须强调能节省多少人力成本，不仅仅是质量提升，才有机会得到高层支持。 大量缺陷在后期才暴露是最常见的质量问题。提前发现并消除这些缺陷最容易能提升项目质量，并降低成本（因大幅减少返工）。所以上面案例使用这质量改进作为例子，但如果面对像你这种通情达理的高层，就可以更全面，从质量、创新等多维度估计改进能如何为公司带来价值。