1 月 6 日，在 TOP100 全球软件案例研究峰会上，ONES 联合创始人兼 CTO 冯斌作了题为《大型团队高效管理的机械化原理》的演讲。
以下是冯斌当天分享的主要内容。
大型团队的技术管理问题
我们先来看大型团队在技术管理上面临的问题。
首先，我们有没有一个办法可以低成本地做出足够正确的决策？因为在研发场景下，特别是技术管理者，天天都需要做决策。这个决策可能是有关招聘，包括决定用哪个人，决定晋升哪位同事；也可能和功能或某个需求相关，包括是否需要选择某个客户，进入某个市场等。
其次，在上百人的研发团队中，所有人的工作质量如何按照预期进行下去？在大中型团队里，技术管理者的下级有经理，经理下级有一线工程师，彼此存在一定的层级关系。作为最顶层的技术管理者，没有办法直接知道每人每天的工作情况如何。
其次，如果我们定义了一些标准，但培训完以后，大家还没完全理解或者执行起来的时候不习惯，这些标准怎样才能快速落地？
最后，当我们有标准的时候，怎么让大家在工作的时候尽可能遵循标准，同时又不死板，有一定的灵活性？
在这里，我要先抛出结论：我们要基于结构化的标准和流程来做「机械化」的执行。这里的「机械化」并非贬义，而是一个中性词。
结构化标准
如何进一步理解「机械化」，我们要从专家系统和结构化标准之间的区别入手。
何谓专家系统？以招聘为例，在决定是否要录取某个研发候选人时，公司的工程师、技术负责人、HR，甚至管理层都会各抒己见，从不同的角度来表达自己的看法，看谁说服谁，最后得出一个结论——这种决策方法就叫做专家系统。
但我们发现，专家系统存在不少问题：行为经济学的不少实践证明，专家系统作出判断和决策的成功率并没有特别高，同时，专家系统经常会比较模糊，这种模糊性会让整个团队觉得不够清晰，甚至可能对有些同事来说不够公平。
相对而言，结构化标准对决策有更好的效果。
结构化量化方式，指的是我们在做决策之前，应该要先对相关事情做一些维度的分解，然后对它进行打分，通过各种手段对需要决策的对象进行量化，量化完后分高的我们可以优先选择。
这种量化的标准更容易被执行，因为我们一旦能把这些东西量化，最后甚至可以用机器去算分。一个结果化的、清晰的标准，更能产生一个公平的效果，也能为团队带来安全感，而安全感能产生多团队的驱动力。
如果我们有办法用结构化的标准去判断一个事物的方方面面，那么它会更容易被我们的数字化工具落地，一旦能落地，我们就可以很方便地去做统计、分析和预判。
决策的结构化标准
既然「机械化」执行的关键是结构化标准，那么，我们应该遵循哪些原则？
从技术管理的角度，结构化标准可以分成两类，一类是关于决策的，另外一类是关于执行的。
那么，关于决策的结构化标准是怎样的？我们在做结构化标准的时候，会列出判断一个事物的各个维度，例如画成一张雷达图，这些维度是应该要满足的一些原则。
第一个是 MECE 法则。它强调每个维度应该是相互独立的，不重复的，尽可能覆盖我们想要判断的问题。
MECE 法则，是麦肯锡咨询顾问芭芭拉·明托在《金字塔原理》中提出的一个思考工具，意思是「相互独立，完全穷尽」，也常被称为「不重叠，不遗漏」。形象地看，就像是拼图游戏，用一张张碎片拼出完整的图，如果拼得正确，最后一定是一张不多，一张不少。
MECE 法则是「结构化思维」的基本功。使用 MECE 法则时，要注意三点：谨记分解目的、避免层次混淆、借鉴成熟模型。
第二个是聚焦原则。我们到底如何落地一个好的标准？而这个标准为什么能低成本地落地？这时要考虑到「聚焦」。
「聚焦」指的是，当我们判断一个事物的时候，不要求要有非常多的维度。最关键的四到六个维度，一般就足以让我们对一个事物做出一个比较准确的判断，一旦我们求大或求全，就非常容易导致成本高、不好执行、不好培训等问题。
在很多时候，我们定了一些结构化的标准，最后却没有用。回头去看，是因为这个标准里需要判断的维度可能有二三十项，例如，在招聘过程中，我们可能要判断候选人的技术能力、沟通能力、价值观，等等，而技术能力里面又细分出很多子类别，从计算机基础，到他的专业的技术栈——这些繁杂的维度让执行变得很困难。
第三个是量化原则。当我们有了维度以后还不够，还要对每个维度进行量化，而量化就会涉及到每一个维度的打分，它的打分标准可以根据不同的情况有所区别，但是有一些方向是需要把握住的：区分度要高，要清晰，要容易衡量。
举个反例，当我们描述某人能力的时候，有时候我们会评价为良好、优秀、卓越，等等，其实，这些词都是「程度词」，无论是确定标准的人，还是执行标准的人，在这里都很难做判断，因为这些词非常模糊，每个人可能都有不一样的理解。
同时，分值不应该太多，分值如果太多的话，也会导致区分度不够高，并且大家需要思考非常多，我们一般都会采用五分制或者十分制的方式。
执行的结构化标准
说完了决策方面结构化标准的原则，我们再来看执行层面上的结构化标准是如何具体实现的。
经过 ONES 的实践，我们发现：把相关的结构化标准在工具上数字化，那么在实践使用中的效率会非常高。
首先，如果我们要真正促使行为变化，就必需内化自己的整个习惯。例如，在一个软件团队项目管理的场景中，如果我们要标准化自己的工作方式和流程，养成习惯最好的办法就是让大家在一个工具里工作，让工具告诉大家，当需求分解完以后，下一步是什么，将一系列的流程固化在整个系统里面。
其次，如果大家可以在一个数字化工具里工作，无论是做决策还是在执行流程，都可以利用工具去收集到相关的数据，并且形成一些新的结论和行动。
最后，这会是一个更公开更透明的场景，使得大家能更好地工作，因为它更有安全感。
我举个经典的例子，让大家可以更好地理解如何执行结构化标准。
「阿普加评分（Apgar Score）」，是麻醉学家阿普加 1953 年设计的一个判断新生儿是否健康的模型。他一共考虑了五个指标，分别是：肤色、心率、表情反应、肌肉张力、呼吸。
第二步，打分。给每个指标设定一个整数分数区间。比如阿普加评分中每个指标可以打 0、1 或者 2 分。像肤色，全身粉红色就是 2 分；四肢是青紫色就是 1 分；如果全身青紫就是 0 分。
第三步，计算总分。也不用加权平均了，简单相加就行。阿普加评分的满分是 10 分。那么这个判断系统规定，总分在 7 分以上就是健康；4 到 6 分就不太健康；0 到 3 分就是需要立即采取急救措施。
这是就是一种「简单易行」的结构化标准。现在医学界的很多诊断，比如一些癌症的筛查，都是使用类似的打分系统。这个方法把复杂的决定分解成了几个维度上的简单判断。它容易操作，不怎么受医生经验和水平的影响，而且因为大大减少了噪声，准确性很高。
数字化工具内嵌标准
关于用数字化工具内嵌标准，我介绍一下 ONES 的具体做法。
在 ONES Project 里，我们可以设置工作流引擎。就是当我们要去处理一个 bug 或需求的时候，到底走的是一个怎样的流程。这里我们看到有七个步骤，这七个步骤如果要人完全记下来，成本太高了。所以，我们可以通过一个数据化工具内嵌整个流程，并且在流程执行的时候用工具来提醒大家每一步需要做的事情。这样，我们的培训成本甚至是文档，都可以大大减少。
例如，在 ONES 新建任务时有很多自定义属性，它是必填的，我们可以把一些任务结构化地管理起来。
关于 ONES Wiki 的功能，这里有一个关于故障分析的模板，它比文档、比培训更加直接。数字化工具能直接给我们提供一个预置好的标准，大家在这个标准之内去工作，快速地去完成一些必要的事情。
当标准真的可以跑起来以后，我们一定要定期复盘，因为简单的标准才好执行，本质上它是在简单和有效之间做取舍，随着时间的推移和外部环境的变化，它是会有局限性的。
除此之外，我也分享一下 ONES 做技术招聘的模型，我们的模型会分成四个方面，第一个方面是专业能力，也就是技术能力。第二个方面是学习能力，第三个是思维表达能力，我们认为一个人的表达能力反映了他的思维能力是否结构化，是否够清楚，是否能聚焦到目标，第四个是思维层次，主要判断一位候选人的驱动力的来源是外部还是内部。
拿学习这个方面来讲，我们会分成 0-5 六个分值，以判断一个候选人有没有主动的学习行为，他的主动学习行为是不是碎片化的，相对于我们刚刚说的主动、坚定、优秀、良好这些词语来说，它更能通过一个特点、一个行为区分出不同的分值，在这个情况下，打分会更加简单和精准。
保证决策足够正确
最后总结一下，在大型团队的技术管理当中，我们经常要做很多决策，同时我们要保证这些决策足够正确。
其实我们不需要百分百正确，我们只需要足够正确，并且让大家在工作中可以按照一个标准来工作，保证一定的质量。
首先，机械化的标准以及流程是更有效的，运行成本是更低的。
结构化的标准和流程都应该是聚焦、清晰、简单的。当我们有这样的一些标准和流程以后，就可以很好地用数字化工具去做管理。
当每个人回到数字化的环境下去工作，自然就会 follow 我们之前定过的一些结构化标准，确保执行到位。同时，我们只需要在系统上点几个按钮，就能汇总出想要的数据，高效完成量化，这对于我们复盘改进都非常有帮助。