项目管理与群体智慧

 知识的诅咒（The Curse of Knowledge），通俗的说是指我们一旦知道了某事，就无法想象这件事在未知者眼中的样子。当我们把自己知道的知识解释给别人的时候，因为信息的不对等，我们很难把自己知道的完完全全给对方解释清楚。是我们拥有的知识“诅咒”了我们。为什么会出现知识的诅咒这种现象呢? 我认为是人类集体的智慧和文明经过数千年的进化,积累了如海洋一般无限量的知识，但是人类单颗大脑的容量和信息处理能力是有限的，每个人经过多年的教育和工作经历之后，都只能获得人类知识库的一小部分知识，一旦你成为一个领域的专家，在其他领域就很难再成为专家。举个很常见的例子，大家去医院看病的时候，疑难杂症通常会由多个科室的专家会诊之后才能做出比较精确的诊断，就是这个道理。人类文明的伟大之处，就在于这种群体智慧的力量，单个个体的体力和脑力有限，但是一旦形成协作之后力量就会非常强大，能完成工作量和难度巨大的工程活动。“知识的诅咒”会给人类的协作带来很多的困难，因为每个个体都只有局部的知识和信息，如何从全局的角度做顶层设计和正确决策就是一个困难的问题。

     软件项目研发活动不同于其他工业工程,是人类历史上最为复杂的技术密集,知识密集和智力密集型工程活动,不同于盖楼、修铁路、桥梁这类体力密集型的工程，研发一个大型软件项目需要成百上千知识工作者的分工协作共同完成，一个软件项目所处理问题的复杂性之高，所涉及的知识面之广，已经不是几个会写代码的工程师就可以解决的问题。以现在大家热谈的中台战略为例，在实施的过程中失败的案例比比皆是，就是因为中台的本质是企业级的整体设计，一个用户视角的完整应用，涉及上百个技术组件，需要成百上千业务人员、架构师、研发人员之间的沟通和协作才能够完成，整个企业的业务人员、技术研发人员会成为一个整体，协作的范围和复杂度远远超过了原来单体时代的项目。现实情况往往是懂业务的不懂技术，懂一个业务领域的不懂另一个业务领域，从业务人员到技术人员之间、不同项目组的技术人员之间都有巨大的信息鸿沟。一方面，软件项目的规模之大、难度和复杂性之高需要成千上万不同领域之间的专家、业务人员和技术人员的协作和集体智慧才能完成，另一方面，“知识的诅咒”现象会给项目的进行带来很大的困难。项目过程中的很多问题都直接或者间接和这个现象有关的。举几个项目过程中常见的问题:

     问题一、业务与产品、开发之间的沟通问题

     业务人员、产品人员和开发经常是各说各话，产品设计人员经常吐糟开发人员做的太慢或者做出来功能的不是自己设计的效果，开发人员回怼说产品人员设计的功能太理想不能实现。出现这个现象是因为产品人员设计的原型或者效果图是从用户的业务需求和最终效果来考虑的，是一个主观的设计过程，往往会忽略技术原理、实现的细节等过程性因素，而开发人员是从客观的技术可行性、实现过程等角度考虑，业务人员纯主观的设计和技术人员客观的思维方式两者之间本身就是存在矛盾的。

     问题二、始终如“一”的项目管理

     这个在软件工程领域的专业术语叫验证和确认(Verification and Validation)。通俗来讲，就是最终实现做出来的软件功能要和最开始的需求、设计目标、约束等保持一致,也经常被大家叫做以始为终或者以终为始。在一个项目研发团队中，需求分析人员的职责在于调研客户需求，建立清晰的需求规格及软件蓝图(原型或功能设计说明书)，开发人员的职责在于设计和实现蓝图，测试人员的职责在于验证系统的实现是否和需求人员的蓝图是一致的。这种角色分工模式带来的一个问题是前一个角色的输出作为后一个环节的输入时出现偏差，经过众多研发测试环节之后最终实现的系统偏离了设计预期以及客户的需求。现代软件工程为了解决这个问题发明出各种各样的方法来解决这个问题，从若干年前的UML建模到近年流行的DDD(领域驱动设计),BDD(行为驱动设计)、软件形式化方法等等,目标都是如何清晰准确的对客观世界建模定义软件的功能和预期行为，帮助不同角色共同分析复杂业务模型、建立业务全貌和统一的沟通语言，减少信息在不同角色传输的损益。测试领域的TDD(测试驱动开发)、实例化需求等方法，目标是让测试的输入和需求阶段的输出保持一致。除此之外，还有项目管理常用的需求追溯矩阵、全流程审计等方法，都是为了实现这个目标。然而在现实的研发管理中，实现始终如一这个目标仍然是一个困难的问题。

      问题三、问题定位排查过程

     生产出现问题的时候，拉上一波研发人员排查定位问题，往往会出现从头开始兜了一圈还是没有定位，在复杂的单体项目，一个系统的整体功能是由若干子系统完成的，每个子系统又分为若干模块，子模块，出现问题的时候只能从头开始逐步缩小搜索范围, 定位问题的系统, 子系统，模块，子模块等。在当前中台和分布式架构盛行的时代，问题的定位和排查更是一个困难的问题，用户视角的一个完整功能，可能会调用数十个组件的服务，虽然有链路追踪系统的辅助定位，问题的定位仍然是一个十分麻烦的问题，动辄几十甚至上百人如热锅上的蚂蚁一样手忙脚乱的排查问题更是家常便饭，经历过的同学肯定都会心有余悸。其原因就是每个个体都只了解整个系统的一部分知识，只有把每个个体所掌握的知识和信息整合起来才能掌握系统的全貌。

     问题四、项目经理的决策过程

    由于每个个体都只具备一部分知识和信息，项目经理作为项目全局的决策者，要做出正确的决策是一件非常不容易的事情，需要具备和掌握正确的思维方式才能够做到。然而什么是正确的思维方式是个见仁见智的问题，因为每个人的思维方式和观点都是不同的(个人认为大概有如下几个方面，正确的思维方式应该具备以下几个方面，全局性、客观性、动态性、开放性等，以后作者将专门就这个话题进行探讨)。项目经理的决策过程，通常要以大量其它角色提供的信息为基础，综合集成判断之后才能做出，由于每个个体的水平是非常参差不齐的，如何保证其他角色提供的信息正确客观是个非常困难的问题。一旦项目经理的信息输入出了问题或者项目经理的决策模型出了问题做出错误的决策，后果将非常严重。当年的723动车事故，以及多架波音飞机坠机的事故等等都是活生生的实例，当系统的规模和复杂性达到一定程度，项目经理如果不能做出正确的决策就会给正常的生产和生活带来巨大的损害。

     从上面的问题我们可以看到虽然每个个体都有局部的知识和信息，在项目经理的统一调度和管理下形成协作和分工，就能研发完成规模巨大精密运行的产品和系统(虽然过程充满了混沌和曲折)，从这点来看，和指挥乐团演奏出华丽的乐章一样，项目管理确实也是一门艺术。

     软件行业已经越来越复杂，不仅所处理问题的复杂性大大提高，所涉及的知识面也越来越大，软件开发是比足球活动更需要团队协作的一项团体活动，软件项目管理是运用组织、流程和工具将每个大脑连接形成一个智慧共同体的过程。在此给各位读者推荐钱老的复杂巨系统方法论相关书籍，开放复杂巨系统方法论是钱老在过去数十年建立中国航空航天以及导弹体系过程中发展创立的学说以及方法论，在此理论的指导下，工程人员解决了很多巨型复杂系统的研发管理难题，对软件项目研发管理领域，同样有巨大的指导和借鉴意义。