问题：

与客户沟通时，客户提出的需求总是比较模糊，在CMMI过程改进的实践中，有没有好方法能应对，以提高沟通效率？

回答：

关于有效的需求沟通，实在是一个过于庞大的问题，在CMMI DEV版本的模型中，有对软件开发的需求问题的专门的过程域（RD），在这里我们只能尽可能简单的提供一些可行的思路。

如何提高需求沟通的效率，是一个关于怎么做的问题；提高需求沟通的效率，就是改进CMMI中的RD过程域。如今，纵观中国整个IT行业，在需求沟通的工作中，主要的问题是需求的沟通始终无法产生“效果”（而非问题描述中所说的“效率”）。

要解决“效果”的问题，首先要清楚的认识到IT研发的需求工作是非常困难的，而它的首要困难因素体现在需求源的隐藏性问题。针对这个问题，我们结合CMMI中的“优秀实践”展开来说说。

第一“我该向谁了解需求？”

大多数人都以为在需求沟通的过程中，主要的问题是双方很难互相理解对方的领域知识，或交流抽象的主题过于困难。但实际上最首要的问题是，总是找不到合适的回答者。

研发团队擅长在第一时间寻找到系统未来的使用者，即潜在用户。因为系统的用户往往是较容易被定位的，但是系统的客户以及利益干系人却多半是隐形的。后者将从系统的运行结果中再萃取出成果，但是由于他们不直接和系统接触，所以他们隐藏在后台之中。

● 但是，客户往往比用户更为重要，他们才是这个系统的最终受益者，也就是系统存在的目的。比如，财务系统的用户虽然是财务经理及出纳，但试图通过财务系统的引入，无论是为了提高工作效率，还是为了财务改革，其最终利益人都是企业高层，是企业有需要才得以引入系统进行改革。

● 同时，利益干系人，虽然不是系统存在的目的，但往往是系统跨不过去的约束。比如，对于酒店系统，与公安部门对接，并提供每日住宿者的身份清单，就是一个系统约束功能，是不得不去实现的功能。

上述两者躲藏在系统的目标背后，不易在策划阶段被发现或被深刻理解。而且，由于其专业领域知识的壁垒，或者更加高端（如企业高层的领域知识是企业管理），或者较难以接触到（如酒店系统例子中的公安部门），所以通常容易被忽视或误解。

但是，客户必定是系统存在的目的，是所有需求的源头，用户也只是衍生物而已，如果我们无法追根溯源，并且深刻理解和洞察客户的需求，就根本谈不上对需求有所把握，而对用户的理解，就多半容易断章取义。

IT研发的需求工作的第二个困难体现在领域与专业知识多样性的问题上。既然我们知道，需求工作的本质就是沟通与分析。那么沟通所需要的恰恰是最基本的互相了解。

第二与第三个要提出的问题是：

● “为了有效沟通，沟通双方需要掌握哪些对方的领域/专业知识？”

● “掌握到什么程度，才能进行基本的沟通？”

举个例子：直至今天，最优秀的财务系统的工程师或项目经理们也不敢拍着胸脯说自己是财务领域的专家，期待财务经理们理解软/硬件系统的专业知识则更是不可能的事情。可是，一套优秀的财务系统，在知识上必须要求具备如下专业知识：

● 最优秀的企业管理知识；

● 最优秀的财务管理知识；

● 最熟悉的（具体环境下的）企业工作流程；

● IT系统知识；

● 系统研发知识；

● 有效改革/进的知识。

能够同时懂得上述内容的人简直就是超人，更不用说精通了。当然，我们至少能够组成一支涵盖所有这些领域和专业知识的项目团队，但这支团队之间需要协 作而不是独立承担不同的工作，这同样意味着沟通。沟通就需要彼此之间有哪怕一丁点的对方的领域/专业知识基础，这一点在绝大多数时候都是奢谈。

知识依照形态，可以分成不同的类别：

● 专业领域知识

就财务系统来说，企业管理知识与财务知识就属于领域知识，学习这些知识必然是研发团队共同的工作之一。这也是多年流行至今领域建模所期望解决的主题（之一）。

● 环境信息

单有领域知识远远不够，再优秀的企业管理知识，如果不能嵌入在具体的企业中去看，那也只是理论。一旦嵌入到具体的企业中，就形成了当前的环境信息。 比如，企业管理知识只提供了相关的工作流程理论（比如CMMI过程管理），但是在具体企业中的工作及流程、控制及工具、组织结构是怎么样的呢？这些就是环 境信息。

● 专业服务知识

包括信息系统知识和项目管理知识等，这些并不是客/用户们的领域知识，而是专业服务工作者们的领域知识。

当然，一个需要剪头发的人肯定不用去了解理发的具体知识与工具，那是理发师的事。但是，几乎所有去美容所进行美容和护理的女士们都能对相关的专业知识、工具和最终成果进行一番热烈的讨论。

高端服务与低端服务工作的不同在于，其中包含了对解决方案的再设计过程，最终成果并不是在服务开始时就能形成共识并具备规格说明的，双方需要在服务的过程中不断的去探索和交流，依据阶段的产出进行调整。

这意味着，在高端服务工作中，客/用户不能参与到设计过程中来，那么结果（及其质量）就只能赌运气。但是如果客/用户要参与到整个设计过程中，就必须要求具备基础的专业服务知识，就像普通女士们对于美容知识的了解一样。

● 执行相关的信息

包括对于许多基础信息的理解与分享，这包括启动日期、团队构成、期望的里程碑与节点，工作与沟通形式等等。这些信息的重点并不在于知识，而在于达成共识，但是首先要有理解的基础，而理解就必须建立在双方的领域知识互相了解的基础上。

比如，如果电商客户团队要求一个关键的发布节点，研发团队能够深刻理解此次发布对于整个商业活动的关键意义所在吗？再比如，研发团队对于进度与规模的定义与衡量，是否也能被客户团队所理解，并达成共识？

如果不能互相理解，这也就解释了，大多数的里程碑会议表面上互相理解，实际上根本就是浪费时间，多数里程碑会议什么都达不成，更糟糕的是根本就不会 有讨论，好像什么问题都没有似的，但到了最终交付的日期，一切问题都会浮出水面。其根本原因在于，本应起到阶段性的监督、控制和调整作用的阶段会议，由于 双方缺乏对于解决方案及项目工作的理解的基础，所以根本就没有机会被讨论，更谈不上达成什么共识了。

● 改革/进的相关信息

但是有一种信息通常被绝大多数研发团队严重忽视！这种信息值得被独立出一种类型。

很少有人意识到，无论是一个自动化系统，一个企业ERP，还是一个电子商务系统，对于客/用户，其意义在于改革其固有的工作方式、管理流程或服务形 态，改革不是自然而然就能完成的，通常伴随着剧烈的震荡和未知。就好像大家都知道CMMI的效用，但每每我们到客户现场进行咨询时，都能听到上至研发总 监，下至程序员，对上CMMI管理过程的担心、抱怨、甚至是抵制。

“服务和被服务方，如何学会协同合作、并肩改革”这是所有IT企业的共同课题。而且，不仅是服务方，被服务方的主要成本源也来自于改革成本，而不是采购系统的成本。

上述分类中，一类是知识，一类是环境信息。关于信息，重要的不是学习，而是沟通，但是需要以专业知识为基础。而对于专业领域知识，一蹴而就是绝无可 能的，长期的培养与培训是必不可少的，更重要的是对于领域知识的学习重在实践而非理论的灌输。同时这也解释了如下两个IT行业的典型状况：

a)在IT行业，最优秀的研发人员必定是企业最宝贵的资产，所以对他们的知识培训是一种长期投资行为，这一点在CMMI的OT过程域中也有体现。因为研发人员不可能像体力工人一样经过短期培训就能基本达到工作需要。他们需要的是长期培训与培养。

b)要么与客户变成长期合作关系，要么等死。双方从互相学习，彼此了解到共同协作，直至解决问题，其周期长，其过程复杂，其投资巨大，每个第一次的 服务都是一次沟通投资，是一笔固定成本，需要在其后的长期服务中不断的被分摊和折旧。客户如果不能变为长期合作关系，那么每一笔对专业领域知识的投资都将 变成企业的无形负债，反之则变为无形资产。

当我们找到了正确的沟通人，也具备了沟通的基础知识与信息，那么其次提问就是：

● “为了顺利的展开工作，我们需要最低限度的沟通与理解的内容是什么？”

● “为了顺利的展开工作，我们需要最低限度的就哪些内容达成共识？”

与传统的理解不同，也许IT研发工作最终产出的就是一个软/硬件集成的系统，但那也只是成果的表现形式，而不是成果本身。一个再优秀的系统，如果不能被用户接受和使用，如果不能产生真正的使用价值，那么就其本身来说，越是华丽就越是失败。

同样的，在许多商业环境下，无论系统本身多么完美，功能多么完善，性能多么出众，技术多么先进，只要无法在合适的节点发布与实施，那么也是失败的，这是一个关于商业竞争的问题。

一个信息系统，无论其功效是自动化、管理还是电子商务等等，对于被服务方都是一次重大的改革/创新活动。就一次改革/创新活动来说，我们首先要沟通 并尽可能达成共识的客户需求是“系统被研发的目的及其意义”，更重要的是要研究其可能“带来的巨大价值或解决的重大问题到底是什么”。

一次研发活动所伴随的巨大的成本投入，如果不能以更加重大的收益作为回报，那么无论解决方案多么完美，都不会被客户方所认可。（所以，这就是为什么 CMMI一直所强调的——通过过程改进最大化股东效益，但是很多人仍然只把CMMI当时管理过程的工具，甚至是夹板，这样的认知不仅限制了CMMI在过程 改进中应用，也限制了CMMI为企业带来更大的价值。）至少一半的研发系统，都是根本不可能产生收益的“尝试性项目”，这些项目如果不是抱着试验的目的， 那么无论投入怎样优秀的资源，在一开始就注定会失败，这些系统的客户需求根本是不可能被了解清楚的，因为并不存在真正有价值的需求。

当然并不是“做”就一定会有“成果”，但这就好像是考试，抱着100分的心态就有可能拿80分，如果抱着60分心态，结果往往是不及格。如果对收益的预测比较小，那么得到的回报很可能刚好抵消成本。这样的投资就是划不来的。

所以需要首先理解，并基本达成共识（注意：这种共识只是一种假设）的是系统被研发的目的及价值。这是关于客户的需要及系统方向性的共识。

接下来要达成的共识是关于具体的解决方案，错误的看法是任何IT系统都有相同的理解方式。实际上，就系统的目的来说可以分为：

● 自动化（如机器人）；

● 工具（如OFFICE）；

● 管理信息系统（如ERP）；

● 电子商务。

不同目的的信息系统，就解决方案有着不同的构成。比如，自动化系统的目的是要代替人类的手工作业，重点在于利用什么样的工具，提供什么样的功能就可以彻底代替过去由人执行的手工作业。不难看出，这个命题中，要就如下信息达成共识：

● 原先的手工作业方式是什么 —— 领域知识；

● 提供的工具（软/硬件系统）是什么；

● 工具所提供的功能有哪些；

● 非功能性的需求；

● 未来，人将如何操作这些工具；

● 如何维护这些工具。

再比如，工具软件的目的并不是要代替人类的手工作业，而是要延展人类的能力。比如，更好的IDE工具并不试图代替程序员，而是让程序员具备更强的编程技能。不难看出，其重点在于沟通：

● 试图提升的能力是什么？ —— 领域知识；

● 提供哪些功能（工具系统意味着工具与功能是一体的）；

● 尤其不同的是，要分析需要何种能力的工作人员来掌握这些工具？（一把屠龙刀在猪肉脯老板那里也只是把过于锋利的杀猪刀而已），而这在自动化系统中通常就不是什么问题；

● 在具体的工作环境下，如何使用这些工具？（微软为何要提供大量的教程帮助办公人员掌握在各种环境下使用Office的技巧？）。

有限的篇幅显然不能详尽的描述不同的系统，就解决方案的各种不同，也只能抛砖引玉了。我们没有照搬CMMI中的RD条款，而是将 CMMI RD过程域中的实践与常见的软件开发过程中遇到的问题做了结合和融入。这里很重要的是，解决方案的共识依然只是一种假设，未经实际验证的假设。

在这里，研发团队将客户的内在需要转化成了一种外在需求，是关于系统的需求。

最后，我们还要就非系统性的需求进行讨论，这些客户需求并不是关于解决方案的，而是关于如何执行的，包括：项目进度、质量控制、团队协作等等。

这种“客户需求”通常是容易被沟通的，困难在于达成共识。