一堆类似项目——平台化项目之间复杂性的驾驭

平台化战略是绝大多数公司开发新产品的思路，我们对这个几乎成为常识的概念也都非常熟悉了，就像IPAD，有Mini，有Air，有8英寸，有10英寸，都是基于一套平台化的技术方案修修改改的。

软件开发也是类似，基于一套基础软件进行拉分支开发，但实际项目里会有不同要素的比较多样的组合，特别是当今这个所谓VUCA时代，各个职能都想“创新”和“茁壮成长”，会打破原有约定俗成的标准模式，从而带来更多的复杂性。

这复杂性该如何驾驭和管理？今天通过写这篇文章来思考思考，但提前说一下，为了尽可能集中到一个小点来讲清楚，我们不谈“艺术”，只谈“技术”。

1

怎么理解复杂性？

VUCA算是一个模型，我们借过来用一下，它是指Volatility、Uncertainty、Complexity、Ambiguity，PMBOK第七版有一种解释：

-易变性 (Volatility)。快速且不可预测的变化的可能性。

-不确定性 (Uncertainty)。缺乏对问题、事件、要遵循的路径或要追求的解决方案的理解和认识。

-模糊性 (Ambiguity)。不清晰的状态，难以识别事件的起因，或者有多个从中选择的选项。

-复杂性 (Complexity)。由于人类行为、系统行为和模糊性而难以管理的项目集、项目或其环境的特征。

由于定义是想要包罗万象，所以对于特定领域而言，不是很容易理解，而且它也确实不满足我们的MECE原则，或许也正是从其本身就很VUCA的定义侧面阐释了VUCA的内涵，姑且作为参考。我们尝试换一种角度，可能不够精准全面，但或有助于理解我们自己的业务。

易变性，相对容易看明白些，我们可以粗略地将其对应为各种变更，包括但不限于需求、方案、时间、团队等。

不确定性和模糊性，初看名字，感觉不出来明显差异，我们就放在一起看，既然正面不好理解，看看它们的反义词，确定和清晰。这样似乎容易些了，“确定”是指状态的稳定（包括自身状态和因果关系），“清晰”是对当下或稳定或不稳定状态的认识。

反过来，不确定性就是整体的状态、关系、结果、目标等都是不稳定的，缺少线性的因果链接，具有偶然性，是因与果内在逻辑上的，是认知上的，比如，某一个Bug莫名其妙地出现几次，又莫名其妙地消失了，由于有很多综合的环境因素，所以即使开发分析出来可能的Root Cause，修复之后，也并不必然确定问题被解决了。

模糊性就是不知道，没有信息，说不明白，是认识上的，比如，一个新员工说不清楚这个项目的状态，甚至由于项目前期管理混乱，没人说得清楚。

那么，复杂性呢？首先我们项目中会有多种要素，比如，不同类型的项目、不同的组织（公司、部门）、不同职能的人、不同的需求、不同的时间线、不同的硬件BOM、不同的软件版本、不同的子系统划分等，这些项目要素之间会交互，会依赖，会有前后次序，会互为输入。当要素越多、交互越多，再加上前面变更的频繁、因果的不确定、认识的模糊，会让复杂性倍增。

总结一下，复杂性就是这一堆项目里有很多项目要素，要素会频繁变更，要素也会互相依赖，而要素本身状态、变更、依赖关系都是不确定的，且我们没认识清楚，说不明白。

希望我们把复杂性的框架讲顺了，或者说这种说法能够自圆其说，并有助于后面的分析了。

2

平台化项目的要素及特点

平台化的一大特点是共享项目要素，在共享的基础上，区分差异性，进行小范围差异点的创造和共享要素的调用组装。

当然，要素是个概念，最终要落实在工作产品上。所谓驾驭，也就是管理。接下来，我们从管理的角度识别一下要关注的工作产品，接触最多的有项目计划、功能模块或子系统、硬件、软件、需求、设计、测试、文档、“系统”、工作项（缺陷、任务、风险……）、团队等。

项目计划是整体的调度，串起了项目的走向，让所有人有迹可循。首先，平台化项目的计划显然会有前后次序，前续项目开发测试交付的各个阶段相对而言都会更早进行而更成熟，根据所共享的产物的不同，可能会有逻辑依赖关系。其次，99.9%的各类项目计划都会变化，不会按照既定的日程安排完成，与此同时，多数PM不能及时更新项目计划，导致大家看到的时间信息多数不对，涉及到多项目、多PM的情况，更是如此。

功能模块或子系统是针对我们这个嵌入式系统进行的划分，是技术实现的需要，也便于按照更细的颗粒来管理。对于平台化项目，模块或子系统往往不跟着项目线的纵向去走，也就是说责任人不隶属于单独的项目，而是通过子系统来横向串联，横纵向的兼顾是平台化管理的关注点。

硬件与软件是我们最终的价值物，自然不可忽视，核心目标是把正确的软件刷到正确的硬件里，并装到正确的车上。对于这两个“实体”的管理，主要是关注到车型的配置、软硬件自身代际平台类别、参数或BOM配置类别、同一配置下不同成熟度的状态等，平台化产品里会频繁地复用这些“实体”。

需求、设计、测试是工程化的基本路径，任何产品的交付离不开这个思路。需求变更是绝大多数变更的类型，甚至对于平台化产品而言，项目本身就是靠需求变更驱动而成的。不过，平台化项目的很多原始功能需求都是共用的，变更可能是针对整个平台项目都铺展开，也可能是针对某个项目进行的独特变更，这就会拉出一条分支来。设计与测试呢，理论上都是向上追溯到需求的，需求共用，设计和测试很多时候就是共用的。

文档、“系统”和工作项都是信息的承载体。文档就是excel、word和ppt。“系统”这里的意思是所谓数字化的工具系统，而非与软件概念同级的系统，所以加了引号。工作项是项目管理里需要跟踪的、独立的事项，一般会创建在工具“系统”里，会带ID的、带Due Date、内嵌流程等。这三者几乎将项目信息全部涵盖，我们今天本身就在探讨这复杂性，所以所有的复杂性都会体现在这里面。

团队嘛，就是不同组织内做事的大大小小老老少少的人。另一个广泛的代称是相关方，客户、Tier 1、Tier 2、系统、软件、开发、测试、匹配、项目管理等等，横向、纵向、职能上、项目里、部门里、外部、内部都会有各式各样的角色，项目越复杂，平台化项目集越大，涉及的人员越繁杂，扯皮不清的事情越多。人是最不稳定，也是最复杂的。

3

复杂性在平台化项目里的表现及应对思路

结合前两节，我们会看到我们的复杂性是什么？

一个平台下有很多类似的项目，每个项目的项目计划、功能模块或子系统、硬件、软件、需求、设计、测试、文档、“系统”、工作项（缺陷、任务、风险……）、团队会频繁变更，它们之间也会互相依赖，而它们本身状态、变更、依赖关系都是不确定的，且我们没认识清楚，说不明白。

针对这复杂性的关键词——变更、依赖、不确定、不清楚，我们找一些对应的方向或思路来尝试普适性的驾驭。

变更不可避免，我们可以尝试增加韧性或者工程语言上的鲁棒性，即可以一定程度适应它的变化；依赖对应的就是解耦，既然依赖，就想办法打断依赖；不确定和不清楚，可以让更多人参与、知晓，可以通过迭代的方式小步快跑，可以通过渐进明细的信息逐渐完善和思路逐渐明晰，还可以为潜在的不同结果准备备选方案，以打有准备之仗。

总结下来，就是增加韧性、解耦、渐进明细、多人参与、准备备选方案。后面我们可以将其作为参考来落实在具体项目上。

4

复杂性驾驭在细节上的落地

大处着眼思考，理论高度统领，但终归要落在细小之处的实施上。

4.1 名字的定义

项目里有各类要素，它们都会有自己的名字、代号、ID等，这名字如何起？

乍一听，不是大事，但随着后续项目越来越多，信息越来越多，再迁延日久，定义不好名字可能就会造成理解和沟通上的偏差，还是有必要花一点心思的。

比如，现在相对有一定规模的软件开发企业几乎都会用到工具链，对应的项目要在特定的工具里建立项目区域，这区域就要起名字。

项目的类型有很多划分维度，比如，客户名、整车架构名、项目名、产品平台名、平台里的配置名、硬件配置名等，一个名字用到的这些维度越多，就会定位得越精确，但所谓的“韧性”越差，一旦任何一个维度有变化，都会造成这个名字的不适用。

一般而言，由于汽车行业多数按照项目来组织，单个项目区域用其完整项目代号即可，而对于平台项目的话，要先理清“平台”的内涵在何处，是针对某个客户的平台化，还是某款硬件的平台化，或者某个软件基础的平台化，结合实际情况，选用平台的代号再加上一些必要的识别符即可。

当然，实际项目千变万化，具体场景下，更知道什么样的模式更好，这里只是提出这个理念。

实际上，在上述描述性的名字定义上，即使没多严谨，倒也问题不大，至多是多几句话解释，但对于某些关键工作产品，比如，软硬件版本号、缺陷号、评审号、需求条目代号等等，它们要具有唯一性和可读性，所以识别符要更全面、更具体，在只有一个项目运行时，随意用个1.0、1.1这种名字，看不出问题，当信息多起来时，会陷入极度混乱中。

然而，也要注意不适合将不稳定的信息映射到名字里，比如，有人将计划发布的时间放到需求代号里，明显不合适，计划时间是个极容易变化的东西，难道每次计划时间变化，都要更改代号吗？这就是“解耦”。

4.2 项目计划的维护

项目计划是项目团队里几乎最重要的东西了，频繁地变化，大家也会频繁地查看，要让其及时且正确地展示需要项目经理花不少精力，所以经常会看到一个项目的计划是陈旧的、错误的。

常规计划是怎么做呢？

PM用ppt或excel拉出一条条甘特图，标记时间、标记里程碑、标记相关事项，纯手动。

这里提供一个思路，利用数字化工具和office结合的方式，所有的里程碑、任务或其他要跟踪的工作项都在工具里布置，在需要临时用于线下评审或汇报时，将工具里的数据导出为excel，结合一些带宏的调用模板，可以做到线下处理高效便捷和线上数据同源稳定的结合。这也是增加“韧性”（通过自动化调用随时更新的数据来增加韧性）和“解耦”（和人工操作解耦）。

虽然我们聊的是项目计划，但这个理念并不仅限于此，甚至所有的文档化工作都可以往此方向尝试，线上数据同源、稳定、基线化，调用线上的线下数据快捷、高效、便于修改。

此外，针对项目计划，如果我们在工具里布置时，有时需要项目成员来选择相关工作项对应的计划，这时相当于将计划下放给了具体的执行者，随意填写的可能性很大，考虑到人的心理，这里有个小技巧，尽量避免建立类似于4.1提到的那种包含性很大的计划或无意义的概述，反而要细化，且建立在同一层上，模棱两可的多个选项且具有包含关系，很容易让人错填。比如，一些下拉字段里设置了General或NA，很多人会不假思索地选它们。

这里的逻辑在于颗粒度上，颗粒度足够细，才能更精细地管理，这在数字化工具链的使用有效性上无处不在地体现着。实际上，ASPICE和CMMI都是有类似的思路在里面。

我们不妨把项目计划的概念再拓展一下——项目裁剪，公司稍微正规一些的，都会有这么个环节，要把项目做什么内容计划出来，这在平台化项目里体现得也是最明显，我们要基于相对平台的变化点，进行复杂度和重要度评估，然后明确复用程度并定义裁剪方式，粗略一点的按照新开发的模块比例进行一定的裁剪，精细一点的还会考虑复杂度、功能安全级别、人员能力要求、软件配属数目、成本大小、涉及的组织多少等。

在这里，解决复杂性的思路可以有两个点：标准化和按需精细化，比如，只是在基础平台上做项目级的标准化裁剪，还是把每个衍生项目再细分进行标准化裁剪。理论上，越精细越标准，复杂性越容易被掌控，但这需要业务本身足够成熟。

4.3 团队架构和责任映射

PM都会有感觉，项目要想推行下去，至少要保证工作包分得足够细和明确，即让人能做下去，并且需要匹配到个体责任人。

当人员比较多、涉及职能和组织比较多时，我们可以通过文档化和可视化的方式建立这样的映射关系，把“事”和“人”映射起来，让团队知道自己该做什么，该找什么人。

实际操作中，不单单是给人挂开口项，这个人可能跟平台走，可能跟项目走，可能按模块或子系统划分，可能按开发链路上的职能划分，比如A员工负责B项目的C模块的D职能，当平台项目庞大时，A员工还有EFG划分。

简单易上手的ppt组织架构图或excel映射表，复杂点的在工具链里建团队、分权限，同时定义各个工作项里的责任人。无论如何，需要搭建框架，并随着信息的完善和改变，进行细化和更正，并通过可视化的方式发布给所有人。

其实，结合工作经验，敏捷里提的面对面的交流的方式是非常实用的，文档或工具起到的是辅助作用，各类会议和沟通才是解决复杂问题的高效方式。之前审计过一家公司，要求强制开变更的CCB会议和关键事项的评审会议，不可以通过工具或邮件替代，想必也是类似的经验。

4.4 “技术”的复杂性管理

日常交流中所谓的“技术”，就是需求、设计和测试这些工程化工作。技术的复杂性很难概述，每一个部分背后甚至都是一门门的学科，一个个独特的系统性工程问题，需要一个个工程师冥思苦想、绞尽脑汁，是一项智力工作，是脑子里的活动，但依然可以从管理上解决部分问题。

ASPICE有个比较好的总结是“一致性由双向可追溯性支持，并可通过评审记录来证明”。

通过“建追溯”的动作，我们可以做到“双向可追溯性”的“不遗漏”（比如，一条需求对应一条或多条测试用例，没有少做）和“不多余”（比如，一条测试对应一条或多条需求，没有多做）；

通过“评审”的动作，可以去尽力确认“一致性”所指的“不矛盾”（需求和测试是对应的）。

所以，核心要落在“建追溯”和“评审”的有效性上，建追溯要便捷快速，比如优化工具等，评审要真正让有能力的人动了脑子，比如，要多人现场梳理、强制开会、划分责任或提供激励等。

此外，对于设计这种难以管理的脑子里的活动，ASPICE也试着通过评估备选方案的活动来完善，本质是你好好思考过你的设计。理论上是有效的，但执行起来极其困难。

那么，针对我们的主题——平台化项目，基础项目和衍生项目都如何去做呢？比如，基础项目要做完善的追溯和评审，衍生项目则可通过完整的配置管理梳理，一来提升效率，二来都可以有清晰的结构化。

5

写在最后

这篇文章不太好写，谈复杂性本身就是个很复杂的事情，写成文章就更复杂了，勉强成文，算是梳理了一些经验技巧。

不过，在写的过程中，对数字化有了一些新的理解，数字化可以说是驾驭复杂性的良好手段，后面可以专门聊一聊数字化的事情。