车载软件开发中的几大浪费

关于项目延期的原因，在项目经理的外部报告里，常年霸榜的无非两个，一个是客户需求频繁变更，一个是外部输入不给力。

说白了，不是客户问题，就是对手件问题，反正自己没问题。

敏捷强调可工作的软件高于详尽的文档，因为文档有时候就是个文字游戏，逻辑上形成闭环就行了，并不能反映实际情况，也不能解决具体问题。

项目经理的报告永远是对的。翻开里程碑报告，我们总能看到客户需求模糊、系统设计不合理、第三方接口延期等各种外部问题。潜台词就是——我这个项目经理是OK的，换其他人也一样有这些问题。

这些原因可能是事实，因为从工作分工来说，项目经理负责的东西本来就是虚的，把这些虚的东西落到实处就必然变成别人的问题。对于项目经理，把握事实当然重要，但更重要的是做好自己可控的事情，少浪费点时间，少做点无价值的工作，项目日程压力自然就小了。这比罗列各种延期原因更有意义。

所以，今天我想总结下车载软件行业的几种浪费。

第一、无意识浪费。在制造业，产线停马上就会被发现，软件不一样，只要人坐在电脑前面，就是在工作，闭眼沉思也是工作。所以大家对浪费的意识很薄弱。比如，明天发版本，测试人员本应该今天9点拿到软件，下午了也没拿到，那他可能会干点别的，不一定马上就暴露出来。但实际上，这时“产线”已经停了，已经造成了浪费。就像这样，很多浪费是无意识的，项目经理应该让全员有防止浪费意识，有了这个意识才能谈如何改善浪费，所以无意识浪费排第一位。

第二、错误认识导致的浪费。有些产品经理总会抱怨客户需求说不明白，不知道想要啥，然后等着客户自己想，让客户自己琢磨，工期被白白浪费，出了问题都推给客户。其实，客户如果能把需求能说的清清楚楚明明白白，那软件公司是不需要配置产品经理这个角色的，产品经理的价值就是在这个时候体现的。需求不明确，我提案，需求不清晰，我梳理。就像空姐的价值不在端茶倒水，而在应对紧急情况。有些浪费是认知错误造成的。

第三、沟通浪费。这个是浪费最严重的环节。脑力劳动的外化表现就是沟通，基数大，浪费的就多。举个例子，两个人面对面坐着，几句话就能沟通明白的事情，非要用微信打字。还有组织架构不合理导致的浪费，分明PO可以直接和客户沟通，却必须经过项目经理确认，加了一个环节就加了时间的浪费；另外，客户按着业务维度（车型和功能）划分职责，供应商按着管理维度（需求管理，问题管理和日程管理）划分职责，导致重复沟通。这样的浪费不可胜数。

第四、形式化浪费。为了走流程做样子而造成的浪费。比如，开发人员在管理工具上写Bug信息，修改内容写修改参数，影响范围写控车模块。这种粒度的信息，对于写的人和看的人都是浪费。要搞清楚具体信息，双方要花费的时间远远大于一次性写清楚的时间。

第五、查询浪费。软件行业有很多工作是由文档支撑的，因为一眼不能看清别人的脑子，也不能保证自己什么都能记得住。但很多时候，为了方便：信息只口头确认不书面留痕，书面留痕的阅后即焚，用一次花一次时间。这样就导致找资料、追溯等浪费很多时间。这方面，我觉得做好配置管理很重要。

第六、等待浪费。项目经理分不清轻重缓急，不放权，什么事情都要自己把握。自己忙得焦头烂额，项目还是各种卡顿。本来是想做好事，最后成为了项目最大的瓶颈。

第七、信任危机造成的浪费。客户已经不信任项目团队，要求提供本来不需要的成果物来证明产品质量或流程执行情况，这些动作造成额外成本增加。比如，由于提供的资料多次出现漏洞，客户要求每个资料上都需要加盖各部门印章。再比如，由于测试总流出Bug，要求每个测试结果后都需要附加log文档。

以上是我自己的一些感悟，没有通用性，也不符合MECE原则。当然，也不全面，软件行业的浪费不止这么多。

自软件定义汽车兴起以来，大量缺乏工业制造经验的软件企业涌入汽车行业。而汽车产业素有 “工业皇冠上的明珠” 之称，拥有极为成熟的体系、标准与方法论。因此，软件企业若想更好地服务车企，很有必要借鉴汽车工业的优秀实践。

丰田精益生产中提出的“八大浪费”，在软件行业却鲜少被提及。究其原因，软件不存在实体物料成本，主要消耗的是时间成本，浪费往往难以直观感知。

在我看来，软件行业也应该有消除浪费的意识和行动，对进度管理和成本管理肯定大有裨益。