“Excel”与“代码”的冲突：软件审计的思考

由于是在一线冲锋陷阵过的，所以我比较排斥把工作做成Paperwork、做成纸上谈兵，而汽车软件行业目前的审计是Paperwork比较典型的代表，负责审计监察的PMO或质量经常幻化为高级Checklist打勾工程师。

就像将士在前方浴血奋战，文官御史们翻开大清律例向皇上参他们军容不够整洁，不是说不对，而是抓不住重点，俨然一副食古不化的腐儒面貌，看起来是不太行的。

大家心目中理想的文官呢，最好像优秀的宰相一样，能够顾全大局，可以平衡矛盾，上应皇命，下抚百官，既不乱了纲常礼法，又不能拂了朝局大计……

但是！

这个道理并非大家不懂，而常常是不能，能力不够，信息不足，职责不许，权力不允。

就像，对于文官出身的御史们，他们是否有能力去评价百战将军排兵布阵的合理性，是否有信息去判断巡抚知府国策落实地区的特异性，是否有资格对刑部判案方式品头论足，又或者上书皇上后是否能够得到支持……最后落脚点似乎只能在律例礼仪的捍卫上。

那么，我们对这个角色抱有宰相的期望是否是一种执念？

尽管中国在周朝就有了独立的监察制度，历经3000年不断发展变化，一直存有这个体系，乃至到了现代，这个角色依然不可或缺。这在一定程度上是否能说明它的必要性挺高？毕竟也3000年了。

但在网上搜索一下历史上著名的御史，似乎能够比较知名的也就一个曾做过一段时间御史的海瑞，还是几乎敢舍了命的主，一大部分是靠不怕死留的名。而回想一下宰相或将军，却是一大把。这在一定程度上能否说明它的重要性不高？毕竟也3000年了。

当然，我不是历史专业，随便拿了例子来引出，很可能有失偏颇，但是“搞理论的务虚”与“搞业务的务实”之间的冲突与鸿沟是显然存在的，怀抱Excel务虚者的无奈和敲打键盘码代码务实者的不屑也显然是存在的。

那我们该如何看待这个有必要但不那么重要的工作呢？

要看你所处的环境是法治还是人治。答案显而易见，越是法治的地方越重视流程或标准审计，越是不容易在权衡决策时被权衡掉。

这个道理本来没什么可单独拿出来说的，想强调的是，法治和人治并不必然有清晰的划分界限。

总体来看，外企相较于民企更接近于法治，工厂相较于研发更接近于法治，劳动密集型相较于智力密集型更接近于法治，成熟产业相较于初生产业更接近于法治，财务相较于销售更接近于法治，底盘相较于娱乐更接近于法治，代码编写相较于项目管理更接近于法治，外审比内审更接近于法治，16949比ASPICE更接近于法治……

但并不尽然，我们所处的企业是个复合的系统，外企里有需要推杯换盏的本土销售，民企里有精打细算的财务会计，工厂里有三教九流工人的管理，研发里也有关键测试的严格规程，有的标准大家还在探讨，有的标准已经被业内普遍认可，有的领导认为好的流程执行导致好的结果，有的领导就是认为人定胜天……

法治还是人治。有时候是来源于各人文化观念的差异，有时候是来源于内在工程逻辑的需要，有时候是来源于外在政治或业务权衡的诉求，有时候则又是来源于整个行业技术发展的成熟度。

作为一个PMO或工程质量，面对审计监察工作时，是至少需要在文化、逻辑、业务和行业这四个层面动脑筋的。

文化环境、业务环境和行业环境往往是我们难以掌控的，可以去理解和揣摩，但不太容易使力。

所以，我们下一个篇幅先着重探讨下审计在内在逻辑上的现实实践。

开局先总结一些关键词和现状。

审计的层次：有没有、对不对和好不好，现实里往往只能做到有没有做，或者按照纸面标准对不对，但基本无能力做到按照实际业务情况判断好不好；

审计的对象：产品和过程，现实里往往只能做到过程是否遵循，以及产品表现的度量指标是否有问题，好一点的看下数据趋势，而很难具备判断产品、软件、测试设计的好坏及合理与否的能力；

审计的一些基础思维：凡事预则立（计划思维）、事事有着落（闭环思维）、完整不遗漏（系统思维）、自己说了不算（评审和批准思维）、拿着要求说问题（标准思维）、决定不能拍脑袋（分析思维）、历史要清白（基线思维）等，能够透彻理解并讲清楚这些逻辑，是审计者安身立命的法宝和最后的杀手锏。

这是理论，实践时可以偶尔回头看一下，辅助指导下实践。

项目组的人经常挖坑和填坑。作为审计的你，其实就是负责找那些没被填好的坑或意图藏起来的坑，找坑的本领彰显你的本事。

一、没有规划或不充分，对于一个项目没有整体的规划或团队成员不清楚。

比如，立项的背景是什么，是要沿用量产产品修改标定优化某些表现，是要应对新升级的法规，是要进入某些新的国际市场，是要解决上一代产品什么样的局限，还是要新增某些新功能点……比如，项目运行的模式是什么，是全栈自研，是模块分包，是多供应商同级供应，还是单供应商全部交付……比如，项目定义的方式是什么，什么样的项目架构，是基于哪个软件拉分支，变更范围什么级别，裁剪为什么样的项目类别，是否要完成ASPICE L2的认证……

当然，这是很大的话题，涉及的内容往往也超过软件自身范畴，但如果交流过程中发现这些信息都非常模糊，可以反向识别出项目启动会或日常内外部沟通会等统筹或信息传递的会议计划未制定且未执行、项目章程或项目启动文档等类似纲领性文件没有编制或没有发布等。

二、没有计划或不完整，以及计划未被很好监控等，计划是更细节一点的，但也是涉及方方面面的。

比如，最基础的时间计划（其他具体的活动也是类似），没有及时更新，里程碑不完整，目标显然无法达成，工作包之间的依赖关系不清楚，计划没有在各部门打散到可执行颗粒度（如无具体的软件开发计划），计划在团队内外部没有达成一致认可，计划部分内容已经超期也无应对措施，工作包没能落实到人，计划执行没有被监控（如无工具里的任务项、开口项清单、会议等），任务项没有按照要求导入到工具里，无法识别出关键路径，资源设备不充足……比如，Feature开发计划，看不到Feature的成熟度，没有明确Feature与里程碑的映射关系，没有和需求有映射关系……

三、开口项跟踪不佳，开口项跟踪是项目经理的主要武器，也是经常会查出问题的地方。

比如，没责任人，没截止日期，描述不清楚，会议上也不沟通，长期无人处理，有些已经超期且也没有对策，录入系统的开口项各字段胡乱填写，未完成的开口项对交付的影响无分析……

四、缺陷管理不佳，Bug是软件比较有特点的一个部分，是务实的人最关注的内容之一，由于软件Bug动辄几千上万，一般都需要特定的系统进行管理，也是出问题的重灾区。

比如，不按照流程进行推进，不分配对应的角色，随意关闭，缺陷等级划分不合理，测试失败项不对应Bug，修复版本和计划混乱错误，Root Cause描述不清楚，问题内容描述不清晰，未与相关的变更、测试用例等建立链接，无法按照计划完成修复，带严重Bug交付，释放文件上声明的清单不完整，交付时遗留的Bug未进行风险分析……

五、变更管理不佳，变更是个极为普遍的活动，甚至很多项目完全就是靠变更驱动的。

这里的问题可能会有，变更影响分析没有进行，没有上CCB就执行，要变更的范围没说清楚（如什么需求、什么版本、哪个章节、变什么……），与该变更相关的需求、测试、任务、开发等无追溯，变更长期无人处理，基于未冻结的内容进行变更，规划的变更未执行软件就被释放，变更与Feature计划未对齐……

六、配置管理不佳，这部分不多说了，前面文章讲了很多（详见数字化配置管理尝试），这部分现在比较弱化了，问题呢，不外乎配置项不全，配置项及整个矩阵无评审无批准，没有打基线……

七、需求管理不佳，需求可以分客户、系统、软件、法规等很多层次，我们放在一起来看。

比如，未考虑法规需求，原始需求没有存档和版本控制，需求没有被拆分，需求没有标记出状态（如被接受、被拒绝、被执行等），未被接受的需求没有相关上游客户的认可，需求Q&A没有关闭就被执行，缺少性能或接口需求，需求颗粒度太大（如软件需求只有概要的描述，未区分不同场景），不同版本的需求文档无变更履历，功能没有按计划实现，还有没有被评审和没有追溯的常规操作……

八、设计实现不佳，实话实说，这部分属于专业玩家的范畴，具备评价设计水平和合理性的审计员基本没见过，多数能做的还是比较浅的管理上、流程上的审计。

比如，没有架构框图，没有功能分配，没有时序图，没有接口定义，没有评审，没有追溯之类，各处信息不统一，未关注资源消耗或已超标（内存、CPU负载等），未完成软件复用分析，代码模型没上传……

九、测试验证不佳，这部分的测试设计、脚本编制、环境调试等专业领域依然不容易深入，只能尽力而为，而因为这个工作目标性很强，即找Bug，所以除了依然要关注策略、计划、评审、追溯、跟踪的一些管理类问题（详见汽车电子软件测试的“脉络”），相对更多会关注到结果。

比如，报告错误（如原始报告未通过，实际汇总标记为已通过），覆盖率、执行率和通过率偏低，静态验证违反项未修复，Fail项未触发Bug或无风险分析……

此外，还有些通用的，不一而足，比如，同样的信息在不同区域显示很容易不一致（如系统和excel，不同模板之间，功能安全和FMEA），描述不够精确（Bug表现描述不清，需求描述不清），模板使用错误，未按规则命名，一个决定无支撑证据等。

……

潦潦草草写了近四千字，总结了一些浅薄的经验，但远远不足，离实际运行的业务还是有不小距离。

不争的事实是，国内汽车圈里能够真正深入业务的流程岗少之又少，而又想让这种不深入业务的审计有价值，只有反过来让各环节真正将流程重视起来，大力制定更合适的流程，且严格执行，即使在某些情况下，这流程显得有些纸上谈兵，但还是为获得效率和质量的平衡而得到上层的支持。只有这样，流程才会臻于完善，价值才会逐渐提升。

显然，这又在国内市场和企业里不太现实，悖论呼之欲出。

这就不得不让我们思考组织模式的问题和流程的价值。