产研团队如何高效决策？一场技术讨论会议给出答案

“团队合作是朝着一个共同的愿景协同工作的能力，是将个人成就引向组织目标的能力，是让普通人获得非凡成绩的动力。”——安德鲁·卡内基

今日开会讨论一个技术问题，会议发起者率先发，约耗时 5 分钟对代码编译器及要讨论的问题予以描述。然而，我听得一头雾水，既抓不住重点，也理不清思路，感觉无从发力提问。于是我重新发问：

首先，明确问题背景和影响范围。原来，我们采用了一项新的技术方案，在测试过程中，发现在某些操作场景下会致使系统出错，而这些操作场景恰是业务系统的核心场景，所以必须给出解决方案。

其次，明确产生原因。通过视频会议的画笔功能，绘出产品架构示意图，阐述在集群模式下，一台服务器中的操作引发的元数据变化无法同步至另一台服务器。两台服务器间元数据不同步，进而导致系统错误。

背景和原因明晰后，接着讨论解决方案。从上到下逐一展开，不断排除选项。比如：起初面临换技术方案还是在原有技术方案上想办法的抉择，经讨论，发现换技术方案存在诸多不确定因素，所以决定在原有技术方案上想办法。但原有技术方案提供了插件（plugin）的能力，且有一些已有的插件可解决问题，不过会引入新的服务组件，增加系统复杂度。于是提出自行开发一个插件（plugin），但自行开发需进行调研，且存在走不通的风险。

于是在插件（plugin）方案之外，又提出了一个覆写代码的解决方案。此方案并非原技术方案官方提供的路线，算是个野路子，虽目前初步测试可用，但有不可预知的风险，也为将来长期维护埋下隐患。

为避免信息盲区，我特意提醒与会人员，让每个人发表观点，尤其是一直未发言的同事。大家对几个方案的优缺点进行充分讨论，并给出了更进一步的细节补充。

终于到了可以决策的时候，大家一致决定先用覆写代码的方案满足当前项目进度，并同时开展插件（plugin）的预研工作，作为长期解决方案。人力投入上先满足项目进度要求，在项目进度风险不大且人力有富裕的条件下，开展预研工作。

复盘项目伊始，为何我听完后一头雾水呢？我们可以复盘出如下经验：

首先，切勿直接从技术细节出发，而应从业务背景出发，按照业务背景介绍－》影响范围分析－》技术原因确认－》解决方案讨论－》民主决策拍板的步骤，循序渐进地展开。

其次，每个步骤之间要留有停顿，并进行反讲，确保大家理解一致后再进入下一个环节。

最后，充分听取各人意见，特别是意见已有倾向性后，不要急于结束会议，关注会场上的沉默者，给予其发言机会，往往会有额外收获。

这样讨论问题的方法，不论是团队领导者还是执行者，都要掌握、练习，在团队内培养有效决策的习惯。

最后我想请你思考一个问题：如果在讨论问题时，部分人员对某个方案存在强烈抵触情绪，应该如何处理呢？