引导现场100问：提升系统思考能力的研发类课题研讨怎么组织？

问：赵老师，我们公司研发呈现多元化、多任务、多关联的特点，过去研发各部门只关注自己的任务就行了，不需要太多跨部门沟通。而现在，很多功能不仅要自己实现，其它科室也会相互调用、交叉使用。

这就要求研发人员能够站在系统层面看问题，相互之间主动协同，主动拉通标准、开发流程、统合参数，了解其它功能的开发模式，以使得资源最优、整车最优、效率最优。

这样的工作坊，研讨逻辑与框架应该如何设计呢？

我们先来看需求。

从信息描述和项目经验来看，我理解可能有几个层面的诉求：

希望功能负责人站在系统层面，全局性看待功能底层的交互问题；

找到影响任务高效交付的核心问题，并提出优化策略与方法；

相互增进了解，提升主动协同的意识；

通过研讨形成节点控制机制，推动新的流程与机制；

经营研讨建立一套类似问题的方法论；

如果以上的需求是成立的，那我们需要带领参与者达到以下目标：

看到彼此，了解对方的工作模式；

增强对标准、流程理解的一致性；

寻找实现部门间协同的最佳路径；

明确技术开发过程中的依赖性；

形成协同机制；

基于以上的分析，我们需要在现场引导大家完成以下动作：

No.1理解为什么要建立系统性的思考

我听到过一个车企的案例：负责“转向”功能开发的部门，过去只需要做好自己的任务就好了，但全车电气化之后，还会与“安全、导航、驾驶辅助、大屏显示”等多种功能产生交集。为了开发效率的整体提升，就要求各部门在功能设计、开发过程中，相对充分地思考各功能模块间的关联度。以便于知道在何时能够为其它功能的开发做出支撑与贡献。

No.2构建系统地图

每个人都是系统中的一个节点，而任务则是连接这些节点的边。由于任务之间可能存在共享资源、依赖关系或数据交换，因此它们之间会产生耦合。所以，有必要请参与者在业务链条中找到这些任务中的耦合点，并据此形成“系统地图”；

No.3拉通基于耦合点的参数定义

每个部门对自己的功能都有参数定义，但部门间的定义往往是有较大差异的，如何让A部门就某件事的定义，与B部门对同一件事情的定义保持一致，是维护大家理解的关键。这个成果的达成，有赖于上下游部门对于各自业务形态的理解，并能够基于耦合点形成统一的参数定义与功能标准；

No.4以系统为基础的开发功能的适恰性评估

参数的统一定义，是两个功能模块或部门间提升一致性的方法。参数定义完成以后，需要把相关模块的参数、定义，放到更大的系统范畴内，测试根据整体系统的需求和目标，评估这些参数在实际运行中的适应性和效果。这包括检查参数在不同模块之间的协调性，以及在整个系统中是否能够达到预期的功能和性能。通过这种方式，可以确保各个模块之间的顺畅交互，提升整个系统的稳定性和效率。同时，这也为后续的系统优化和升级提供了坚实的基础，因为各个部分都是基于统一的参数和标准构建的。

No.5推动标准拉通并萃取协作最佳实践

项目核心目的之一，在于推动跨功能、跨模块与跨部门的系统性融合。这一目标的实现，不仅需要在技术层面实现标准的统一与流程的优化，更需关注如何在不同部门之间构建出高效且顺畅的协作模式。寻找最佳实践的方法，可以帮助伙伴们通过“以小见大”，摸索深度融合与协作模式，从而寻找类似问题最佳的解决路径。

No.6思考如何在运营中落地

所有的研讨结果，只有付诸于实际业务，才能检验策略的有效性。在组织中的落地运行，除了对过往流程的分析、对最佳路径的设定，评估改善的方向与策略方向之外。还要深度评估改进关键环节中“人”的能力。比如本文需求中提到的“节点工程师”，除了纳入流程节点管理之外，还要加强对他们的能力培养，尤其是当他们面临跨职级、跨部门、跨功能的时候，如何发挥他们的管理能力，也是他们迫切需要提升的关键能力。

当然，基于不同团队的实际需求，需要对以上的框架进行重新整理，以便更有效地推动目标达成。以上的内容也仅仅是个人的思考，针对不同需求的项目会有很大调整的空间。

对于引导师来讲，工作坊的流程设计，一定要遵循逻辑框架，先有框架后有流程，再有工具，是引导工作坊设计的基础原则。（全文完）