夜雨聆风
助力汽车软件研发管理效率提升全攻略︱汽车软件研发
会议推荐
1
2
3
4
2026第五届中国项目经理大会
5
2026第三届中国医药企业项目管理大会
本 文 目 录
1
适合汽车软件研发管理的35个指标
2
搭建车载软件研发数字化管理系统，这3个坑你可能爬不出来
3
汽车软件研发：主机厂 vs. 供应商
4
软件研发全攻略（一）
5
软件研发全攻略（二）
一、适合汽车软件研发管理的35个指标
（原创 水轻言 水轻言）
-
此为无奈之举，简化至可以理解和管控的可量化指标，是认识的需要，也是管理的抓手。
-
指标既会作为具备相当一致性的成熟产品或团队的绩效表征，也是将不成熟推向成熟的手段，而且推动意义大于表征意义。
既然仍然需要指标，本文会汇总对汽车软件相对有价值的度量指标，以供大家选用。
需求规模=需求大小或颗粒度
该指标反映了单个需求交付及开发的复杂度，如果能对需求规模进行比较好的拆分与估算，十分有利于项目计划与工作量的合理规划。
按照不同的项目或产品类型，可以使用故事点、feature、功能点、对应代码当量等维度来评价。
需求交付周期=需求释放时间–需求创建时间
该指标反映了团队对新需求的评估及交付速率，这也体现了敏捷宣言中拥抱变化的力度。
算法里的需求释放时间可以按照系统里需求通过评审释放或变更经过CCB批准释放的时间来定义，而需求创建时间可以按照系统里需求打基线或者提交的时间来定义。
需求变更率=发生过变更的需求数/已释放的需求总数
该指标反映了对变更控制的能力，在传统汽车瀑布式开发下，对变更控制的能力也会指向管理的水平，但敏捷时代下，低需求变更率甚至是负面的表征。
算法里的需求数可以按照需求管理系统里的条目数或者需求文本的数量来统计。
需求评审通过率=通过评审释放的需求数/提交评审的需求数
该指标反映了需求提出者撰写需求的能力，也会反映出对需求上线进行整体规划的能力。
算法中的需求数可以按照需求管理系统里的条目或者变更管理系统里工作项的数量来统计。
需求评审缺陷密度=需求评审检出缺陷数/需求规模
该指标反映了需求评审的效果。
算法中的缺陷数可以按照评审finding或者开出的问题项的数量来统计，而需求规模可以使用故事点、feature、功能点、对应代码当量等维度来统计。
设计评审通过率=通过评审的组件数/提交评审的组件数
该指标反映了组件及接口定义和设计的质量。
算法里的组件数可以按照软件架构的组件拆分来统计。
设计评审缺陷密度=设计评审检出缺陷数/设计规模
该指标反映了设计评审的效果。
算法中的缺陷数可以按照评审finding或者开出的问题项的数量来统计，而设计规模可以通过需求规模或者组件数来统计。
组件按时交付率=按时交付的组件数/计划交付组件数
该指标反映了软件开发人员进行模块或组件开发的能力，软件需要多组件集成后才能进行下一步的测试和发布，各组件开发都要按节奏协调起来。
算法里的组件数可以按照软件架构的组件拆分来统计。
组件复用率=复用的组件数/总组件数
该指标反映了架构设计、组件设计甚至需求沟通方面的能力，不重复造轮子、进行复用开发是我们所鼓励的。
算法里的组件数可以按照软件架构的组件拆分来统计。
接口变更率=变更的接口数/总接口数
该指标与组件复用率关注的能力接近，但组件复用率提升的是单个组件开发的效率，接口变更率更会致力于跨组件、跨系统的协同开发效率。
算法里的接口数可以按照系统及软件架构中定义的软件接口与软硬件接口来统计。
代码开发当量=代码抽象语法树加权最小编辑距离
该指标反映了代码的逻辑量和修改代码的工作量，排除了编程风格、换行习惯、注释等干扰因素，准确性比传统的代码行数更好。
代码提交频率=单位时间代码提交次数
该指标反映了代码开发的活跃度，也是敏捷中鼓励的小步快跑提交，但有可能也会让开发进行表面化的频繁小提交，反而带来质量的下降。
算法中的代码提交次数可以按照代码配置管理系统中记录的代码变更次数来统计。
代码重复率=重复代码的代码规模/总代码规模
该指标反映了代码的可维护性，即代码重复率越高，代码可维护性越差，因为多处修改所需的工作量越大。这个指标会驱动代码抽象，如用函数、类、库、服务来封装等。
算法中的代码规模可以用代码当量或代码行数来统计。
代码评审缺陷密度=代码评审检出的缺陷数/代码规模
该指标反映了代码评审的效果。
算法中的缺陷数可以按照评审finding或者开出的问题项的数量来统计，而代码规模可以用代码当量或代码行数来统计。
静态扫描缺陷密度=静态扫描检出缺陷数/代码规模
该指标反映了编码规范程度，如MISRA C。
算法中的缺陷数按照工具扫出来的finding统计，而代码规模可以用代码当量或代码行数来统计。
提测成功率=提测成功次数/提测总次数
该指标反映了开发满足测试准入条件的水平，除了软件质量本身，通常也会涉及一些过程规范性要求。
算法里的提测次数可以按照真实版本或者对应的releasenotes的数量来统计。
测试一次通过率=一次性通过测试的版本数/总测试的版本数
该指标反映了开发的质量，会一定程度推进团队对代码评审或单元测试等开发测试的重视，但是，能否通过测试终归是来源于对测试准出条件的定义，如果发布压力大于质量压力，准出条件形同虚设，这个指标也就失去了意义。
算法里的版本数可以按照真实版本或者对应的releasenotes的数量来统计。
该指标反映了测试对需求或代码的覆盖程度，也细分为测试需求覆盖率或测试代码覆盖率。
算法中的条目数量，对于需求的覆盖，可以按照需求管理系统里的条目数来统计，而对于代码的覆盖，可参考《汽车软件单元测试的要点与意义》里的描述。
该指标反映了测试的效果。
算法中的缺陷数可以按照开出的缺陷项的数量来统计，而代码规模可以用代码当量或代码行数来统计。
缺陷重开率=重新打开缺陷数量/总缺陷数量
该指标反映了缺陷修复的效果，重开率高组件或团队应进行针对性的分析与改进。
算法中的重新打开缺陷可能需要缺陷管理工具配置对应的字段来统计。
缺陷阶段移除率=某一阶段引入中移除的缺陷数量/该阶段引入的总缺陷数
该指标反映了特定阶段的活动或团队对于缺陷的整体贡献，自己带来的缺陷最好自己带走。
算法中的阶段移除（这里的移除指在该阶段发现）和引入缺陷数都需要依赖缺陷管理工具配置的特定字段来统计。
缺陷逃逸率=后期发现的缺陷数量/总缺陷数量
该指标反映了前期缺陷检出的效果，也直接反映了汽车软件质量的真实水平。
算法中后期发现的缺陷数量可以理解为售后、工厂、整车集成这些环节发现的缺陷数量。
该指标反映了软件开发不同阶段的缺陷检出的效果，同缺陷逃逸率指向接近，但它对不同阶段的不同活动或团队的缺陷检出进行了细化，通常作为优化缺陷逃逸率的进一步指标。
算法中各阶段可以理解为需求评审、设计评审、代码评审、开发测试、集成测试、软件测试、系统测试、整车测试、工厂生产、售后这些不同环节。
该指标反映了缺陷视角下的软件整体质量状态，其中的缺陷等级定义以及对应权重的划分是指标有效与否的关键。
缺陷分布=缺陷不同属性的交叉分析
该指标反映了缺陷属性交叉分析的结果，同其他分布一样，它更多作为整体对比、分析、决策的工具。
缺陷属性可以根据类型、严重度、根本原因、模块、优先级、测试环境和负责的测试人员等进行分类，这些属性之间可以进行二维或多维的交叉分析，比如，利用透视表、直方图、饼图或帕累托图等方式。
测试自动化率=自动化测试用例数/总测试用例数
该指标反映了自动化测试的能力，要想实现敏捷的频繁迭代发布，很重要一个前提就是快速的自动化测试，尤其要关注回归测试的测试自动化率。
流负载=已开始但未交付的需求数分布
该指标反映了需求、设计、 开发、测试、发布各阶段的需求数分布状态，类似工作量分布，但关注的是在制品瓶颈和积压，控制在制品数量有助于提高交付效率。
算法里的需求数可以按照需求管理系统里的条目数或者需求文本的数量来统计。
流效率=活跃工作时间（即无阻塞地工作）/总交付时间（包括活跃工作时间和等待时间）
该指标反映了软件开发过程的顺畅程度和资源利用效率，也能比较好地将软件开发工作透明化。
算法里的活跃工作时间指的是需求沟通、需求评审、架构设计、开发、测试、发布等实际工作的时间，而总交付时间则包括了活跃工作时间以及各种等待时间，如配置在ALM工具中的待评审、待开发、待测试、待发布之类的等待阶段的停留时间。
工作量分布=不同维度下的工作量差异展示
该指标反映了软件开发过程中，不同阶段、不同团队下的工作量分布比例，通常用来支持项目管理的工作分配，也会与其他指标进行关联分析。
工作量可以通过工作项数量（缺陷、变更、任务等）或者工作时间或者代码规模或者需求规模等不同维度体现。
售后问题解决时长=售后问题解决时间–售后问题响应时间
该指标反映了解决售后客户问题的及时性，是“能力”问题。
算法里的解决时间可以按照系统里解决或者按照OTA或刷件解决实车问题的时间来定义，而响应时间可以按照系统里分配或者给客户首次正式答复（有切实计划）的时间来定义。
净推荐值NPS=客户愿意向其他人推荐某功能或场景的意愿
该指标反映了客户的主观感受，而不聚焦在工程或软件质量本身。这在场景体验评价里，是一个有价值的指标，它也可以用于客户满意度的整体评价。
净推荐值以0-10的数字范围表示，得分为0到6的客户是负面评价者；7和8的分数是中立者；9和10是推荐者。
二、搭建车载软件研发数字化管理系统，这3个坑你可能爬不出来
（原创 罗宇超 九章智驾）
对于一个现代化的企业来说，数字化管理系统非常重要。
将范围缩小到汽车行业，企业的数字化管理系统大致包含了ERP（人力、资源、财务、供应商等）、MESS（生产制造）、PLM（BOM、PDM、供应商管理，有形的硬件产品生命周期）和ALM（需求管理、测试管理、bug管理，无形的软件产品生命周期管理）。
一些汽车行业的企业，在搭建自身的车载软件研发数字化管理系统中，存在的一些误区，以及可能导致的一些风险。
1. 过于关注单点问题的高效解决，而忽视了整体流程的高效管理
2. 高估了流程的独特性，而低估了流程的通用性
3. 被动收集各类平台数据，形成“虚假”且“臃肿”的研发数字化管理系统
有一次我去给一家企业讲解研发管理系统，客户是做电驱系统的架构设计与集成。我的讲述思路是，如何在满足汽车行业的三大法规标准（ASPICE、功能安全和信息安全）的情况下，实现从需求管理、开发任务管理、测试管理、项目管理、质量管理等流程的全打通。
我自以为讲解的还算比较充分，事实上也得到了对方实施这一计划的工程师认可，将我推给了其他正在创业的同事。
不过我也碰到了一些挑战，对方的负责人质疑说，整个系统是站在流程质量和项目管理的角度来设计的，对于工程师直接提高某一现有工序的效率，比如帮助需求工程师更快速地、自动化地生成需求，帮助测试工程师更快地生成自动化测试用例，或者更高效地扫描出代码缺陷等，则缺少效果。
这家公司拥有业界最优秀的汽车工程师。事实上，他们一方面能提供最佳的产品设计品味、最好的内外饰设计思路、富有竞争力的售后运维服务，但是却在研发和运营效率上有所拖累。内部系统和工具过多，数据传输效率低于同行。
在公司创业早期，人员冗余+强大的工程师个体，是一个优势，很容易通过赛马机制，使得某一方提前跑出来。但是当同行都推出车型之后，此时更考验不同团队的精细化管理和效率提升，庞大而臃肿的研发团队和研发数据，反而形成了太多噪音，成为拖累。
以车载软件开发为例，这是一个涉及多个环节的复杂过程，包括需求分析、系统设计、编码实现、测试验证、部署上线以及后续的维护和更新。如果管理者只关注测试用例的自动化，或者代码自动扫描，可能会导致以下几个问题：
1. 研发流程的瓶颈转移：即使测试用例的自动化提高了测试效率，但如果需求分析和设计阶段存在问题，可能会导致测试阶段频繁修改用例，反而增加了工作量。同时，如果代码实现阶段的质量控制不到位，可能会导致测试阶段发现大量问题，导致测试工作量激增，从而形成新的瓶颈。
（精益管理里面，有一个很经典的提高效率的例子。比如项目是“某五星级餐厅准备晚餐”，分析其流程包含了：确定菜品、app下单买菜、小哥送菜、洗菜、炒菜、上菜。这其中不仅涉及了像炒菜这种“工序”，还包含了炒菜和上菜这两道工具之间的交接时间。因此，为了提高整体的做饭效率，需要先调研每一个工序花费的时间，以及工序之间的交接时间，找到效率瓶颈，然后再逐点解决。可见，不仅仅是“工序”会成为效率瓶颈，工序与工序之间的“交接流程”本身，也可能成为效率瓶颈。）
2. 资源分配不均衡：过多的资源可能被分配到测试自动化上，而其他同样重要的环节，如需求分析的准确性、系统设计的合理性、代码的可读性和可维护性等，可能因资源不足而受到影响。
3. 产品质量风险：车载软件对安全性和稳定性的要求极高，如果开发流程中的某些环节被忽视，可能会导致软件在实际运行中出现严重的安全问题或稳定性问题。
4. 市场竞争力下降：如果因为开发流程中的问题导致产品上市延迟，或者产品质量不符合市场预期，可能会导致公司在激烈的市场竞争中失去优势。
5. 维护成本上升：在车载软件的后续维护阶段，如果因为前期开发流程的问题导致软件存在大量隐患，可能会导致维护成本大幅上升，甚至需要进行昂贵的召回。
因此，管理者应该采取一个更全面的视角，关注整个车载软件开发流程的每一个环节。
这里也分享一个案例，这个案例来自于我和某车载团队一名测试leader的对话。
我和其讨论的话题是：如何更好地构建测试团队的管理工具，以提高软件测试团队的效率。他向我展示，在测试管理工具层方面，他的团队做了大量工具开发，形成了一个相对完善的测试管理系统，包含所有的测试用例、用例评审、测试计划、发版计划、执行结果回填等等。
1. 当我问他，整车需求和该团队的产品需求、开发任务，都存在于需求管理系统，测试用例如何和这些需求、开发任务做关联？—-通过链接关联，双向点击可访问，已解决
2.以及需求、开发人员是否能随时访问他的测试平台，以方便查看测试用例和结果？—-局部可以开放权限，大部分人不行，因为这个平台是测试部门内部的平台
3. 其他测试部门是否也使用他的平台？—-不使用，其他部门也会开发自己的测试管理平台
4. 为什么其他测试部门不使用他的平台，而需要自己独立开发？——因为每个部门的测试流程和使用习惯不同
5. 追溯性的统计，功能安全、信息安全流程如何支持？—-暂时无法解决，也不考虑
6. 如果产品和开发很少能访问他们的测试工具，那如何才能让产品、开发、测试形成一个更高效的沟通机制？—-
他有点犯难了，他认为那是整个大部门的事情，他这边没有办法干涉，也解决不了，所以他只能想尽办法让测试过程更高效，至于整体团队的效率，他难以推动
这位测试leader虽然意识到将测试管理平台，和需求、开发平台一体化管理，能提高效率，他却无法推动整个团队往一个平台上使劲儿和迁移。
即使他意识到，各个部门重复建立测试管理平台，是资源的大浪费，他也无法推动其他部门使用他的工具。
这不是工程师个人能力的问题，而是因为，这是企业一把手工程。
使用不同的测试平台，和各个部门测试流程的独特性有一定关系，但显然关系不大。
因为看了一遍他的系统，我们自己开发的MappingSpace系统，也能够在几乎不怎么调整的情况下，满足绝大部分功能。
换句话说，我们往往容易高估企业流程的独特性，而低估了企业流程的通用性。
这也是很多国内公司非常喜欢做定制化系统的原因。
宁愿摒弃一套行业通用的平台，也要找业余团队定制化开发，认为自己的流程非常独特。往高大上了讲，就是源码可见，自主可控，随时可调整。
不过深入分析里面的原因却很复杂，和国民性格、复杂的采购申请流程、对产品的认知、对乙方的信任、幕后交易都不无关联。但是，自研有很大风险。
一方面，部门之间的测试管理系统，差距肯定会越来越大，这样的测试平台，在诞生之初，就无需考虑设计的通用性。
另一方面，随着差距越来越大，再也无法做到统一，此时就进入了下一个状态——打通。请看下一个故事。
这个故事是我和整车部门的一位大项目管理的对话，这位PM的目标是开发整车项目管理的数字化平台。他自述是这个平台的第4代产品经理，因为前面三代产品经理都离职了，留下了一大堆还未完成的feature，他这个平台的目的是，将各个部门、各类工具上的研发数据汇总，建立追溯性，然后在这个平台上以更加可视化、结构化的方式显示出来，基于此来做更高效、更清晰的项目管理和质量管控。
我说那这个系统岂不是很复杂，因为他不仅要去和各个业务部门梳理业务数据，以判断这些数据分别属于什么类型，然后才能和自己做的这个平台的数据结构做匹配。而且这似乎只是一个“数据汇总平台”，离真正的研发流程管控还差了很远。
他表示同意，现阶段各个部门不同的工具平台都太多了，还有不少部门在线下管理，没有形成线上的数据，没有办法去做流程管控，只能先将业务数据汇总到这样一个平台上来，然后基于数据再去反推流程，针对异常数据或者无法提供数据的部门，再去各个击破。
这确实是一个很复杂、很繁琐的工程，而且我非常怀疑这个项目在第四代产品经理手上，能不能顺利完工。我对这个数据汇总平台，能产生多少效果，也有一些怀疑。
最终，我提了一个可能的方向：现在这种情况，有点像逆向工程。通过结果数据来反推过程。但是由于需要理清楚的过程涉及到太多不同的部门，以及部门之间的交互错综复杂，这是一个庞大得似乎看不到头的工程。有没有可能采用正向开发的模式，先找到一个大家都认可的开发流程，然后将已有的流程往这个正向开发的流程的方向去靠近，最终将大家的流程梳理到一个统一的平台上
总结
汽车行业的研发数字化系统搭建过程中，对于以下三点的考虑非常重要：
第一：要站在全局的角度设计。所谓的全局，应尽可能依赖汽车行业的标准和法规，减少后期逆向工程来满足法规的成本和代价。基于标准和法规，并不一定意味着繁琐，也可以裁剪，追求更快地开发速度。
第二：中大型企业的数字化研发系统设计，应尽可能让不同部门采用相似的流程，采用相同的工具。而不是每个部门采用一套工具，最终去打通数据流转，极易造成上述第二和第三个例子中的情况，从而拖累整体的研发数字化流程。
第三：单点效率很重要，但整体的流转流程更重要。使用精益管理的方法，逐个分解流程中涉及的“工序”和“交接”，各个击破，提高整个团队的协作效率。
三、汽车软件研发：主机厂 vs. 供应商
（罗宾5G商业评论 罗宾研答）
软件是未来汽车的主要特征。一架飞机只要 1,400 万到 1,500 万行代码，而如今的汽车所有软件代码已突破一亿行，而全自动驾驶的啊汽车所需代码至少是此数字的五倍。
将汽车制造的重点从车体结构钢铁等硬件转移到软件，这对传统主机厂和供应商而言，困难重重。
与此同时，围绕汽车研发软件化之后的分工，哪些工作应该主机厂做，哪些应该供应商做？成为一个重要而敏感的话题。
围绕智能汽车的所谓 “灵魂” 到底谁来负责提供，也是业界讨论的热点。
附图来自德勤与知名汽车和供应商的调研，附图列举了重要软件部件在主机厂和供应商分别的打分，从战略重要性和内部能力两个方面。
德勤认为：主机厂和供应商在 “OTA”、“云生态系统” 和 “互联服务” 这三个领域的差异化最大。也许更容易达成合作互补。
四、软件研发全攻略（一）
（原创 大果树 ARVO INSIGHT 价值洞察）
在当今数字化浪潮中，软件开发不仅是技术领域的核心驱动力，更是企业创新与商业成功的战略支点。特别是软件定义汽车的时代，软件研发的规范化管理成为车企的难言之痛：软件版本如此多，如何测试？全量测试还是采样测试？软件版本发布如何管控？软件质量如何保障？软件功能为什么总是赶不上造车的节奏？软件是如何集成的？敏捷会让车企的软件开发一夜之间发生神奇的变化？….
本篇文章依据《软件研发全攻略》这份详实的教程资料，为您揭开软件开发的神秘面纱，以科普的方式探讨其理论基础、关键模型、实战技巧以及组织与人才发展等重要议题，旨在为读者提供一幅全景式的软件研发导图。
一、软件开发基石：软件开发生命周期模型的选择
软件开发生命周期模型是组织软件研发活动的框架，它定义了开发过程中的阶段、顺序、迭代方式以及各阶段间的关联（见图1）。
图1
软件开发生命周期模型，大家耳熟能详的是经典的瀑布模型和敏捷开发模型。
瀑布模型：
瀑布模型遵循严格的线性顺序，从需求分析到详细设计，再到编码、测试和维护，每个阶段必须在前一阶段完全完成后才能开始。瀑布模型适用于需求稳定、技术路径清晰的项目，但其僵化性可能导致应对变化的能力较弱，一旦前期需求定义有误，后续阶段修正的成本极高。
关于瀑布模型，我们需要知道，目前看到的瀑布模型（见图2）更多是停留在了理论模型基础之上。实际上，在1980s, Fred Brooks, 著名的产品开发畅销书《人月神话》作者，图灵奖获得者，在NASA内部会议上指出，“在超过370亿美金的投资项目中，只有2%的项目使用了纯粹的瀑布模型，75%的项目或夭折或没有使用.”
图2
在现实的世界里，更多的是采用了基于瀑布模型演化的进化模型，如螺旋模型，V模型等。他们都融合了瀑布模型的结构化特点与迭代思想。螺旋模型特别适用于高风险项目，通过反复的风险评估和原型迭代降低不确定性；而V模型（见图3）强调开发与测试的对应关系，确保每个阶段的验证与确认工作紧密相连。V模型成为了产品工程，特别是软硬一体的嵌入式产品开发的核心骨架，也是产品开发使用最为广泛的模型。像汽车行业的ASPICE标准，功能安全的ISO26262标准，信息安全的ISO21434标准，基本都是根据V模型制定了相应的规范要求。
图3
敏捷模型：
敏捷开发模型则以快速响应变化为宗旨，倡导迭代开发和持续集成。它强调团队协作、用户参与以及适应需求的灵活性，通过短周期的迭代（如Scrum中的Sprint）快速产出可用软件，并根据反馈进行调整。敏捷模型更多地关注了软件开发过程中的工程实践，对于软件交付后的运营提及不多。交付后的管理更多的还是采用传统的软件生命周期管理的模式。
敏捷软件开发模型同样存在多种实操模型，例如XP，FDD，等。目前应用最广的还是团队级敏捷SCRUM模型（见图4）
图4
敏捷开发在实际落地过程中有两种具体的项目管理方式：基于时间盒的迭代计划（见图5）和基于流的迭代计划（见图6）。采用不同的迭代计划，将决定了敏捷项目每个冲刺（SPRINT）的交付内容。我们需要注意的是，因为产品形态及产品技术架构的复杂度不同，组织架构的不同，如果迭代规划方式选择与之不匹配，敏捷反而会引入更多的混乱和内卷。
例如，如果产品是单一架构的（monolithic Architecture）且功能依赖多，如果采用时间盒的迭代规划方式，会出现待开发的新功能不得不削足适履，进行功能分拆用户故事，确保能在一个时间盒的窗口交付，反而导致大量的模块之间的相互依赖，交易成本（Transaction Cost）巨升，协调工作冗长，从系统论的维度看下来，反而是降低了效率。针对这种情况，要么是改变时间盒的跨度，要么是采用基于流的迭代工作模式。
图5 （来源：From Prince2 Agile）
图6（来源：From Prince2 Agile）
软件开发的模型选择：
“There’s no singular technique or process that will bring about significant improvements in software development productivity”
– No Silver Bullet—Essence and Accidents of Software Engineering
Gerald Weinberg, Fred Brooks, and Grady Booch
面临乱花渐欲迷人眼以及病急乱投医的汽车软件开发，到底如何选择自己的软件开发模式呢？正如Fred Brooks所言，没有单一技术或模型能够显著提成软件开发效率。我们需要的是因地制宜，选择适合自己组织和产品属性的研发活动的模型。
在实际工作中，我们应该且必须学以致用，灵活适配合适的软件开发模型，而不是简单地照猫画虎，仿照各种敏捷框架，站会，结对编程，…（题外话：其实，适配性（Adapability）才是业务敏捷的精髓所在）。不管选择何种开发模型，其核心目的是更快、更好地交付客户价值和业务价值。具体来讲，可以基于Stacey矩阵，选择合适的开发模型（图7）。当然，除了Stacey矩阵提供的需求确定性和技术确定性的两个维度外，还需要考虑团队的成熟度，团队成员的技能经验，工作地点分布，团队规模以及组织文化等因素。
图7
二、需求分析与架构设计的艺术
软件开发始于需求的获取与需求开发的过程（通常将这个过程称为需求工程阶段）。需求的获取主要是从市场需求，用户需求，业务等维度，理解并分析企业所在的行业，国家，地区，适用的法律法规等各个维度，定义软件产品的需求。
近几年来，随着国内互联网造车的兴起，互联网用户需求分析的工具也逐步引入到垂直行业，也成为国内传统造车企业纷纷攘攘去学习的重心。但从第一性原理来看，需求获取的原理没有改变，变化的是传统企业缺少需求获取的数字化手段，缺少人物画像的细节管控。
需求获取的方法手段很多，我们总结如图8所示。
图8
在对软件产品功能进行定义的过程中，往往采用的是多种方法的综合应用，确保功能能够满足最大数量的用户期望。同时，我们要关注，对于TOC业务与ToB业务的需求获取方法，也存在着差异。无论是从调研对象，调研数量以及调研方法，在实际过程中，要注重理论与实践的结合。
这里，特别给大家推荐一个用来识别或改进产品可用性功能需求（Usability）的强大工具–用户历程地图（题外话：对于其他如非功能性需求的定义与改进，建议采用其他工具方法）。图9展示了对电车用户充电活动的用户历程地图，通过一张纸，可以清晰地将产品功能的优劣以及待创新的功能点描述清楚。
图9
需求获取只是开启了整个软件开发的序幕。我们下一步要做的是需求的确认。需求的确认，是确保软件产品的开发“做正确的事”。需求确认的方法包括了VOC，焦糖布丁法，Y分析法，数据分析法等等。
为什么要进行需求的确认呢？其实，这涉及到了人类认知的过程，如图10所示，当我们看到现实的人形机器人图片时，我们会根据自己的认知(Perception)和我们个人的知识（Knowledge）对其进行描述。然后，我们将我们自己脑海里，经过自己认知过滤过的图片，用自己的知识，包括文字语言对其进行描述，这个过程，将不可避免的引入人为的错误。所以，在专业的产品研发环境中，我们意识到这个人类认知的过程偏差，所以需要建立规范的工具方法，如需求文档的评审，需求撰写的规范，等，作为“获取正确需求”的底线保障，确保最大可能地不失真。而敏捷思想里强调的“客户合作胜于客户合同”，也正是基于这个不可更改的事实做出的更合理的过程建议。
图10
需求的开发包括需求分析与需求的分解与分配的过程。它是软件产品开发“正确做事”的过程。这个过程可以使用类似FAST功能分析图，EFFBD图，UML建模或者其他建模工具实现。也可以使用其它不同的工具方法，如KJ法，KANO法，QFD法，Pugh 矩阵法等等，帮助我们有效工作。
需求开发从产品定义语境出发，逐步细化分解功能，最后分配到子系统和模块。这个过程是用户可见的功能和可感知的非功能性期望，转化为我们软件产品能力的过程。如果是0到1的产品开发，这个过程与产品架构设计交互迭代，最终形成产品的雏形；如果是基于原有产品架构的功能增加，则更多的工作是基于原有架构进行需求分配的过程。当然，不排除原有系统需要重构，才能满足客户的功能要求的情况。
而架构设计则是将技术需求转化为系统的蓝图，涉及功能模型定义、架构评估方法选择、物理架构布局等多个环节。软件产品常见的技术架构包括了C/S架构，MVC架构，分层的SOA架构等。但具体的架构设计，要考虑的不仅关乎技术实现，更是一种权衡艺术（Trade -Off），需要在功能、成本、时间、用户期望等多种因素间寻求最佳平衡。如图11，当面对客户“过河”的需求，架构设计可能需要考虑桥梁、船只、潜水艇，飞机等多种解决方案，每种方案背后代表了不同的技术复杂度、投资规模与时间周期，系统架构就是需要在不同的解决方案中选择最合适的，而不仅仅是技术最优的。
图11
在架构设计过程中，可以运用启发式问题法、KJ法、QFD等工具进行评估与决策，有助于识别最合适的架构。同时，评估软件架构的有效性，还可以通过创建原型、迭代开发、模型模拟等方式获取直观反馈，必要时引入量化指标进行深度分析。
康威定律揭示了一个重要规律：软件架构往往反映出组织内部的结构。这意味着，良好的组织设计有助于催生高效、协调的软件架构，反之亦然。因此，在软件开发过程中，应充分考虑组织架构对技术实现的影响，确保架构设计既能满足功能需求，又能顺应组织协作模式。
五、软件研发全攻略（二）
（原创 大果树 ARVO INSIGHT 价值洞察）
-
冒泡排序算法的内层循环条件for (j = 0; j < len – 1 – i; j++)中的len – 1 – i可能会导致数组越界。应该将内层循环条件修改为for (j = 0; j < len – 1; j++)。
-
在冒泡排序算法中，如果数组已经是有序的，仍会执行完所有的比较和交换操作，造成了性能上的浪费。可以在内层循环中增加一个判断条件，如果没有发生交换，即可提前退出循环。
四、软件发布：舞动的韵律
-
技术研发着眼于长远，追求技术先进性与知识积累，目标是开发出具有竞争优势的技术成果，为未来的市场化产品提供技术支持（TPF过程）。 -
产品研发更直接面向市场，关注产品创新与商业化进程，旨在快速推出符合用户需求的新产品，创造价值与利润（PMF过程）。
END
1、如您转载本公众号原创内容必须注明出处。
2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。
3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。
4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。
