一场全球疫情大流行迫使各行业改变工作方式，远程工作突然被推到风口浪尖。「软件众包」这个话题伴随着远程工作的热烈讨论又重新获得关注。作为践行「众包」理念的从业人员，我想顺着这个话题聊聊对软件众包的看法，并结合行业的基本原理与实践经历，分享一些感悟。

如何众包？

软件众包服务模式虽层出不穷，但基本都可以归属于如下三种类型，我们通过了解这些模式的利弊，来简单回顾软件众包这个行业的发展。

找人模式

众包模式首先是从兼职找人的需求开始演进，从最早的猪x戒开始推行「威客」概念，通过产品或运营方式，为需求方提供人才匹配服务。从独立的兼职与自由职业者，衍生至基于专业能力的服务团队，并按照需求发布或人才匹配次数对需求方收费，这个模式我称为「找人模式」。

这个模式的服务形式非常直观，换句话说就是信息对接平台。但此模式最大的问题是没有直接解决需求方的问题。需求方的要求是「我需要解决某个问题」，找人模式给出的答案是「我提供某个资源可能会帮助解决问题」，至于是不是真的解决了，如何解决的，这些都无法被管理。

这个商业模式最大的窘境是陷入到「火车站生意」当中。你会问火车站生意是什么？我们在火车站广场上摆摊做生意，由于广场的天然人流量，只要对某些群体来说你提供的服务是刚需，他们就会产生消费行为，然而不管你提供服务的质量好坏，每个客户原则上只会消费一次。本质上来看，找人模式就是个流量生意。

让我们回到找人模式，如果你推荐给需求方的人合适，他们会倾向于线下长期与此人合作；如果推荐的人不合适，那客户也不会再次使用服务。所以，无论你推荐的人是否合适，绝大多数情况下需求方只会使用一次你的服务。

那你可能会问，如果将人才筛选审核，然后分级化，标签化，并加入用户反馈与评分机制形成服务闭环，是不是就可以产生连续售卖行为？我们看到无论是国外成熟兼职市场，或是国内较有影响力的服务对接平台，其实都具有类似的产品功能与运营策略。这里我们先不下结论，单就找人模式对于软件服务行业来看，有二个逻辑问题将会长期存在并且很难解决：

首先，平台方无法了解需求方对于人才使用的真实目的。为什么会这样？因为绝大多数情况下需求方也不能判断自己需要什么样的人，只能根据技术要求，或第三方评价等客观指标匹配，那这样是否是合适的方式？

举个例子，有人挖了一个池塘，将自然界中的雨水收集起来，并通过一套品质标准分级制度来售卖水源。但作为出售方，在售卖时并不清楚客户买水的用途是什么，而客户也只能基于出售方对于水质的描述来购买。但可能同一品质的水，有的客户用来浇花，反馈水质非常好；也有客户用来饮用，但反馈水质非常差。基于用途不同，出售方收到反馈也会完全不同。同样在软件行业中，我们常常能够看到不同团队对于角色要求描述完全一样，但实际使用时对人才的要求却完全不同，导致同一个人在不同团队中获得的评价反馈完全相反。

其次，人才不等同于商品，人才产出的效率与交付物是会受到外部环境与个人能动力而不断变化。特别是知识型工作者，这个变化造成的影响甚至大于固有能力本身。例如一名技术能力中等的工程师，在开放尊重与流程清晰的团队中发挥出来的效率，比一名技术大牛在朝令夕改与流程混乱的团队产出的效率可能还要高，所以很大程度上是否真正匹配，是需要基于供需双方互相了解并开始实践后才能得知。

你可能会问，有没有可能在做匹配前，识别不同需求方与不同人才的背景与优劣情况，然后再进行精准匹配？我的答案是可以的，但同时你有没有想过，这样将会与猎头服务一样，耗费大量人力与物力。但这个模式与猎头行业的本质又不同，双方一般为项目制或短期合作，不可能支付与猎头行业基于企业全职雇用而产生的交易费用，平台方的投入与回报将不成正比。

我认为找人模式的定位是满足一定场景下对于团队资源的补充，或作为解决一个完全独立的专业需求而存在。当然，如果你要求的交付物能够黑盒复用（什么是黑盒复用之后会讲），使用找人模式也能起到非常好的效果。例如各种设计师平台已经发展得相当不错。但作为以匹配技术为导向的工程师行业来说，非常难以作为一种盈利方式。

撮合模式

在 2014 至 2015 年间，基于商业模式创新与各新场景应用，创业氛围高涨，市场对于软件服务需求快速增长，许多中小企业或创业者希望快速构建软件产品并推广到市场。传统全职雇佣制的外包模式，与单纯的找人模式都无法规模化满足其市场需求，各类软件服务平台开始爆发性增长。平台通过悬赏报名的形式，将需求方与服务方对接起来，并结合费用托管，阶段划分等辅助的第三方服务，通过交易抽佣方式赚取利润。这个模式我称为「撮合模式」。

与找人模式相比，撮合模式最大的不同是平台方对于需求方有一定的服务保障。最初定位于解决软件服务中长尾的业务场景。以 2016 年为例，一个运营良好的软件服务平台每个月可成功撮合约 50 单左右，如果按照平均客单价格在 10 万，这样一个交易流水额当时吸引了众多企业，打造各种形式的软件众包、开发者服务、技术社群等平台来建立自己的撮合模式，一时间大批程序员、产品经理、设计师兼职平台孕育而生。

软件服务是一项专业性很强的服务行业，对服务人员的综合水平要求比较高，仅写好代码是无法满足客户需求的。但此类撮合服务能够吸引的绝大多数需求方，恰恰是缺乏软件研发认知的非行业客户，在合作过程中，客户方与服务方对需求与技术的认知会产生一定的差距，而往往是这种认知差距是导致项目失败的最大原因。

举个例子，需求方需要开发一个商城应用，服务方按照需求方提供的需求列表进行报价，双方简单沟通后就通过平台托管的形式启动项目研发过程。在实施过程中，服务方发现需求方的需求一直在蔓延，从单店铺订单演变成多店铺订单模式，这时候服务方提出变更请求，但需求方认为是服务方的专业原因导致没有了解清楚自己的业务需求，因此项目发生纠纷，这时候双方都要求平台方介入解决。

从上面这个典型例子可以看出需求方使用撮合交易的目的是期望平台对于项目进行保障，但由于软件研发管理的复杂性（之后将详细阐述），平台方作为第三方是很难确保服务方产出的结果是满足客户需求的。而交付物的质量往往需要在上线或验收时才暴露出来，这样非常容易发生三方纠纷，特别是在项目烂尾或是产品无法运营上线的情况下，平台方也无法挽回项目失败。而项目失败对于需求方业务造成的损失，可能远大于实际投入到技术开发的成本。另一方面，服务方也面临项目范围超出，变更频繁，业务需求不合理等原因，让平台方无法同时保障双方利益。所以在实施过程中，撮合交易对于供需双方来说体验度都较差。

我认为平台模式最大优势是对需求方来说有随时可供匹配的资源。前提条件是需求方对于需求认知与服务方一致。由于服务方一般都是行业专家，这样就需要需求方自身提高行业认知水平。因此近年来，专业的研发团队逐渐充当其各大软件服务平台的主力需求方，而平台逐渐没落为单纯的资金托管工具，解决双方交易信任的问题。

直营模式

既然以上二种模式都无法直接有效解决需求方的痛点，很多团队选择下沉，将模式做「重」，按照甲乙方模式与需求方合作，但交付形式借鉴众包的思想，通过非雇佣或部分非雇用的组织形式构建生产能力来完成项目，并期望通过某种标准化方式，让研发环节各角色像工厂流水线一样制作软件，这个模式我称为「直营模式」。

对比传统依靠全职雇用员工的外包服务商，直营模式下的服务团队希望从研发效率上占有优势。为此，有非常多的团队基于不同纬度进行探索。

首先，形成直营模式的主要原因是基于「资源」的考虑；对于传统外包服务商来说，在客户与市场都占据一定份额的情况下，希望借助「众」的方式降低成本，提升竞争力。对于各种众包平台方来说，拓展并转型为软件服务商，在市场上将有利于获取更多高价值项目。由于每个团队背景与目标不同，拆分的实践也会有所不同。

直营模式下基于角色进行分工是最常见的行为模式，以软件研发角色来说，按照产品、设计、前后端工程师、测试来分工最为常见。是否拆分的角色都需要不同人员来担任，或者每个角色按照何种雇用方式来协作，团队都自己的实践，总的来说按照组织方式不同可以归类为二种实践方式：

一种是产品经理导向，产品经理（或设计师）为核心作为团队唯一接口人，负责产品设计范围定义，同时兼顾项目进度。将开发工作通过远程协作方式交予工程师或开发团队。由于产品经理往往侧重于对产品的打磨与业务思考，对技术可行性缺乏有效判断，对实施落地计划也缺乏把控，这种方式比较适用于小型或咨询为主导的项目。   
另一种是项目经理导向，以项目经理为核心全面统筹项目进度、范围与成本。将需求分析与产品设计的工作剥离出来，交由产品经理单独负责，同时对开发工作进行精细化管理。并安排设计、测试、技术咨询等垂直纬度的辅助角色来把控项目过程中关键节点。这种方式理论上可以实施较复杂的项目，但对项目经理的综合素质要求较高，同时多角色协同对于远程团队在沟通和组织管理上带来较大负担。

这二种实践方式的组织结构与自雇团队完全相同，只是某些角色从全职雇佣转化成按件记酬，我将这类实践方法统称为「众协」。使用众协的团队，需在人才甄选、流程标准、技术与基础架构等方面建立较完整框架。虽然人员市场性价比较高，在生产力成本控制上有较大优势，但在实际执行中，交付物的质量还达不到同级角色组成的自雇用团队。但对于一些预算有限，工期较为宽松的项目，这种形式也能够被一部分需求方所接受。

除此之外，也有团队通过代码模块外包的形式，将一段代码或一部分功能模块同步分配给众多外部工程师，通过代码提交，代码审查的方式进行协作。也有产品研发团队，基于区块链方式，将产品研发的各项工作通过币值的方法进行评估、合作与结算。

总的来说，众协的实践并没有改变团队需要协同才能产出交付物的模式，只是在单个生产力的成本，与组织流程上进行一定的优化，而希望通过众包来大规模提高研发效率的核心诉求并没有得到满足。

软件众包面临的核心问题是如何将各项工作有效的拆分，并在尽可能少产生协同成本的情况下高效率完成工作。换句话来说，众包希望解决的是如何分工的行为。

那能不能将软件研发进行分工？如何保障分工之后是有效率的？在讨论这个核心问题前，先让我们来认真思考一个概念，软件研发管理为什么那么难？

在以下章节，我们将引入软件研发中的专业概念，如果没有兴趣往下继续阅读的朋友可以跳过，直接看最后一章的结论。

研发管理为什么那么难？

首先让我们从逻辑上来看目前的软件研发管理是否合理，我们会发现在很多时候大家都是在依赖惯性思考，而不是逻辑思考来处理问题。管理软件研发这么难的主要原因，是我们惯性参考已有的管理实践与方法，而这种管理模式跟软件开发这件事情本质上不兼容。

举个例子，我们观察任何一个软件研发团队，会有这样存在二种现象：第一，在团队中存在不同的角色，或是团队与团队之间协作是按照功能模块进行划分；第二，团队中都有一个领导角色，通常是项目经理或是技术负责人。那我们来反问一下自己，为什么会是这样？

要探究这个问题会比我们想象中要复杂很多，最初亚当·斯密在《国富论》里用很长的篇幅阐述了社会分工对整个社会的意义。

例如，书中给出如果出现了社会分工，那我们就不是依赖于某一个人，而是依赖于一类角色，那我们就会从对一个人的依赖转向对一片市场的依赖，而到市场上可以找到很多同一类型的人。所以人力配置能够达到很好的效果，而整个资本社会都是建立在社会分工的基础上，一旦出现社会分工，就出现的专业化的人才，才会出现我们现在所有的工作。因此大家一定会默认为分工是好的，分工会带来效率的提升。

但如果我们仔细阅读亚当·斯密对于社会分工的描述，是有一个前提假设：通过社会工作的产出物是需要可以交换，而基于交换才能够提高效率。

所以，效率的提升并不是由于分工带来的，而是分工之后可以去交换，然后通过交换的方式，来提升整个社会配置和资源共享。

举个例子，我们去购买一个面包，其实我们不需要关心小麦是如何种，如何变成面粉，以及如何烘培成为面包，我们只要花钱就能买到。所以基于可供交换的产出物进行交换，就可以得到一个效率的提升。

因此，我们讨论分工，本质上讨论的是如何解决效率问题。而在惯性思考框架下，大家都会认为分工是提升效率的方法，但基于逻辑的思考我认为是通过分工加交换的方法，才能够提升整个的效率。

回软件开发当中来，我们很天然的思考角度和出发点是说分工可以促进专业化，促进专业化以后可以提升效率。这时候问题来了，当我们在软件行业进行分工的时候，我们是否还能基于交换去提升效率？如果我们按照逻辑来思考，而非假设分工一定能够提升效率，这个答案可能会超出很多人的想象。

这里我们需要先理解一个基本认知, 软件开发是一个构造过程，还是一个知识消费过程？

绝大多数人包括之前的我在内，对于软件开发的理解可能是错误的，如果大家没有耐心看下去，那先看我的结论：软件开发是一个知识消费过程，我们不能从生产的视角去看待整个流程。

举个软件开发很粗略的场景描述为例：客户想要做一个产品，产品经理将需求理解清楚并转化成某种形式，也就是把知识从一种形式转化成了另一种形式，然后产品经理需要将这段知识让开发人员更好的理解，所以产出了原型与设计。开发人员理解之后，会将它变成另一种可执行形式的知识，所以产出可执行的代码；然后测试人员也需要理解这个知识，把它进行很好的结合，产出测试用例与测试结果。因此将软件开发看成是一个知识不断消费与传递的过程，比将它看成一个生产的过程是更合理的方式。

如果将它看成是一个知识不断消费与传递的过程，从传统思维上来讲，我们利用分工的方法是提高了知识壁垒，知识壁垒越高效率越高，因为不需要我掌握的知识，我不需要知道将会变得非常好。但实际上是不是这样？

我们再基于同一个业务场景来看，产品经理写了一段需求，这段需求开发人员完全不了解，那我们会发现使用知识消费与传递模型来看，这段知识是完全没有办法用于消费与传递的。实际工作经验告诉我们，如果产品经理只将需求通过原型与设计作为交付物给到开发人员，开发人员几乎不可能 100% 理解并按照产品经理的要求开发出来。所以我们发现在此类业务场景下，通过提升知识壁垒而产生效率完全不成立。如果我们提升知识壁垒，告诉程序员不需要理解行业，不需要理解业务上下文，就完全按照需求人员的需求进行开发，会发现效率反而变低，因为开发人员没有办法完全了解业务人员与需求所描述的业务场景到底是什么样子。所以我们通过惯性思维来看，只有产品经理需要去理解业务，而开发人员不需要理解业务的时候，我们会发现这种方式的效率本身不是很高。

这样一来我们就会发现一个现象，传统管理的本质是通过分工去划分知识根源，提升知识壁垒来强化整个团队协作之间的效率和关系。而软件开发在逻辑上来说，本质上需要消除知识壁垒，才能达到效率的提升。

这就是为什么很多时候我们作为软件行业的管理者，会觉得管得越来越多，团队水平就越来越差，这是因为采用的是一种惯性管理实践，下意识的管理方法都是去提升知识壁垒，希望通过交换来达成效率提升的方法。

而回到软件开发的本质来思考，这种惯性的管理实践和这个行业的本质是不相符的，所以在管理上我们会面临如此多的挑战，从根本上来讲是我们思考问题的方法，本身就与我们工作的方式不吻合。

那么，回到我们对众包核心问题的思考，在软件行业我们应该如何进行分工？

如何进行分工？

通过上一节我们了解到，如果在软件开发过程中根据角色，或是社会分工的方法来划分不是一个最有效的方法，那有没有让我们效率提升的划分方法？

我认为方法是有的，其基本原则与亚当·斯密所描述的社会分工方法一样，当且仅当你的产出物可以进行交换的时候，那么分工可以带来效率的提升。

让我们换一个角度，将分工这个概念替换成知识壁垒的话，那么我们可以得到另外一个答案：当且仅当产出物可以进行交换的时候，那么提升知识壁垒可以得到效率的提升。

如果我们应用到软件行业，大家知道交换在软件开发行业类似于「黑盒复用」，什么是黑盒复用？我们先了解什么是白盒复用，白盒复用是指的知识复用，指的是我需要打开这个盒子，了解里面结构与构造，并理解里面的知识，才能够去复用这样的一段软件和架构。而黑盒复用恰恰相反，我不需要打开这个盒子，就可以去用最终的结果和产出物。

我们将亚当·斯密完整表述中的产出物替换成黑盒的话，那我们可以在软件行业使用一样提高效率的方法，当且仅当你可以进行黑盒复用的时候，去提升知识的壁垒，会提高软件开发效率。

这个时候如果我们想通过分工进行效率的提升，首先需要看能不能在团队和模块之间，找到黑盒复用的知识背景，然后切分就会得到一个效率的提升。换句话说，我们要求的是完全不需要关心是如何做，只是去利用一个产出物，才会得到一个最终效率提升的结果。

举个实际的例子，当我们将一个软件开发项目分成前、中、后，或者基于传统意义上的分成数据库、中间业务逻辑、前台展示和业务流程的话，我们会发现业务逻辑层对于数据库层，相互间无法做到黑盒复用，那么如果去强化相互的知识壁垒和边界的时候，并不能提高效率。

源于20年前的软件开发实践，为什么都强调的是端到端交付？就是因为意识到业务逻辑层和数据库层实际上是同一个知识边界，所以应该沿着知识边界去划分团队。在同样一个知识上下文当中，团队会变成一个全功能端到端的团队。

例如，A 业务逻辑上下文和 B 业务逻辑上下文是否可以切分成二个团队，将这二个团队都变成全功能。这样端到端的方法为整体软件开发的响应速度和交付节奏带来提升，那么实际上就符合刚才所述，只有在知识边界的地方去强化隔离和复用，才能带来真正的效率提升。

对于传统的敏捷交付来说，需要端到端交付而不要在中间切开是一个共识，而前后端分离是一个反模式。在端到端交付之前，我们通常会看到有前端团队，中间件团队，数据库团队等各种形式的团队。但为什么我们会看到在近些年开始，前后端分离从不提倡，到逐渐又提倡起来？

如果我们看到传统的前后端分离，它是将一个明确的知识边界强行切开了，那么切开之后的结果是虽然分成了二个团队，但团队之间的信息需要同步，所以带来很多同步的成本。那被拆分出来的软件也没有办法被独立交付出去，因为他们完全依赖与其他团队同步的更新，需要在二个团队中同步一下交付的时间点，这样就造成很多困扰。那所谓的端到端并不一定是需要在软件架构上进行，而是在一个知识上下文体系中，从端到端是被提倡的做法。

再来看近年来很火的微服务概念，实际上会发现它本质上实现了按照业务的上下文，划分端到端的方法来划分了团队，团队之间通过黑盒复用。目前微服务已经成为了基础的架构风格并促进了软件生态系统，基于它去做其他各种各样的东西，例如中台服务都会变得很好。

但经常会有客户问一个问题，项目的微服务到底应该如何划分？

我目前看到结果和方法也是各式各样，按照领域、功能、业务上下文等方式的都有。我认为实际上微服务的划分，仍需要按照一个知识边界内去划分出来，效率才能提升。如果不在一个知识上下文内，或者强行将一个知识上下文拆分成几个区域，那得到的仍然是解耦合的方式，仍然是白盒彼此之间有复用能力团队，而得不到微服务划分好处和优势，反而会由于服务治理的复杂性带来效率的降低。

从目前的软件发展趋势上来看，我们现在实际已经形成了二个比较明确的端到端的知识边界。

一个是围绕着微服务所发展起来的后台技术，后台技术已经不是单纯的是中间件和数据库表，如果微服务做的好，那微服务代表的是一个团队或者是企业的能力，微服务本身是一个生命周期更长的业务范围，换句话说，它自己本身就是一个知识边界。它可能会伴随团队或是企业相当长的一段时间，而项目的业务流程与用户体验，会随着时间变化产生不一样的影响，而能力本身会变得相当固化与稳定。如果以能力为核心去构建微服务的话，那在后台会形成一个明确并闭环的知识边界，那微服务本身在交付的时候就是一个端到端的交付。

而我们将传统的，包括之前在服务器端的逻辑，与页面跳转逻辑通过 BFF 放到前端，那么在前端又存在了一个典型的端到端的范围。当我们将新的前后端分离作为一个推荐的实践，以能力为单位进行微服务构建，那在这个时候我们已经出现了明确的，由不一样的知识上下文组成的边界，那就可以进一步的推进它去解耦，得到一个更好的最佳实践。

在实际应用过程中，很多团队与公司认为他们做的是前后端分离，也就是沿着企业的能力、业务流程与用户体验去划分的交付，但实际上还是在同一个大上下文中去做的拆分，所以仍然面临较大的问题。造成这个原因并不是由于方法有问题，而是在使用这个方法的时候，是否寻找得到正确的知识边界。对于知识工作者来说，如果我们能够找到合理的知识上下文去区分边界的话，那我们永远能够找到更好的方式提升效率。

举个更好的例子，前端的 UI Components 在知识边界上出现了二个不同的边界的划分，一个是对于 Data 的表述，一个是 User Interaction 的表述。当之前二个混在一起的时候，我们需要将这二个放到一起去交付。但我们发现能够找到一种方式，使得 Data 的表述形成一个相对封闭的知识上下文边界，只要按照这个规矩来表述 Data，我们就可以将 User Interaction 从知识边界中分离，这样我们又得到了效率的提升。所以为什么在现在的前端实践中，应用成熟的 UI 组件进行开发变成了标配。

因此在行业中帮助我们进行效率的提升，是因为我们找到了合适的知识边界，当我们沿着这个知识边界去切分的时候，我们就可以得到效率的提升。而相反的是，如果在一个知识上下文体系中强行分割，无论是通过角色，团队，功能模块的维度，只能增加团队之间同步的成本，而无法得到显而易见效率的提升。本质上来说，效率的提升与在背后采取的原则相关性更大，而对于所采取的行为方式或是技术能力，关系并不是很大。

如果我们仍然按照逻辑来思考，当划分出服务之后，是否促进了黑盒复用？如果划分的方法仍然存在白盒复用，我指的这个白盒复用不仅仅是白盒的复用，甚至有交付节奏的白盒，有修改内容的传播，我们都可以认为不是纯黑盒的情况下来说，这样的微服务划分方案，带来的效率可能都不高。那如何在本质上来提升知识工作者的效率？

如何提高效率？

当我们认识到在管理知识工作者的过程中，沿着知识边界来进行切割并形成黑盒复用可以提升效率。但在实际的应用过程中，绝大多数情况下团队都是在同一个知识体系上下文中进行工作，那么在知识边界内如何能够提高效率？

我们已经了解到在知识边界内，需要消除知识壁垒才可以提高效率。但我们经常会问，知识工作者的效率是啥？彼得·德鲁克讲的很好，对于知识工作者的管理难点是因为我们很难区分工作的有效性和效率。

举个例子，没有任何一个团队会根据产品经理一天能够画出多少个原型页面来作为效率判断的依据。因为产品经理可以很容易的画出一百张没有人能够理解的页面，对产品经理来说这不是效率，只是在浪费时间。那我们会问产品经理的效率在什么时候才能被判断？

产品经理的效率在他产出的东西，被下游角色所消费了，只到被消费的这一刻才能够判断所产出的东西是有效还是无效。例如产品经理画出的原型界面，需要被客户与开发人员所理解并接受，才能衡量是否正确，所以知识工作者的有效性是由消费侧来决定。

因此对于知识工作者我们先要判断 0 与 1 的问题，如果工作是没有效果的，那就是 0，效率再高也没有用。如果工作本身有效果，才会判断效率高低。知识工作者的有效性判断是依从于协同效果，所谓的协同效果就是一加一要大于二，那如何做到？

当团队有着共同的知识背景与知识体系的时候，才可以产生协同效应。所以从团队的角度来思考什么是效率的时候，我们的出发点本身就不能以产出作为度量，而应该是以消费的项目作为一个整体度量的效果，这也是在做管理的时候大家通常不会去思考的问题。因为我们通常会把软件构造的过程，想象是在构造房子，但本质上软件开发与构造房子完全不同，实际上它真正的过程，是一个知识被消费而且被传递的过程。

在这个过程中，我们应该以知识被消费的效率来代替最终结果产生的多少，来评定是有效还是没效。所以在团队内我们对于效果的度量和判断，要采用完全不同的标准和视角才能真正理解到底什么是效率。

那我们来看一下传统的管理度量是什么？从科学管理理论的角度来看，工作的产出物，工作内容与工作时间是管理的三个维度。

科学管理之父泰勒告诉我们，管理工作的产出物是不可能的，工作产出物也是无法被直接管理的，所以在做管理时，着重的是在管理工作内容和工作时间。

举个例子，如果让工人一天搬 300 根木头，但如果工人告诉你说做不到，那你就没有办法反驳。所以抛弃直接管理工作结果的方式，绝大多数管理者管理的是工作内容与工作时间。那么该如何管理？

泰勒又告诉我们，科学的管理方法是将工作内容和工作时间结合。那我们还是引用之前这个例子，目标还是让工人一天搬 300 根木头，但是告诉工人，用什么样的方式去搬，搬多少根就需要休息，休息多久再继续搬等，要求工人按照这样的工作内容，以及持续的工作时间，就可以达到目标的工作结果。所以一线的项目管理者，通常会着重管理工作内容和工作时间。

但在知识型管理上，我们会发现以上三项完全都失效了。

我们先来看产出物管理，基于我们对知识工作者效率的认知，能够知道直接管理产出物是非常困难的，因为我们很难去管理知识的消费过程，那所以我们也很难管理知识的产出物。

那我们又来看工作内容，知识型工作者的工作内容非常有趣。这里有一个特点，当知识型工作者开始动手来做时，他绝大部分的工作内容，或者工作的核心难点都已经完成了。

例如程序员在开始写代码时，在头脑中对架构的框架已经思考的差不多了；设计师在开始做设计时，已经有了构思和风格样式。换句话说，知识型工作者的有效性工作在管理者能够观察到之前，基本已经做完，所以外在的观察是无法判断工作进入到了哪个阶段。

由于知识工作成果的有效性是依靠消费来验证，所以非常难以及时判断。例如，开发工程师写了一串代码，什么时候这串代码才会被证明是有效的？这串代码需要被集成到代码库中，得到了用户反馈，并且之后上线产生了真正的业务价值，这时候我们才能真正判断是有用还是没用。

但是这样一来，我们能够得到的反馈周期将会变得非常长，如果我们完全依赖于这样节奏去管理项目的话，那我们的管理节奏将基于月或者年为单位，放在当代的管理思路下是完全不能被接受。

再举一个例子，程序员在发呆，但你没有办法去判断他是否目前在工作。当然，我们也有部分的方法将隐性的工作内容显性出来，例如要求团队在做开发的时候先做任务的分解，实际上这是一种工作内容的管理。但一般来说，对于较低水平的知识工作者，可以基于这样的方式来管理工作内容，而对于高水平的知识工作者来说，例如需要得到解决方案，或创新的产品设计来说，这种管理内容的方式也无法奏效。

因此，在软件行业中工作内容和工作的产出物都无法有效管理的情况下，管理工作时间成为了管理者唯一的管理手段。本质上来说，对于知识工作者的管理需要新的实践、新的角度、新的视野来探索，而目前的管理思路还是沿用了对于传统体力工作者的管理方法，所以我们常常能够看到互联网企业的 996 常态化，或是在项目上我们常常以人力工时的方式进行计算与核算。这并不能够说明管理者管理水平的低下，而是管理知识型工作者目前就是缺乏有效的思路。

那我们会问，是否就没有方法来有效管理知识工作者了？

我认为答案是否定的，如果我们对于产出物和工作内容没有办法进行直接的管理，那需要思考有什么替代品能够被管理，或者说通过某种锚定物能够间接的，或是更好的达到管理产出物的目的。

我们来看产出物，在软件行业中我们实际管控的是什么？我们管控的是反馈周期，如果我们已经明白软件研发是一个消费过程。那作为一线的管理者来说，可以将所有需要管理的因素看成是需要被消费的层级与周期。

例如，当开发人员写完了一段代码，当代码被成功集成到代码库中，可以看成是对这段代码的知识消费。当完成自动化测试时，至少能证明一点，这段代码对于项目之前的代码来说是没有造成破坏，同时已经消费了这段代码带来的新功能。当测试人员对于这段代码进行逻辑验证，并且逻辑验证完成时，我们认为团队完成了一次完整的知识消费，这代表着产品经理所规划出来的功能，开发人员对它进行了二次消费，且管理者认为这个消费是对的。最后客户验收成功，项目成功上线，产生实际效果，可以看成是客户对于我们知识消费的肯定。

当我们将每一次这样的反馈当作知识的消费去看待，那这样一来，如果我们能够更快的促进知识的消费周期，换句话来说，如果我们能够缩短知识被消费的时间，就可以来判断结果是否是有效的。

所以我们看到所谓的互联网开发模式本质上，就是利用各种方式进行无限的端到端交付的加速，基于团队所产生的一段代码，到最终被消费并证明它有效性的过程。

因此我们看到很多开发实践，例如不做测试，直接在生产环境上去测。例如 DevOps, 互联网厂商要求一段代码的修改，在数小时或者更短的时间内就必须部署到生产环境等，所追求的都是一个原则，需要追求对产出物的管理。之前的问题是反馈周期长，那就通过各种手段无限缩短反馈周期。所以在行业中我们会看到，有些团队抛开对内容的管理，直接进行产出物管理，如果我们按照这个方式去管理，那得到的就会是一个互联网研发管理模式。

同时在实际运用中会看到，这种研发管理模式与业务是有很强相关性的，有些业务就算是再缩短研发反馈周期，它的实际反馈周期还是很长。我们应该如何管理？这样我们就需要同时对工作内容进行管理，既然是知识工作者，那么我们就需要将工作内容的管理，转成对团队成员胜任能力与学习能力的管理。

例如，我们认为团队成员不停的学习，不断的胜任工作的要求，那么团队成员的工作内容与工作方式就会发生变化，也就是既然我无法管理在团队成员头脑里发生的东西，我就不停的告诉团队成员我认为有效的工作和学习方法，并基于这个方法产出胜任力与学习的计划，通过这样将团队变得越来越有效率。

所以我们看到通过以上二种替代，一种是对于消费周期的管理来代替工作产出物的管理。另一种是通过对团队胜任力和学习能力的管理来代替对工作内容的管理，结合仍然不变的时间管理。使用一个新的管理三角代替原有的内容，产出物与时间。这时候会发现我们将获得更多的操作与管理的空间。

软件众包何去何从？

我们现在可以得出结论，软件的研发过程是一个知识被消费而且被传递的过程，而提高软件研发效率的协作方法有二种，一种服务于知识边界之间，通过划分知识边界来提升知识壁垒，产生黑盒交换。另一种服务于知识边界内，基于同一个知识上下文体系内进行协作，并努力消除知识壁垒。

最初我们讨论众包，很大一部分原因是对于软件研发过程的错误认知，希望通过工厂化的模式来构建软件而提出的一种解决方式。

在最初的实践中，我们仍然依靠惯性的管理方法，基于同一个知识上下文来进行角色或模块的拆分，但这样并没有收到良好的效果，反而增加了我们的管理与控制成本。而对于软件服务企业来说，全职雇用的方式又无法带来有效的市场竞争力，似乎众包这种方式又是提高竞争力的救命稻草。

在软件行业诞生以来，大家都在通过不同的方式，无论在思想上，组织上或是技术上进行了大量的创新与创造，但目前并没有改变一个事实，软件研发是一项基于手工艺方式的创造性工作。你可能会产生疑问，我们不是定义了软件工程学，定义了各种规模化软件研发实践的方法论吗？我们需要认清楚，这些只是实施的手段。本质上软件开发是一个知识工作，不是完全目标导向，所以知识工作的管理本质是为了培养互相协作的土壤，并进行赋能，而交付出来的结果与产生的价值只是这个过程的副产品。

如果一个企业和团队需要提高研发效率，那么必须同时具备能划分出知识边界进行黑盒复用的方法，和提升知识边界之内协作的手段，而众包服务并不是一个商业模式，只是提升效率的方法之一。

那么具体应该如何提升软件开发的效率？

其实我们看到很多团队与企业在实际过程中已经运用到了很多。例如，我们观察一些互联网公司的工程师招聘要求，会发现绝大多数岗位实际要求具备全栈的能力，即使要求是一个后端开发，但也要求他对前端有所涉猎。招募测试岗位，也要求最好能够有编写代码的能力。

同时，我们也越来越感觉到行业对 DDD 有更多的重视，大家开始理解 DDD 到底讲的是什么，DDD 在强调说我们应该用统一的语言，其实就是在说我们应该要有一个公共交流和消费知识的语言体系。我们应该彼此更好的去理解与了解对方的知识背景和上下文，从而更好的去促进知识的消费，所以在一个知识体系上下文中，大家努力的在消除知识壁垒，希望得到效率的提升。

我们也看到通过微服务，云原生的实践，行业对于前后端的理解发生了截然不同的变化，现在的前后端更多会依照知识边界进行裁剪，例如 BFF 加微服务的模式，希望通过黑盒交换促进效率的提升。

另外，随着 DevOps 与各种工程化实践的运用，研发团队对于消费周期的管理越来越强。同时在选人，用人时更加注重对于学习能力的考察与胜任力的培养，在项目管理时更多的去管理约束而非管理问题。这些方式都非常有益于团队内部效率的提升。

未来的发展趋势会是什么？

在未来，我判断软件众包有如下几个趋势：

首先，我们应该认识到，人才本质上是不可复制的稀缺资源，优秀的人才不是韭菜，割了一茬马上就有，而是需要大量时间培养的高成本低概率物种。所以在有可能的情况下，尽量招最优秀的人，其实是一个软件研发企业提高效率的最优解。

但在实际过程中，不可能所有企业都有能力招募到最优秀的人才，但不妨碍企业去寻找最适合自己要求的人才。尽管我认为找人模式不能作为一个盈利模式，但团队与企业的刚需是存在的，基于找人或人才匹配的服务市场将会一直持续下去。由供需双方互相判断是否彼此合适，而基于各种线上协作工具与专业社区，建立远程协作的信任成本将会越来越低。

此外，软件行业的「混沌市场」也将长期存在，什么是混沌市场？指的是由非专业 IT 需求方产生的长尾软件需求。这部分需求方虽然无法真正像 B 端客户那样产生连续性的消费。由于新的需求方不断加入，这类需求会一拨又一拨的持续出现，我将这种特性的需求侧称为「混沌的需求」。

参与到供给的行业从业者出于兼职，或是以提升技能为目的，在基于个人效率不变的情况下，愿意以低于市场雇用的价格方式履行服务。但这类的服务人员提供的服务通常是无法长期持续的，由于具有庞大的从业者基数，即使既有的服务人员会退出，但源源不断的从业者愿意参与进来，承担这种短期服务价值，我将这种特性的供给侧称为「混沌的供给」。

基于直营模式的众协实践实际上是将混沌市场上的供需两侧连接起来，通过远程工作模式，在混沌市场中发挥一定的作用。

那么真正意义上可以基于分工而大范围提升软件研发效率的方式，将通过微服务, 云原生等技术手段，并结合互联网研发管理模式，运用到 B 端客户的中大型项目中，为团队效率带来提升空间。但由于成本与软件复杂度的原因，此类方式并不是混沌市场的最优解，随着混沌市场上的供给方对无代码、低代码方案与 BasS 服务的应用，将逐步提升需求方的满意度。

我们可以观察到，在软件行业中只要能够划分出知识边界，并做到黑盒交换，那么众包模式就可以应用到每个企业。

而传统上我们习惯将众包模式，与企业和个人是否产生雇用行为挂钩，我认为已经不再受制于此类局限，自雇用团队内部也完全可以利用众包的方式。

因此，我们应该将软件众包定义为如何进行黑盒交换的方法论，随着当前客观因素对远程办公的推动，更好的利用软件众包模式将成为企业提高效率的必修课。

后记

在文章发布后，有几位朋友问到：现在的众包模式是不是不好，研发团队还是要回到自雇佣团队的组织形式？

在这里我先分享一下我的观点：组织形式是由业务需求决定，而非研发效率。当我们认识到提升研发效率的方法有二种，分别来自于知识边界内需要消除知识壁垒的协作，与知识边界外需要提高知识壁垒时，那么传统自雇佣团队会意识到还有另一种手段可以通过划分知识上下文边界，提高知识壁垒来提升团队效率，那他们可以去追求能同时使用知识边界内外二种方式的条件，只要团队总体效率比之前有提升就是有益的。

对于我之前描述的混沌市场，面对成本导向性的需求，众协实践或是传统自雇佣团队已经能够满足当下需求方的诉求，那也没有必要因为需要使用黑盒复用，而去追求理想的众包模式场景。这二种提高研发效率的方法并不冲突，团队可以只使用其中一种，或是有条件叠加使用二种方式都可以。

因此，我认为是否需要改变既有的组织关系，更多的是取决于团队面对的市场与业务诉求，与效率相关性不大。在已认知的技术实践与组织管理中，软件研发没有银弹解决方案，是所有行业从业者必须认清的事实。

关于此文

本文首发于公众号“岛主聊 IT：软件众包是伪命题吗？”， 其中部分章节引用 TW “八叉说”的内容，谦虚说也不是 100% 原创。但对于远程和众包这些事情，岛主倒是有自己的见解。

文章发布后，电鸭社区共建者在公众号留言询问是否可以转载，但由于后台回复时间限制，没有办法获取这位伙伴的微信，最近有时间索性自己发布过来，也算是为社区共建做一些贡献。

如果其他伙伴需要转载或分享到其他媒体，请先联系岛主。